下列选项中哪一项是跨站点脚本攻击漏洞

某天深夜，下列选项某电商平台的中项订单系统突然涌进大量异常请求。安全工程师老周打开日志，跨站发现攻击者往商品搜索框里塞了一段<script>alert(document.cookie)</script>，点脚洞页面居然原样执行了。本攻这不是击漏病毒，也不是下列选项暴力破解——这是典型的跨站点脚本攻击，业内简称XSS。中项

XSS漏洞的跨站本质，是点脚洞程序把用户输入当成了代码来执行。攻击者不需要攻破你的本攻服务器，只需要找到一个没过滤输入的击漏地方，把恶意脚本注入进去，下列选项等别的中项用户访问页面时，脚本就在他们的跨站浏览器里跑起来。偷Cookie、篡改页面、伪造登录表单，全看攻击者心情。

最常见的类型叫反射型XSS。你点开一个带参数的链接，比如http://example.com/search?q=苹果，服务器把“苹果”这个词原样塞回HTML页面。攻击者把“苹果”换成恶意脚本，再把这个链接发给你，你一戳，脚本就在你的浏览器里执行了。整个过程就像回音壁——你喊什么，它反弹什么，只不过反弹回来的可能是一把刀。

存储型XSS更阴险。攻击者把恶意代码存在服务器数据库里，比如论坛签名栏、评论区、用户昵称。每个浏览这个页面的用户都会中招，根本不需要点链接。2018年某知名开源论坛就栽在这上面，攻击者在个人简介里藏了段脚本，管理员一登录后台就自动执行，直接拿下管理员权限。

还有种DOM型XSS，不走服务器，纯粹在前端JavaScript里捣鼓。页面用document.getElementById().innerHTML直接插入用户输入，浏览器解析时就炸了。这种漏洞特别难发现，因为攻击流量根本不经过服务器日志，静态分析工具也经常漏报。

回到开头那道选择题——到底哪一项是跨站点脚本攻击漏洞？关键看三条：输入有没有被当作HTML或JavaScript解析？有没有输出到页面？有没有绕过转义？如果某个输入框把<script>标签原样存进数据库，那百分百中招。如果程序用了htmlspecialchars()或者等价函数转义了尖括号，那基本安全。最怕的是那种“半吊子”过滤——只拦了<script>，没拦<img onerror=alert(1)>，照样能打。

我见过不少开发者觉得“反正我这是内部系统，没人攻击”。结果呢？内部员工一个随手粘贴的富文本，就能把整个后台搞瘫痪。XSS不挑系统大小，只挑代码里有没有信任用户输入的地方。写代码时多写一行转义函数，比事后排查省事一百倍。

所以，判断XSS漏洞的标准很简单：用户能不能通过输入改变页面行为？如果能，且没做任何过滤，那答案就是它。