看了一些Web安全的文章，有些讲得非常好，也非常详细，但不够言简意赅；本文是个吸取了他们的精华之后总结，以清晰明了、言简意赅为目的。
目录
- 1. XSS (Cross Site Script) 跨站脚本攻击
- 2. CSRF（Cross-Site Request Forgery）跨站请求伪造攻击
- 3. SQL 注入
- 4. 点击劫持
- 5. 命令行注入
- 6. DNS劫持
- 7. HTTP劫持
内容
1. XSS (Cross Site Script) 跨站脚本攻击
1.1. 示例
如你的 Web 页面中有如下类似的代码：
document.write(
"" +
"<div >" +
location.href.substring(location.href.indexOf("default=") + 8) +
"</div>"
);
攻击者可以直接通过 URL 注入可执行的脚本代码，如：https://xx.com/xx?default=<script>alert(document.cookie)</script>；
1.2. 原理
当页面有动态渲染 或 执行的内容（比如通过：eval、document.write()、innerHTML），且并未对未渲染的内容做转义时，就可以通过注入带有可执行脚本的内容（如：<script></script>）来运行恶意代码；
1.3. 解决方案
- 从源头：尽量从自已的服务端获取数据来源，尽量不要从
location、document.referrer、document.forms等这种可被外部操作的 Api 中获取数据直接渲染。 - 从出口：在将内容渲染至 dom 中时，一律对内容的 HTML 关键字进行转义（如：
<>）。
2. CSRF（Cross-Site Request Forgery）跨站请求伪造攻击
2.1. 原理
完成 CSRF 攻击必须具备以下条件：
- 浏览器中保存了 站点 A 的 cookie，并且 cookie 还没失效；
- 用户访问了恶意 站点 B
- 恶意站点 B 可向 A 站点的服务器发送请求，并会自动携带上 站点 A 的 cookie；
- 站点 A 没有做任何 CSRF 攻击防御；
2.2. 解决方案
- 为每个用户生成一个唯一的 token，该 token 不是通过 cookie 的方式返回给 用户，用户在每次请求时带上该 token；后端收到请求后，验证 token；
3. SQL 注入
3.1. 示例
假设：
用户的登录表单：
<form action="/login" method="POST">
<p>用户名: <input type="text" name="username" /></p>
<p>密码: <input type="password" name="password" /></p>
<p><input type="submit" value="登陆" /></p>
</form>
后端查询用户的 SQL 语句：
let querySQL = `
SELECT * FROM user
WHERE username='${username}'
AND psw='${password}'
`;
// 接下来就是执行 sql 语句...
则：
当恶意攻击者输入的用户名是 zoumiaojiang' OR 1 = 1 -- 时，密码随意输入，就可以直接登入系统了；
因为这会使得最终生成的 SQL 语法为：
SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1 --' AND psw='xxxx'
在 SQL 中，-- 是注释的意思，所以查询语句就变成了：
SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1
这条 SQL 语句的查询条件永远为真，所以意思就是恶意攻击者输入正确的密码，就可以登录进账号；
3.2. 解决方案
- 对于需要通过参数拼接的生成数据库语句的情况，要对参数进行 SQL 关键字检查、转义、过滤。
- 使用数据库提供的参数化接口来进行数据库的操作，而不是通过拼接数据库语句。
4. 点击劫持
4.1. 示例
假如恶意者想诱骗用户为其在博客的发布的某个文章点赞，那么他可以将他的博客文章用 iframe 嵌入自己设计的网页中，然后 iframe 元素层级下面 与 文章点赞按钮对应的位置上放一个诱导性按钮，然后将 iframe 设置为透明，这样用户就看不到 iframe 了，但能看到那个诱导性按钮，当用户点击 诱导性按钮 时，其实是点击了 iframe 中文章点赞的按钮；
4.2. 解决方案
- 在 HTTP 响应头中增加
X-FRAME-OPTIONS字段，并将该字段设置为以下几种值：-
DENY：表示页面不允许通过 iframe 的方式展示 -
SAMEORIGIN：表示页面可以在相同域名下通过 iframe 的方式展示 -
ALLOW-FROM：表示页面可以在指定来源的 iframe 中展示
-
- 通过 js
self == top判断当前页面是否运行在 iframe，如果运行在 iframe，则可能通过 js 禁止一些操作 或 把整个页面给移除掉；
5. 命令行注入
5.1. 示例
原理和 SQL注入 类似，就是：服务器要执行命令，但命令是通过请求参数拼接而成的，就会存在被注入恶意命令的风险；
如下：
// 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repo
const exec = require('mz/child_process').exec;
let params = `用户输入的参数`;
exec(`git clone ${params} /some/path`);
如果用户输入的参数是 https://github.com/xx/xx.git && rm -rf /* &&，则最终会执行的命令是 git clone https://github.com/xx/xx.git && rm -rf /* && some/path
5.2. 解决方案
解决方案也和 SQL注入 类似：
- 对于需要通过参数拼接的生成命令的情况，要对参数进行 命令 关键字检查、转义、过滤。
6. DNS劫持
6.1. 原理
通过篡改电脑 或 路由器的 DNS ，来让一个域名 映射到一个恶意网站上，当你通过域名访问网站时，其实访问的是恶意网站；
7. HTTP劫持
在网络请求链接中的某一个环境上（比如：路由器 或 运营商），拦截 HTTP 的响应，然后篡改响应体 或 在响应体内插入内容（比如：广告）
