声明！ 学习视频来自B站up主 **泷羽sec** 有兴趣的师傅可以关注一下，如涉及侵权马上删除文章，笔记只是方便各位师傅的学习和探讨，文章所提到的网站以及内容，只做学习交流，其他均与本人以及泷羽sec团队无关，切勿触碰法律底线，否则后果自负！！！！有兴趣的小伙伴可以点击下面连接进入b站主页[B站泷羽sec](泷羽sec的个人空间-泷羽sec个人主页-哔哩哔哩视频)

本章课程链接：burp（4）burp常见用法 以及 漏洞测试理论_哔哩哔哩_bilibili

一、proxy（代理）

工作原理

拦截请求和响应：

Burp Proxy 作为一个中间人代理，位于客户端（如浏览器）和服务器之间。当浏览器发送 HTTP/HTTPS 请求时，请求会先被发送到 Burp Proxy。它可以拦截这些请求，在发送给服务器之前查看和修改请求的内容。
同样，服务器返回的响应也会先经过 Burp Proxy，然后再转发给客户端。这使得用户可以查看和修改响应内容，观察服务器的行为以及对修改后的请求或响应的反应。

设置代理服务器：

要使用 Burp Proxy，需要在客户端（如浏览器）中配置代理设置。通常，将浏览器的代理服务器地址设置为运行 Burp Proxy 的机器的 IP 地址，端口一般是 Burp 默认监听的端口（如 8080）。这样，所有来自浏览器的 Web 请求都会被引导到 Burp Proxy。

主要功能

请求和响应查看：

查看请求详情：可以查看请求头（包括 User - Agent、Cookie、Referer 等重要信息）、请求方法（如 GET、POST 等）、请求的 URL 以及请求体（对于 POST 请求等包含数据的请求）。这有助于了解客户端向服务器发送了什么信息。
查看响应详情：能够查看响应头（例如服务器类型、缓存设置等）、响应状态码（如 200 表示成功、404 表示未找到等）和响应体。通过查看响应体，可以检查返回的 HTML、JSON 数据或者其他类型的内容是否符合预期。

请求修改和重放：

修改请求：在拦截请求后，可以修改请求中的任何部分。例如，更改请求头中的 User - Agent 字段来模拟不同的浏览器访问，或者修改 POST 请求中的数据，以测试服务器对不同输入的反应。
请求重放：可以将已经捕获的请求进行多次重放。这在测试服务器的负载能力、验证身份验证机制是否正确工作或者检查是否存在缓存问题等场景中非常有用。例如，通过快速重放多个相同的请求来观察服务器的响应时间是否会发生变化。

站点地图生成：

随着对目标网站的请求拦截和处理，Burp Proxy 可以自动生成站点地图。站点地图能够展示网站的结构，包括页面之间的链接关系、资源（如 CSS 文件、JavaScript 文件）的位置等。这有助于安全测试人员更好地理解目标网站的架构，发现隐藏的页面或者未授权访问的路径。

SSL/TLS 处理：

Burp Proxy 支持处理 SSL/TLS 加密的通信。它可以通过配置自己的证书，使得在拦截 HTTPS 请求时能够解密和查看加密的内容。这对于测试安全的 Web 应用程序至关重要，因为许多现代网站都使用 HTTPS 来保护数据传输的安全性。不过，需要注意的是，在配置过程中可能会出现浏览器警告证书不信任的情况，这是因为 Burp 的证书不是由公认的证书颁发机构颁发的。

1.代理设置

        通过设置代理，Burp 可以拦截浏览器或其他客户端发送到服务器的请求。这使得安全测试人员能够查看请求的详细信息，如请求方法（GET、POST 等）、请求头（包含重要的信息，如 User - Agent、Cookie、Referer 等）以及请求体（对于 POST 请求等含有数据的请求）。例如，在测试一个 Web 应用程序的登录功能时，可以拦截登录请求，查看用户名和密码是以何种方式（如明文、加密等）发送的。

        同样，服务器返回给客户端的响应也会被拦截。可以查看响应头（包括服务器类型、缓存设置等）、响应状态码（200 表示成功、404 表示未找到等）和响应体。以一个网页应用为例，通过查看响应体，可以检查返回的 HTML 页面是否包含预期的内容，或者查看 JSON 数据的格式和内容是否正确。

1.1burp代理设置

在burp的[代理]—[代理设置中]可以查看、修改代理端口，默认为8080端口

1.2浏览器代理设置

以火狐浏览器为例，在浏览器中点击设置—常规—下拉找到网络设置，修改代理为127.0.0.1，端口默认8080或按自定义设置。

1.2.1导入证书

在浏览器中输入：127.0.0.1:8080访问并下载证书

下载好证书后在浏览器中打开设置—隐私与安全—查看证书

点击导入证书，并找到刚刚下载的证书，点击信任后确定

2.抓放数据包

抓数据包主要是基于代理（Proxy）机制。当你将浏览器或其他应用程序的网络设置指向 Burp 的代理服务器后，所有通过该代理的网络流量都会被拦截和捕获。它就像是在客户端和服务器之间设置了一个 “中间人”，这个 “中间人” 可以查看和处理两边传递的信息

2.1抓包

在浏览器中设置好代理后，在 Burp 的 Proxy 模块中有一个 “Intercept” 按钮。点击它可以开启拦截功能。当开启拦截后，数据包会被暂停在代理处，你可以在 Burp 的界面中查看和修改数据包的内容，如修改请求头中的某个字段或者修改请求体中的数据。查看完毕后，点击 “Forward” 按钮可以放行数据包，让它继续向服务器发送。

当抓取一个网站数据时会有很多的数据包，这样意味着有很多的传参点。

拦截请求 / 响应（Intercept）
功能描述：这是抓包模块最常用的功能之一。可以通过设置拦截规则，在浏览器和目标服务器之间拦截 HTTP/HTTPS 请求和响应。当开启拦截后，请求会暂停在代理服务器（Burp）中，直到用户手动放行。在测试一个 Web 应用的登录功能时，开启拦截后，用户输入的登录账号和密码信息的请求会被拦截。测试人员可以查看这些信息是否以明文形式传输，或者修改请求中的参数（如修改用户名或密码字段）来测试系统的安全性，查看是否存在 SQL 注入、弱密码验证等漏洞。

2.1.1抓数据包

抓包后可以对数据包进行修改

2.2（drop）丢包

2.3foeward(放行)

Forward”（放行）功能主要用于将被拦截的 HTTP/HTTPS 请求或响应继续发送到目标服务器或浏览器。当开启抓包拦截后，请求会被暂停在代理服务器（Burp）处，此时 “Forward” 按钮可以让这些被拦截的内容按照正常流程继续前进。

假设在测试一个网站的用户注册功能，拦截了包含用户注册信息（如用户名、密码、邮箱等）的 POST 请求。在手动修改了请求体中的某些参数（比如尝试一些可能导致 SQL 注入的特殊字符）后，通过 “Forward” 功能将修改后的请求发送给服务器，然后观察服务器的响应，以判断是否存在安全漏洞。

        配合 Intercept（拦截）功能：“Forward” 和 “Intercept” 是相互配合的关键功能。Intercept 用于暂停请求，而 Forward 用于放行。这种组合使得测试人员可以在需要的时候仔细检查每个请求，在完成检查后，及时将请求发送出去。例如，在测试一个包含多个步骤的业务流程（如电商购物的下单 - 支付 - 发货流程）时，对于每个步骤的请求都可以先拦截，查看是否存在异常（如参数是否被正确加密等），然后使用 Forward 功能让流程继续。
        配合 HTTP History（HTTP 历史记录）功能：当请求被 Forward 后，它会被记录在 HTTP History 中。这样，在后续的测试过程中，可以方便地从历史记录中找到之前已经放行的请求进行回顾和进一步分析。例如，如果在之前的某个请求放行后，服务器返回了一个异常的响应状态码，就可以从 HTTP History 中调出该请求，重新检查请求的内容，或者使用其他工具（如 Repeater）对其进行重放测试。

3.Http history（历史记录）

保存抓过的数据包，在日志中可以筛选想要显示的内容，也可以设置高亮显示。

HTTP History 是一个存储所有经过代理服务器的 HTTP/HTTPS 请求和响应信息的仓库。它详细记录了每个请求 - 响应交互的各种关键信息，包括请求的时间戳、请求方法（如 GET、POST、PUT 等）、请求的 URL 地址、请求头（如 User - Agent、Content - Type 等）、请求体（对于 POST 等有请求体的请求），以及对应的响应状态码（如 200 OK、404 Not Found 等）、响应头和响应体。当测试一个网站的登录功能时，所有与登录相关的请求（包括获取登录页面、提交登录信息等）都会被记录在 HTTP History 中。这就像是一个详细的日志，记录了客户端与服务器之间的通信历史，方便后续随时查看和分析。

数据包

信息查看和检索功能
详细查看：可以通过双击 HTTP History 中的某一个记录条目来查看该请求 - 响应对的详细内容。在查看窗口中，可以方便地在请求和响应部分之间切换，查看每一个具体的头信息字段和内容，以及请求体和响应体中的数据。例如，在查看一个包含文件上传的请求时，可以详细查看请求头中关于文件类型、大小等的描述，以及请求体中文件的二进制数据或编码后的内容。
筛选和排序：HTTP History 提供了强大的筛选和排序功能，以帮助测试人员快速定位特定类型的请求或响应。可以根据请求方法（如只查看 GET 请求）、响应状态码（如只查看返回 404 的请求）、域名、URL 路径、包含特定头信息（如包含特定的 Cookie 头）等来进行筛选。同时，也可以按照时间顺序（升序或降序）、请求方法字母顺序等进行排序。例如，在一个大型网站的测试中，想要快速找到所有返回 500 错误状态码的请求，就可以通过筛选功能轻松实现。
漏洞发现辅助：通过查看 HTTP History，可以发现许多潜在的安全漏洞线索。例如，如果在历史记录中发现某个请求的响应体中包含了敏感信息（如数据库查询错误信息，其中可能暴露了数据库结构或查询语句），这可能提示存在信息泄露漏洞。或者，如果看到一个 POST 请求的响应状态码是 302 Found，并且重定向的目标 URL 看起来可疑，可能涉及到开放重定向漏洞。
请求重放和验证：从 HTTP History 中选择一个请求，可以方便地将其发送到其他 Burp 工具（如 Repeater）进行重放。这在验证潜在漏洞或者测试不同参数修改后的效果时非常有用。例如，发现一个可能存在 SQL 注入的请求，将其重放到 Repeater 工具中，然后修改其中的参数进行多次发送，观察服务器的响应，以确定是否真的存在 SQL 注入漏洞。
与其他模块协同工作
与 Target 模块配合：HTTP History 中的请求可以根据其所属的目标（在 Target 模块中定义）进行分类查看。这有助于在对多个目标网站进行测试时，保持条理清晰。例如，在同时测试一个主网站和它的多个子域名时，通过 Target 模块的分类，HTTP History 中的记录会相应地按照不同的目标进行划分，方便分别对每个目标进行深入分析。
与Intruder 模块关联：可以从 HTTP History 中选择合适的请求作为 Intruder 模块攻击的基础。例如，选择一个包含用户输入参数的请求，将其发送到 Intruder 模块，然后通过设置合适的攻击载荷（Payloads）来测试该参数是否容易受到攻击，如暴力破解密码、SQL 注入攻击等。

数据包-请求

请求方法（Request Method）

常见类型及含义：

GET：这是最常见的请求方法之一。主要用于从服务器获取资源，例如获取网页、图片、脚本文件等。GET 请求将参数包含在 URL 中，通常用于查询操作，并且对服务器是幂等的，即多次相同的 GET 请求应该返回相同的结果。例如，在浏览器中输入一个网页地址并访问，浏览器发送的就是 GET 请求来获取该网页的内容。

POST：用于向服务器提交数据，这些数据通常包含在请求体中。POST 请求常用于表单提交，比如用户登录、注册、发表评论等操作。与 GET 请求不同，POST 请求不是幂等的，每次提交可能会对服务器数据产生不同的影响，因为它通常涉及数据的修改或创建。

PUT：主要用于更新服务器上的资源。PUT 请求要求客户端提供完整的更新后的资源数据，它会用请求中的数据替换服务器上指定资源的现有内容。

DELETE：顾名思义，用于删除服务器上的指定资源。
安全测试关注点：不同的请求方法可能涉及不同类型的安全漏洞。例如，GET 请求可能存在通过 URL 参数进行的攻击，如 SQL 注入或跨站脚本攻击（XSS），因为参数是暴露在 URL 中的。POST 请求虽然参数在请求体中，但也可能存在数据篡改、SQL 注入等问题，特别是在处理用户提交的表单数据时。

请求 URL（Request URL）

组成部分及意义：

请求 URL 包含了协议（如 http 或 https）、域名、端口（如果不是默认端口）、路径和查询参数（如果有）。例如，在 “https://example.com/api/user?id=123” 这个 URL 中，“https” 是协议，“example.com” 是域名，“/api/user” 是路径，“?id=123” 是查询参数。路径通常指向服务器上的特定资源或服务端点，查询参数则用于向服务器传递额外的信息，如筛选条件、用户标识等。

安全隐患方面：通过分析请求 URL，可以发现很多潜在的安全问题。例如，路径遍历漏洞可能通过修改 URL 路径部分来访问服务器上不应被访问的文件或目录。查询参数部分则是 SQL 注入、XSS 攻击等的常见攻击点。攻击者可能会尝试修改查询参数的值来触发服务器端的异常行为或获取敏感信息。

请求头（Request Headers）
关键头信息及作用：

User - Agent：这个头信息标识了客户端软件（如浏览器）的类型和版本。例如，“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/5.4 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36” 是一个典型的 Chrome 浏览器的 User - Agent 头。服务器可以根据这个信息来提供适当的内容，例如为移动设备和桌面设备提供不同的页面布局。从安全角度看，一些网站可能会根据 User - Agent 来限制访问，而攻击者可能会尝试修改 User - Agent 来绕过这些限制。

Content - Type：用于指定请求体的内容类型。例如，“application/x - www - form - urlencoded” 表示请求体中的数据是经过 URL 编码的表单数据，“application/json” 表示是 JSON 格式的数据。在安全测试中，了解请求体的内容类型有助于判断数据的处理方式，以及是否可能存在数据解析相关的漏洞。

Cookie：Cookie 是服务器通过响应头 “Set - Cookie” 发送给客户端，然后客户端在后续请求中通过 “Cookie” 头返回给服务器的小文本块。Cookie 常用于用户身份验证和会话管理。在安全测试中，需要关注 Cookie 是否包含敏感信息，如用户密码或会话令牌，以及 Cookie 的安全性设置，如是否设置了 HttpOnly 属性来防止 JavaScript 访问 Cookie，从而避免 XSS 攻击导致的 Cookie 窃取。

整体重要性：请求头提供了关于请求的上下文信息，包括客户端的意图、提供的数据类型以及身份验证相关的细节。这些信息对于理解请求的目的以及识别可能的安全漏洞至关重要。

请求体（Request Body）
内容形式与示例：

如果请求方法是 POST 或 PUT，通常会有请求体。对于 POST 请求，当 Content - Type 为 “application/x - www - form - urlencoded” 时，请求体中的数据是按照 “键 = 值” 的形式进行 URL 编码的。例如，一个用户登录的请求体可能是 “username=admin&password=123456”。当 Content - Type 为 “application/json” 时，请求体是 JSON 格式的数据，如 {"username": "admin", "password": "123456"}。

安全风险关注：请求体是用户输入数据的主要载体，因此是安全测试的重点区域。例如，对于包含用户输入的请求体，需要检查是否存在 SQL 注入漏洞，即用户输入的内容是否被正确地验证和过滤，以防止恶意 SQL 语句被注入到数据库查询中。同时，对于上传文件的请求体，需要检查是否存在文件上传漏洞，如是否可以上传恶意脚本文件。

数据包-响应

查看响应信息
响应状态码：显示服务器返回的状态码，如 200 表示成功，404 表示未找到资源等，通过状态码可快速了解请求的处理结果是否正常，帮助判断是否存在潜在安全问题或错误配置 。

• 1xx 系列（信息性状态码）：这类状态码主要是提供信息的，比较少见。例如，100 Continue 表示客户端可以继续发送请求的其余部分，服务器已经收到了请求的头部并且愿意接收请求体。
• 2xx 系列（成功状态码）：最常见的是 200 OK，表示服务器已成功处理请求并返回了请求的内容。201 Created 表示请求成功并且服务器创建了新的资源，通常用于 POST 或 PUT 请求后，告知客户端资源已成功创建。
• 3xx 系列（重定向状态码）：301 Moved Permanently 表示请求的资源已经永久移动到了新的位置，浏览器会自动重定向到新的 URL；302 Found 表示资源临时移动，下次请求时可能又会回到原来的位置。重定向可能会被攻击者利用来进行钓鱼攻击或者绕过安全策略。
• 4xx 系列（客户端错误状态码）：400 Bad Request 表示客户端发送的请求有语法错误，服务器无法理解；401 Unauthorized 表示需要用户认证才能访问资源；403 Forbidden 表示服务器理解请求，但拒绝执行，可能是因为用户没有权限；404 Not Found 是最常见的，意味着服务器无法找到请求的资源。
• 5xx 系列（服务器错误状态码）：500 Internal Server Error 表示服务器内部出现错误，可能是由于代码错误、数据库问题或者资源耗尽等原因导致。502 Bad Gateway 表示服务器作为网关或者代理，从上游服务器收到了无效的响应。

异常的响应状态码可以帮助发现潜在的安全漏洞。例如，500 状态码可能暗示服务器端代码存在问题，有可能是受到 SQL 注入、命令注入等攻击导致数据库或系统命令执行出错。403 状态码可能表示访问控制设置可能存在漏洞，攻击者可能会尝试绕过这些限制。

响应头：包含如 Content-Type 指定响应内容类型，Content-Length 表示响应内容长度，Set-Cookie 用于在客户端设置 Cookie 等重要信息。这些信息对于客户端正确解析和处理响应内容至关重要，也与安全密切相关，例如可检查 Cookie 的属性设置是否安全.

• 主要头信息介绍：
  • Content - Type：用于指定响应内容的类型，如 “text/html” 表示 HTML 文档，“application/json” 表示 JSON 数据，“image/jpeg” 表示 JPEG 图片。这有助于客户端（如浏览器）正确地解析和显示内容。从安全角度看，如果 Content - Type 被错误设置或者可以被攻击者修改，可能会导致浏览器错误地解析内容，引发安全问题，如 XSS 攻击。
  • Content - Length：表示响应内容的长度（以字节为单位）。这个信息对于客户端正确接收和处理数据很重要。在某些情况下，攻击者可能会尝试修改 Content - Length 头来干扰数据接收过程。
  • Set - Cookie：用于在客户端设置 Cookie。Cookie 通常用于用户身份验证和会话管理。需要关注 Cookie 的属性设置，如 HttpOnly 属性（防止 JavaScript 访问 Cookie，降低 XSS 攻击导致 Cookie 窃取的风险）、Secure 属性（要求在 HTTPS 连接下传输 Cookie，提高安全性）等。
  • Cache - Control 和 Expires：这些头信息用于控制客户端缓存响应内容。不当的缓存设置可能会导致敏感信息被缓存，或者旧版本的恶意脚本被重复使用，从而产生安全风险。

响应头包含了许多关于如何处理和保护响应内容的重要信息。错误的设置或者可被攻击者利用的头信息可能会导致各种安全漏洞，如信息泄露、缓存中毒、跨站脚本攻击等。

响应体：根据 Content-Type 的不同，响应体可以是 HTML 文档、JSON 数据、二进制数据等各种类型。对于 HTML 内容，需检查是否存在跨站脚本攻击漏洞等；对于 JSON 内容，要关注数据完整性和安全性；对于二进制或可下载文件，则要检查文件来源和完整性，防止安全风险

• HTML 内容：如果响应头的 Content - Type 是 “text/html”，响应体就是 HTML 文档。它包含网页的文本、图片引用、链接、脚本代码（如 JavaScript）等。
• JSON 内容：当 Content - Type 为 “application/json” 时，响应体是 JSON 格式的数据。例如：{"message": "Success", "data": {"id": 1, "name": "John"}}，这种格式常用于服务器和客户端之间的数据传输，特别是在 Web API 中。
• 其他类型内容：还可能包括二进制数据，如图片（响应头为 “image/jpeg”、“image/png” 等）、音频（如 “audio/mpeg”）、视频（如 “video/mp4”）等，或者是可下载的文件格式，如 “application/pdf” 表示 PDF 文件。

HTML 内容：对于 HTML 响应体，要检查是否存在跨站脚本攻击（XSS）漏洞。这包括检查是否对用户输入进行了正确的过滤和转义，防止恶意脚本嵌入。同时，要注意是否存在信息泄露，如在 HTML 注释或者错误消息中暴露了敏感信息。
JSON 内容：在 JSON 响应体中，要关注数据的完整性和安全性。确保没有敏感信息被错误地返回给客户端，并且要检查 JSON 数据的解析过程是否安全，防止 JSON 劫持等攻击。
其他类型内容：对于二进制或可下载文件，要检查文件的来源和完整性，防止恶意文件被下载或者替换。例如，在下载软件更新时，要确保文件是来自可靠的源并且没有被篡改。0

过滤：

按请求方法过滤

Burp 的 HTTP History 过滤功能可以根据请求方法（如 GET、POST、PUT、DELETE 等）来筛选记录。例如，在测试一个主要通过 GET 请求获取数据的 Web 应用时，如果只想关注数据提交相关的操作，就可以使用过滤功能只显示 POST 请求。这样可以快速缩小查看范围，聚焦于可能会修改服务器数据的操作，方便检测诸如 SQL 注入（常见于 POST 请求的表单数据提交）等安全漏洞。
 

        按响应状态码过滤
可以按照响应状态码进行过滤，如过滤出所有返回 200（成功）、404（未找到）、500（内部服务器错误）等状态码的请求。这在查找问题时非常有用。例如，大量的 404 状态码可能意味着网站存在链接失效或资源被误删除的情况；而 500 状态码则可能暗示服务器端代码存在错误，有可能是因为存在漏洞（如 SQL 注入导致数据库查询出错）被触发。
        按域名和 IP 过滤
能够筛选出特定域名或 IP 地址相关的请求。在对包含多个子域名或不同服务器的复杂 Web 应用进行测试时，这种过滤方式可以帮助分离不同来源的请求。例如，对于一个大型企业网站，有主域名和多个子域名用于不同业务部门，通过过滤出特定子域名的请求，可以单独分析该子域名对应的功能是否存在安全隐患。

        按文件类型或路径过滤
可以根据请求的 URL 路径中涉及的文件类型或路径进行过滤。比如，过滤出所有指向图片文件（如.jpg、.png 等）的请求，或者只查看与特定目录（如 /admin/ 目录下的请求，这可能涉及后台管理功能）相关的请求。这有助于针对特定类型的资源或功能区域进行重点检查，对于检测路径遍历等漏洞很有帮助。
        按请求头或响应头过滤
根据请求头或响应头中的特定字段进行过滤。例如，过滤出包含特定 Cookie 头的请求，这在分析用户认证相关的功能时非常有用。或者过滤出响应头中含有 “Content - Type: application/json” 的记录，以关注服务器返回 JSON 数据的情况，方便检查 JSON 数据是否存在安全风险，如 JSON 劫持。
        按请求体或响应体过滤
能够根据请求体或响应体中的内容进行过滤。例如，过滤出请求体中包含特定关键词（如 “password”）的请求，这可以帮助发现可能涉及用户密码处理的操作。或者过滤出响应体中有错误信息（如数据库查询错误信息）的记录，从而快速定位可能存在安全隐患的功能区域。

过滤操作方式

        简单过滤
可以通过在 HTTP History 界面的过滤栏中输入简单的过滤条件来实现基本的筛选。例如，在过滤栏中输入 “POST” 就可以筛选出所有的 POST 请求；输入 “status: 404” 就可以过滤出所有返回 404 状态码的请求。这种简单的过滤方式操作便捷，能够快速满足一些常见的过滤需求。
        组合过滤
还可以组合多个过滤条件来进行更精确的筛选。例如，可以同时过滤出 “POST 请求且返回状态码为 404 且包含特定域名” 的请求。通过使用逻辑运算符（如 “AND”、“OR”）和括号来构建复杂的过滤表达式，能够满足复杂的测试场景下对请求 - 响应记录的筛选需求。例如，过滤表达式 “(GET OR POST) AND (status: 200 OR status: 302) AND (domain: example.com)” 可以筛选出所有 GET 或 POST 请求，并且返回状态码是 200 或 302，同时属于example.com域名下的请求。

漏洞测试理论

Burp 漏洞测试是通过模拟攻击者的行为，对 Web 应用程序进行系统的检查，以发现其中可能存在的安全弱点。这些安全弱点（漏洞）可能导致数据泄露、系统被控制、服务中断等严重后果。

一、漏洞测试流程与方法

信息收集阶段

目标确定：明确要测试的 Web 应用的范围，包括 URL、IP 地址、端口号等基本信息。例如，对于一个企业内部的 Web 管理系统，需要确定其访问地址和使用的端口。
技术栈探测：了解目标应用所使用的技术栈，如服务器类型（Apache、Nginx 等）、编程语言（PHP、Java 等）和数据库（MySQL、Oracle 等）。这有助于预测可能出现的漏洞类型。例如，知道应用是用 PHP 开发的，就可以重点关注 PHP 相关的漏洞，如文件包含漏洞。
功能梳理：通过手动浏览、使用蜘蛛工具等方式，确定应用的各种功能，如用户注册登录、文件上传下载、数据查询等。不同的功能可能存在不同类型的漏洞，例如，文件上传功能可能存在文件上传漏洞，允许攻击者上传恶意文件。

漏洞扫描与探测阶段

主动扫描：使用 Burp Suite 的扫描器工具进行自动化扫描。扫描器会根据内置的规则和漏洞库，发送大量测试请求来查找漏洞。但是，扫描器也有一定的局限性，它可能会产生误报（将正常情况判定为漏洞）或漏报（遗漏真正的漏洞）。
手动探测：结合自己的经验和对漏洞的了解，手动修改请求。例如，在测试跨站脚本攻击（XSS）漏洞时，在输入框中输入 “<script>alert('XSS')</script>”，查看页面是否会弹出警告框。如果弹出，就说明可能存在 XSS 漏洞。手动探测可以更灵活地发现一些自动化扫描难以发现的复杂漏洞。

漏洞验证与利用阶段

验证漏洞的真实性：当发现一个潜在漏洞后，需要进一步验证。例如，对于一个疑似 SQL 注入漏洞，通过使用更复杂的 SQL 注入语句，如联合查询（UNION SELECT）来获取数据库中的敏感信息，如用户名和密码的哈希值。如果能够成功获取这些信息，就可以确定漏洞是真实存在的。
评估漏洞的影响和可利用性：确定漏洞可能造成的危害程度，如是否可以获取敏感数据、是否可以控制服务器等。同时，还要考虑利用漏洞的难度，有些漏洞可能需要特定的条件或复杂的攻击步骤才能利用。

常见漏洞类型与测试方法
 

SQL 注入漏洞
原理：由于 Web 应用程序对用户输入的 SQL 语句过滤不严格，导致攻击者可以将恶意 SQL 语句注入到数据库查询中，从而获取、修改或删除数据。例如，在一个登录页面的 SQL 查询中，如果用户输入的用户名和密码没有被正确过滤，攻击者可以输入 “' or 1=1--” 作为密码，使 SQL 查询的条件恒成立，从而绕过登录验证。
测试方法：在输入框中输入可能导致 SQL 注入的特殊字符和语句，如单引号（'）、双引号（"）、分号（;）、注释符（--）等，观察服务器的响应。还可以使用 Burp Suite 的 Repeater 工具，修改请求中的参数，发送不同的 SQL 注入尝试语句，如联合查询语句（UNION SELECT）来获取数据库中的信息。
跨站脚本攻击（XSS）漏洞
原理：当 Web 应用程序没有对用户输入的内容进行适当的过滤和转义就输出到浏览器时，攻击者可以插入恶意脚本（通常是 JavaScript），这些脚本会在用户浏览器中执行。例如，攻击者在评论区输入一段包含恶意 JavaScript 的评论，当其他用户查看评论时，脚本就会在他们的浏览器中执行，可能导致用户信息泄露或被控制。
测试方法：在可以输入内容的地方（如评论框、搜索框等）输入测试脚本，如 “<script>alert('XSS')</script>”，查看是否有弹窗。也可以尝试输入更复杂的 XSS payload，如窃取用户 Cookie 的脚本，并观察浏览器的行为和网络请求，看是否有可疑的数据发送。
跨站请求伪造（CSRF）漏洞
原理：攻击者利用用户在目标网站的登录状态，通过诱导用户访问恶意网站，在用户不知情的情况下，让用户浏览器向目标网站发送请求，从而完成一些非用户本意的操作，如修改密码、转账等。
测试方法：检查目标网站是否对请求进行了有效的 CSRF 防护，如是否存在 CSRF 令牌。可以通过构造恶意页面，模拟发送目标网站的请求，观察是否可以在没有用户手动操作相关功能的情况下完成操作。
文件上传漏洞
原理：如果 Web 应用程序没有对上传的文件进行严格的验证和过滤，攻击者可以上传恶意文件，如 Webshell（一种可以通过浏览器远程执行服务器端命令的脚本文件），从而获取服务器的控制权。
测试方法：尝试上传不同类型的文件，包括可执行文件（如.php、.jsp、.asp 等脚本文件），观察服务器是否允许上传。如果允许上传，再检查上传后的文件是否可以被访问和执行。