【白帽子讲Web安全】注入攻击

注入攻击

两个关键条件：
第一个是用户能够控制输入。
第二个是原本程序要执行的代码，拼接了用户输入的数据。
7.1 SQL注入
在拼接的过程中导致代码注入，也可利用错误回显进行注入。
7.1.1 盲注
盲注，即在服务器没有错误回显时进行的注入攻击，
常用的方法：构造简单的条件语句，根据返回页面是否发生变化，来判断SQL语句是否执行。
在攻击者构造条件 “and 1=1” 时。如果页面正常返回，说明and语句成功执行，就可以判断“id”参数存在SQL注入漏洞。
盲注的工作原理：攻击者通过简单的条件判断，再对比页面返回结果的差异，就可以判断出SQL注入漏洞是否存在。

【AND 和 OR 运算符
AND 和 OR 可在 WHERE 子语句中把两个或多个条件结合起来。
如果第一个条件和第二个条件都成立，则 AND 运算符显示一条记录。
如果第一个条件和第二个条件中只要有一个成立，则 OR 运算符显示一条记录。】
7.1.2 Timing Attack
利用BENCHMARK()函数，可以让同一个函数执行若干次，使得结果返回的时间比平时要长；通过对比时间长短的变化，可以判断出注入语句是否执行成功。这是一种边信道攻击，这个技巧在盲注中被称为Timing Attack。结果为真，时间较长，不为真，语句将很快完成。
在建立数据库账号时，应该遵循“最小权限原则”，尽量避免给Web应用使用数据库的管理员权限。
7.2.4 编码问题
在有些时候，不同字符编码也可能导致一些安全问题，需要统一数据库，操作系统、Web应用所使用的字符集，以避免各层对字符的理解存在差异。当浏览器与服务器返回的字符编码不同，也会存在字符集攻击，解决方法就是在HTML页面的标签中制定当前页面的charset。如果因为种种原因无法统一字符编码，则需要单独实现一个用于过滤或转义的安全函数。根据系统所使用的不同字符集来限制用户输入数据的字符允许范围，以实现安全过滤。
7.3正确防御SQL注入
7.3.1 使用预编译语句
一般来说，防御DQL注入的最佳方式，就是使用预编译语句，绑定变量。例子见书 P171。
7.3.2 使用存储过程
使用安全的存储过程对抗SQL注入。使用存储过程的效果和预编译语句类似，区别在于，存储过程需要先将SQL语句定义在数据库中，但是，存储过程也可能存在注入问题，因此要尽量避免在存储过程中使用动态的SQL语句。如果无法避免，则应该使用更严格的输入过滤或者是编码函数来处理用户的输入数据。
7.3.3 检查数据类型
7.3.4 使用安全函数
从数据库自身的角度来说，应使用最小权限原则，避免Web应用直接使用root、dbowner等高权限账户直接连接数据库。如果有多个不同的应用在使用同一个数据库，则也应该为每个应用分配不同的账户。Web应用使用数据库账户，不应该有创建自定义函数、操作本地文件的权限。

注入攻击都有相同的特点，就是应用违背了“数据与代码分离”原则。
7.4.1 XML注入
XML注入需要满足两大条件：用户能控制数据的输入、程序拼凑了数据。
修补方案：对用户数据中包含“语言本身的保留字符”进行转义即可。
7.4.2 代码注入
代码注入与命令注入往往都是由一些不安全的函数或者方法引起的。
在Java中也可以实现代码注入，比如利用Java的脚本引擎。 例子见书P175.
PHP、JSP的动态include（文件包含漏洞）导致的代码执行都可以算是一种代码注入。
代码注入多见于脚本语言，有时候代码注入可以造成命令注入。
对抗代码注入、命令注入时，需要禁用eval()、system()等可以执行命令的函数。如果一定要使用这些函数，则需要对用户输入的数据进行处理。此外，在PHP/JSP中避免动态include远程文件，或者安全地处理它。
7.4.3 CRLF 注入
CRLF常被用做不同语义之间的分隔符。因此通过“注入CRLF字符”，就有可能改变原有的语义。CRLF注入并非仅能用于log注入，凡是使用CRLF作为分隔符的地方都可能存在这种注入。比如“注入HTTP头”
在HTTP协议中，HTTP头是通过“\r\n”来分隔的，因此如果服务器端没有过滤“\r\n”,而又把用户输入的数据放在HTTP头中，则有可能导致安全隐患。这种在HTTP头中的CRLF注入，又可以称为“Http Response Splitting”。可以说Http Response Splitting的危害性甚至比XSS还要大，因为它破坏了HTTP协议的完整性。
Cookie是最容易被用户控制的地方，应用经常会将一些用户信息写入Cookie中，从而被用户控制。

对抗CELF的方法很简单，只要处理好 “\r”、“\n”这两个保留字符即可，尤其是那些使用“换行符”作为隔离的应用。
7.5 小结
牢记“数据与代码分离原则”，在“拼凑”发生的地方进行安全检查。