渗透测试xss
一个搜索结果页面，渗透输入框里敲进一段 ``，测试回车，渗透浏览器弹出一个白框，测试里面就一个数字“1”。渗透这大概是测试每个做渗透测试的人最早接触XSS时的场景。简单、渗透直观，测试甚至有点无聊。渗透但就是测试这个“无聊”的弹窗，背后能扯出的渗透攻击链，远比想象中长。测试 XSS全称跨站脚本，渗透核心就一句话：让受害者的测试浏览器执行攻击者注入的JavaScript代码。注意，渗透是“受害者的浏览器”，不是服务器。这跟SQL注入有本质区别——SQL注入打的是数据库，XSS打的是人。服务器可能完全不知情，它只是忠实地把恶意脚本当作正常内容返回给了用户。 按注入方式分，XSS通常被归为三类：反射型、存储型、DOM型。反射型最“一次性”，恶意脚本藏在URL参数里，服务器把它原样吐回页面，用户点了链接才触发。存储型最危险，脚本被写进数据库，比如评论区、用户昵称、论坛帖子，所有访问该页面的用户都会中招。DOM型则更隐蔽，服务器返回的HTML可能完全正常，是前端JavaScript在操作DOM时把不可信数据当代码执行了。 我见过一个真实案例。某电商平台的商品搜索框，输入关键词后页面会显示“您搜索的是：xxx”。这里没有做HTML实体编码。攻击者构造了一个链接，参数里带上 ` 防御XSS，很多人第一反应是“过滤 另一个常被忽略的点是Cookie的HttpOnly属性。给会话Cookie加上HttpOnly，JavaScript就读不到它。就算XSS成功执行了，攻击者也拿不到最关键的凭证。这不能阻止XSS本身，但能大幅降低危害。CSP（内容安全策略）也是好东西，通过HTTP头告诉浏览器只允许加载哪些来源的脚本，能直接掐死大部分内联脚本执行。不过CSP配置起来挺折腾，很多老站点一上CSP就白屏，得慢慢调。 做渗透测试时，碰到XSS别急着弹窗。先看上下文，看输出点落在HTML的哪个位置。是标签之间？属性值里？还是 `
`。用户点开，浏览器尝试加载那个不存在的图片，触发onerror，cookie就被发到了攻击者的服务器。整个过程用户只看到页面闪了一下，搜索框里显示了一串乱码般的字符。他可能以为只是搜索词没显示好，根本不会想到自己的登录凭证已经泄露。
<script>”。这思路本身就歪了。浏览器解析HTML的容错性极强，`` 这种事件属性、甚至 `