注入解释型语言

攻击数据存储

注入解释性语言

解释性语言（interpreted language）是一种在运行时有一个运行时组件（runtime component）解释语言代码并执行其中包含的指令的语言。与之相对，编译型语言（compiled language）是这样一种语言：它的代码在生成时转换成机器指令，然后在运行时直接由使用该语言的计算机处理器执行这些指令。

从理论上说，任何语言都可使用编译器或解释器来执行，这种区别并不是语言本身的内在特性。但是，大多数语言仅通过上述其中一种方式执行，开发Web应用程序使用的许多核心语言使用解释器执行，包括SQL、LDAP、Perl和PHP。

基于解释型语言的执行方式，产生了一系列叫做代码注入（code injection）的漏洞。任何有实际用途的应用程序都会受到用户提交的数据，对其进行处理并执行相应的操作。因此，由解释器处理的数据实际上是由程序员编写的代码和用户提交的数据共同组成的。有些时候，攻击者可以提交专门设计的输入，通常提交某个在应用程序中使用解释型语言语法的具有特殊意义的句法，向应用程序实施攻击。结果，这个输入的一部分被解释称程序指令执行，好像它们是由最初的程序员编写的代码一样。因此，如果这种攻击取得成功，它将完全攻破目标应用程序的组件。

另一方面，在编译型语言中实施旨在执行任意命令的攻击往往非常困难。这是，注入代码的方法通常并不利用开发目标程序所使用的语言的任何语法特性，注入的有效载荷为机器代码，而不是用哪种语言编写的指令。

避开登录

无论访问操作是由普通用户还是应用程序管理员触发，应用程序访问数据存储区的过程都大致相同。Web应用程序对数据存储区实施自主访问控制，构造查询基于用户的账户和类型来检索、添加或修改数据存储区中的数据。修改查询（不只是查询中的数据）的成功注入攻击可以避开应用程序的自主访问控制并获取未授权访问。

如果需要安全保护的应用程序逻辑有查询结果控制，攻击者就可以通过修改查询来更改应用程序的逻辑。举一个典型的例子-在后端数据存储区的用户表中查询与用户提供的证书匹配的记录。许多实施基于表单的登录功能的应用程序使用数据库来存储用户证书，并执行简单的SQL查询来确认每次登录尝试。以下是一个典型的示例：

SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’

这个查询要求数据库检查用户表中的每一行，提取出每条username列值为marcus、password列值为secret的记录。如果应用程序收到一名用户的资料，登录尝试将取得成功，应用程序将为该用户建立一个通过验证的会话。

在这种情况下，攻击者可以注入用户名或者密码字段，以修改应用程序执行的查询，从而破坏它的逻辑。例如，如果攻击者知道应用程序管理员的用户名为admin，那么他就可以通过提交一下用户名和任意密码，以管理员身份登录：

admin’–

应用程序将执行以下查询：

SELECT * FROM users WHERE username=’admin’–’ AND password = ‘foo’

因为其中使用了注释符号（–），上面的查询等同于：

SELECT * FROM users WHERE username = ‘admin’

于是这个查询完全避开了密码检查。

加入攻击者不知道管理员的用户名，该如何实施攻击呢？在大多数应用程序中，数据库的第一个账户为管理账户，因为这个账户通常手工创建，然后再通过它生成其他应用程序账户。而且，如果查询返回几名用户的资料，许多应用程序只会处理第一名的用户。因此，攻击者可利用这种行为，通过提交一下用户名，以数据库中的第一个用户的身份登录：

‘ OR 1 = 1–

应用程序将执行一下查询：

SELECT * FROM users WHERE username = ‘’ OR 1=1– ‘ AND password = ‘foo’

因为其中使用了注释符号，上面的查询等同于：

SELECT * FROM users WHERE username = ‘’ or 1=1

该查询将返回全部应用程序用户的资料。