安全相关，SQL 注入

最终攻击者就可以成功登录 admin 账号了，这就是最简单的 SQL 注入了。从上面这个简单示例中，我们发现漏洞成因可以归结为以下两个原因叠加造成的：

1. 程序编写者在处理应用程序和数据库交互时，使用字符串拼接的方式构造SQL语句。
2. 未对用户可控参数进行足够的过滤便将参数内容拼接进入到SQL语句中。

SQL注入根据攻击者获取数据的方式分为回显注入、报错注入以及盲注。

刚才演示的直接从返回结果中获取数据则为回显注入，当然也可以通过 MySQL 执行的报错结果中嗅探到数据库的结构和内容，这就是报错注入。盲注则是根据数据库执行的延时等操作来判断是否接近正确值，简单的说来有点像是拿着听诊器试探保险箱的密码的感觉。

不同的分类原则会有不同的分类，也有按照注入位置及方式不同进行分类分为POST注入、GET注入、cookie注入、盲注、延时注入、搜索注入、base64注入等。

不过大家都支持分类形式不同，原理还是一致的，这里就不一一细说了。

数据校验

从文章开头可以看到，其实漏洞的主要原因还是没有对用户输入的数据进行过滤，所以对来自用户的数据（GET, POST, cookie 等）最好做到以下两种过滤校验：

1. 检查输入的数据是否具有所期望的数据格式。这种在参数是数字的时候特别有效，如果攻击者选择在参数中插入内容的话则会被转换成 NaN 导致攻击失败。在 ThinkJS 中我们提供了强大的 Logic 功能可以方便的对数据进行格式校验。
2. 使用数据库特定的敏感字符转义函数把用户提交上来的非数字数据进行转义。在 ThinkJS 中封装了 escapeString() 方法可以对敏感字符进行转义，其原理则和 PHP 的 mysql_escape_string() 方法是一致的。

检查输入数据格式在 ThinkJS 中还能防止另外一种非通用 SQL 安全问题。文章开头的示例代码我们在实际的应用中一般会这么写：

// user.js
module.exports = class extends think.Controller {
  async loginAction() {
    const { username, password } = this.post();
    const user = await this.model(‘user‘).where({
      name: username,
      password
    }).find();

    if (think.isEmpty(user)) {
      return this.fail();
    }
    return this.success(user);
  }
}

当我们构造如 name=admin&password[]=!%3D&password[]= 的请求参数时，最终执行的 Model 语句就会变成

this.model(‘user‘).where({name: ‘admin‘, password: [‘!=‘, ‘‘]});