SQL注入、XSS与CSRF漏洞的复现及分析 一、SQL注入漏洞复现与分析 1. 复现步骤 假设有一个登录页面，其后端逻辑未对用户输入进行充分过滤和转义，直接拼接SQL查询语句： ```sql SELECT FROM users WHERE username = '" + 用户名 + "' AND password = '" + 密码 + "'"; ``` 攻击者可以尝试注入： 1. 发现注入点： - 输入 `' OR '1'='1` 作为用户名，任何密码尝试登录。如果成功，说明可能存在SQL注入问题，因为"' OR '1'='1"这个条件始终为真，所以会返回至少一条用户记录。 2. 提取数据库信息： - 利用注释符 `--` 或者 `/ /` 注释掉部分原始查询语句，尝试注入如 `' UNION SELECT database(), version() --` 来获取当前数据库名和MySQL版本信息。 3. 获取数据： - 更进一步，攻击者可以尝试注入 `' UNION SELECT username, password FROM users --` 以尝试获取所有用户账户的用户名和密码。 2. 防御措施 - 预编译参数化查询：使用PreparedStatement，将变量与SQL分开处理，让数据库引擎负责SQL语句的拼接与执行，防止直接拼接导致的注入。 - 输入验证：对所有用户输入进行严格的类型检查和长度限制，去除特殊字符。 - 输出编码：对于数据库查询结果，在展示给用户之前做好HTML编码，防止意外的脚本执行。 二、跨站脚本攻击(XSS)漏洞复现与分析 1. 复现步骤 在一个用户评论区，假设系统直接将用户输入的内容展示到网页上： ```html <%= usercomment %> ``` 攻击者可以输入以下payload： ```javascript ``` 当其他用户浏览包含此评论的页面时，会弹出警告框，表明存在XSS漏洞。 不同类型的XSS攻击举例： - 持久型（Stored XSS）：上述payload被保存在数据库中并在每次加载该页面时执行。 - 反射型（Reflected XSS）：攻击payload通过URL参数传递，如搜索栏或GET请求，服务器将它原样回显在响应页面中。 2. 防御措施 - 内容转义：对所有从用户处接收并输出至HTML文档的数据进行适当转义，如使用JavaScript函数`encodeURI()`或`encodeURIComponent()`，在服务器端则可以使用类似OWASP Java Encoder或Microsoft AntiXSS库。 - HTTP头部设置：启用Content-Security-Policy（CSP），限制加载脚本的来源。 - 浏览器同源策略强化：利用浏览器自身的安全特性限制恶意脚本执行。 三、跨站请求伪造(CSRF)漏洞复现与分析 1. 复现步骤 假设有银行转账页面，其POST请求仅依赖Cookie进行身份验证，而没有其他防CSRF措施： ```html ``` 攻击者可以在自己的网站上创建类似的表单，诱使用户在其不知情的情况下触发此表单提交，完成转账。 2. 防御措施 - CSRF Token：为每个敏感操作生成一个一次性Token，并将其放入隐藏字段和Cookie中，服务器端校验两个地方的Token是否一致。 - 双重验证：除了Cookie验证外，增加验证码或其他形式的用户交互确认。 - SameSite属性：调整Cookie的SameSite属性，限制第三方网站发起的请求携带Session Cookie。 总结起来，SQL注入、XSS和CSRF都是常见且危害严重的Web漏洞。理解这些漏洞的复现方法和原理有助于我们更好地制定针对性的安全策略，并通过实施有效的防御措施来保护Web应用不受此类攻击的侵害。 精彩渗透课：「链接」