代码这么写，可缜密？
一、背景知识
1、安全问题的三大属性
涉及到安全问题时，可以问问自己: "代码这么写，可缜密？"，细心的你已经联想到，安全的三大属性正是让代码可(可用性)缜(完整性)密(机密性)?疑问句转换为肯定句丫
1.1、机密性
通过加密处理后，数据内容不被泄漏。加密算法主要有可逆和不可逆两种类型
1.1.1、 不可逆加密算法
不可逆加密算法最大的特点就是不需要密钥，但是HMAC是需要密钥的。其常用的场景就是用户密码加密，它的验证过程就是通过比较两个加密后的字符串是否一样来确认身份，最常见的不可逆加密算法有：MD5
注意喔：单纯不可逆加密可以被撞库破解，即从一个库中取密文，去另一个网站的库中验证，常见于用户喜欢不同网站都设置一个密码
为了避免上述问题，可根据用户信息不可变的部分hash多一个成分，比如用户ID，每个站点基本不同，但一般由雪花算法生成的绝对随机。因此，改进方案：MD5+用户ID/随机字符串。
1.1.2、 可逆加密算法
可逆加密算法的数据，不管加密还是解密都需要使用秘钥操作，其又分为 对称加密 和 非对称加密
1.1.2.1、对称加密
数据加密和解密时用的都是同一个密钥，其安全性相对较低。密钥被中间人如vpn、公共wifi、路由器、代理等劫持，中间人就可以使用密钥解密通信内容
比较适用的场景是内网环境中的加解密，常见的算法有：DES
1.1.2.2、非对称加密
非对称加密算法有两个密钥，这两个密钥完全不同但又完全匹配。一个密钥加密的内容只能由另一个密钥解开，而通信时只传递一把密钥
只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。常见的非对称加密有RSA、SM2等
1.2、完整性
保护数据内容是完整的，没有被篡改。可通过数字签名等措施
1.2.1、数字签名的生成过程
- CA 拥有一对非对称加密的私钥和公钥
- CA 对证书明文信息进行 hash
- 对 hash 后的值用私钥加密，得到数字签名
1.2.2、浏览器验证
- 得到 [被 CA 私钥加密过的] 内容 和 数字签名
- 用 CA 机构的公钥对 加密过的数字签名 解密，得到 数字签名
由于 CA 是浏览器信任的机构，所以浏览器保有 CA 的公钥。
- 用证书里说明的 hash 算法对 数字签名 进行 hash 得到 [被数字签名保护内容]。
- 比较 [被数字签名保护内容] 是否等于 内容，等于则表明证书可信
1.3、可用性
即保证数据随时都能够使用，主要防御DOS、DDos攻击。常见的措施有：
- 定期扫描 // 补充：域名巡检、健康检查
- 在骨干节点配置防火墙 // 补充：流量网关，域名IP频率限制
- 用足够的机器承受黑客攻击 // 补充：CDN节点
- 充分利用网络设备（路由器、防火墙等负载均衡设备）保护网络资源，比如在路由器上过滤假IP，即过滤不必要的服务和端口
2、安全的原则
2.1、黑白名单原则
黑名单禁用不安全的资源，白名单给安全的资源授权
2.2、最小权限原则
2.3、数据与代码分离原则
2.4、纵深防御原则
类似木桶理论，安全水平往往取决于最短的那块板
2.5、不可预测性原则
提高攻击门槛，有效防止基于篡改、伪造的攻击，比如数据库中使用 uuid 代替 number 型的自增主键，可以避免 id 被攻击者猜到，从而进行批量操作
二、安全攻防
安全攻防分为客户端攻击以及服务端攻击，这里主要针对客户端攻击进行分析梳理，暂不讨论服务端攻击
1、XSS攻击
1.1、本质
将用户数据当成了 HTML 代码一部分来执行，从而混淆原本的语义，产生新的语义。从而使得攻击者可以获取大量的用户信息，其常见的场景有：
- 向页面注入一个登录弹窗，让用户认为是网站内的登录弹窗（其实是钓鱼网站的），一旦用户登录，账号密码就泄露给了钓鱼网站
1.2、触发
所有和用户交互的地方，都有可能存在 XSS 攻击，比如：input 框、window.location、document.referrer、document.cookie
1.3、方式
首先往浏览器中注入恶意脚本，再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上
1.3.1、存储型 XSS 攻击
黑客提交恶意脚本到网站的数据库中 -> 用户向网站请求包含恶意脚本的页面 -> 当用户浏览该页面时，恶意脚本将用户信息上传到恶意服务器
1.3.2、反射型 XSS 攻击
用户提交含有恶意脚本的请求到服务器 -> 服务器接收请求且将恶意脚本反射给了浏览器端
1.3.3、基于 DOM 的 XSS 攻击
可能发生于web资源传输过程 或者 用户登录状态时修改页面数据
1.4、防御
- 服务器对输入脚本进行过滤或转码
- 添加身份验证，限制输入长度
- 使用 HttpOnly 属性，即无法通过脚本来读取Cookie
- CSP：让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联脚本
2、CSRF攻击
2.1、本质
跨站请求伪造利用服务器的漏洞和用户的登录状态来实施攻击， 其常见的场景有：
- 自动发起GET请求，一般会利用图片发起请求
<img src="http://huamu.com/withdraw?amount=10000&for=hacker" />
当用户访问含有如上图片的页面时，浏览器会自动向huamu.com发起一次HTTP请求，huamu.com会收到包含用户登录信息的跨域请求
- 自动发起POST请求，常见于表单模拟
<form action="http://huamu.com/withdraw" method=POST>
<input type="hidden" name="account" value="airing" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
当用户访问含有如上代码的页面时，表单会自动请求，相当于模拟了一次POST 操作
- 引诱用户点击链接，常见于链接，类似以上两种，只是换成
href方式请求
2.2、发起攻击必要条件
- 目标站点一定要有CSRF漏洞
- 用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态
- 需要用户打开一个第三方站点，可以是黑客的站点，也可以是一些论坛
2.3、防御
黑客利用用户的登录状态，通过第三方站点发起的请求
2.3.1、利用 HTTP 协议特性阻止不明外域的访问
- 同源检测：优先判断
Origin，根据实际情况判断Referer
| 请求头属性 | 描述 |
|---|---|
| Referer | 包含路径信息，非必选项，不可靠 |
| Origin | 只包含域名信息，必选项（通过xhr、Fecth发起跨站或Post方法请求时都会带上） |
- 在响应头，设置
cookie时，带上SameSite选项：Set-Cookie: SameSite=strict;
| 选项值 | 描述 |
|---|---|
| strict | Cookie只会在第一方上下文中发送，不会与第三方网站发起的请求一起发送 |
| lax | 相对宽松。跨站点情况下，从第三方站点的链接打开和第三方站点提交GET方式的表单这两种会携带cookie，若使用post，或通过img，iframe等标签的URL，不会携带cookie。这是浏览器中的默认值 |
| none | 任何情况下都发送，即允许跨域发送 |
2.3.2、提交时要求附加本域才能获取的信息
-
生成 CSRF Token（随机字符串）区分正常请求与攻击请求
将CSRF Token输出到页面中 -> 页面提交的请求携带这个Token -> 服务器验证Token是否正确 -
双重Cookie防御
服务器向请求域名注入一个Cookie，如：csrfcookie=v8g9e4ksfhw
|
浏览器发起POST请求时携带注入的Cookie，如：https://www.huamu.com/xxx?csrfcookie=v8g9e4ksfhw
|
服务器验证Cookie是否正确
3、网络劫持
3.1、本质
视觉欺骗，一般通过 iframe 嵌入攻击者网页，将iframe设置为透明，并暴露按钮诱导用户点击
3.2、防御
3.2.1、frame busting
使用 JS 脚本判断是否被恶意网站嵌入，若监测到站点被一个 iframe 打开，自动跳转到正常的页面即可
3.2.2、在响应头，带上x-frame-options选项：x-frame-options: sameorigin;
| 选项值 | 描述 |
|---|---|
| deny | 页面不允许通过 iframe 的方式展示 |
| sameorigin | 可以在相同域名下通过 iframe 的方式展示 |
| allow-from | 可以在指定来源的 iframe 中展示 |
3.2.3、iframe 带上 sandbox = "allow-same-origin" 属性
只能加载与主站同域的资源
