前端安全

xss：跨站脚本攻击

反射型：将用户输入的数据“反射”给目标网站
存储性：将带有恶意的脚本存储在数据库，当浏览器请求数据时，服务器返回并执行恶意脚本
基于DOM：通过恶意脚本修改 DOM 结构

xss 攻击的防范

csp（内容安全策略）：指定资源的来源，如 1) 只允许加载本站资源Content-Security-Policy: default-src 'self'；2) 只允许加载HTTPS协议图片Content-Security-Policy: img-src https://*; 3) 允许加载任何来源框架 Content-Security-Policy: child-src 'none'
httpOnly 阻止 cookie 劫持
对输入进行转义：如 vue 中的 decodingMap：

// 在 vuejs 中，如果输入带 script 标签的内容，会直接过滤掉
const decodingMap = {
'&lt;': '<',
'&gt;': '>',
'&quot;': '"',
'&amp;': '&', 
' ': '\n'
}

csrf: 跨站请求伪造

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的

csrf 攻击类型

GET类型的CSRF：第三方网站中含有发起操作请求的 img 标签

<img src="http://bank.example/withdraw?amount=10000&for=hacker" >

POST类型的CSRF：第三方网站加载后自动提价表单

    <form action="http://bank.example/withdraw" method=POST>
        <input type="hidden" name="account" value="xiaoming" />
        <input type="hidden" name="amount" value="10000" />
        <input type="hidden" name="for" value="hacker" />
    </form>
    <script> document.forms[0].submit(); </script>

链接类型的CSRF：需要点击链接才能触发，一般是广告弹窗的形式

csrf 攻击的防范

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

阻止不明外域的访问
- 同源检测
- Samesite Cookie
提交时要求附加本域才能获取的信息
- CSRF Token
- 双重Cookie验证

用户验证机制

Cookie 与 Session

Cookie：客户端保存用户信息的一种机制，用来记录用户的一些信息；大小一般不超过 4kb

httpOnly：客户端则无法通过js代码去访问（包括读取、修改、删除等）这个cookie
Domain和Path: 域名，域名的子域名也可以访问
Path: 路径，Domain和Path一起来限制 cookie 能被哪些 URL 访问
Expires: 过期时间，具体的时间，http/1.0
Max Age: 秒为单位时间段， http/1.1；有三种可能的值：session（的有效期）、0（删除cookie）、正数（有效时间）；默认值是 session
Session：服务端保存用户信息的一种机制（主要存储的的SessionID和Session内容，同时也包含了很多自定义的内容如：用户基础信息、权限信息、用户机构信息、固定变量等）；

作用：客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
存储：Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效
验证：
- 用户第一次登录后，浏览器会将用户信息发送给服务器
- 服务器会为该用户创建一个SessionId，并在响应内容（Cookie）中将该SessionId一并返回给浏览器，浏览器将这些数据保存在本地
- 当用户再次发送请求时，浏览器会自动的把上次请求存储的Cookie数据自动的携带给服务器
- 服务器接收到请求信息后，会通过浏览器请求的数据中的SessionId判断当前是哪个用户，然后根据SessionId在Session库中获取用户的Session数据返回给浏览器。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

Token

采用 Cookie 和 Session 保持用户的状态时，每次请求都需要将 cookie 传给服务端，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否。而Session的存储是需要空间的，频繁的查询数据库给服务器造成很大的压力。

在这种情况下，Token应用而生。

Token的生成
最简单的Token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由Token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器)

Token验证流程

客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者数据库里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据