防御
对XSS的防御
-永远不信任用户的提交内容 -不要将用户提交内容直接转换成DOM
前端现成工具：-主流框架默防御XSS； -google-closure-library
服端(Node)：DOMPurify
如果需要动态生成DOM：
1）string->DOM：即new DOMParser();时 ，需要对string进行转译
2）上传svg：需要对svg进行扫描检查，不允许插入script标签
<svg>
<script>alert("xss");</script>
</svg>
3）尽量不要做让用户自定义跳转的行为，如果做一定要做好过滤，因为可能会传递js代码。Blob 动态生成script
const blob = new Blob{
[script],
[ type: "text/javascript"],
};
const url = new URL.createObjectURL(blob);
const script = document.createElement("script");
script.src = url;
4）自定义样式
CSP内容安全策略
Content Security Policy(CSP):
-哪些源(域名)被为是安全的 -来自安全源的脚本可以执行,否则直接抛错 -対 eval + inline script直接拒绝
CSP举例：只允许同源的和domain.com地址访问
对CSRF的防御
限制请求来源
检查Origin和Referer，如果是服务器端的域名放行，反之拒绝。同源请求中,GET+HEAD不发送Origin字段。
token
CSRF-token解决：token必须和具体用户进行绑定，且有过期时间
CSRF-ifrane攻击解决方案
按钮下边盖着iframe(合法页面)，按钮点击事件因为css而穿越到了iframe下触发了点击，点击按钮也就让iframe中发出了同源请求。
可以设置响应头部X-Frame-Options: DENY/SAMEORIGIN（当前页面不能加载iframe/是同源页面才能加载iframe）来防御。
避免用户携带SameSite Cookie
也就是说我的页面的Cookie只能我的页面使用，别的页面不能访问的到
如果第三方的必须使用到cookie，比如发送弹幕需要用到用户当前登录状态；服务器可以先把SameSite设置网None。Set-Cookie: SameSite=None; Secure; 即SameSite=None表示该Cookie可以让第三方携带。
SameSite CORS -Cookie发送 -资源读写(HTTP请求) -domain vs 页面域名 -资源域名vs页面域名 -“我跟你个事儿, 出这屋我可就不了” -白名単
对Injection的防御
对SQL注入的防御
-找到项目中查询SQL的地方 -使用prepared statement
其他防御操作：
1)-最小权限原则 : -sudo || root
2)-建立允许名单+过滤 : -rm 3)-对URL类型参数进行协议、域名、ip等限制 : -访问内网
对DoS的防御
ReDoS的防御
-Code Review (X /(ab*)+/) ：避免使用正则的贪婪匹配模式 -代码扫描 + 正则性能测试
-拒绝使用用户提供的正则
DDoS的防御
对中间人攻击的防御
HTTPS的特性：
-可靠性:加密 （采用对称加密和非对称加密） -完整性:MAC验证。
如何确保HTTPS在传输过程中的完整性，图如下：
-不可抵赖性:数字签名
数字签名的执行者有自己的私钥privatekey和公钥sessionkey ，执行者可以对内容用私钥进行加密，双方可以用公钥进行解密。
数字签名过程：
服务提供方提供的一些元信息，和公钥一起合并成的信息，使用CA提供的私钥进行签名，形成真正的服务器端的证书，然后将证书传递给浏览器，浏览器会用CA的公钥对证书进行校验，判断证书签发者是否可信。
浏览器会内置大量CA签发的证书，证书里会包含公钥。
HTTPS加密过程：
HTTP Strict-Transport-Security(HSTS)
SRI
如果CDN资源托管平台CDN被攻陷，放在CDN上的静态资源被劫持，可以使用SRI。SRI就是 对比标签 hash(原始内容 hash) 和 实际内容 hash
