1. 从一次“意外”的502错误说起那天下午我正在调试一个内部服务。本地环境跑得好好的前端页面一调用某个API接口浏览器控制台就弹出一个刺眼的红色错误unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。相信不少开发同学都见过类似的报错第一反应往往是“后端服务挂了”或者“Nginx配置错了”。我检查了后端服务进程运行正常查看了Nginx日志也没有明显的错误。问题出在哪经过一番排查最终定位到是服务间通信时一个上游服务因为请求参数被恶意构造导致了进程崩溃进而触发了网关的502错误。这个“恶意构造”的参数本质上就是一个非常初级的SQL注入攻击。这件事让我感触很深。我们常常把“Web安全”想象成防火墙、WAFWeb应用防火墙这些运维或安全团队负责的“高大上”的东西觉得离日常业务开发很远。但实际上很多安全问题就源于我们写的一行行业务代码。那个导致502错误的注入点可能就是某位同事在赶工期时图省事直接拼接了SQL语句。unexpected status 502 bad gateway这个错误本身不是漏洞但它像是一个“症状”背后隐藏的可能是SQL注入、SSRF服务器端请求伪造甚至是因过滤不严导致的资源耗尽等问题。所以今天我想抛开那些复杂的学术定义和庞杂的安全体系就从一个一线开发者的视角聊聊Web安全里最基础、最常见但也最要命的几个“老朋友”HTTP/HTTPS、SQL注入、XSS跨站脚本和SSRF。我会结合像ctfshow、ctfhub这类实战靶场中常见的套路以及开发中真实遇到的坑比如配置http客户端却访问了https的phpmyadmin导致的failed to set session cookie问题把这些知识揉碎了讲明白它们到底是怎么发生的我们该如何在代码层面就“御敌于国门之外”。2. 一切的基础HTTP与HTTPS不只是“S”的区别我们每天开发的Web应用都跑在HTTP超文本传输协议或HTTPSHTTP Secure之上。很多人对它们的理解停留在“HTTPS更安全是加密的HTTP”。这个说法没错但太笼统了。理解它们之间的区别是理解很多Web攻击手法的前提。2.1 HTTP的“透明”与风险HTTP协议是明文传输的。这意味着从你的浏览器到服务器之间所有数据包括URL、请求头、Cookie尤其是POST请求体里的用户名和密码就像一张明信片途径的任何一个网络节点比如咖啡馆的Wi-Fi路由器、运营商网关都能看得一清二楚。这就是为什么在公共网络下登录不使用HTTPS的网站是极度危险的行为。除了窃听HTTP还面临篡改和冒充的风险。攻击者可以拦截你的请求修改其中的内容比如将转账金额从100元改成10000元或者伪装成目标网站与你通信中间人攻击。你可能会想我的网站就是个内部系统不对外网开放用HTTP没问题吧这里就引出一个常见的配置错误。在部署诸如phpMyAdmin、Jenkins这类Web管理界面时我们有时会图方便直接用HTTP访问。但如果你的Web服务器或反向代理如Nginx配置了强制HTTPS跳转或者应用本身对Cookie设置了Secure属性要求仅通过HTTPS传输那么通过HTTP访问就会出问题。就像错误提示failed to set session cookie. maybe you are using http instead of https to access phpmyadmin.所说你明明登录了但会话Cookie无法被浏览器保存或发送导致一直处于“未登录”状态。这虽然是个配置问题但从安全角度看它强制了安全通道的使用是好事。2.2 HTTPS如何构建安全通道HTTPS并非一个新的协议而是在HTTP和TCP之间加入了一个安全层——TLS/SSL协议。这个协议主要干了三件大事加密通过对称加密算法如AES对传输的数据进行加密即使被截获也是乱码。认证通过数字证书验证服务器的身份。你浏览器地址栏的小锁图标就代表当前连接的服务器的证书是受信任的机构颁发的你确实在访问“真正的”百度或谷歌而不是一个山寨网站。完整性校验通过消息认证码MAC确保数据在传输过程中没有被篡改。所以将网站从HTTP升级到HTTPS是Web安全最基础、最重要的一步。它不仅保护用户数据也关乎搜索引擎排名Google对HTTPS网站有排名加成和现代浏览器API的调用资格如地理位置、Service Worker等。2.3 开发中的HTTP客户端安全在我们的后端代码中经常需要扮演“客户端”的角色去调用其他服务的HTTP/HTTPS接口。这里就藏着SSRF的隐患我们稍后会详细讲。但首先一个基础的安全实践是务必验证和限制出站请求。当你使用HttpClientJava、requestsPython、axiosJavaScript等库时默认它们可能是“信任”你所提供的URL的。但如果你从用户输入中动态拼接了URL比如一个让用户输入头像链接的功能就必须警惕协议限制只允许http://或https://开头的URL。防止类似file:///etc/passwd读取服务器本地文件或gopher://利用旧协议进行攻击的恶意协议。目标限制避免请求内网IP段如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16和本地回环地址127.0.0.1,localhost。这是防止SSRF攻击内网服务的关键。响应处理对返回的数据大小、类型做限制。防止服务器返回一个巨大的文件拖慢你的服务或者将响应内容直接输出到页面而引发新的XSS。一个常见的反面教材是某些配置或脚本中允许用户输入完整的URL如某些爬虫或代理配置。如果过滤不严攻击者可以输入http://127.0.0.1:8080/admin/deleteAll这样的地址让你的服务器从内部攻击自己。3. 数据库的“刺客”SQL注入详解与实战防御回到开头那个引发502错误的罪魁祸首——SQL注入。它常年位居OWASP Top 10开放式Web应用程序安全项目十大安全风险前列原理简单危害极大可以导致数据库信息泄露、数据篡改、甚至服务器被完全控制。3.1 SQL注入是如何发生的它的本质是“数据被当成了代码执行”。我们来看一段经典的错误代码以PHP为例$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);看起来很正常如果用户老实地输入用户名admin和密码123456SQL语句是SELECT * FROM users WHERE username admin AND password 123456但如果用户在用户名输入框里输入的是admin --注意最后有个空格那么拼接后的SQL语句就变成了SELECT * FROM users WHERE username admin -- AND password ...在SQL中--是注释符它会把后面的语句都注释掉。这意味着攻击者无需知道密码就能以管理员身份登录这就是所谓的“万能密码”绕过的一种形式。更危险的攻击是使用UNION查询。假设用户输入 UNION SELECT username, password FROM users --那么原查询可能变成SELECT id, name FROM products WHERE id UNION SELECT username, password FROM users -- 这样攻击者就能把用户表的敏感信息直接“联合查询”出来显示在页面上。在ctfshow、sql注入靶场等练习平台上你会遇到各种过滤和限制比如过滤了空格、union、select等关键词。这时就需要用到各种绕过技巧比如用/**/代替空格用ununionion绕过简单的union关键词删除删除后变成union用select的十六进制编码0x73656c656374等等。这些技巧的核心思路就是利用WAF或简单过滤规则的缺陷让恶意SQL“变形”后依然能被数据库解析。3.2 如何彻底防御SQL注入防御的核心原则就是让代码和数据分家。永远不要相信用户输入永远不要拼接SQL语句。使用参数化查询预编译语句这是最重要、最有效的手段。几乎所有现代编程语言和数据库驱动都支持。Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); // 参数1绑定用户名 stmt.setString(2, password); // 参数2绑定密码 ResultSet rs stmt.executeQuery();Python (sqlite3):cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);它的原理是数据库引擎会先编译SQL语句的结构SELECT * FROM users WHERE username ? AND password ?这个结构是固定的。之后传入的参数username,password会被严格视为数据无论里面包含什么引号、分号、SQL关键词都不会改变原语句的结构从而从根本上杜绝注入。使用ORM框架像MyBatis注意要使用#{}而非${}、Hibernate、Django ORM、Sequelize等它们底层通常也使用参数化查询能提供更安全的数据库操作方式。严格的输入验证虽然不能替代参数化查询但作为辅助手段很有用。例如对于已知是数字的ID参数如/product?id123在代码里强制转换为整数类型int productId Integer.parseInt(request.getParameter(id))这样即使攻击者传入id1 OR 11也会在转换时抛出异常而不是传入数据库。最小权限原则连接数据库的应用程序账号不应该拥有DROP TABLE、DELETE *等高危权限。通常只赋予SELECT、INSERT、UPDATE等必要权限这样即使发生注入危害也能被限制。注意有些古老的教程或代码中会推荐使用“转义”用户输入如PHP的mysqli_real_escape_string。这种方法容易出错需要知道数据库字符集且对于数字注入无效不推荐作为主要防御手段参数化查询才是黄金标准。4. 前端页面里的“幽灵”XSS攻击与防护如果说SQL注入是攻击数据库那么XSS跨站脚本攻击就是攻击访问网页的用户。它的原理同样是“数据被当成了代码执行”只不过这个“代码”是JavaScript执行环境是用户的浏览器。4.1 XSS的三种主要类型反射型XSS攻击脚本“反射”在URL中。常见于搜索框、错误信息提示页。比如一个搜索功能将用户输入的关键词直接显示在结果页p您搜索的关键词是?php echo $_GET[q]; ?/p。如果用户访问一个构造好的链接http://example.com/search?qscriptalert(XSS)/script那么这段脚本就会在用户的浏览器中执行。反射型XSS通常需要诱导用户点击恶意链接。存储型XSS攻击脚本被“存储”在服务器上如数据库、评论内容当其他用户浏览到该页面时自动执行。比如一个论坛的评论功能如果没有过滤攻击者可以提交一条包含script.../script的评论。此后所有查看这条评论的用户都会中招。危害最大因为它是持久性的。DOM型XSS漏洞存在于前端JavaScript代码中不经过服务器。例如一段不安全的JS代码从URL的hash部分#后面获取数据并动态写入页面var data decodeURIComponent(location.hash.substr(1)); document.getElementById(message).innerHTML data;攻击者可以构造URLhttp://example.com/page#img srcx onerroralert(XSS)导致脚本执行。在ctfshow、ctfhub的XSS挑战中你会遇到各种过滤比如将、转义成lt;、gt;这就是所谓的尖括号转义。绕过的方法包括利用事件处理器img srcx onerroralert(1)不需要闭合标签。利用JavaScript伪协议a hrefjavascript:alert(1)click/a。在DOM型XSS中如果innerHTML被转义可以尝试innerText或document.write等不同的输出点。4.2 如何有效防御XSS防御XSS的核心是区分“数据”和“代码”对用户输入进行正确的编码/转义并设置严格的内容安全策略。对输出进行编码HTML转义这是最普适的防御措施。在将不可信数据输出到HTML页面时必须根据上下文进行编码。输出到HTML标签内容textContent将,,,,分别转义为amp;,lt;,gt;,quot;,#x27;。几乎所有后端模板引擎如Thymeleaf, Freemarker, Jinja2都默认开启或提供了自动转义功能。输出到HTML属性值除了上述字符空格也需要视情况处理。最好总是用引号包裹属性值。输出到JavaScript代码或事件处理器如onclick这非常危险应尽量避免。如果必须需使用JavaScript专用的编码如\uXXXX形式的Unicode转义。输出到URL如果用户输入要作为URL的一部分需要使用URL编码如encodeURIComponent。实操心得不要试图用黑名单过滤script、onerror等来防御XSS绕过方法太多。坚持使用白名单只允许安全的标签和属性如富文本编辑器场景和上下文相关的编码才是正道。使用现代前端框架React、Vue、Angular等框架在设计上就考虑了XSS防护。它们默认会对渲染到DOM中的数据进行转义。例如在React中使用{}插入变量是安全的但使用dangerouslySetInnerHTML就需要你格外小心确保内容可信。设置Content-Security-PolicyCSP这是一个强大的浏览器安全特性通过HTTP响应头来告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行。一个严格的CSP可以极大地缓解XSS的影响。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;这个策略表示默认只允许加载同源资源脚本只允许同源和指定的CDN样式允许同源和内联样式unsafe-inline是宽松策略理想情况应避免。即使攻击者成功注入了script标签如果该脚本的源不在白名单内浏览器也不会执行它。使用HttpOnly Cookie将敏感的会话Cookie标记为HttpOnlySet-Cookie: sessionIdabc123; HttpOnly这样JavaScript就无法通过document.cookie访问它。即使网站存在XSS漏洞攻击者也无法直接窃取用户的会话凭证。5. 让服务器“内讧”SSRF漏洞剖析SSRF服务器端请求伪造是一种由攻击者构造请求让服务器向内部或外部的任意地址发起请求的攻击。它危害巨大因为攻击者可以利用受信任的服务器作为跳板去探测或攻击内网中那些本应被防火墙保护的服务。5.1 SSRF的常见触发场景与危害功能设计缺陷很多Web应用提供了“网页抓取”、“URL预览”、“文件导入”、“网络诊断”等功能。例如一个社交网站允许用户输入头像URL服务器会去抓取这个URL的图片并保存。如果这个功能没有对URL做任何限制攻击者就可以输入file:///etc/passwd来读取服务器本地文件或者输入http://192.168.1.1/admin来探测内网管理后台。引用外部资源比如在Markdown编辑器里插入图片如果服务器为了生成缩略图或验证图片会主动去请求这个URL。利用协议和URL解析差异这是SSRF攻击中非常狡猾的一点。攻击者可以利用浏览器、服务器、库之间对URL解析的差异来绕过防御。利用符号http://expected-hostattacker-host。一些旧的解析器可能会将前面的部分认为是认证信息实际请求的是attacker-host。利用IPv6地址和[]http://[::ffff:127.0.0.1]:8080可能被解析为访问本地环回地址。利用DNS重绑定攻击者控制一个域名其DNS记录TTL极短。第一次解析时返回一个合法的外网IP通过校验服务器发起请求时DNS再次解析返回一个内网IP如127.0.0.1从而成功攻击内网。这就是所谓的“未知SSRF”或需要高级技巧的SSRF。它的危害包括攻击内网服务扫描内网存活主机和端口攻击Redis、MySQL、Memcached等未授权访问的内网服务。读取本地文件利用file://、gopher://、dict://等协议。绕过认证如果内网应用采用IP白名单或基础认证服务器发起请求时会自动带上这些信任关系。5.2 防御SSRF的层层设防防御SSRF需要从多个层面共同构建防线因为攻击者总会寻找最薄弱的一环。输入校验与白名单这是第一道也是最重要的防线。协议白名单只允许http://和https://。明确拒绝file://、gopher://、dict://、ftp://等危险协议。目标地址黑名单/白名单黑名单禁止请求内网IP、回环地址127.0.0.1、localhost、链路本地地址169.254.0.0/16等。但黑名单可能被绕过如用127.0.0.1.nip.io域名解析到本地。白名单推荐如果业务明确只允许请求有限的、已知可信的外部域名或IP。这是最安全的方式。统一出口与网络隔离设置网络访问控制运行Web应用的服务器DMZ区与核心内网业务服务器如数据库之间应设置严格的防火墙策略限制DMZ区服务器对内网的访问权限遵循最小权限原则。使用专用出站代理所有需要外发请求的服务统一通过一个配置了严格白名单的代理服务器进行。这样即使应用层存在漏洞网络层的限制也能起到作用。响应处理限制服务器请求的响应时间、响应大小防止被用于发起DoS攻击或读取大文件。不要将请求的原始响应内容直接返回给前端用户。如果业务需要如URL预览应对返回的内容如图片、文本进行严格的检查和过滤防止成为XSS等攻击的二传手。代码层面使用安全的库使用诸如url.parseNode.js注意旧版本有问题、Java的URI类等标准库来解析URL并仔细检查解析后的host、protocol等属性避免使用正则表达式做简单的匹配容易出错。6. 实战中的组合拳与纵深防御在实际的渗透测试或CTF比赛中漏洞往往不是孤立存在的。攻击者会像玩解谜游戏一样将各种基础漏洞组合起来形成一条完整的攻击链攻击路径。一个假设的攻击场景攻击者首先发现一个反射型XSS漏洞但无法直接窃取Cookie因为设置了HttpOnly。他利用这个XSS让受害者的浏览器向网站内部一个存在SSRF漏洞的端点发起请求因为浏览器发起的请求会携带用户的Cookie所以这个请求是“已认证”的。这个SSRF漏洞被用来攻击内网的一个Redis服务未设置密码。通过构造特定协议的数据包如使用gopher协议攻击者可以向Redis写入数据。攻击者将一条恶意的PHP代码写入网站服务器的临时目录并通过Redis配置使Web服务器将其作为PHP文件执行最终获得一个Webshell完全控制服务器。这个链条里XSS是入口SSRF是桥梁内网未授权访问的Redis是目标。防御这样的攻击就需要纵深防御思想在每一个环节都设置防护即使一道防线被突破还有其他防线阻止攻击者达成最终目标。第一层安全编码。做好输入验证、输出编码使用参数化查询杜绝SQL注入和XSS的产生。第二层应用配置。设置严格的CSP、HttpOnly Cookie使用最小权限的数据库账户。第三层服务器与网络配置。及时更新系统和中间件补丁配置严格的防火墙规则隔离网络区域。第四层安全监控与响应。部署WAF、IDS/IPS监控异常日志如大量502错误、异常的本地请求建立应急响应流程。Web安全不是一个可以“一键修复”的模块它需要开发、运维、测试各个角色在软件生命周期的每个阶段都保持安全意识。从写出第一行安全的代码开始到设计一个安全的架构再到部署时进行安全的配置每一步都算数。别再让那个unexpected status 502 bad gateway的错误成为你系统被攻破的第一次警报。 从502错误到Web安全实战：SQL注入、XSS与SSRF防御指南
1. 从一次“意外”的502错误说起那天下午我正在调试一个内部服务。本地环境跑得好好的前端页面一调用某个API接口浏览器控制台就弹出一个刺眼的红色错误unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。相信不少开发同学都见过类似的报错第一反应往往是“后端服务挂了”或者“Nginx配置错了”。我检查了后端服务进程运行正常查看了Nginx日志也没有明显的错误。问题出在哪经过一番排查最终定位到是服务间通信时一个上游服务因为请求参数被恶意构造导致了进程崩溃进而触发了网关的502错误。这个“恶意构造”的参数本质上就是一个非常初级的SQL注入攻击。这件事让我感触很深。我们常常把“Web安全”想象成防火墙、WAFWeb应用防火墙这些运维或安全团队负责的“高大上”的东西觉得离日常业务开发很远。但实际上很多安全问题就源于我们写的一行行业务代码。那个导致502错误的注入点可能就是某位同事在赶工期时图省事直接拼接了SQL语句。unexpected status 502 bad gateway这个错误本身不是漏洞但它像是一个“症状”背后隐藏的可能是SQL注入、SSRF服务器端请求伪造甚至是因过滤不严导致的资源耗尽等问题。所以今天我想抛开那些复杂的学术定义和庞杂的安全体系就从一个一线开发者的视角聊聊Web安全里最基础、最常见但也最要命的几个“老朋友”HTTP/HTTPS、SQL注入、XSS跨站脚本和SSRF。我会结合像ctfshow、ctfhub这类实战靶场中常见的套路以及开发中真实遇到的坑比如配置http客户端却访问了https的phpmyadmin导致的failed to set session cookie问题把这些知识揉碎了讲明白它们到底是怎么发生的我们该如何在代码层面就“御敌于国门之外”。2. 一切的基础HTTP与HTTPS不只是“S”的区别我们每天开发的Web应用都跑在HTTP超文本传输协议或HTTPSHTTP Secure之上。很多人对它们的理解停留在“HTTPS更安全是加密的HTTP”。这个说法没错但太笼统了。理解它们之间的区别是理解很多Web攻击手法的前提。2.1 HTTP的“透明”与风险HTTP协议是明文传输的。这意味着从你的浏览器到服务器之间所有数据包括URL、请求头、Cookie尤其是POST请求体里的用户名和密码就像一张明信片途径的任何一个网络节点比如咖啡馆的Wi-Fi路由器、运营商网关都能看得一清二楚。这就是为什么在公共网络下登录不使用HTTPS的网站是极度危险的行为。除了窃听HTTP还面临篡改和冒充的风险。攻击者可以拦截你的请求修改其中的内容比如将转账金额从100元改成10000元或者伪装成目标网站与你通信中间人攻击。你可能会想我的网站就是个内部系统不对外网开放用HTTP没问题吧这里就引出一个常见的配置错误。在部署诸如phpMyAdmin、Jenkins这类Web管理界面时我们有时会图方便直接用HTTP访问。但如果你的Web服务器或反向代理如Nginx配置了强制HTTPS跳转或者应用本身对Cookie设置了Secure属性要求仅通过HTTPS传输那么通过HTTP访问就会出问题。就像错误提示failed to set session cookie. maybe you are using http instead of https to access phpmyadmin.所说你明明登录了但会话Cookie无法被浏览器保存或发送导致一直处于“未登录”状态。这虽然是个配置问题但从安全角度看它强制了安全通道的使用是好事。2.2 HTTPS如何构建安全通道HTTPS并非一个新的协议而是在HTTP和TCP之间加入了一个安全层——TLS/SSL协议。这个协议主要干了三件大事加密通过对称加密算法如AES对传输的数据进行加密即使被截获也是乱码。认证通过数字证书验证服务器的身份。你浏览器地址栏的小锁图标就代表当前连接的服务器的证书是受信任的机构颁发的你确实在访问“真正的”百度或谷歌而不是一个山寨网站。完整性校验通过消息认证码MAC确保数据在传输过程中没有被篡改。所以将网站从HTTP升级到HTTPS是Web安全最基础、最重要的一步。它不仅保护用户数据也关乎搜索引擎排名Google对HTTPS网站有排名加成和现代浏览器API的调用资格如地理位置、Service Worker等。2.3 开发中的HTTP客户端安全在我们的后端代码中经常需要扮演“客户端”的角色去调用其他服务的HTTP/HTTPS接口。这里就藏着SSRF的隐患我们稍后会详细讲。但首先一个基础的安全实践是务必验证和限制出站请求。当你使用HttpClientJava、requestsPython、axiosJavaScript等库时默认它们可能是“信任”你所提供的URL的。但如果你从用户输入中动态拼接了URL比如一个让用户输入头像链接的功能就必须警惕协议限制只允许http://或https://开头的URL。防止类似file:///etc/passwd读取服务器本地文件或gopher://利用旧协议进行攻击的恶意协议。目标限制避免请求内网IP段如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16和本地回环地址127.0.0.1,localhost。这是防止SSRF攻击内网服务的关键。响应处理对返回的数据大小、类型做限制。防止服务器返回一个巨大的文件拖慢你的服务或者将响应内容直接输出到页面而引发新的XSS。一个常见的反面教材是某些配置或脚本中允许用户输入完整的URL如某些爬虫或代理配置。如果过滤不严攻击者可以输入http://127.0.0.1:8080/admin/deleteAll这样的地址让你的服务器从内部攻击自己。3. 数据库的“刺客”SQL注入详解与实战防御回到开头那个引发502错误的罪魁祸首——SQL注入。它常年位居OWASP Top 10开放式Web应用程序安全项目十大安全风险前列原理简单危害极大可以导致数据库信息泄露、数据篡改、甚至服务器被完全控制。3.1 SQL注入是如何发生的它的本质是“数据被当成了代码执行”。我们来看一段经典的错误代码以PHP为例$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);看起来很正常如果用户老实地输入用户名admin和密码123456SQL语句是SELECT * FROM users WHERE username admin AND password 123456但如果用户在用户名输入框里输入的是admin --注意最后有个空格那么拼接后的SQL语句就变成了SELECT * FROM users WHERE username admin -- AND password ...在SQL中--是注释符它会把后面的语句都注释掉。这意味着攻击者无需知道密码就能以管理员身份登录这就是所谓的“万能密码”绕过的一种形式。更危险的攻击是使用UNION查询。假设用户输入 UNION SELECT username, password FROM users --那么原查询可能变成SELECT id, name FROM products WHERE id UNION SELECT username, password FROM users -- 这样攻击者就能把用户表的敏感信息直接“联合查询”出来显示在页面上。在ctfshow、sql注入靶场等练习平台上你会遇到各种过滤和限制比如过滤了空格、union、select等关键词。这时就需要用到各种绕过技巧比如用/**/代替空格用ununionion绕过简单的union关键词删除删除后变成union用select的十六进制编码0x73656c656374等等。这些技巧的核心思路就是利用WAF或简单过滤规则的缺陷让恶意SQL“变形”后依然能被数据库解析。3.2 如何彻底防御SQL注入防御的核心原则就是让代码和数据分家。永远不要相信用户输入永远不要拼接SQL语句。使用参数化查询预编译语句这是最重要、最有效的手段。几乎所有现代编程语言和数据库驱动都支持。Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); // 参数1绑定用户名 stmt.setString(2, password); // 参数2绑定密码 ResultSet rs stmt.executeQuery();Python (sqlite3):cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);它的原理是数据库引擎会先编译SQL语句的结构SELECT * FROM users WHERE username ? AND password ?这个结构是固定的。之后传入的参数username,password会被严格视为数据无论里面包含什么引号、分号、SQL关键词都不会改变原语句的结构从而从根本上杜绝注入。使用ORM框架像MyBatis注意要使用#{}而非${}、Hibernate、Django ORM、Sequelize等它们底层通常也使用参数化查询能提供更安全的数据库操作方式。严格的输入验证虽然不能替代参数化查询但作为辅助手段很有用。例如对于已知是数字的ID参数如/product?id123在代码里强制转换为整数类型int productId Integer.parseInt(request.getParameter(id))这样即使攻击者传入id1 OR 11也会在转换时抛出异常而不是传入数据库。最小权限原则连接数据库的应用程序账号不应该拥有DROP TABLE、DELETE *等高危权限。通常只赋予SELECT、INSERT、UPDATE等必要权限这样即使发生注入危害也能被限制。注意有些古老的教程或代码中会推荐使用“转义”用户输入如PHP的mysqli_real_escape_string。这种方法容易出错需要知道数据库字符集且对于数字注入无效不推荐作为主要防御手段参数化查询才是黄金标准。4. 前端页面里的“幽灵”XSS攻击与防护如果说SQL注入是攻击数据库那么XSS跨站脚本攻击就是攻击访问网页的用户。它的原理同样是“数据被当成了代码执行”只不过这个“代码”是JavaScript执行环境是用户的浏览器。4.1 XSS的三种主要类型反射型XSS攻击脚本“反射”在URL中。常见于搜索框、错误信息提示页。比如一个搜索功能将用户输入的关键词直接显示在结果页p您搜索的关键词是?php echo $_GET[q]; ?/p。如果用户访问一个构造好的链接http://example.com/search?qscriptalert(XSS)/script那么这段脚本就会在用户的浏览器中执行。反射型XSS通常需要诱导用户点击恶意链接。存储型XSS攻击脚本被“存储”在服务器上如数据库、评论内容当其他用户浏览到该页面时自动执行。比如一个论坛的评论功能如果没有过滤攻击者可以提交一条包含script.../script的评论。此后所有查看这条评论的用户都会中招。危害最大因为它是持久性的。DOM型XSS漏洞存在于前端JavaScript代码中不经过服务器。例如一段不安全的JS代码从URL的hash部分#后面获取数据并动态写入页面var data decodeURIComponent(location.hash.substr(1)); document.getElementById(message).innerHTML data;攻击者可以构造URLhttp://example.com/page#img srcx onerroralert(XSS)导致脚本执行。在ctfshow、ctfhub的XSS挑战中你会遇到各种过滤比如将、转义成lt;、gt;这就是所谓的尖括号转义。绕过的方法包括利用事件处理器img srcx onerroralert(1)不需要闭合标签。利用JavaScript伪协议a hrefjavascript:alert(1)click/a。在DOM型XSS中如果innerHTML被转义可以尝试innerText或document.write等不同的输出点。4.2 如何有效防御XSS防御XSS的核心是区分“数据”和“代码”对用户输入进行正确的编码/转义并设置严格的内容安全策略。对输出进行编码HTML转义这是最普适的防御措施。在将不可信数据输出到HTML页面时必须根据上下文进行编码。输出到HTML标签内容textContent将,,,,分别转义为amp;,lt;,gt;,quot;,#x27;。几乎所有后端模板引擎如Thymeleaf, Freemarker, Jinja2都默认开启或提供了自动转义功能。输出到HTML属性值除了上述字符空格也需要视情况处理。最好总是用引号包裹属性值。输出到JavaScript代码或事件处理器如onclick这非常危险应尽量避免。如果必须需使用JavaScript专用的编码如\uXXXX形式的Unicode转义。输出到URL如果用户输入要作为URL的一部分需要使用URL编码如encodeURIComponent。实操心得不要试图用黑名单过滤script、onerror等来防御XSS绕过方法太多。坚持使用白名单只允许安全的标签和属性如富文本编辑器场景和上下文相关的编码才是正道。使用现代前端框架React、Vue、Angular等框架在设计上就考虑了XSS防护。它们默认会对渲染到DOM中的数据进行转义。例如在React中使用{}插入变量是安全的但使用dangerouslySetInnerHTML就需要你格外小心确保内容可信。设置Content-Security-PolicyCSP这是一个强大的浏览器安全特性通过HTTP响应头来告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行。一个严格的CSP可以极大地缓解XSS的影响。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;这个策略表示默认只允许加载同源资源脚本只允许同源和指定的CDN样式允许同源和内联样式unsafe-inline是宽松策略理想情况应避免。即使攻击者成功注入了script标签如果该脚本的源不在白名单内浏览器也不会执行它。使用HttpOnly Cookie将敏感的会话Cookie标记为HttpOnlySet-Cookie: sessionIdabc123; HttpOnly这样JavaScript就无法通过document.cookie访问它。即使网站存在XSS漏洞攻击者也无法直接窃取用户的会话凭证。5. 让服务器“内讧”SSRF漏洞剖析SSRF服务器端请求伪造是一种由攻击者构造请求让服务器向内部或外部的任意地址发起请求的攻击。它危害巨大因为攻击者可以利用受信任的服务器作为跳板去探测或攻击内网中那些本应被防火墙保护的服务。5.1 SSRF的常见触发场景与危害功能设计缺陷很多Web应用提供了“网页抓取”、“URL预览”、“文件导入”、“网络诊断”等功能。例如一个社交网站允许用户输入头像URL服务器会去抓取这个URL的图片并保存。如果这个功能没有对URL做任何限制攻击者就可以输入file:///etc/passwd来读取服务器本地文件或者输入http://192.168.1.1/admin来探测内网管理后台。引用外部资源比如在Markdown编辑器里插入图片如果服务器为了生成缩略图或验证图片会主动去请求这个URL。利用协议和URL解析差异这是SSRF攻击中非常狡猾的一点。攻击者可以利用浏览器、服务器、库之间对URL解析的差异来绕过防御。利用符号http://expected-hostattacker-host。一些旧的解析器可能会将前面的部分认为是认证信息实际请求的是attacker-host。利用IPv6地址和[]http://[::ffff:127.0.0.1]:8080可能被解析为访问本地环回地址。利用DNS重绑定攻击者控制一个域名其DNS记录TTL极短。第一次解析时返回一个合法的外网IP通过校验服务器发起请求时DNS再次解析返回一个内网IP如127.0.0.1从而成功攻击内网。这就是所谓的“未知SSRF”或需要高级技巧的SSRF。它的危害包括攻击内网服务扫描内网存活主机和端口攻击Redis、MySQL、Memcached等未授权访问的内网服务。读取本地文件利用file://、gopher://、dict://等协议。绕过认证如果内网应用采用IP白名单或基础认证服务器发起请求时会自动带上这些信任关系。5.2 防御SSRF的层层设防防御SSRF需要从多个层面共同构建防线因为攻击者总会寻找最薄弱的一环。输入校验与白名单这是第一道也是最重要的防线。协议白名单只允许http://和https://。明确拒绝file://、gopher://、dict://、ftp://等危险协议。目标地址黑名单/白名单黑名单禁止请求内网IP、回环地址127.0.0.1、localhost、链路本地地址169.254.0.0/16等。但黑名单可能被绕过如用127.0.0.1.nip.io域名解析到本地。白名单推荐如果业务明确只允许请求有限的、已知可信的外部域名或IP。这是最安全的方式。统一出口与网络隔离设置网络访问控制运行Web应用的服务器DMZ区与核心内网业务服务器如数据库之间应设置严格的防火墙策略限制DMZ区服务器对内网的访问权限遵循最小权限原则。使用专用出站代理所有需要外发请求的服务统一通过一个配置了严格白名单的代理服务器进行。这样即使应用层存在漏洞网络层的限制也能起到作用。响应处理限制服务器请求的响应时间、响应大小防止被用于发起DoS攻击或读取大文件。不要将请求的原始响应内容直接返回给前端用户。如果业务需要如URL预览应对返回的内容如图片、文本进行严格的检查和过滤防止成为XSS等攻击的二传手。代码层面使用安全的库使用诸如url.parseNode.js注意旧版本有问题、Java的URI类等标准库来解析URL并仔细检查解析后的host、protocol等属性避免使用正则表达式做简单的匹配容易出错。6. 实战中的组合拳与纵深防御在实际的渗透测试或CTF比赛中漏洞往往不是孤立存在的。攻击者会像玩解谜游戏一样将各种基础漏洞组合起来形成一条完整的攻击链攻击路径。一个假设的攻击场景攻击者首先发现一个反射型XSS漏洞但无法直接窃取Cookie因为设置了HttpOnly。他利用这个XSS让受害者的浏览器向网站内部一个存在SSRF漏洞的端点发起请求因为浏览器发起的请求会携带用户的Cookie所以这个请求是“已认证”的。这个SSRF漏洞被用来攻击内网的一个Redis服务未设置密码。通过构造特定协议的数据包如使用gopher协议攻击者可以向Redis写入数据。攻击者将一条恶意的PHP代码写入网站服务器的临时目录并通过Redis配置使Web服务器将其作为PHP文件执行最终获得一个Webshell完全控制服务器。这个链条里XSS是入口SSRF是桥梁内网未授权访问的Redis是目标。防御这样的攻击就需要纵深防御思想在每一个环节都设置防护即使一道防线被突破还有其他防线阻止攻击者达成最终目标。第一层安全编码。做好输入验证、输出编码使用参数化查询杜绝SQL注入和XSS的产生。第二层应用配置。设置严格的CSP、HttpOnly Cookie使用最小权限的数据库账户。第三层服务器与网络配置。及时更新系统和中间件补丁配置严格的防火墙规则隔离网络区域。第四层安全监控与响应。部署WAF、IDS/IPS监控异常日志如大量502错误、异常的本地请求建立应急响应流程。Web安全不是一个可以“一键修复”的模块它需要开发、运维、测试各个角色在软件生命周期的每个阶段都保持安全意识。从写出第一行安全的代码开始到设计一个安全的架构再到部署时进行安全的配置每一步都算数。别再让那个unexpected status 502 bad gateway的错误成为你系统被攻破的第一次警报。