Web安全的原理及解决方案

看了一些Web安全的文章，有些讲得非常好，也非常详细，但不够言简意赅；本文是个吸取了他们的精华之后总结，以清晰明了、言简意赅为目的。

目录

• 1. XSS (Cross Site Script) 跨站脚本攻击
  • 1.1. 示例
  • 1.2. 原理
  • 1.3. 解决方案
• 2. CSRF（Cross-Site Request Forgery）跨站请求伪造攻击
  • 2.1. 原理
  • 2.2. 解决方案
• 3. SQL 注入
  • 3.1. 示例
  • 3.2. 解决方案
• 4. 点击劫持
  • 4.1. 示例
  • 4.2. 解决方案
• 5. 命令行注入
  • 5.1. 示例
  • 5.2. 解决方案
• 6. DNS劫持
  • 6.1. 原理
• 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 攻击必须具备以下条件：

1. 浏览器中保存了 站点 A 的 cookie，并且 cookie 还没失效；
2. 用户访问了恶意 站点 B
3. 恶意站点 B 可向 A 站点的服务器发送请求，并会自动携带上 站点 A 的 cookie；
4. 站点 A 没有做任何 CSRF 攻击防御；

2.2. 解决方案

1. 为每个用户生成一个唯一的 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. 解决方案

1. 对于需要通过参数拼接的生成数据库语句的情况，要对参数进行 SQL 关键字检查、转义、过滤。
2. 使用数据库提供的参数化接口来进行数据库的操作，而不是通过拼接数据库语句。

4. 点击劫持

4.1. 示例

假如恶意者想诱骗用户为其在博客的发布的某个文章点赞，那么他可以将他的博客文章用 iframe 嵌入自己设计的网页中，然后 iframe 元素层级下面 与 文章点赞按钮对应的位置上放一个诱导性按钮，然后将 iframe 设置为透明，这样用户就看不到 iframe 了，但能看到那个诱导性按钮，当用户点击 诱导性按钮 时，其实是点击了 iframe 中文章点赞的按钮；

4.2. 解决方案

1. 在 HTTP 响应头中增加 X-FRAME-OPTIONS 字段，并将该字段设置为以下几种值：
   • DENY：表示页面不允许通过 iframe 的方式展示
   • SAMEORIGIN：表示页面可以在相同域名下通过 iframe 的方式展示
   • ALLOW-FROM：表示页面可以在指定来源的 iframe 中展示
2. 通过 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注入 类似：

1. 对于需要通过参数拼接的生成命令的情况，要对参数进行 命令 关键字检查、转义、过滤。

6. DNS劫持

6.1. 原理

通过篡改电脑 或 路由器的 DNS ，来让一个域名 映射到一个恶意网站上，当你通过域名访问网站时，其实访问的是恶意网站；

7. HTTP劫持

在网络请求链接中的某一个环境上（比如：路由器 或 运营商），拦截 HTTP 的响应，然后篡改响应体 或 在响应体内插入内容（比如：广告）