前端——影子杀手篇

前言

对于一个影子杀手而言，总能杀人于无形。前端也有影子杀手，它老是防不胜防地危害着你的网站

本篇打算介绍一些前端的影子杀手们——XSS和CSRF。或许，你对它恨之入骨；又或者，你运用的驾轻就熟。恨之入骨，多是由于你的网站被它搞得苦不堪言；驾轻就熟，多是由于你从事这项工做，天天都在和此类问题打交道。那咱们今天就来了解它，防护它。若是你喜欢个人文章，欢迎评论，欢迎Star~。欢迎关注个人github博客

正文

注：在开始正文以前，先声明一下，全部的实验环境均为本地搭建——DVWA。

影子杀手们，由来已久，几乎伴随着整个互联网的发展。历史的潮流，老是值得去考究，去深思的。可能在十年以前，这些问题层出不穷；随着开发者安全意识的提升，老是多多少少能够避免的。那么，咱们就先来看看，今天的第一位主角——XSS。

第一位主角——XSS

记得在学校的时候，玩过CTF，应对相似于XSS等网络漏洞，老是会有固定的套路。今天咱们也来了解了解这些套路。

概述

XSS的全名叫作Cross-site Scripting。不知你能否会有个疑问，老外都喜欢将英文缩写，可是为何这个缩写倒是XSS呢？由于只能怪它来的晚咯，被css抢先一步^_^。不过不要紧，并不阻碍咱们记忆它。

XSS是一种代码注入类攻击，它容许攻击者在其余人的电脑上面执行恶意的脚本代码。每每XSS并不须要攻击者去直接攻击受害者的浏览器。攻击者能够利用网站的漏洞，将这一段恶意代码提交。而后，经过网站去传递给受害者，同时窃取受害者的信息等。

咱们能够先看一个简单的例子：

或许，你会好奇，我应该怎么去运用网站的漏洞，那咱们先来看一张图：

comment

这是一个评论框，而后咱们能够在其中输入：

comment

而后，你提交这条信息，若是该网站没有作防御(例如：过滤)，那么，你所在的页面会跳出以下画面：

xss

看了这个信息，或许你已经意识到了它的危害。由于若是能够这样子随意的运行js脚本，对于你客户端的信息(例如：cookie)将通通被窃取。

回到咱们的话题，在看到xss的基本效果以后，你会认为JavaScript是危险的吗？

其实否则，真正的JavaScript是运行在比较严格的环境下面，并不会对操做系统或者其余应用形成伤害。不信的话，你能够打开控制台，在里面随意尝试，你会发现你并无形成任何危害。那么，咱们所谓的XSS的严重性，是吹的吗？

那就更加不是了。首先，咱们要申明的是——何为恶意代码？恶意代码的叫法，并非由于它自己是有危害的，而是它的意图是对使用者有害的。咱们能够来看看，何为对使用者有害？例子：

1. JavaScript对于用户的私密信息进行读取(例如：cookies)。
2. JavaScript能够经过XMLHttpRequest发送任意的信息到任意的服务器上
3. JavaScript能够修改当前页面中的任意DOM元素

这些行为，若是是不善的人所为，那么，将对使用者形成不可估量的损失。

XSS中的角色扮演

XSS整个流程中，会出现不一样的角色。演员表可分为：网站、受害者、攻击者。

网站，一般是指那些会被受害者访问的HTML页面。

受害者，指的是那些访问网站的普通用户

攻击者，则是那些躲在阴暗角落，敲击着键盘的恶意用户。一般，攻击者还会具有一台本身的服务器，用来接收发送过来的用户信息。

整个流程图，以下：

xss-process

整个流程中，演员都是必须的环节，否则整个攻击都没法完成。可从图中看出4个步骤：

1. 攻击者选取一个具有漏洞的网站，在其数据库插入恶意代码
2. 用户向网站服务器请求这个被注入的网站
3. 网站服务器响应用户请求，并发送给用户已被修改的网站
4. 用户完成访问，同时注入的恶意代码执行，将用户的cookie发送给攻击者服务器

但愿你对这幅流程图多看几眼，由于它也将会是咱们后续防护XSS的先决条件。以后，咱们来看看XSS的分类状况

分类

XSS的目标是在受害者的浏览器中执行恶意代码。而实现这一目标，每每只有不一样的途径，主要能够分为三种：反射型XSS、存储型XSS、基于DOM的XSS。

• 反射型XSS：用户的恶意代码字符串来源于受害者的请求，例如，邮件中参杂的恶意连接。
• 存储型XSS：用户的恶意代码字符串来自于网站的数据库。一般是咱们图中举的例子——在评论中注入恶意代码，让受害者进行访问
• 基于DOM型XSS：这种攻击的漏洞主要在客户端，而非服务端。通常比较少见。

因为存储型的XSS的流程图，咱们已经在上面看到过了。以后，咱们须要来看一看反射型的XSS流程图，如图：

xss-reflect

能够看到流程中，并未向网站的数据库中插入恶意代码，而是由如下4步骤组成：

1. 攻击者向受害者传递一个网站URL地址
2. 而后，受害者点击了这个地址，同时会向网站发出请求
3. 网站响应原先已经存在恶意代码的网页给用户
4. 当用户加载完网页以后，会向攻击者的服务器发送私密信息。

这种形式每每是须要用户进行点击的。

还有一种基于DOM的XSS，平时运用较少，并且攻击条件较为苛刻。在此不作讨论。

咱们看完分类以后，对于攻击的大致流程已经掌握。

接下来的操做平台，我比较推荐——DVWA。由于目前网上XSS漏洞比较少，主要也是由于开发者的重视，并且网上操做会致使必定的危害，因此在本地搭建开发环境是最好的选择。

实际操做：

最初，咱们须要安装DVWA，这个教程网上有不少，因此，能够自行百度。

第一步，咱们须要将DVWA的安全级别调低，由于不一样的安全级别采起的防护措施不一样。

DVWA

第二步，咱们开始在XSS reflected中进行xss试验。

第三步，在输入框中输入""，如图：

XSS

第四步：提交以后，咱们便可看到弹窗(这里提醒一下尽可能不要使用chrome，那个浏览器会屏蔽这些，最好使用老版本的IE)，如图：

xss

若是你具有后台服务器的话，那么就能够将这个cookie经过请求的形式发送到服务器后台上面，此处就不作演示了。

防护

既然有人企图使用这些玩意来危害使用者，那么，咱们这些开发者在开发应用的过程当中，天然会有应对之策。不知你还记得上面的攻击流程图没有？若是忘记了，不妨回去看一眼。由于，最好的防护措施就是截断攻击环节中的任意一个环节。

首先，做为一个开发者，必须达成的一点共识是全部的用户输入都是不安全的。尤为是相似于XSS这类的注入型漏洞。咱们能够经过两个方式对其进行防护——编码和验证。

编码：对于用户的输入而言，所输入的内容只会做为数据，而不是代码。

验证：经过正则表达式等方式，去检查用户的输入中是否带有敏感字符等。

因此，咱们的解决方案能够围绕上述两点进行展开：

1. 输入检测
   对用户输入的数据进行检测。对于这些代码注入类的漏洞原则上是不相信用户输入的数据的。因此，咱们要对用户输入的数据进行必定程度上的过滤，将输入数据中的特殊字符与关键词都过滤掉，而且对输入的长度进行必定的限制。只要开发的人员严格检查每一个输入点，对每一个输入点的数据进行检测和xss过滤，是能够阻止xss攻击的。

2. 输出编码
   经过前面xss的原理分析，咱们知道形成xss的还有一个缘由是应用程序直接将用户输入的数据嵌入HTML页面中了。若是咱们对用户输入的数据进行编码，以后在嵌入页面中，那么html页面会将输入的数据看成是普通的数据进行处理。

3. Cookie安全
   利用xss攻击，咱们能够轻易的获取到用户的cookie信息。那么咱们须要对用户的cookie进行必定的处理。首先，咱们尽量减小cookie中敏感信息的存储，而且尽可能对cookie使用hash算法屡次散列存放。合理的使用cookie的httponly的属性值。这样能够防止恶意的js代码对cookie的调用。

4. 禁用脚本
   能够在浏览器中进行js的安全设置。相似与chrome等浏览器都会拦截一些危险的xss操做，例如：想要读取cookie时，浏览器会阻止这个操做，征求用户指示，同时提醒用户此类操做的危害性。

对于XSS而言，咱们能够了解的内容就到此为止。若是你想要深究，能够看一些网络安全的书籍，或者查阅其余的文章，都可获得详细的解答。下面咱们须要介绍咱们的第二位主角——CSRF

第二位主角——CSRF

还记得第一位主角的名字叫什么吗？是叫——跨站脚本攻击。那么第二位主角也有一个相似的名字——跨站请求伪造(Cross-site request forgery)。

概述

CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操做。咱们知道，绝大多数网站是经过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，由于 Session ID 也是大多保存在 cookie 里面的），再予以受权的。因此要伪造用户的正常操做，最好的方法是经过 XSS 或连接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......

或许，咱们如今对它了解的少了，可是网络中的确还留有它的足迹。咱们具体的操做就不实际操做了。咱们能够来看一下CSRF的原理，如图(该图来自一篇知名的博客，在此注明)：

CSRF

能够从图中看到如下步骤：

1. 首先用户会登陆网站A，以后在经过验证以后，会由cookie来进行信息的传递
2. 这时，用户又访问了网站B(例如：邮件连接等形式)，用户会在不知情的状况下，利用用户在网站A的cookie，对网站A发送第三方请求。
3. A站点一般不会关注这个访问是来自用户或者网站B

分类

CSRF也可会分红两种形式的攻击：站内攻击和站外攻击

CSRF站内类型的漏洞在必定程度上是因为程序员滥用$_REQUEST类变量形成的，一些敏感的操做原本是要求用户从表单提交发起POST请求传参给程序，可是因为使用了$_REQUEST等变量，程序也接收GET请求传参，这样就给攻击者使用CSRF攻击创造了条件，通常攻击者只要把预测好的请求参数放在站内一个贴子或者留言的图片连接里，受害者浏览了这样的页面就会被强迫发起请求。

CSRF站外类型的漏洞其实就是传统意义上的外部提交数据问题，通常程序员会考虑给一些留言评论等的表单加上水印以防止SPAM问题，可是为了用户的体验性，一些操做可能没有作任何限制，因此攻击者能够先预测好请求的参数，在站外的Web页面里编写javascript脚本伪造文件请求或和自动提交的表单来实现GET、POST请求，用户在会话状态下点击连接访问站外的Web页面，客户端就被强迫发起请求。

防御

CSRF，对于目前而言攻击较少，也是由于对于这方面的防护手段愈来愈成熟所致使的。下面，咱们来看一下如何去防御CSRF的攻击。

预防CSRF攻击能够从两方面入手：

• 正确使用GET、POST和cookie
• 在非GET请求的时候添加伪随机码

何为正确使用GET和POST呢？拿RESTful API举例来讲，GET是获取资源，而POST是提交修改资源。那么咱们在定义一个url时，遵循这个规则，就能够保证GET的非用户请求，没法对服务器资源进行修改，这样就能够防止GET的CSRF攻击。

那么，你可能会疑惑，要是POST的请求攻击怎么办呢？这就须要从第二方面下手。

增长伪随机码的方式，通常能够分为三种：

• 为每一个用户生成一个cookie token，这样能够保证在每次表单验证时附带上同一个伪随机码。这种方式是最简单的，可是同时也须要保证cookie的安全。每每cookie中的信息是很是容易被盗取的，因此这种方案在保证没有XSS的前提下是比较安全的。

• 每次请求生成验证码。这种方法是安全的，可是相对于用户体验来讲，并不友好

• 不一样表单包含一个不一样的token。有兴趣能够去了解一下，这种是比较安全的POST请求方式。

小结

因为，如今对于CSRF的攻击预防比较完全，通常在没有XSS的前提下，已经很难进行此类攻击了。因此真实的实际操做环境并无多少。以往主要的攻击手段仍是，经过XSS对于cookie进行盗取，而后经过CSRF用户数据进行修改。咱们能够一个例子来讲明最经典的银行的例子：

若是银行A容许以GET请求的形式来转帐，咱们这里大多指的不是实际生活中的，由于实际生活中银行不可能只用get请求转帐这么简单操做：www.mybank.com/Transfer.ph…

这是危险网站B的代码段中有这么一句：

<img src=” http://www.mybank.com/Transfer.php?toBankId=11&money=1000”>复制代码

那么当你再回A银行时，就会发现你的帐户上已经少了1000元。

固然，这是假的。

总结

前端安全，一直以来都是被关注的重点对象。咱们在了解他们的同时，应该注重他们的防御，这就是对用户的包含。能够是XSS的漏洞，时有发生，BAT等大厂的产品也不例外。今天总结了XSS和CSRF的攻击与防御，是警醒本身，在之后的开发中多加注意，同时，也但愿和大家一块儿分享。

若是你对我写的有疑问，能够评论，如我写的有错误，欢迎指正。你喜欢个人博客，请给我关注Star~呦github博客