web攻防勇者成名录-XSS&CSRF

前言

一切的原由都源于一次他人的试探，在一千二百四十四天前，我用Angular1.x写了一个“树洞”，发布在公众号上。一段时间后，意想不到的是我与一个奇怪评论不期而遇了，没错就是它<sctipt>sendTokenToServer()<script>。在以后一分钟的时间里，默然发觉，web安全威胁是离咱们这么的近。若是不是用了angular框架，若是angular没有作相关的防范，后果是未知的，不过我知道的是，这即是后来的故事的开始，不管如何都值得拥有。

知己知彼，先来看看危害性最强的XSS攻击

XSS（跨域脚本攻击）

攻击描述

当访问有XSS漏洞的页面时，可以使攻击代码运行在他人的浏览器中。这就意味着网站前端的掌控权已经在他人手中了，这样的结果就可能就会致使用户身份认证被盗取，用户行为被记录等等状况的出现。XSS攻击看似复杂，但其实原理很简单，通常来自于对输入的拼接。XSS又分为好几种类型。

反射型XSS攻击

攻击代码会植入到url相关的参数中，通常通过假装与混淆以后，用户很容易中招。

发动条件

• 页面有与用户相关的交互（例如搜索框）
• 先后端都没对输入内容过滤或被绕过
• Js从url位置获取相关参数，而且页面中有相关回显
• 用户主动点击带有攻击代码的连接

攻击例子

【亲朋好友帮忙砍一刀，点击得到红包】
http://localhost:8080/?name=%3Cimg%20src=1%20onerror=alert(document.cookie)%3E%3C/div%3E 
【发送连接砍一刀即有机会得到笔记本电脑，百分百中奖快来参与！】
复制代码

点击连接以后token就被获取了，omg！

有漏洞的代码【示例】

function getParams(key) {
    const reg = new RegExp(`(&|^)${key}=([^&]*)($|&)`);
    const res = window.location.search.substr(1).match(reg);
    if (res != null) {
        return unescape(res[2]);
    }
    return null;
}
document.getElementById('xss').innerHtml=getParams('name')
复制代码

那我不点击可疑连接不就行咯？很惋惜，那也是不行的。

储存型XSS攻击

目的是将攻击代码持久化到服务器，这样用户即便不点击可疑连接，只访问相关页面就能够被攻击，更严重的是，储存型的XSS漏洞可被编写成蠕虫脚本，具有社交传播属性。

必要攻击条件

• 页面有与用户相关交互（富文本，评论框），或一切能持久化的行为
• 页面有对相关数据进行回显
• 先后端都没对输入内容过滤或被绕过
• 用户访问了储存攻击代码的页面连接

攻击例子

http://localhost:8080/article?id=58
复制代码

点击连接以后，token又又被获取了，org。

这个连接中的评论功能有一个储存型XSS漏洞，用户一旦点击进入了这个页面，那么存储在评论区中的攻击代码就会执行。只要将攻击载荷换成可发表文章的脚本，那么这段攻击代码就具有传播性了。

有漏洞的代码【示例】

async getCommentById=(id)=>{
    ...
}
getCommentById(123).then(res=>{
    document.getElemtById('comment').innerHtml=res
})
复制代码

Dom型XSS攻击

利用交互回显，破坏正常dom结构，获得开发者预期以外的结果。跟sql注入相似，都是拼接用户输入惹的锅。

必要攻击条件

• 页面有与用户相关交互（利用dom拼接破坏本来的dom结构）
• 先后端都没对输入内容过滤或被绕过
• 用户主动点击带有攻击代码的连接or主动点击储存了攻击代码的页面连接

攻击例子&有漏洞的代码【示例】

若是有漏洞代码存在，那么又可经过某种方式插入如下例子的话，就构成了DOM型XSS攻击了
payload="><sctipt>/*恶意脚本*/getCookie();sendCookie()</sctipt"
...
有漏洞的代码
document.getElementById('demo').innerHtml='<option data='+ getInput() +'>2333hhhh</option>'
复制代码

防护手段

http only

经过设置cookie的httpOnly字段，防止经过脚本获取cookie中的信息。

严格控制输入输出

关键字过滤（好消息是像如今流行的前端框架都帮开发者作了这一层过滤）

七个控制输入输出原则

接下来继续来挑战另外一种漏洞

CSRF（跨域请求伪造）

攻击描述

跨域请求伪造的原理也很简单，因为网站在发送请求时，会自动地将储存在本地的cookie带上，发送给后台验证。利用这个特性，就能够在不知道用户身份凭证的状况下，模拟用户的正常请求。并且在后台的角度来看，这一切都是正常的，一切都是用户本身在操做。

攻击例子

这是brandf网站正常的发表文章接口，以前特地设置的一个CSRF漏洞，看看就好。
http://www.brandf.cn:8010/articles/csrfdemo

经过iframe伪造一下这个请求，再进行一些小小的假装。

【亲朋好友帮忙砍一刀，点击得到红包】 http://localhost:8080 
【发送连接砍一刀即有机会得到笔记本电脑，百分百中奖快来参与！】
复制代码

用户在网站http://www.brandf.cn登陆以后，又点击进入隐藏了攻击代码的网站（http://localhost:8080）。这时，就会在用户不知情的状况下，在用户的帐号里发表一篇文章。细思恐极，若是这是一个更加危险的操做呢？好比转帐等等。

若是存在漏洞的地方拥有社交属性，例如一个发送消息的接口是能够伪造的，那么这个CSRF漏洞就拥有了传播性，也就是CSRF蠕虫了。

必要攻击条件

• 用户在已登陆的状态下，点击了恶意连接
• 网站的用户凭证经过cookie传递

防护手段

后台校验referer字段

但请求头中的referer字段能被伪造，存在被绕过的风险。既然CSRF利用了浏览器请求默认带上cookie的机制，那么能不能从源头去杜绝呢？

JWT

JWT即web身份令牌技术，最重要的一点是它将用户凭证放在请求body中，杜绝了浏览器默认行为自动带上cookie所带来的风险。

最后

XSS,CSRF这两种能够讲是前端最多见也是危害最大的漏洞，固然有不少时候漏洞是由人为主观形成的，例如弱密码等等。同时在过去的十分钟时间里，很感谢你阅读了这篇文章，若是能对你有帮助，不妨点个赞哈哈，以上的全部例子和方法都是为了你们能更好地去认识到这些漏洞的危害，更好的去作好防范，同时也提升安全意识。例子均在本地实现，有兴趣的朋友可有在本地写写，但别去其余网站乱试。推荐几个web漏洞练习平台，Pikachu漏洞平台，DVWA。

CSP浏览器安全策略

CSP（Content-Security-Policy）为何要最后单独拿出来说呢，由于CSP须要后端的配合，在响应头中加入相关字段合规则。CSP至关于在浏览器中设置一个资源白名单，在白名单中的资源才能加载，能很大程度上提高网站的安全性。这里就不展开了，以后有会一篇详细的使用配置介绍嘿嘿。