常见Web漏洞原理与防御：SQL注入、XSS、越权、文件上传

直接说结论大部分所谓的“被黑”事件根子都出在几个常见漏洞上。搞安全这些年我见过太多开发者和运维被同一块石头绊倒。今天不聊那些玄乎的高级利用链就踏踏实实把几个高频漏洞的原理、利用条件和防御方案掰开揉碎讲清楚。这篇文章是给写代码的人、做运维的人、以及刚入行想做安全的人看的目标只有一个——让你看完之后能对自己负责的系统做一次有效的自查。很多人一听到“漏洞”两个字脑子里就是黑客、木马、提权这些电影情节。实际上日常工作中遇到的绝大多数安全问题都源于代码层面的逻辑缺陷或者配置层面的疏忽。一个SQL注入能脱库一个越权能看遍全站用户数据一个上传点没做好能直接拿到服务器权限。这些不是耸人听闻而是每天都在发生的事情只是大多数没有被公开而已。1. 漏洞的核心成因与分类逻辑要理解漏洞先要理解漏洞是怎么来的。抛开复杂的攻击链不谈所有漏洞的根源都可以归结为一句话程序对用户输入的处理超出了预期范围。这句话听起来简单但展开讲就很有内容了。1.1 从“输入”到“信任”的失控程序本质上是在处理数据而数据从哪里来除了开发者自己写的常量剩下的几乎都来自用户输入。这个“用户输入”的范围比很多人想象的要宽得多不止是你在网页表单里填写的用户名和密码还包括HTTP请求头、Cookie、URL参数、上传的文件内容、甚至是你从第三方接口拉取的数据。问题就出在“信任”上。程序默认认为这些输入是“安全”的、“符合预期”的而没有去验证它们真的是否如此。当攻击者构造一个超出预期的输入比如在用户名那里填了一段SQL语句程序就傻乎乎地把它拼接进数据库查询里执行了——这就是SQL注入的起点。我曾见过一个真实的案例。某内部管理系统的登录接口开发为了方便调试在代码里留了一个万能密码的后门。后来这个后门被扫到了攻击者用起来比正常用户还顺畅直接以管理员身份登录导走了所有客户的联系方式。这个案例里没有用到任何高深的0day就是一个简单的逻辑漏洞加上一个不严谨的开发习惯。这就是“信任”失控的典型。1.2 常见漏洞的家族图谱漏洞分类的方式有很多种业内最常参考的是OWASP Top 10它每几年更新一次反映了当前最普遍、最危险的安全风险。这里不把整个榜单搬过来只说几个在实战和代码审计中最常遇到的“老朋友”。第一个是注入类漏洞Injection包括SQL注入、命令注入、LDAP注入等。它的核心就是前面说的恶意代码被当作数据拼进了“解释器”里执行。SQL注入是最老牌的漏洞也是危害最大的之一因为它直接面对数据库可以读数据、改数据、删数据。第二个是XSS跨站脚本攻击。这个漏洞的可怕之处在于它攻击的是“用户”而非“服务器”。攻击者把JavaScript代码注入到页面里当正常用户访问这个页面时脚本就在用户的浏览器里执行了。轻则弹个窗、改个页面重则直接窃取用户的登录凭证Cookie实现账户接管。第三个是文件上传漏洞。只要业务需要用户上传文件头像、附件、图片就存在这个风险。如果服务端没有严格校验文件类型和内容攻击者很可能上传一个WebShell一种网页木马拿到服务器的执行权限。这个漏洞的杀伤力是“秒杀”级的一旦利用成功整个服务器就沦陷了。第四个是越权漏洞又分为水平越权和垂直越权。水平越权就是我能看到和我同级别的其他用户的数据比如用户A登录后把URL里的用户ID换成用户B的就能看到B的订单记录。垂直越权则是我一个普通用户能调用管理员才能执行的接口。这类漏洞完全是逻辑层面的没有任何攻击载体纯粹是后端接口没校验当前操作者的权限。这四个家族占了日常安全工作里七八成的精力。后面的篇幅会逐个把它们的原理、利用方法和防御拆开讲。2. SQL注入原理、实战与参数化查询SQL注入是老生常谈但现在依然稳坐着漏洞榜的头把交椅。只要还有人在用字符串拼接的方式写SQL语句这个漏洞就会一直存在。2.1 一次典型的注入过程还原假设后端代码是这样的$id $_GET[id]; $sql SELECT * FROM products WHERE id $id; $result mysqli_query($conn, $sql);这段代码的逻辑很清晰根据URL里传过来的id参数查询对应的商品信息。正常情况下用户访问/product.php?id1看到的就是第1个商品。但攻击者只需要把id的参数改成1 AND (SELECT 1 FROM (SELECT SLEEP(5))a) -- -原本的SQL语句就变成了SELECT * FROM products WHERE id 1 AND (SELECT 1 FROM (SELECT SLEEP(5))a) -- -这会让数据库执行一个延迟5秒的操作。如果页面响应时间也变成了5秒就说明攻击者注入的代码被执行了——这是一个标准的“时间盲注”探测手法用延时判断是否存在SQL注入即使页面上什么都不显示也能用。在实战中攻击者不会满足于“探测是否存在”他们会用UNION SELECT来拼接出自己想要的数据或者用报错注入比如extractvalue函数直接回显数据库版本、当前用户、库名、表名、字段名一步步把整个数据库的结构摸清楚然后精准地拖走目标数据。2.2 为什么“过滤”和“转义”靠不住很多开发者的第一反应是那我把单引号、双引号、分号这些都过滤掉不就行了这里必须先说一个残酷的现实基于黑名单的过滤永远是可以绕过的。就拿替换单引号来说攻击者可以用char(39)这种函数来替代单引号的输入或者用URL编码、十六进制编码等方式打一套组合拳。数据库和脚本语言的编码差异、各种稀奇古怪的函数特性都给绕过过滤提供了大量机会。真正稳妥地解决SQL注入的方案只有一个参数化查询Prepared Statement。$stmt $conn-prepare(SELECT * FROM products WHERE id ?); $stmt-bind_param(i, $id); $stmt-execute();这段代码的精髓在于SQL语句的结构和用户输入的数据被彻底分开了。?是占位符数据库会把这个位置当成纯粹的数据值而不是可执行代码。就算用户传入的是1 OR 11它在数据库眼里也只是一串字符串不会参与语法解析注入自然就失去了效果。注意在任何语言的数据库驱动里都优先使用参数化查询。Java的PreparedStatement、Python的?占位符、Go的$1占位符原理完全相同。2.3 防御纵深不止是参数化光有参数化查询还不够一个负责任的安全方案至少有三层。第一层严格校验输入格式。如果这个参数是数字类型比如id就在后端用is_numeric或者正则表达式校验它必须是纯数字。如果它是个邮箱就校验它必须符合邮箱格式。只要类型符合预期攻击者的注入语句根本没有发挥空间。这里建议“正向校验”也就是白名单思路。与其过滤掉所有的非法字符不如只允许规定格式的合法数据通过。第二层最小权限数据库账户。很多公司为了省事业务系统连接数据库直接就用root或者DBA权限的账户。这种习惯极其危险。一旦发生注入攻击者数据库里为所欲为什么都能干。正确的做法是每个业务系统单独建一个数据库账号只给它该业务库的SELECT、INSERT、UPDATE、DELETE权限绝不能给FILE、GRANT这类高危权限。这样即使被注入攻击者能做的最多就是操作那些表无法跳出数据库去读写服务器文件。第三层Web应用防火墙WAF兜底。对于比较老的项目可能一时半会儿改不动代码那就在前面挡一层WAF通过规则拦截明显的攻击流量。但WAF是“事中拦截”代码修复才是“源头治理”。别把WAF当成万能的护身符它很容易被绕过。3. XSS跨站脚本从反射型到存储型XSS的知名度可能不如SQL注入但在实际场景中它的出现频率和危害性一点也不逊色。而且因为XSS最终作用在浏览器端很多后端开发者对它缺乏直观的认识容易低估风险。3.1 XSS的三种常见形态按照“是否存储、是否经过服务器”可以把XSS分为三类。反射型XSS是最直观的。攻击者把恶意脚本放在URL里诱导受害者点击这个链接。服务器收到请求后把URL里的参数作为报错信息或搜索结果直接反射到页面HTML里。脚本不需要存储到服务器只在用户的浏览器里执行一次。存储型XSS则更“持久”。攻击者把一个包含恶意脚本的内容比如一条论坛帖子、一个昵称、一段评论提交到服务器服务器把它存储在数据库里。之后任何一个用户访问这个页面都会加载这段恶意脚本并执行。存储型XSS的危害面最大因为受害者完全不需要点击什么特殊链接只要正常浏览网站就会中招。DOM型XSS跟前两者不太一样甚至不需要经过服务器。它完全是前端JavaScript的行为通过修改页面的DOM节点来执行恶意代码。比如Web页面用document.location读取URL参数然后直接通过innerHTML插入到页面上这种操作就会造成DOM XSS。3.2 一个“弹窗”演示背后的真实危害很多人觉得XSS不就是弹个窗吗有什么大不了的这种观念需要纠正一下。攻击者在XSS里注入的JavaScript可以做任何事包括但不限于窃取Cookie。代码里通过fetch把document.cookie发送到攻击者的服务器。如果Cookie里带有会话标识session token攻击者就可以把这个Cookie放到自己的浏览器里直接“伪装”成受害者登录这就是经典的“会话劫持”。钓鱼。在页面上注入一段伪造的登录框诱导用户输入账号密码。用户看到的是正规网站的页面但数据已经流向了攻击者的服务器。键盘记录。页面上监听用户的所有键盘输入用户输入的任何内容包括支付密码、聊天内容都会被记录下来。所以XSS的破坏力不亚于SQL注入。它利用的是“用户对网站的信任”——用户在正规站点上看到的东西天然地认为是安全的。这种信任被滥用才是最大风险。3.3 输出编码是唯一正解XSS的防御核心总结成一句话不要信任任何来自外部的数据在输出到HTML时都要经过适当的编码。按照输出位置不同编码策略也不同。如果数据要输出在div标签的文本内容里需要做HTML实体编码把变成lt;把变成gt;。如果数据要输出在script标签里那需要的是JavaScript编码\x22等格式。如果数据要输出在URL属性里则要先做URL编码。这些细节看起来很琐碎但直接影响安全性。现在的主流前端框架比如Vue、React在默认情况下都会对插值表达式做转义处理直接用{{ data }}是安全的。但要注意如果用了v-html或dangerouslySetInnerHTML这类直接渲染HTML的指令等于跳过了框架的默认编码必须保证传进去的内容是绝对安全的。实操建议制定一条开发规范——项目中所有富文本内容的上传一律做白名单过滤只允许p、strong、a这类核心的简单标签其余的全部剥掉。宁可损失一点样式也不要冒存储型XSS的风险。4. 身份认证与越权漏洞看不见的逻辑陷阱比起注入和XSS这种“代码问题”越权漏洞则完全是“逻辑问题”。它不涉及复杂的攻击载荷也不需要绕过什么过滤——攻击者只是正常地使用功能只不过在请求中“动了手脚”。这恰恰是最阴险的地方因为常规的WAF和扫描器很难发现它们。4.1 水平越权为什么“改个ID”就能看别人的数据水平越权是极其常见的一个漏洞。它的产生原因非常直接后端在处理请求时没有校验“当前的用户”是否拥有“被操作的资源”。看一个典型的错误代码逻辑。一个订单详情接口的伪代码GetMapping(/api/order/{orderId}) public Order getOrder(PathVariable Long orderId) { // 直接查订单 return orderService.getOrderById(orderId); }这段代码只处理了一件事根据URL路径里的orderId去查询订单并返回。它完全没有确认“查询这个订单的人”是不是“这个订单的主人”。于是攻击者的操作就变得非常简单用自己的账号登录访问/api/order/1001然后再换成/api/order/1002、/api/order/1003……只要订单号是连续数字就能把所有其他用户的订单信息遍历出来。这是标准的水平越权。防御的核心原则是任何涉及资源访问的接口都必须校验“资源所有者”。在返回结果之前先查一下这个订单所属的用户ID是否等于当前登录用户的ID。如果不等直接返回403或404绝不返回数据。4.2 垂直越权权限校验不能只看前端垂直越权比水平越权更危险因为它意味着普通用户可以做管理员才能做的事情比如创建账号、修改权限、删除数据。它产生的原因也很常见很多项目在开发时只是在前端把某些菜单和按钮“藏起来”不给普通用户看而后端接口没有任何权限校验。攻击者不需要猜测接口地址它可能就在前端的JavaScript文件里躺着。用普通用户身份直接调用管理员的接口后端照样放行。防御垂直越权的方法是在后端做统一的权限拦截器或中间件。每个接口都标注所需权限比如RequiresPermissions(user:delete)由框架层统一拦截判断当前登录用户是否具备这个权限标识。这样就算前端界面显示不显示后端也会在真正执行前挡住无权限的请求。4.3 会话管理的规范细节除了越权会话管理本身也有不少坑。首先Session ID会话标识必须是高强度的随机值。有不少老系统用用户ID、时间戳这种可预测的值作为会话标识攻击者完全可以遍历出来冒充任意用户登录。合理的实现是用密码学安全的随机数生成器如random_bytes生成。其次Cookie要设置HttpOnly和Secure属性。HttpOnly能禁止JavaScript读取Cookie这样即使有XSS漏洞攻击者也无法直接通过document.cookie窃取会话。Secure属性保证Cookie只通过HTTPS传输防止在HTTP通道上被截获。第三频繁操作应强制要求重新认证。修改密码、绑定手机号、查看敏感信息这类高危操作不能因为用户已经登录就直接放行而是需要让用户再次输入密码或进行二次验证。这是防止“已登录用户被诱导进行敏感操作”的重要防线。5. 文件上传漏洞从图片到WebShell的演变路径文件上传功能几乎是所有业务系统都有的而它也是最容易获得高权限的一个爆发点。核心逻辑就一句话让用户上传的文件不能在服务器上被当作代码执行。5.1 攻击者如何把“图片”变成“木马”最常见的一种攻击手法是攻击者准备一张正常的图片在图片文件的末尾追加一段WebShell代码内容一般是?php eval($_POST[cmd]);?然后把文件后缀名改成jpg上传。如果后端只校验了文件的扩展名Content-Type或文件头没有检查图片数据的有效性那么这个文件就会被原样保存到服务器上。接下来攻击者利用其他漏洞比如文件包含漏洞把这个“图片”文件包含执行WebShell就激活了。更糟糕的情况是如果服务器配置不当例如Apache的解析特性、Nginx的解析漏洞攻击者可能直接访问/uploads/shell.jpg.php就能把它当PHP执行。一旦WebShell在服务器上运行攻击者就拥有与Web服务进程相同的权限可以在服务器上执行任意命令、下载或篡改文件、甚至利用内网渗透进一步扩大战果。5.2 文件上传的完整防御方案防御上传漏洞需要一套组合拳每一项都不能偷懒。第一扩展名白名单。不要用黑名单去屏蔽php、jsp因为绕过方式太多了比如php5、phtml、pht这些变体扩展名。正确的做法是若业务只允许图片就只放行jpg、jpeg、png、gif等几个明确后缀如果确实需要上传其他类型再按业务场景细化白名单。第二文件内容校验。扩展名白名单可以拦截常规的攻击但防不住前面说的“图片马”。所以还需要校验文件内容。用服务端的图像处理库比如PHP的getimagesize()或Java的ImageIO.read()尝试解析文件如果解析失败就拒绝保存。如果是图片文件就一定能被解析成图片正常文件不会被误判而图片马虽然图片部分能解析但内容里夹带的代码通常也会被剥离前提是后续对图片重新编码处理。第三存储与执行隔离。上传目录必须独立于可执行代码目录。例如不要在上传目录里放任何脚本文件并且通过配置让该目录禁止解析脚本Nginx下可以设置location块让上传目录不解析PHPApache下在目录配置里禁用AddHandler。这样就算恶意文件传到服务器上也只是以“数据”存在无法以“代码”运行。第四随机化文件名。上传的文件名不要沿用用户提供的原始文件名而是服务器随机生成一个不可预测的新文件名比如UUID加扩展名。这一方面防止了文件名路径穿越另一方面也大大增加了攻击者找到并访问这个WebShell的难度。6. 安全编码清单把漏洞扼杀在开发阶段讲完具体的漏洞最后做一个汇总。与其每天在服务器上补丁打不停、WAF规则改来改去不如从源头把漏洞扼杀掉。以下是我在实际代码评审过程中反复强调的安全编码清单建议贴在工位上。输入校验篇所有外部输入表单、URL、请求头、Cookie默认不信任。对参数做“白名单”式的正向校验明确允许的格式和范围。数字类型必须校验范围字符串必须限制长度上限防止缓冲区溢出和超长输入消耗资源。上传文件时校验扩展名、MIME类型和内容。输出编码篇动态数据输出到HTML前做HTML实体编码。动态数据输出到JavaScript、CSS、URL前按对应语义做编码。禁止直接使用innerHTML、v-html等“血液注入”式接口渲染用户输入。所有响应设置正确的Content-Type和X-Content-Type-Options: nosniff。数据库操作篇禁止字符串拼接SQL一律使用参数化查询。业务数据库账户遵循最小权限原则禁止使用高权限账户连接。数据库连接字符串和密码禁止明文写在代码里必须走配置中心和密钥管理服务。逻辑认证篇所有接口都必须先做身份认证再做权限校验。涉及资源ID的请求必须校验当前用户对目标资源的属主关系防止水平越权。高危操作删数据、改密码需要二次确认或重新认证。Session ID使用高强度的随机值并设置HttpOnly、Secure属性。配置部署篇生产环境的报错信息必须隐藏堆栈和SQL语句只显示简洁的错误页面。定期更新依赖组件版本关注官方安全公告修复已公开的CVE公共漏洞披露。Web服务器不以root/Administrator权限运行应用启动账号也必须是独立低权限账号。数据库、Redis等中间件不对外开放公网端口通过内网安全组访问。这套清单不能保证百分百不出问题但遵循它至少能挡掉市面上绝大多数自动化扫描工具和“脚本小子”的攻击。7. 实战排查漏洞发现后的应急响应流程写代码的时候要做好防御但现实往往是你接手一个老项目漏洞已经存在了。这时候该怎么办我建议按照下面这个流程来做应急响应和修复。第一步止血。如果是可利用的漏洞被发现了第一步不是立刻改代码而是先确认是否已经造成实际危害。检查相关日志、服务器文件、数据库操作记录看有没有异常的请求和痕迹。如果确认被入侵先断网或隔离服务器然后备份完整的日志和受影响的数据保留证据。第二步定位漏洞。结合漏洞报告或自己排查的结果找到具体的代码位置和触发路径。这一步要“抠细节”把漏洞的利用链完整画出来否则很容易修漏。举个例子如果你发现了一个上传漏洞不要只把上传接口过滤掉就完事还要排查上传后的文件是否已经被攻击者访问过、服务器的解析配置是不是还存在同样的风险点。第三步修复与验证。修复时建议多管齐下。还是以上传漏洞为例前端加校验、后端加白名单、上传目录关执行权限、文件名随机化。修完之后自己照着漏洞发现时的攻击路径复测一遍确认无法利用。同时跑一遍业务回归确保正常功能没被误伤。第四步追溯与复盘。漏洞修复之后要回答几个问题这段漏洞代码是什么时候引入的为什么当时评审没有发现同类型的代码在项目里还有没有别的地方在用把这些问题整理成复盘文档推动团队的安全意识和开发规范对齐。提示发现漏洞后不要抱着“偷偷修好就行”的心态。安全问题的处理过程文档化很重要既是积累也是保护自己。真要出了事完整的处理记录也是客观的说明材料。我自己在处置安全事件时最深的体会是漏洞本身并不可怕可怕的是对漏洞的无视和漫不经心。很多系统明明被自动化工具扫出了高危漏洞团队却总以“业务太忙、改代码影响大”为由拖着不修直到数据被拖走才追悔莫及。安全工作的本质其实就是在跟“侥幸心理”做斗争。把这篇文章里提到的基础内容真正落到开发和运维流程中你的系统安全性就已经超过了大多数人。最后分享一个屡试不爽的小技巧每上线一个功能都让开发人员自己用“攻击者的思路”来一遍——如果我是一个坏人我最想把这段代码变成什么样只要带着这个问题去写代码和做评审你会发现很多低级的漏洞根本走不到上线那一步。