这是我参与「第四届青训营 」笔记创作活动的第4天。
安全问题是无处不在的，只要一个不小心，用户、公司和程序员都会受到危害。
一：如果是一个hacker—攻击
1. xss：因为盲目信任用户的提交内容。利用一段伪代码进行攻击。攻击时是暗地里执行脚本的，难以感知，并窃取用户的信息，会诱骗用户点击表单。（程序员没有过滤的代码，很容易被攻击）
a) Stored XSS：在访问页面读数据的时候，就会被攻击。
b) reflected XSS 不涉及数据库，从URL上攻击（访问页面）。
c) DOM-based XSS 不需要服务器的参与，恶意攻击的发起+执行，全在浏览器完成。（有恶意脚本）
d) Mutation-based XSS 利用了浏览器渲染DOM的特性，不同浏览器，会有区别（按照浏览器进行攻击），最难防御的一种形式。
2. CSRF：在用户不知情的前提下利用用户权限，构造指定HTTP请求，窃取或修改用户敏感信息。是跨站违章请求。
3. injection：注入攻击使数据面临删除和修改的危害。Injction不止于SQL，虽然严格来说SSRF不是，但是基本的原理是一样的。容易暴露数据的地址。（写的重要文件的代码被暴露，就容易被修改）
4. Dos：通过某种方式，导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而导致雪崩效应。正则表达式如果有贪婪模式，则容易被攻击。
5. DDoS：短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。（通过中间人进行攻击，因为代码是明文传输、信息篡改不可知、对方身份未验证）（例子：洪水攻击）
a) 攻击特点：直接访问IP，任意API，消耗大量带宽（耗尽）
二：如果是一个开发者—防御
1. XSS：永远不要信任用户提交的内容，不要将用户递交内容直接转换成DOM。
a) 开发工具：前端：主流框架默认防御XSS。google-closure-library。服务端：DOMPurify
b) 如果非要生成DOM：将string转化成DOM，如果上传svg文件，需要将文件进行一次扫描，不要让自定义跳转，如果要跳转，则要使用过滤，注意一些细节。
c) Same-origin Policy：要注意协议，域名和端口是否一致，在HTTP请求的时候同源是ok的，但是跨域的时候就要注意服务器的设置。
2. CSP：那些源（域名）被认为是安全的，对来自安全源的脚本可以执行，否者直接抛错，对eval+inline script说不。
3. CSRF：注意先有页面，后有请求，除了Origin+Referrer其他判断【请求来自于合法来源】的方式：if（请求来自合法页面）、then（服务器接收过页面请求）、then（服务器可以标识）。Token与具体用户进行保护，并且有期限。
a) 绕过iframe攻击：进行同源请求。
b) Anti_pattern:不能将get弄成get+post。
c) 避免用户信息被携带：Same Site Cookie：限制的是Cookie ｄｏｍａｉｎ和页面域名。
4. Ｉｎｊｅｃｔｉｏｎ：找到项目中查询ＳＱＬ的地方，使用prepared statement。要有最小权限原则，建立允许名单＋过滤，对ＵＲＬ类型参数进行协议、域名、ｉｐ等限制。
5. DOS：代码扫描＋正则性能测试，不为用户提供的使用正则的权限。
6. ＤＤＯＳ：流量治理，负载均衡、ＡＩＰ官网、ＣＤＮ快速自动扩容，非核心服务降级。
7. HTTP的一些特性：可靠性：加密。完整性：MAC验证。不可抵赖性：数字签名。
安全看起来是一件小事情，但是也是非常值得我们去注意的事情，不能被忽视。
\
