前端安全-常见的攻击以及防护

1、基础知识

一、XSS（Cross Site Scripting）跨站脚本攻击

（1）原理：页面渲染的数据中包含可运行的脚本

（2）攻击的基本类型：反射型（url参数直接注入）和存储型（存储到DB后读取时注入）

（3）注入点：HTML节点内的内容（text）；HTML中DOM元素的属性；Javascript代码；富文本

//HTML节点内容注入
<div><script>alert(1);</script></div>  

//DOM属性注入
<img src='/images/1.png' onerror='alert(1);'>  

//javascript代码
<script>
    var a = '1';alert(1);''
</script>

//富文本是html标签，文字，以及样式的集合，很容易实现HTML节点内容注入和DOM属性注入，有被攻击的风险

 

二、CSRF（Cross Site Request Forgy）跨站请求伪造

原理：在第三方网站向本网站发起请求（如图）

（1）用户在a站前端页面发起登陆（身份认证）请求

（2）a站后端确认身份，登陆成功，cookie中存在用户的身份认证信息

（3）b站前端页面向a站后端发起请求，带着a站的cookie信息（身份认证信息），请求成功

综上，能够清楚的知道，只要用户访问了b站的前端页面，b站就能够在用户彻底不知道的状况下，带着a站的用户登陆态（cookie）向a站发起请求

三、点击劫持

原理：第三方网站经过iframe内嵌某一个网站，而且将iframe设置为透明不可见，将其覆盖在其余通过假装的DOM上，假装的可点击DOM（按钮等）与实际内嵌网站的可点击DOM位置相同，当用户点击假装的DOM时，实际上点击的是iframe中内嵌的网页的DOM从而触发请求操做

特色：用户本身作了点击操做；用户绝不知情；

 

2、如何防护

一、XSS攻击防护

（1）浏览器自带防护机制，主要应对反射型攻击（HTML内容或属性）：http响应头中自动添加x-xss-protection，值为0（关闭），1（打开），默认打开

（2）对特定字符作转义：内容注入替换尖括号（ < => &lt;   > => &gt; ） 属性注入替换单引号或双引号（ " => &quot;  ' => &#39; ）

（3）CSP（Content Security Policy）内容安全策略：用于指定哪些内容可执行

//咱们能够在http响应头中设置Content-Security-Policy
//图片能够从任何地方加载(注意 "*" 通配符)
//多媒体文件仅容许从 media1.com 和 media2.com 加载(不容许从这些站点的子域名)
//可运行脚本仅容许来自于userscripts.example.com
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

//同时meta中也支持设置Content-Security-Policy
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

二、CSRF攻击防护：

CSRF的发生有几个特色，b站发送的请求带着a站的cookie信息； b站发送请求不通过a站的前端；http请求头中的referer为b站。咱们能够从这些特色入手，思考防护的办法

（1）禁止第三方网站携带本网站的cookie信息：设置same-site属性，same-site属性有两个值，Strict（全部的第三方请求都不能携带本网站的cookie）和Lax（连接能够，可是form表单提交和ajax请求不行）

（2）本网站前端页面添加验证信息：使用验证码或者添加token验证

　　验证码：当发起请求时，前端须要输入本网站页面的验证码信息，后端对验证码进行验证，验证码正确才会进行相关操做（存取数据等）

　　token验证：a站前端将token存在当前页面中（好比表单中的input隐藏域，meta标签或者任何一个dom的属性）和cookie中，当请求a站后端的时候，参数中带上这个token字段，a站后端将参数中的token和cookie中的token作对比， 相同则验证经过，不一样则请求不合法

不论是验证码仍是token验证，原理都是同样的，在a站前端页面加入验证，当第三方网站请求a站后端时，即便能携带a站cookie，可是由于没有通过a站的前端页面从而拿不到验证信息，也会致使请求失败。

两种防护的方法也有区别，验证码须要用户去填写，从而增长了用户使用网站的复杂度，而token验证在用户无感知的状况下就能够实现，不影响用户体验。我我的理解，验证码验证通常使用在须要提升用户认知的场景，好比，登陆屡次失败，修改我的信息（用户名，密码，绑定手机号等等），而一些获取商品列表信息，搜索等接口，使用token比较合理。能够看看咱们平时使用的这些网站，做参考～

（3）referer验证：禁止来自第三方的请求

（4）使用post请求：有一个说法是“post请求比get请求更安全”，那这种说法对不对呢？实际上这种说法并不许确，对于CSRF攻击来说，不论是post仍是get都能实现攻击，区别只是post请求攻击方须要构造一个form表单才能够发起请求，比get请求（img的src， a标签的href等等）的攻击方式复杂了一些，可是并不能有效的阻止攻击。

三、点击劫持攻击防护

（1）Javascript禁止内嵌：当网页没有被使用iframe内嵌时，top和window是相等的；当网页被内嵌时，top和window是不相等的；能够在本网站的页面中添加以下判断：

 

<script>
if (top.location != window.location) {
    //若是不相等，说明使用了iframe，可进行相关的操做
}
</script>

 

可是这种方式并非万能的，由于iframe标签中的属性sandbox属性是能够禁用内嵌网页的脚本的：

<iframe sandbox='allow-forms' src='...'></iframe>

 

（2）设置http响应头 X-Frame-Options：有三个值 DENY（禁止内嵌） SAMEORIGIN（只容许同域名页面内嵌） ALLOW-FROM（指定能够内嵌的地址）

　　  能在全部的web服务器端预设好X-Frame-Options字段值是最理想的状态。

（3）一些辅助手段，好比添加验证码，提升用户的防范意识

3、总结

本文旨在对平时了解到的知识作一些总结和记录，方便查阅和复习，描述不当之处，欢迎指出。

文中有些部分并未深刻展开，好比iframe的sandbox属性（只适用于内嵌网页是form提交的状况，若是全部的请求都经过ajax来请求，而js脚本又被禁用的话，那就没办法实现点击劫持了），有一些内容须要你本身动脑思考。

后续可能还会有补充，好比SQL注入部分，总之，今天先这样啦～