前言在前面三篇 SQL注入系列文章中我们基本掌握了手工漏洞验证能力 工具高效辅助思维建立了Web安全最核心的底层渗透逻辑。本篇进入新的章节新手容易在SRC挖到漏洞的领域XSS跨站脚本攻击。SQL注入的防护越来越严格WAF基本全覆盖新人很难有限出洞但XSS漏洞不少存在于企业官网、后台管理、搜索框、留言板、个人中心是公益SRC、厂商SRC等相对来说高频、容易提交成功、容易积累成果的中低危漏洞。本文秉承着不说废话的原则把三类XSS原理、触发条件、挖掘位置、手工Payload、过滤绕过、真实SRC审计思路一次性讲透靶场依旧选择我们的皮卡丘pikachu的靶场演示一、XSS核心本质面试掌握靶场验证逻辑XSSCross-Site Scripting跨站脚本漏洞本质是后端未过滤用户可控输入 → 前端直接渲染输出 → 攻击者可控JS代码被浏览器执行和SQL注入类似属于输入输出不信任漏洞是Web安全中的经典漏洞类型。核心危害SRC报告话术劫持用户Cookie、钓鱼诱导、后台权限接管、页面篡改、挂黑页、恶意代码执行可窃取用户敏感信息、劫持用户会话严重威胁站点与用户安全。靶场对照逻辑Pikachu所有XSS关卡均严格遵循该漏洞成因无多余复杂环境专注复现「输入可控-无过滤-前端执行」的核心链路。二、三类XSS分类、实战区别Pikachu靶场逐类复现三类XSS是SRC提交、面试、渗透测试的核心考点接下来博主结合原理特点靶场实操逐一拆解复现步骤零基础可直接照搬。1. 反射型XSS一次性危害较小src可能不收漏洞原理用户提交参数 → 服务器接收 → 立即回显页面 → 执行JS → 关闭页面即失效核心特点无数据库存储漏洞只有一次性生效需要诱导用户点击恶意链接才能触发高发位置搜索框、跳转参数、页面标题、提示信息Pikachu靶场实操复现Reflected XSS靶场路径Pikachu - XSS - 反射型xss(get)1场景说明页面存在输入回显功能用户输入的内容会直接展示在页面中后端无任何过滤是典型的反射型业务场景2基础探测Payloadscriptalert(1)/script这里发现长度超出了输入框的限制首先我们观察到这只是前端的限制所以我们可以选择在浏览器的开发者工具F12中修改前端限制代码这个思路适用于许多需要绕过前端限制的地方我们选中输入框发现输入框进行了20个字符长度的限制我们把限制改成100然后再输入测试代码发现弹窗成功这样就进行了一次简单的前端限制绕过3漏洞验证提交后页面直接弹窗URL参数中携带恶意代码关闭页面后漏洞失效完美印证反射型XSS「一次性、无存储」的特点4漏洞利用贴合SRC危害小伙伴们看到这可能会疑惑你这就弹个弹窗有个卵用虽然反射型xss确实危害没有那么大但是还是有发掘价值的。既然我们构造的js代码可以利用我们就可以构造一个恶意代码比如获取当前访问用户的cookie并发到攻击者自己的服务器上把类似的恶意js代码拼接到网址中然后把构造好的网址发给目标用户结合社会工程学就会产生危害。除了获取cookie还能盗取个人信息或者诱导用户下载恶意文件记录键盘输入页面跳转等操作具体要结合社会工程学和网站本身特性来构造网上也有很多构造好的js代码5我们可以看到除了GET型传参的xss皮卡丘靶场里还有一个POST型传参的xss大家看过之前的两篇文章或者是对传参有一定了解的可能会想是不是要抓包实则不然。post传参的xss利用条件比较苛刻首先因为post型传参在实际测试中基本没办法在网址或者输入框等地方输入pikachu靶场的post反射型xss这关登录之后就可以看到post的输入框就可以进行xss所以此时我们如果想利用到POST传参就需要自己构造一个前端页面页面上携带我们写好的传给目标网站的恶意POST参数在进行利用的时候受害者需要已经登录目标网站浏览器保存有效 Cookie关键此时攻击者把这个恶意 html 文件发给受害者诱导打开页面加载瞬间自动发送 POST 请求携带 XSS payload服务器接收 POST 参数把 payload 反射回页面返回给受害者浏览器受害者浏览器渲染页面执行恶意 JS偷 Cookie / 钓鱼 / 执行操作2. 存储型XSS永久性、SRC会收漏洞原理用户输入内容 → 存入数据库 → 任何人访问页面都会触发JS执行核心特点永久存在页面与数据库中持久化漏洞无需诱导任意用户访问页面自动触发高发位置留言板、评论、用户昵称、公告提交、反馈模块SRC收录优先级存储型 反射型Pikachu靶场实操复现Stored XSS靶场路径Pikachu - XSS - 存储型xss打开之后我们看到经典的留言板存储型xss漏洞存在较多的地方我们直接注入xss的测试代码img srcx onerroralert(存储XSS成功)可以看到页面成功弹出了我们想要打印的信息这样就算漏洞测试成功那存储型和反射型的区别是什么呢前面也提到过存储型xss属于是持久性的xss我们输入的xss测试代码不止停留在了前端还传入了网站后端的数据库也就是说在我们上传了恶意js代码之后任何人访问这个页面都会触发攻击造成信息泄露。3. DOM型XSS前端漏洞、难挖、大厂SRC高频纯前端JS逻辑漏洞一些WAF拦截不到位核心JS关键词全局检索innerHTML / outerHTML前端输出编码统一使用HTML实体编码、JS编码、URL编码转义特殊字符复现验证思路访问构造链接页面成功弹窗全程抓包无任何恶意请求发送至服务器后端无日志完全符合DOM XSS漏洞特征我们输入测试代码后点击What do you see就可以看到我们的代码弹窗成功 onclickalert(1)//DOM型XSS深入原理拆解底层技术原理核心逻辑Source数据源 - 传输/处理 - Sink危险函数DOM型XSS的本质是纯前端漏洞。后端只下发静态的 HTMLJS漏洞的产生完全在于前端JS代码将“不可信的数据”写入了“危险的位置”。1. Source可控数据源攻击者能够控制的数据输入点最常见的有location.searchURL的?后面的参数location.hashURL的#后面的内容不发给服务器location.href/document.referrer/window.namepostMessage跨窗口通信localStorage/sessionStorage存储型DOM XSS2. Sink危险接收器前端JS将数据写入这些位置时如果没有做安全处理就会导致代码执行HTML相关innerHTML、outerHTML、document.write、insertAdjacentHTMLJS执行eval()、setTimeout()、setInterval()、new Function()属性/URLlocation.href javascript:...、src、href3. 为什么Pikachu的Payload是 onclickalert(1)//结合Pikachu DOM型的源码通常是document.getElementById(a).innerHTML ...当你的输入被塞进innerHTML时浏览器会将其解析为HTML。闭合原有的HTML属性值就比如闭合了原有的href...中的引号。onclickalert(1)利用HTML解析器规则属性名以on开头如onclick,onerror会被浏览器绑定为事件处理器属于JS执行环境。点击时触发。//JS注释符把原本后面多余的引号、标签等代码注释掉类似于我们之前学的SQL注入语句防止语法错误导致弹窗失败。核心总结DOM型XSS的挖掘秘诀就是“全局搜索Source顺藤摸瓜找Sink”。在F12中搜索location、innerHTML、eval等关键词找到数据流执行链。四、零基础手工Payload体系由简到繁靶场逐一套用常用闭合Payload1. 注入在【双引号 HTML 属性】value这里输出你的输入 onclickalert(1)//解析闭合原有双引号新增 onclick 事件//注释后面剩余引号。 拼接后示例input value onclickalert(1)//2. 注入在【单引号 HTML 属性】Pikachu DOM 关卡href你的输入 onclickalert(1)//解析闭合前面单引号注入事件//注释后面多余单引号。 拼接后a href onclickalert(1)//xxx/a3. 注入在【HTML 正文】直接输出在页面标签之间不用闭合引号不需要引号闭合直接写标签 payloadimg srcx onerroralert(1)4. 注入在【JS 代码块内部】输入直接放在scriptvar a输入/script里面;alert(1);//;闭合 JS 字符串终止原有语句执行 alert//注释剩下代码场景WAF/前端拦截alert关键词方案 Aconfirm/prompt替代img srcx onerrorconfirm(1)方案 Bwindow 对象调用 alertimg srcx onerrorwindow[alert](1)方案 CUnicode 编码绕过img srcx onerror\u0061\u006c\u0065\u0072\u0074(1)场景站点拦截小括号禁止函数传参JS模板字符串反引号调用函数不需要括号img srcx onerroralert1原理JS 标签模板语法alert1 等价于alert(1)没有 ()完美绕过括号过滤。靶场Pikachu到真实SRC的差距Pikachu是“无菌环境”真实SRC是“战场”。新手很容易拿着 scriptalert(1)/script 去真实站点测被WAF拦截后怀疑人生。1. WAF拦截与过滤• 靶场无过滤原样回显。• 真实SRC常规的 script、alert、onerror 大概率被WAF和前端黑名单拦截。你需要掌握大小写混写、Unicode编码、HTML实体编码、使用冷门标签如 svg、details、iframe、利用JS模板字符串反引号、拆分关键字等绕过技巧。2. 输出上下文差异• 靶场通常在标签之间直接输出。• 真实SRC可能在HTML属性内、script标签内的JS变量中、JSON响应中。不同的输出点需要完全不同的闭合方式。直接拿靶场Payload去打真实环境大概率是语法错误页面崩溃。3. 浏览器安全机制• 靶场无防护。• 真实SRC现代浏览器有 HttpOnlyCookie偷不到、SameSite跨站POST不自动带Cookie、CSP内容安全策略内联脚本直接禁止执行。CSP存在的情况下就算你注入了JS浏览器也会拒绝执行。4. SRC审核与危害证明• 靶场弹个窗就算通关。• 真实SRC只弹窗的XSS通常会被判为低危或忽略。你需要证明实际危害◦ 存储型XSS证明能打到管理员后台比如发一条留言管理员一访问就触发。◦ 反射型XSS构造出完整的利用链比如利用XSS窃取用户Token、发起CSRF修改密码。◦ DOM型XSS必须证明恶意链接能稳定触发且能执行任意JS如document.cookie被HttpOnly挡住时构造键盘记录或钓鱼弹窗。◦ SRC报告话术“该漏洞可导致攻击者获取用户登录态执行任意操作建议定级中危/高危修复方案如下……”XSS修复建议SRC报告结尾必备如果你在SRC提交漏洞报告里附上修复建议不仅会显得你专业还能提高审核通过率和定级。1. 首选方案上下文输出编码最核心不要试图过滤用户输入而是根据数据输出的位置进行编码• HTML标签间将 转义为 HTML 实体lt; gt; amp; quot; #x27;。• HTML属性内除上述字符外还需对空格、换行等进行编码确保闭合引号失效。• JavaScript代码块内使用JS Unicode编码或 JSON 序列化输出。• URL参数使用 encodeURIComponent() 进行URL编码。2. DOM型XSS专项防御• 避免使用 innerHTML、document.write、eval 等危险Sink。• 优先使用安全的APItextContent、innerText、setAttribute。• 如果必须插入HTML使用第三方安全库如 DOMPurify 进行净化。3. 内容安全策略CSP• 配置 Content-Security-Policy 响应头禁用 unsafe-inline 和 unsafe-eval。• 例如script-src self https://trusted.cdn.com;• CSP作为最后一道防线即使XSS被注入也能阻止恶意JS执行。4. Cookie安全加固• 为敏感Cookie设置 HttpOnly禁止JS读取防Cookie劫持。• 设置 SameSiteLax 或 Strict防止跨站POST型XSS自动携带Cookie。5. 输入验证与过滤辅助• 对输入格式进行严格的白名单校验如手机号、邮箱格式。• 过滤 script、on* 等危险关键字注意这只是辅助不能完全依赖因为存在大量绕过。结语Pikachu靶场完美适配本文全套XSS知识点是SRC新手最优练习靶场大家可以自己下去尝试一下pikachu中xss章节的其他关卡靶场中除了xss和SQL注入以外还有许多漏洞类型还未涉及接下来的博客中我会一一提到。至此我们完成了 Web安全三大基础核心手工SQL注入 → 工具高阶注入 → XSS全体系学习原理靶场实操绕过方案声明本文所有内容仅用于本地靶场学习未经授权不得对互联网任何真实网站进行渗透测试
前言在前面三篇 SQL注入系列文章中我们基本掌握了手工漏洞验证能力 工具高效辅助思维建立了Web安全最核心的底层渗透逻辑。本篇进入新的章节新手容易在SRC挖到漏洞的领域XSS跨站脚本攻击。SQL注入的防护越来越严格WAF基本全覆盖新人很难有限出洞但XSS漏洞不少存在于企业官网、后台管理、搜索框、留言板、个人中心是公益SRC、厂商SRC等相对来说高频、容易提交成功、容易积累成果的中低危漏洞。本文秉承着不说废话的原则把三类XSS原理、触发条件、挖掘位置、手工Payload、过滤绕过、真实SRC审计思路一次性讲透靶场依旧选择我们的皮卡丘pikachu的靶场演示一、XSS核心本质面试掌握靶场验证逻辑XSSCross-Site Scripting跨站脚本漏洞本质是后端未过滤用户可控输入 → 前端直接渲染输出 → 攻击者可控JS代码被浏览器执行和SQL注入类似属于输入输出不信任漏洞是Web安全中的经典漏洞类型。核心危害SRC报告话术劫持用户Cookie、钓鱼诱导、后台权限接管、页面篡改、挂黑页、恶意代码执行可窃取用户敏感信息、劫持用户会话严重威胁站点与用户安全。靶场对照逻辑Pikachu所有XSS关卡均严格遵循该漏洞成因无多余复杂环境专注复现「输入可控-无过滤-前端执行」的核心链路。二、三类XSS分类、实战区别Pikachu靶场逐类复现三类XSS是SRC提交、面试、渗透测试的核心考点接下来博主结合原理特点靶场实操逐一拆解复现步骤零基础可直接照搬。1. 反射型XSS一次性危害较小src可能不收漏洞原理用户提交参数 → 服务器接收 → 立即回显页面 → 执行JS → 关闭页面即失效核心特点无数据库存储漏洞只有一次性生效需要诱导用户点击恶意链接才能触发高发位置搜索框、跳转参数、页面标题、提示信息Pikachu靶场实操复现Reflected XSS靶场路径Pikachu - XSS - 反射型xss(get)1场景说明页面存在输入回显功能用户输入的内容会直接展示在页面中后端无任何过滤是典型的反射型业务场景2基础探测Payloadscriptalert(1)/script这里发现长度超出了输入框的限制首先我们观察到这只是前端的限制所以我们可以选择在浏览器的开发者工具F12中修改前端限制代码这个思路适用于许多需要绕过前端限制的地方我们选中输入框发现输入框进行了20个字符长度的限制我们把限制改成100然后再输入测试代码发现弹窗成功这样就进行了一次简单的前端限制绕过3漏洞验证提交后页面直接弹窗URL参数中携带恶意代码关闭页面后漏洞失效完美印证反射型XSS「一次性、无存储」的特点4漏洞利用贴合SRC危害小伙伴们看到这可能会疑惑你这就弹个弹窗有个卵用虽然反射型xss确实危害没有那么大但是还是有发掘价值的。既然我们构造的js代码可以利用我们就可以构造一个恶意代码比如获取当前访问用户的cookie并发到攻击者自己的服务器上把类似的恶意js代码拼接到网址中然后把构造好的网址发给目标用户结合社会工程学就会产生危害。除了获取cookie还能盗取个人信息或者诱导用户下载恶意文件记录键盘输入页面跳转等操作具体要结合社会工程学和网站本身特性来构造网上也有很多构造好的js代码5我们可以看到除了GET型传参的xss皮卡丘靶场里还有一个POST型传参的xss大家看过之前的两篇文章或者是对传参有一定了解的可能会想是不是要抓包实则不然。post传参的xss利用条件比较苛刻首先因为post型传参在实际测试中基本没办法在网址或者输入框等地方输入pikachu靶场的post反射型xss这关登录之后就可以看到post的输入框就可以进行xss所以此时我们如果想利用到POST传参就需要自己构造一个前端页面页面上携带我们写好的传给目标网站的恶意POST参数在进行利用的时候受害者需要已经登录目标网站浏览器保存有效 Cookie关键此时攻击者把这个恶意 html 文件发给受害者诱导打开页面加载瞬间自动发送 POST 请求携带 XSS payload服务器接收 POST 参数把 payload 反射回页面返回给受害者浏览器受害者浏览器渲染页面执行恶意 JS偷 Cookie / 钓鱼 / 执行操作2. 存储型XSS永久性、SRC会收漏洞原理用户输入内容 → 存入数据库 → 任何人访问页面都会触发JS执行核心特点永久存在页面与数据库中持久化漏洞无需诱导任意用户访问页面自动触发高发位置留言板、评论、用户昵称、公告提交、反馈模块SRC收录优先级存储型 反射型Pikachu靶场实操复现Stored XSS靶场路径Pikachu - XSS - 存储型xss打开之后我们看到经典的留言板存储型xss漏洞存在较多的地方我们直接注入xss的测试代码img srcx onerroralert(存储XSS成功)可以看到页面成功弹出了我们想要打印的信息这样就算漏洞测试成功那存储型和反射型的区别是什么呢前面也提到过存储型xss属于是持久性的xss我们输入的xss测试代码不止停留在了前端还传入了网站后端的数据库也就是说在我们上传了恶意js代码之后任何人访问这个页面都会触发攻击造成信息泄露。3. DOM型XSS前端漏洞、难挖、大厂SRC高频纯前端JS逻辑漏洞一些WAF拦截不到位核心JS关键词全局检索innerHTML / outerHTML前端输出编码统一使用HTML实体编码、JS编码、URL编码转义特殊字符复现验证思路访问构造链接页面成功弹窗全程抓包无任何恶意请求发送至服务器后端无日志完全符合DOM XSS漏洞特征我们输入测试代码后点击What do you see就可以看到我们的代码弹窗成功 onclickalert(1)//DOM型XSS深入原理拆解底层技术原理核心逻辑Source数据源 - 传输/处理 - Sink危险函数DOM型XSS的本质是纯前端漏洞。后端只下发静态的 HTMLJS漏洞的产生完全在于前端JS代码将“不可信的数据”写入了“危险的位置”。1. Source可控数据源攻击者能够控制的数据输入点最常见的有location.searchURL的?后面的参数location.hashURL的#后面的内容不发给服务器location.href/document.referrer/window.namepostMessage跨窗口通信localStorage/sessionStorage存储型DOM XSS2. Sink危险接收器前端JS将数据写入这些位置时如果没有做安全处理就会导致代码执行HTML相关innerHTML、outerHTML、document.write、insertAdjacentHTMLJS执行eval()、setTimeout()、setInterval()、new Function()属性/URLlocation.href javascript:...、src、href3. 为什么Pikachu的Payload是 onclickalert(1)//结合Pikachu DOM型的源码通常是document.getElementById(a).innerHTML ...当你的输入被塞进innerHTML时浏览器会将其解析为HTML。闭合原有的HTML属性值就比如闭合了原有的href...中的引号。onclickalert(1)利用HTML解析器规则属性名以on开头如onclick,onerror会被浏览器绑定为事件处理器属于JS执行环境。点击时触发。//JS注释符把原本后面多余的引号、标签等代码注释掉类似于我们之前学的SQL注入语句防止语法错误导致弹窗失败。核心总结DOM型XSS的挖掘秘诀就是“全局搜索Source顺藤摸瓜找Sink”。在F12中搜索location、innerHTML、eval等关键词找到数据流执行链。四、零基础手工Payload体系由简到繁靶场逐一套用常用闭合Payload1. 注入在【双引号 HTML 属性】value这里输出你的输入 onclickalert(1)//解析闭合原有双引号新增 onclick 事件//注释后面剩余引号。 拼接后示例input value onclickalert(1)//2. 注入在【单引号 HTML 属性】Pikachu DOM 关卡href你的输入 onclickalert(1)//解析闭合前面单引号注入事件//注释后面多余单引号。 拼接后a href onclickalert(1)//xxx/a3. 注入在【HTML 正文】直接输出在页面标签之间不用闭合引号不需要引号闭合直接写标签 payloadimg srcx onerroralert(1)4. 注入在【JS 代码块内部】输入直接放在scriptvar a输入/script里面;alert(1);//;闭合 JS 字符串终止原有语句执行 alert//注释剩下代码场景WAF/前端拦截alert关键词方案 Aconfirm/prompt替代img srcx onerrorconfirm(1)方案 Bwindow 对象调用 alertimg srcx onerrorwindow[alert](1)方案 CUnicode 编码绕过img srcx onerror\u0061\u006c\u0065\u0072\u0074(1)场景站点拦截小括号禁止函数传参JS模板字符串反引号调用函数不需要括号img srcx onerroralert1原理JS 标签模板语法alert1 等价于alert(1)没有 ()完美绕过括号过滤。靶场Pikachu到真实SRC的差距Pikachu是“无菌环境”真实SRC是“战场”。新手很容易拿着 scriptalert(1)/script 去真实站点测被WAF拦截后怀疑人生。1. WAF拦截与过滤• 靶场无过滤原样回显。• 真实SRC常规的 script、alert、onerror 大概率被WAF和前端黑名单拦截。你需要掌握大小写混写、Unicode编码、HTML实体编码、使用冷门标签如 svg、details、iframe、利用JS模板字符串反引号、拆分关键字等绕过技巧。2. 输出上下文差异• 靶场通常在标签之间直接输出。• 真实SRC可能在HTML属性内、script标签内的JS变量中、JSON响应中。不同的输出点需要完全不同的闭合方式。直接拿靶场Payload去打真实环境大概率是语法错误页面崩溃。3. 浏览器安全机制• 靶场无防护。• 真实SRC现代浏览器有 HttpOnlyCookie偷不到、SameSite跨站POST不自动带Cookie、CSP内容安全策略内联脚本直接禁止执行。CSP存在的情况下就算你注入了JS浏览器也会拒绝执行。4. SRC审核与危害证明• 靶场弹个窗就算通关。• 真实SRC只弹窗的XSS通常会被判为低危或忽略。你需要证明实际危害◦ 存储型XSS证明能打到管理员后台比如发一条留言管理员一访问就触发。◦ 反射型XSS构造出完整的利用链比如利用XSS窃取用户Token、发起CSRF修改密码。◦ DOM型XSS必须证明恶意链接能稳定触发且能执行任意JS如document.cookie被HttpOnly挡住时构造键盘记录或钓鱼弹窗。◦ SRC报告话术“该漏洞可导致攻击者获取用户登录态执行任意操作建议定级中危/高危修复方案如下……”XSS修复建议SRC报告结尾必备如果你在SRC提交漏洞报告里附上修复建议不仅会显得你专业还能提高审核通过率和定级。1. 首选方案上下文输出编码最核心不要试图过滤用户输入而是根据数据输出的位置进行编码• HTML标签间将 转义为 HTML 实体lt; gt; amp; quot; #x27;。• HTML属性内除上述字符外还需对空格、换行等进行编码确保闭合引号失效。• JavaScript代码块内使用JS Unicode编码或 JSON 序列化输出。• URL参数使用 encodeURIComponent() 进行URL编码。2. DOM型XSS专项防御• 避免使用 innerHTML、document.write、eval 等危险Sink。• 优先使用安全的APItextContent、innerText、setAttribute。• 如果必须插入HTML使用第三方安全库如 DOMPurify 进行净化。3. 内容安全策略CSP• 配置 Content-Security-Policy 响应头禁用 unsafe-inline 和 unsafe-eval。• 例如script-src self https://trusted.cdn.com;• CSP作为最后一道防线即使XSS被注入也能阻止恶意JS执行。4. Cookie安全加固• 为敏感Cookie设置 HttpOnly禁止JS读取防Cookie劫持。• 设置 SameSiteLax 或 Strict防止跨站POST型XSS自动携带Cookie。5. 输入验证与过滤辅助• 对输入格式进行严格的白名单校验如手机号、邮箱格式。• 过滤 script、on* 等危险关键字注意这只是辅助不能完全依赖因为存在大量绕过。结语Pikachu靶场完美适配本文全套XSS知识点是SRC新手最优练习靶场大家可以自己下去尝试一下pikachu中xss章节的其他关卡靶场中除了xss和SQL注入以外还有许多漏洞类型还未涉及接下来的博客中我会一一提到。至此我们完成了 Web安全三大基础核心手工SQL注入 → 工具高阶注入 → XSS全体系学习原理靶场实操绕过方案声明本文所有内容仅用于本地靶场学习未经授权不得对互联网任何真实网站进行渗透测试
