今天看了 jsliang 大佬关于网络安全的文章，为了加深一下印象，自己动手写一下。
主要参考文章：网络安全 ——— jsliang
XSS攻击
XSS（Cross Site Script）跨站脚本攻击，指的是向网页注入恶意代码，并对网页进行篡改。在用户浏览时，从而获取用户隐私数据的一种攻击方式。一般为 JavaScript 。
- 窃取 Cookie 信息，模拟用户进行登录，然后进行转账等操作
- 使用 addEventListener 监听用户行为，监听键盘事件，窃取用户的银行卡密码等。并发送到攻击者的服务器
- 通过修改 DOM 伪造假的登录窗口，欺骗用户输入用户名和密码等
- 生成浮窗广告等
- 修改 URL 跳转到恶意网站
- ....
防御 ：
- 输入检查：对输入内容中的 script 和 iframe 等标签进行转义或者过滤
- 设置 httpOnly(后端)： 设置此属性可防止 JavaScript 获取 Cookie, 只能在 HTTP请求过程中使用 Cookie
- 开启 CSP 白名单 ：即开启白名单，可以阻止白名单意外的资源加载和运行 （参考：web安全csp白名单的弊端、开启CSP网页安全政策防止XSS攻击）
CSRF攻击
CSRF(Cross—Site Request Forgery) 跨站请求伪造。简单说一下自己的理解，不对的地方请指正。CSRF攻击主要是利用用户登陆过的网站生成的Cookie,也就是这个用户的凭证，操控用户，进行转账等有利于攻击者的行为。但并不是像XSS攻击一样窃取Cookie,攻击者不知道Cookie的内容，只是利用而已。 例子： 网站A为用户正常浏览的网站，网站B为攻击者的恶意网站。假设用户已经登录网站A获取到了Cookie,这时候用户打开网站B，这时候网站B运行恶意代码，请求访问网站A或者说网站A某个api（例如网站A的转账api），通常是在用户不知情的情况下。
防御：
- 验证 Token：浏览器请求服务器时，服务器返回一个 token，之后每个请求都需要同时带上 token 和 Cookie 才会被认为是合法请求
- 验证 Referer：通过验证请求头的 Referer 来验证来源站点，但请求头很容易伪造
- 设置 SameSite：设置 Cookie 的 SameSite，可以让 Cookie 不随跨站请求发出，但浏览器兼容不一
具体实现和原理参考：CSRF攻击与防御
SQL注入
主要是通过往输入框里面输入 SQL语句，利用 SQL的语法识别机制，从而修改数据库实际上运行的SQL语句，以达到攻击者的目的
例如：
（假设前端没有做用户名和密码的校验）
用户输入的用户名：Kite OR '1 = 1'--
用户输入的密码：123456
预想执行的SQL语句：SELECT * FROM user WHERE username='Kite' AND psw='123456'
实际执行的SQL语句：SELECT * FROM user WHERE username='Kite' OR 1 = 1 --' AND psw='xxxx'
"--":是SQL的注释代码。也就是说 1 = 1 后面的代码无效。 结果就变成无论输入的用户名和密码是否正确，都可以登录。因为 1 = 1 肯定是为 true 。
防御：
- 通过正则验证用户输入的内容是否包含引起隐患的字符
- 一般由后端来处理。
流量劫持
DNS 劫持
建过站点的朋友应该都知道，需要域名解析，不然无法通过自己购买的域名访问自己的服务器。域名解析，也就是通过 DNS 服务器实现域名和服务器IP的映射，例如 kite1874.com 对应的 IP 为 127.0.0.1。你访问 kite1874.com 的时候，实际访问的是 127.0.0.1 这个IP地址对应的服务器。实际上输入 127.0.0.1 也可以正常访问站点。之所以需要使用域名进行访问，是为了方便记忆和SEO
DNS劫持，也就是通过篡改域名映射的IP，导致用户访问的网站，变成攻击者准备的恶意网站。
例如：
- 篡改路由器 DNS 配置。
- 篡改 Hosts 文件貌似也可以做到（自己脑补的）
- 网络供应商可以修改，如果有意这样做的话。
- ...
HTTP 劫持
大家都知道，HTTP 请求是明文的。而 HTTP 劫持主要是篡改请求的内容。例如:你打开一个网页,请求返回一个HTML文件，然后有意者修改这个HTML，往里面插了个小广告，然后再返回给你。广告还算小事，要是返回一个表单让你输入账号密码呢？你全然不知，还以为这是原来网站上的表单呢
防御：
- HTTP 传输是明文，所以需要给它加密。也就是 HTTPS 协议。需要申请 SSL 证书。
