做技术这么多年跟XSS和SQL注入这两个老伙计打交道次数太多说实话前端工程师往往把安全当作后端的事后端又觉得XSS是前端的锅结果漏洞就藏在责任缝隙里。我见过不少项目上线前被安全扫描打回问题就出在几个输入框上也见过核心数据被拖库源头只是一段没处理好的查询拼接。这篇博文我会把前端XSS攻击与SQL注入从原理到防御拆开揉碎讲清楚结合实际代码案例给出能直接落地的防护方案适合刚入门的前端开发、写接口的后端同学以及负责项目安全评审的测试和架构同事参考。1. 前端XSS攻击的核心形态与中招场景1.1 三种XSS攻击类型存储型、反射型、DOM型XSS的全称是Cross-Site Scripting跨站脚本攻击。它本质上是攻击者把恶意脚本“注入”到你的页面里让浏览器执行不该执行的JavaScript。根据恶意脚本的“藏身位置”和“触发方式”业内一般把它分成三类。存储型XSS是最危险的一种。攻击者把恶意脚本提交到服务器数据库里比如在用户名、评论内容、文章标题这类需要长期保存的字段中写入scriptalert(1)/script。当其他用户访问页面、后端把这段内容从数据库取出来渲染到HTML里时脚本就在受害者浏览器中执行了。这类攻击的杀伤力在于“持久化”——一次提交所有人中招传播范围不可控。反射型XSS不落库恶意脚本藏在URL参数、搜索关键字、表单提交报错信息中由服务端直接拼进返回的HTML。典型场景是搜索页回显用户提交?keywordscript.../script服务端把keyword原样吐到页面上浏览器解析就执行了。它需要诱导用户点击构造好的恶意链接属于“定向投递”。DOM型XSS更隐蔽纯前端就出问题恶意脚本根本不经过服务端。前端代码用innerHTML、document.write、location.href等API把用户可控的内容插入页面攻击者利用window.name、location.hash、postMessage等浏览器端数据触发执行。我排查过一个案例服务端返回的数据完全干净但前端某段富文本预览逻辑用了v-html直接渲染照样被注入。1.2 XSS攻击能干什么不只是弹个窗很多人觉得XSS就是弹个框、改个页面文案实际危害远不止这些。攻击者拿到执行权限后能做的第一件事就是偷Cookie。Cookie里通常存着会话标识Session ID一旦被document.cookie读取并通过网络发给攻击者攻击者就能直接“借用”受害者的登录态这一步叫会话劫持不需要密码就能登录你的账号。除了偷CookieXSS还能做用户行为监控。脚本可以监听键盘输入、截获表单数据账号密码、支付信息、身份证号都可能被静默窃取。2018年前后某社交平台就是靠XSS注入读取了数千万用户的私信内容这说明一旦前端被攻破整个用户信任体系就崩了。还有一类利用方式是钓鱼与挖矿。攻击者通过XSS篡改页面局部内容伪造登录弹窗、充值提示诱导用户输入敏感信息或下载恶意文件。更有甚者脚本在后台调用浏览器挖矿脚本用用户设备挖虚拟货币这种危害用户几乎无感知。1.3 一套够用的XSS防御组合拳防御XSS的核心思路只有一条用户输入一律不可信输出到页面时必须做上下文感知的编码与过滤。具体分四层来做。第一层是输出编码转义。在HTML上下文需要把转成lt;转成gt;转成amp;转成quot;转成#39;。在JavaScript字符串上下文需要对引号、反斜杠、换行符做转义。在URL上下文需要用encodeURIComponent处理用户拼接的参数值。Vue的插值语法{{ }}、React的{}表达式输出都会自动做HTML转义这就是为什么推荐优先用插值而不是v-html或dangerouslySetInnerHTML。第二层是富文本白名单过滤。业务上确实需要用户提交带格式的HTML内容比如富文本编辑器这类场景不能简单转义因为标签如果被转义就没有格式效果了。通常做法是使用成熟的HTML解析库把标签、属性、事件处理逐一过滤。无论是哪套成熟方案原则都一样只允许白名单内的标签和属性事件绑定属性onclick、onerror、onload等一律剔除javascript:协议一律不允许style、script、iframe这些高风险标签直接丢弃。第三层是CSP内容安全策略。CSP是浏览器层面的一道强防御网通过HTTP响应头Content-Security-Policy限制页面允许加载和执行的资源。核心配置项有script-src限制脚本来源default-src作为兜底img-src限制图片域名frame-ancestors阻止页面被嵌入iframe。合理配置下即使攻击者把脚本注入到页面浏览器也会因为来源不合法而拒绝执行。建议至少配置script-src self线上如果依赖外部CDN再把对应域名加入白名单。第四层是Cookie安全属性。给会话Cookie加上HttpOnly标记后document.cookie就读取不到这个Cookie了直接切断了XSS偷Cookie的通路。同时加上Secure属性保证Cookie只在HTTPS连接中传输。SameSite属性可以限制跨站请求携带Cookie对CSRF也有防御效果。注意这四层不是选做项而是叠加关系。输出编码是基础富文本过滤是业务刚需CSP是纵深防御HttpOnly是最后一道保险。四层都做了才能称得上“够用”。2. SQL注入的攻击链与参数化查询防线2.1 从一句拼接SQL看透注入原理SQL注入发生在数据查询代码把用户输入直接拼进SQL语句的场景。看一个经典漏洞代码String sql SELECT * FROM users WHERE name userName AND password passWord ;如果用户提交的用户名是admin --拼出来的SQL变成SELECT * FROM users WHERE name admin -- AND password --在SQL里是注释符后面的条件全部被注释掉攻击者不需要知道密码就可以通过这一条查询。更极端的写法是admin OR 11这会直接绕过身份校验。注入还能叠加其他语句如果JDBC的Statement允许执行多条语句攻击者可以追加; DROP TABLE users;这就会造成毁灭性打击。注入位置不仅限登录框。搜索关键字、排序字段、分页参数、订单号、文件下载名凡是进入SQL语句的数据都可能成为注入点。排序场景尤其隐蔽很多开发直接用order by拼接前端传来的列名因为排序字段没法预编译攻击面就出现了。文件下载场景如果文件名是从数据库查出再拼路径同样可能被利用做目录穿越。2.2 参数化查询为什么是“治本”方案很多人以为SQL注入防御就是过滤关键字于是写正则屏蔽or、select、union这类词。这个思路方向就错了而且很容易被绕过。举例说攻击者可以用注释符分割关键字uni/**/on也可以用十六进制编码0x73656c656374绕过简单关键词过滤。黑名单永远不可能穷尽攻击手法。参数化查询PreparedStatement能治本的原理在于SQL语句结构在服务端提前编译用户输入只作为“参数值”传入而不是作为“SQL代码”拼接。数据库对参数值的解析发生在编译之后输入的引号、注释符、关键字都只是普通字符串不可能改变SQL的执行结构。类比生活会更容易理解。你打印一张带格式的表格参数化查询相当于先锁定表格模板再把数据填进单元格字符串拼接则相当于把数据直接混进表格的格式定义里内容里如果出现格式控制符表格结构就废了。XSS的本质问题在于“数据与代码混在一起”所以治本就需要让数据和代码分离参数化查询正是这种隔离思想在SQL世界的落地。2.3 实操PDO预处理与ORM的落地写法以PHP PDO为例参数化查询的标准写法是$stmt $pdo-prepare(SELECT * FROM users WHERE name :name AND password :pass); $stmt-execute([:name $userName, :pass $passWord]);注意prepare里面只有SQL结构参数全部用占位符:name替代。execute时传入的参数数组与占位符一一对应PDO内部会完成参数转义与类型绑定。另一个写法是使用?问号占位符按参数顺序传递$stmt $pdo-prepare(SELECT * FROM users WHERE id ?); $stmt-execute([$id]);两种写法等价但项目稳定期建议统一用命名占位符代码可读性更高参数一多也不容易顺序错乱。Java场景的JDBC预编译写法String sql SELECT * FROM users WHERE name ? AND password ?; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, userName); ps.setString(2, passWord); ResultSet rs ps.executeQuery();这里setString会自动处理引号等特殊字符不要自己手动拼接。如果项目用了MyBatis#{}就是预编译参数化写法会生成PreparedStatement占位符而${}是字符串拼接直接拼接变量内容。框架层面有一条红线业务SQL一律使用#{}禁止${}传参。${}的合法用途只限于必须动态拼接的结构性内容如表名、排序字段且必须与固定的白名单映射表配合。ORM框架如MyBatis-Plus、Sequelize、SQLAlchemy默认自带参数绑定能力只要不手写裸SQL就安全得多。注意MyBatis里如果写了Provider注解自定义SQL同样要走参数绑定链路不能图省事直接字符串拼接。3. 前后端联动的纵深防御实践3.1 输入校验别只靠正则要有“双重校验”安全领域有个经典认知所有输入都是不可信的直到被证明安全。输入校验不能只依赖前端因为前端脚本可以被绕过——攻击者直接用HTTP工具发请求前端约束形同虚设。正确的姿势是前后端都要做校验前端校验的目的是提升交互体验后端校验才是真正的安全防线。后端校验分两个层面。语法校验检查格式手机号是否符合正则邮箱是否包含年龄是否在合理数值范围枚举字段是否在白名单内。语义校验检查业务约束订单号是否归属当前登录用户操作状态是否允许流转请求频次是否异常。数据格式错误直接返回400没必要进业务逻辑。这里给出一个经过实践验证的校验规则制定方案字段类型用强类型限制整型参数必须强转int而不是字符串比较枚举值用白名单数组校验文本字段设置最大长度和字符集白名单如仅允许中文、英文、数字和常规标点JSON请求体制定义严格Schema拒绝未知字段。3.2 统一安全出口别让每个接口“各自为战”常见的漏洞根源是每个开发各自写了一套过滤逻辑有的过滤严有的过滤松只要有一个出口漏了整条链就破了。我在项目中推行过一个策略前后端分别建立统一安全出口组件。前端层面封装一个全局输入清洗函数库所有对接后端的数据在提交前都要经过统一的sanitizeInput处理。该函数按字段类型做分层防护字符串类型做HTML实体编码转换同时剥离危险协议头数值类型做取整与范围钳制URL类型用new URL()做合法性和协议白名单校验只允许http:和https:。后端层面提供公共安全SDK统一处理四件事参数合法性校验、SQL注入关键字层过滤、输出编码、统一异常响应结构。尤其注意异常信息不能直接把原始SQL、堆栈、数据库类型抛给用户统一替换为“系统繁忙请稍后重试”。这类统一出口做法还有一个额外收益——安全配置变更时只需要改一处就能全局生效。比如发现某个编码库有漏洞升级公共组件即可覆盖所有接入方不需要各业务线重复改造。3.3 三层纵深防御体系前端、后端、运行时我总结了一套适用于中大型项目的前后端联动防御体系按“事前-事中-事后”三个维度落地层面防御手段保障内容前端事前插值渲染、CSP限制、HttpOnly Cookie、输入清洗从源头降低XSS载荷进入页面的概率后端事中参数化查询、输出编码、参数校验、权限控制阻断SQL注入与持久化XSS的攻击链运行时事后安全日志、WAF规则、异常监控、访问频率限制防御绕过及时发现并封控攻击行为前端CSP如果配置了script-src self即使某个后端字段意外输出了可疑脚本浏览器也会拒绝执行这就是运行时兜底的价值。后端日志里如果出现大量 OR 11特征参数WAF应该能直接拦截并触发告警。安全不可能是某一次加固就完事而是多层防护的动态对抗过程。4. 常见问题与排查技巧实录4.1 高频问题速查表我在实际项目中遇到的高频问题整理成速查表供参考问题现象根本原因排查与解法富文本内容导致页面样式错乱过滤仅转移了标签未处理style属性富文本过滤时剥离style属性或使用安全的CSS清洁库参数化查询后SQL仍报错传入参数类型不匹配数值字段用了字符串断言参数类型用bindValue显式指定类型PDO::PARAM_INTXSS脚本在页面源码可见但未执行CSP策略正确生效无需改动确认HTTP响应头存在CSP且规则正确中文内容被转义后变成乱码编码函数使用不当或字符集不一致统一项目字符集UTF-8编码函数与输出上下文匹配搜索框输入被数据库拒绝被当成了SQL结构字符改用参数化查询不依赖前置过滤同时检查是否用了${}拼接排序字段没法参数化怎么办排序字段是结构签名不能占位建立字段白名单映射前端传索引/名称后端映射为固定SQL片段新开发的接口遗漏了安全检查接入统一安全组件意识不足代码评审加安全检查项接入SDK后强制走统一校验入口第七个问题我特别说一句团队里总有新同学不了解套路写的接口直接绕过公共校验组件。纪律性解决方案是把安全校验做进框架基础拦截器里对每个请求强制执行而不是期望每个开发者记得去调用公共函数。4.2 一次XSS事件排查复盘某次测试环境反馈在某个动态渲染用户昵称的位置出现弹窗。初步排查服务端日志字段值确实是脚本文本。再查源头发现管理员后台导入Excel数据时昵称列未经过滤就入库了。更隐蔽的是该导入接口走的是独立逻辑完全没有经过公共清洗组件。复盘结论是数据入口不止常规表单文件导入、API对接、消息队列消费都是潜在的绕过路径。清洗逻辑必须做成全局拦截或公共基建而不是在业务代码里使用“手写过滤”。如果要根除这类问题建议在数据访问层做“入库前统一校验出库时统一编码”双保险覆盖所有入口和出口。4.3 异常请求的特征识别与处置排查安全问题离不开日志和监控。可用日志记录用户会话ID、请求路径、参数内容、来源IP、User-Agent存入独立的访问日志库。对参数中出现的单引号、--、union、select、script等特征做计数告警也可以在上线前根据业务正常行为建立基线偏离基线的高危请求进入静默观察队列。被判定为攻击的IP可以在网关层限流或拉黑但要注意操作要快、误判要少。曾经出现过正常用户在昵称里写“选秀select联盟”被误判成注入的情况所以规则引擎适合做“初筛人工复核”不要一刀切封死业务。5. 实操心得与最终建议做了几年安全对抗和加固我自己最大的体会是XSS和SQL注入虽然是两类完全不同的漏洞但防御思路是相通的——根子上都是“数据与代码分离”这个原则没有做到位。前端防御XSS的核心就是绝不让用户输入直接成为可执行代码后端防御SQL注入的核心就是绝不让用户输入直接拼接进SQL结构。这两个原则只要在团队里形成肌肉记忆大部分高危漏洞根本不会出现。最后再分享一个我踩过多次坑之后总结出的自检清单每次上线前过一遍所有输出到HTML的内容是否经过上下文编码富文本是否走了白名单过滤库所有SQL是否已用参数化查询是否存在${}拼接登录态的Cookie是否带上了HttpOnly和SameSiteCSP是否配置上线环境是否还能注入脚本文件导入、消息队列等非常规入口是否也过了清洗逻辑安全是持续对抗没有一劳永逸。把防御做进框架和基建层面让开发者不需要每次手写安全处理才是可持续的方案。这套方法在我参与过的多个项目里跑得很稳照着搭一层至少能把绝大多数脚本小子挡在门外。