转载

SQL 注入有病，安全专家有何良方？

SQL 注入攻击现状

SQL 注入攻击是一个非常老的攻击方式，由于很多应用程序都存在 SQL 注入漏洞而且 SQL 注入方式与手段变化多端，尽管大型企业一般都花巨资购买多种安全保护系统，但是 SQL 注入攻击导致企业蒙受损失的新闻还是层出不穷：

香港航空某站 SQL 注入（涉及156万乘客信息/268万机票信息/八千多员工信息）
中石化车 e 族 APP 存在 SQL 注入漏洞之一（可跨9个库）
海尔旗下日日顺商城 SQL 注入可导致300万会员信息泄漏
邯郸市工信办漏洞危及大量个人信息以及金额等数据，百万用户数据泄露
中国电信翼支付某系统漏洞泄露400万用户信息、支付交易明细信息（超市购物/加油站加油）以及充值等数据

从这些例子可以看出 SQL 注入是当前应用安全防护的重点和难点，是什么原因导致如此古老的攻击方式在当今安全软件如此丰富的情况下依旧导致这么大伤害呢？笔者认为有以下几点：

SQL 注入漏洞大面积的存在：当今系统越来越复杂，发布节奏越来越快，遗漏代码非常多。很多公司对安全不够重视，带病上线是非常常见的事情。
关系型数据库是现在最流行的存储方式，大多数有价值的信息都存在数据库里。这对黑客的诱惑力太大了。
攻击方式并不难找，网络有大量的 SQL 注入攻击的方法和手段。黑客很容易找到攻击的方式。

SQL 注入的原理

SQL 注入：就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串里，最终达到欺骗服务器执行恶意的 SQL 命令。

具体来说，它是利用现有应用程序，将（恶意）的 SQL 命令注入到后台数据库引擎执行的能力，它可以通过在 Web 表单输入（恶意）SQL 语句得到一个存在安全漏洞的网站的数据库信息，而不按照设计者的意图执行 SQL 语句。

首先让我们了解下什么时候可能发生 SQL 注入：

假设我们在浏览器中输入 URL: www.sample.com，由于它只是对页面的简单请求无需对数据库进行动态请求，所以它不存在 SQL 注入，当我们输入 www.sample.com?testid=23 时，我们在 URL 中传递了变量 testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中 ?testid＝23 表示数据库查询变量），所以我们可以在该 URL 中嵌入了恶意 SQL 语句。

具体的例子和详细的原理就不在这里赘述了，有兴趣的同学可以去谷歌或者百度搜索，上面会有大量的例子和攻击方式。

SQL注入常用保护方式

最主要的保护方式有以下几点：

使用 Prepared Statements（参数查询）来代替 Statements — 这要求所有数据库开发人员在开发 SQL 查询语句时将代码和数据分开，先定义查询语句的结构，将数据通过参数的方式出入，这样输入的参数将不会当作 SQL 命令来执行，基本上能避免 SQL 注入的攻击。
使用存储过程来操作数据库 — 所有的存储过程都存放在数据库里面，应用程序调用存储过程来查询数据。
转义用户输入的所有特殊字符 – 永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。这些在一定程度可以缓解SQL注入。

还有些辅助的方法：

以最低权限的数据库连接，为每个应用使用单独的权限与有限的数据库连接。
不要把机密信息明文存放，加密或者 hash 掉密码和敏感的信息。
应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

RASP 从根本上解决 SQL 注入攻击

上面描述的是一些非常有用的 SQL 防护手段，但是都存在一个共同的缺点——需要花费大量的精力制定代码规范，确保每个程序员都能按照这个规范来编写代码。但是现在的程序都非常复杂，代码量动辄百万行，需要非常多的程序员一起完成，要确保每个程序员写出完全符合安全规范的代码是完全不可能的。有些公司通过第三方代码扫描工具对代码进行静态和动态扫描，试图发现和修复所有 SQL 注入的漏洞，在实践中也非常不理想，以下几个方面的约束使这种想法很难实现：

代码量巨大，完全修复这些漏洞要花费巨大的人力和时间，在大多数公司基本不可能实现。
扫描工具漏洞更新比较滞后，很多漏洞都不能得到及时更新。即使完全修复，上线后也会有新的漏洞产生。
一般项目都会大量使用第三方 API 和框架，这些外部程序的漏洞是不可修改的，即使提供商承诺修改也需要比较长得时间。

现在有很多的安全产品，包括传统防火墙，WAF（Web 防火墙）等等，这些安全产品基本上是根据数据流扫描的结果来提供保护，并不了解应用程序的上下文，所以不能精确识别攻击行为，更谈不上有效的保护，再加之现在云计算越来越盛行，传统的有清晰边界的网络拓扑结构也越来越少，因此这些产品对类似于 SQL 注入等应用安全攻击效果并不好。

那么安全专家有什么好的建议呢？他们推荐了 RASP，这是最近非常流行的应用安全保护方案，它是在应用程序运行时进行自我保护，它将实时代码漏洞扫描和 Web 防火墙实时拦截安全攻击的能力组合起来，像疫苗一样将安全保护代码注入到应用程序中，它无需用户修改任何代码，只需要简单修改 JVM 启动脚本就可以和应用程序完美结合在一起，在应用程序运行时一起运行，拥有应用程序的上下文，可以根据具体的用户行为有针对性行的进行安全监控和保护，既可以精确的识别和防范安全攻击，也可以最大限度的降低对性能和用户体验的影响。

而具体到 SQL 注入保护方面，RASP 做得非常完美。它就像一个大的虚拟补丁，将大部分已知的 SQL 注入漏洞进行修补，确保大部分漏洞得到保护。这样大部分的攻击将无效，目前国内已知的仅有 OneRASP 具备这样的防护能力。

对于未知漏洞 OneRASP 将建立实时漏洞更新系统，能及时更新最新漏洞，在不影响用户系统的前提下，确保用户及时有效地抵御零日攻击。

对于无法预知的 SQL 注入方式，OneRASP 也有办法防御。常见的 SQL 注入保护方式往往采用通用的方法，而每个数据库的实现方式有很大的不同，这些通用的方式必然会有遗漏之处。对安全来说任何遗漏都是致命的，黑客可以利用任何可乘之机获得机密。OneRASP 对 SQL 注入保护非常完整，它将保护代码植入 SQL 注入攻击的必经点：JDBC 的各个厂家的实现类 Statement.class 里面，每个保护动作都是在对数据库 SQL 语言的实现完全理解的基础上编写的，考虑 SQL 注入的每种攻击可能，实现从根上对 SQL 注入的完整保护。

OneRASP 是应用性能管理领军企业 OneAPM 公司最新推出的 RASP（运行时应用程序自我保护系统）应用程序保护方案。这是国内第一款 RASP 安全产品，其稳定性、准确性、易用性以及对应用程序性能和使用影响非常小的这些特点，给很多开发者留下了深刻的印象。但是由于是新推出的产品，还需要时间的检验，有兴趣的同学可以访问 OneASP 的官网。

正文到此结束