注入攻击
OWASP将注入攻击和跨站脚本攻击(XSS)列入网络应用程序十大常见安全风险。实际上,它们会一起出现,因为 XSS 攻击依赖于注入攻击的成功。虽然这是最明显的组合关系,但是注入攻击带来的不仅仅是 XSS。
注入攻击代指一类攻击,它们通过注入数据到一个网络应用程序以期获得执行,亦或是通过非预期的一个方式来执行恶意数据。这种类别的攻击包括跨站脚本攻击(XSS)、SQL 注入攻击、头部注入攻击、日志注入攻击和全路径暴露。当然限于篇幅,这里只是一个简单的介绍。
这类攻击是每个程序员的梦魇。它们数量庞大、攻击范围广,并且有时候防御措施很复杂,因此是最常见、成功率最高的网络攻击。所有的应用程序都需要从某个地方获取数据来运行。跨站脚本攻击和界面伪装漏洞最为常见,并且它们本身就已经非常重要,通常与注入攻击分开归类。接下来的一章我将单独介绍它们。
OWASP 对注入攻击的定义如下:
类似SQL、OS、LDAP注入攻击等注入攻击会在不可信数据作为命令或请求的一部分被发送到解释程序时发生。攻击者的恶意数据会迷惑解释程序去执行非计划的命令,或访问非授权的数据。
SQL 注入攻击
目前最常见的注入攻击形式是臭名昭著的 SQL 注入攻击。SQL 注入攻击不仅常见,而且致命。我要特别强调,了解这种攻击、实现攻击的条件以及防御攻击需要采取的措施极为重要。
SQL 注入攻击通过将数据注入网络应用程序,然后被用于 SQL 请求来操作。数据通常来自类似网页表单的不可信来源。不过,数据也可能来自包括数据库本身在内的其他来源。程序员通常会信任来自自己数据库的数据,以为它们是非常安全的,却没有意识到,在一种用法中安全,不代表它在所有其他用法中都是安全的。来自数据库在经过证明(比如说,通过验证流程)之前,应该被视为不可信。
如果攻击成功,SQL 注入攻击能够操纵受攻击的 SQL 请求,从而进行非程序员意愿的数据库操作。
看一下这条请求:
git·$db = new mysqli('localhost', 'username', 'password', 'storedb'); $result = $db->query( 'SELECT * FROM transactions WHERE user_id = ' . $_POST['user_id'] ); ·git
上面的请求中存在多处问题。首先,我们还没有验证 POST 数据来确保这是个有效的 user_id。其次,我们允许一个不可信来源告诉我们要使用哪个 user_id——攻击者可以任意设置一个有效 user_id。也许 user_id 包含在一个隐藏的表单字段,因为网络表单不允许编辑,我们就以为安全了(却不知道攻击者可以提交任何信息)。第三,我们并没有 escape 该 user_id,或将其作为一个绑定参数传给请求,由于我们一开始没有验证 SQL 请求,这就让攻击者有机会注入任意字符串来操纵该请求。
上述三点问题在网络应用程序中极其常