背景

随着大模型时代的到来,许多领域都能够借助大模型提高生产效率,安全领域也不例外。本文通过实践探索了如何借助大模型提升甲方安全运营中的漏洞发现效率和漏洞修复推荐效率。

甲方安全运营过程中,不仅需要能够发现漏洞,还需要将漏洞推进给业务线修复,本文实践主要围绕,通过GPT来提高漏洞审核效率,以及漏洞推进效率而进行。

本文使用 AWVSDongTai IASTCodeQl 等工具,并整合到安全工具集成平台 QingScan 中,以便实践和测试。

项目地址:https://github.com/78778443/QingScan

一、提升白盒漏洞发现效率

现状: 白盒扫描结果中漏洞数量众多,人工审核效率低。

1.1 审核辅助提示

目前的漏洞审计仅包括数据流转和漏洞类型描述,缺乏详细的漏洞数据流转描述,导致人工审核效率低下。需要AI对具体的漏洞数据流进行描述,弥补工具仅提供漏洞类型及描述的不足。

1.2 自动判定漏洞有效性(待验证)

现有代码审计会检测出大量漏洞,人工难以完全及时审核。需要AI自动判定漏洞有效性,但面临以下挑战:

  1. 大模型的"幻觉"问题。
  2. 大模型的token长度限制问题。
  3. 漏洞链路相关代码提取准确度问题。

二、提升推进漏洞修复的效率

现状: 在推进业务线修复黑盒、灰盒和白盒漏洞之前,需要人工描述漏洞,耗时费力。以AWVS为例,每天人工仅能处理约20个漏洞。生成的描述信息直接给业务线查看,存在修复建议模糊、专业词汇过多、漏洞描述为英文等问题。

2.1 对黑盒AWVS漏洞进行AI解读

目前漏洞详情只有安全工程师能理解,业务线无法直接看懂,存在专业词汇和语言障碍。需要用AI生成中文描述,细化解释漏洞信息及修复建议。

示例描述:

{
  "id": 11,
  "parameter": "username",
  "url": "http://172.29.66.195:8888/home/public/login.php",
  "requestMethod": "POST",
  "severity": 100,
  "confidence": 10,
  "impact": null,
  "cvssScore": 581,
  "cvssVector": "AV:N/AC:M/Au:N/C:P/I:P/A:P",
  "status": "open",
  "tags": ["CWE-89", "verified", "sql_injection"],
  "issueId": "efd881ff-14d1-4d48-8cc4-fa2d41c62908",
  "requestId": "db04b846-7dec-fb62-f12d-1a152945cdae",
  "vulnerabilityType": "SQL injection",
  "proof": "-1' OR 3*2*1=6 AND 000305=000305 -- ",
  "testsPerformed": [
    "-1' OR 2+305-305-1=0+0+0+1"
  ],
  "consequences": "An attacker can use SQL injection to bypass authentication, retrieve database contents, add, modify, and delete records affecting data integrity.",
  "attackVector": "The vulnerable website includes user input directly in an SQL statement.",
  "mitigation": "Use parameterized queries to separate user input from SQL commands.",
  "references": [
    {
      "href": "https://www.acunetix.com/websitesecurity/sql-injection/",
      "rel": "SQL Injection (SQLi) - Acunetix"
    },
    {
      "href": "https://www.acunetix.com/websitesecurity/sql-injection2/",
      "rel": "Types of SQL Injection (SQLi) - Acunetix"
    }
  ],
  "requestExample": {
    "headers": {
      "Content-Type": "application/x-www-form-urlencoded",
      "X-Requested-With": "XMLHttpRequest",
      "Referer": "http://172.29.66.195:8888/home/index.php",
      "Cookie": "PHPSESSID=k6canj0fjoh2ruij7869bf3je2",
      "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
      "Accept-Encoding": "gzip,deflate",
      "Content-Length": "83",
      "Host": "172.29.66.195:8888",
      "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36",
      "Connection": "Keep-alive"
    },
    "body": "password=g00dPa%24%24w0rD&username=-1'%20OR%203*2*1=6%20AND%20000305=000305%20--%20"
  },
  "detectedBy": "/Scripts/PerScheme/Sql_Injection.script",
  "detectedAt": "2024-06-23T03:25:15Z",
  "falsePositive": false,
  "outOfScope": false,
  "duplicate": false,
  "scanId": 103
}

上面的漏洞信息缺乏大白话描述,仅限于安全工程师能看懂,此时可以使用用大模型对漏洞进行大白话描述;以下内容是大模型对漏洞具体的信息, 并细化解释到参数, 以及给出更具体的修复建议

漏洞关键信息如下:

  • 漏洞位置: 在URL http://172.29.66.195:8888/home/public/login.php 的登录接口中,通过 POST 方法提交的请求参数 username 存在漏洞。
  • 漏洞类型: SQL注入(SQL Injection),具体为CWE-89类别。
  • 影响程度: 高危,CVSS评分达到581,向量为"AV:N/AC:M/Au:N/C:P/I:P/A:P",意味着攻击者可以利用此漏洞绕过认证、检索数据库内容、增删改记录,严重影响数据完整性。
  • 如何复现: 使用测试语句 -1' OR 2+305-305-1=0+0+0+1 可以验证漏洞存在。
  • 修复建议: 采用参数化查询来隔离用户输入与SQL命令,以防止恶意输入被解释为SQL代码的一部分。具体实施时,可以使用预编译语句或ORM框架中的安全查询方法。
  • 参考链接:

    1. SQL Injection (SQLi) - Acunetix
    2. Types of SQL Injection (SQLi) - Acunetix

请立即对受影响的业务线进行修复,避免潜在的数据泄露和系统安全风险。

如上面大模型的解读,业务线可以更清晰的理解漏洞的位置,以及修复建议;相比原始的漏洞位置和漏洞类型解释,对业务线来说更有说服力。

2.2 对灰盒IAST漏洞进行AI解读

目前灰盒漏洞结果中仅有漏洞类型和数据流,描述不够清晰。以DongTai IAST检测的SQL注入漏洞为例,以下是示例JSON数据:

{
  "vulnerability": {
    "id": "vuln-12345",
    "type": "SQL Injection",
    "description": "A SQL Injection vulnerability occurs when input is improperly sanitized before being used in a SQL query.",
    "severity": "High",
    "discovered_at": "2024-06-23T12:34:56Z",
    "status": "open"
  },
  "location": {
    "file": "/var/www/html/app/controllers/UserController.php",
    "line": 42,
    "method": "getUserDetails"
  },
  "request": {
    "url": "http://example.com/api/user/details",
    "method": "POST",
    "parameters": {
      "user_id": "1 OR 1=1"
    },
    "headers": {
      "Content-Type": "application/json",
      "User-Agent": "Mozilla/5.0"
    },
    "body": "{\"user_id\":\"1 OR 1=1\"}"
  },
  "response": {
    "status_code": 200,
    "body": "{\"user\":{\"id\":1,\"name\":\"admin\"}}"
  },
  "context": {
    "database": "MySQL",
    "query": "SELECT * FROM users WHERE id = '1 OR 1=1'",
    "code_snippet": [
      {
        "line": 41,
        "code": "$userId = $_POST['user_id'];"
      },
      {
        "line": 42,
        "code": "$query = \"SELECT * FROM users WHERE id = '$userId'\";"
      },
      {
        "line": 43,
        "code": "$result = $db->query($query);"
      }
    ],
    "remediation": "Use prepared statements and parameterized queries to prevent SQL Injection."
  }
}

这个JSON数据包含了以下几个部分:

  1. vulnerability:漏洞的基本信息,包括ID、类型、描述、严重性、发现时间和状态。
  2. location:漏洞在代码中的具体位置,包括文件路径、行号和方法名。
  3. request:触发漏洞的HTTP请求信息,包括URL、请求方法、参数、头部信息和请求体。
  4. response:服务器返回的HTTP响应信息,包括状态码和响应体。
  5. context:漏洞相关的上下文信息,包括使用的数据库类型、执行的SQL查询、代码片段和建议的修复措施。

上面的IAST漏洞信息缺乏大白话描述,仅限于安全工程师能看懂,此时可以使用用大模型对漏洞进行大白话描述;以下内容是大模型对漏洞具体的信息, 并细化解释到参数, 以及给出更具体的修复建议

漏洞关键信息摘要:

  • 漏洞ID: vuln-12345
  • 类型: SQL Injection(SQL注入)
  • 严重性:
  • 发现时间:

2024-06-23T12:34:56Z

  • 状态: 开放

漏洞位置:

  • 文件: /var/www/html/app/controllers/UserController.php
  • 行号: 42
  • 方法: getUserDetails

漏洞描述:

  • SQL注入漏洞在用户输入未经过适当清理的情况下用于SQL查询时发生。攻击者可以通过特制输入来操控数据库查询,从而获取或修改数据。

请求示例:

  • URL: http://example.com/api/user/details
  • 方法: POST
  • 参数: { "user_id": "1 OR 1=1" }
  • 请求头: { "Content-Type": "application/json", "User-Agent": "Mozilla/5.0" }
  • 请求体: {"user_id":"1 OR 1=1"}

响应示例:

  • 状态码: 200
  • 响应体: {"user":{"id":1,"name":"admin"}}

代码上下文:

  • 数据库: MySQL
  • 查询: SELECT * FROM users WHERE id = '1 OR 1=1'
  • 代码片段:
// 行号 41
$userId = $_POST['user_id'];
// 行号 42
$query = "SELECT * FROM users WHERE id = '$userId'";
// 行号 43
$result = $db->query($query);

修复建议:

  • 使用预编译语句和参数化查询以防止SQL注入攻击。

如上面大模型的解读,业务线可以更清晰的理解漏洞的位置,以及修复建议;相比原始的漏洞位置和漏洞类型解释,对业务线来说更有说服力。

2.3 对白盒CodeQL漏洞进行AI解读

以CodeQL检测到的XSS漏洞为例,以下是示例JSON数据:

{
  "vulnerability": {
    "id": "vuln-67890",
    "type": "Cross-Site Scripting (XSS)",
    "description": "A XSS vulnerability occurs when input is improperly sanitized before being rendered to the user.",
    "severity": "Medium",
    "discovered_at": "2024-06-23T14:22:01Z",
    "status": "open"
  },
  "location": {
    "file": "/var/www/html/app/views/user_profile.php",
    "line": 20,
    "method": "displayUserProfile"
  },
  "request": {
    "url": "http://example.com/user/profile?user_id=<script>alert('XSS')</script>",
    "method": "GET",
    "parameters": {
      "user_id": "<script>alert('XSS')</script>"
    },
    "headers": {
      "User-Agent": "Mozilla/5.0"
    }
  },
  "response": {
    "status_code": 200,
    "body": "<html><body>User Profile: <script>alert('XSS')</script></body></html>"
  },
  "context": {
    "code_snippet": [
      {
        "line": 19,
        "code": "$userId = $_GET['user_id'];"
      },
      {
        "line": 20,
        "code": "echo \"User Profile: $userId\";"
      }
    ],
    "remediation": "Properly escape and sanitize all user input before rendering it in the HTML response."
  }
}

这些数据中有数据流的走向,但是没有关键的代码信息,因此我们需要做一次处理,将代码走向的关键信息提取出来,做出prompt词,以下是prompt词汇

审计提示:
-------------------------------
漏洞类型: py/sql-injection
文件路径: kcweb/sql_injection.py
行号: 8

漏洞描述:
This SQL query depends on a [user-provided value](1).
漏洞代码片段:

代码 kcweb/sql_injection.py 片段(行 5 到 5 ):
def show_user(request, username):

代码 kcweb/sql_injection.py 片段(行 8 到 8 ):
        cursor.execute("SELECT * FROM users WHERE username = '%s'" % username)
-------------------------------

当我将这些提示词给到大模型时,他会给我返回如下提示信息

关键信息摘要:

  • 漏洞ID: vuln-67890
  • 类型: Cross-Site Scripting (XSS)
  • 严重性:
  • 发现时间: 2024-06-23T14:22:01Z
  • 状态: 开放

漏洞位置:

  • 文件: /var/www/html/app/views/user_profile.php
  • 行号: 20
  • 方法: displayUserProfile

漏洞描述:

  • XSS漏洞在用户输入未经过适当清理的情况下直接渲染到用户的浏览器时发生。攻击者可以通过特制输入在受害者浏览器中执行恶意代码。

请求示例:

  • URL: http://example.com/user/profile?user_id=<script>alert('XSS')</script>
  • 方法: GET
  • 参数: { "user_id": "<script>alert('XSS')</script>" }
  • 请求头: { "User-Agent": "Mozilla/5.0" }

响应示例:

  • 状态码: 200
  • 响应体: <html><body>User Profile: <script>alert('XSS')</script></body></html>

代码上下文:

  • 代码片段:
// 行号 19
$userId = $_GET['user_id'];
// 行号 20
echo "User Profile: $userId";

修复建议:

  • 在将用户输入渲染到HTML响应中之前,进行适当的转义和清理。

如上面大模型的解读,业务线可以更清晰的理解漏洞的位置,以及修复建议;相比原始的漏洞位置和漏洞类型解释,对业务线来说更有说服力。

结论

通过借助大模型,可以有效提高甲方安全运营中的漏洞发现和修复效率。具体实践中,可结合AWVS、DongTai IAST、CodeQL等工具,并通过QingScan平台进行整合和应用。未来的工作将进一步验证AI在漏洞有效性判定方面的可行性,并持续优化AI对漏洞的解读和修复建议生成能力。

作者: 汤青松
日期: 2024年6月23日
微信:songboy8888

汤青松
5.2k 声望8.3k 粉丝

《PHP Web安全开发实战》 作者