- 基于签名检测
- 原理:WAF(Web 应用防火墙)包含一个庞大的已知 SQL 注入攻击签名数据库。这些签名是通过对以往 SQL 注入攻击模式的分析总结而来。当请求到达 WAF 时,它会将请求内容(如 URL 参数、POST 数据、HTTP 头信息等)与这些签名进行匹配。
- 举例:像 “’ or ‘1’=’1” 这样的典型 SQL 注入语句就是一个签名。如果用户在登录表单的密码字段输入这个内容,WAF 会检测到这个字符串与 SQL 注入签名匹配,从而拦截这个请求,因为这是一种常见的绕过登录验证的 SQL 注入尝试。
- 详细过程:WAF 会扫描请求中的每个参数值和数据片段。对于 URL 中的查询参数,例如 “https://example.com/product?id=1‘ or ‘1’=’1”,它会提取 “1′ or ‘1’=’1” 这个部分,然后与签名库中的条目进行比较。如果发现匹配,就会触发警报并阻止请求进一步到达后端应用程序。
- 参数化查询验证
- 原理:WAF 可以检查应用程序是否正确使用参数化查询。在安全的编程实践中,参数化查询将用户输入作为参数传递,而不是将其直接嵌入到 SQL 语句中。WAF 会分析应用程序的 SQL 语句构建方式,确定是否遵循了参数化的规则。
- 举例:在一个安全的代码示例中,如使用 Python 的 SQLAlchemy 库,SQL 查询可能是这样构建的:
query = session.query(User).filter(User.username == username_param).filter(User.password == password_param)
,其中username_param
和password_param
是从用户输入中获取的参数,以安全的方式传递到查询中。WAF 会识别这种正确的参数化查询方式,而如果发现 SQL 语句是通过字符串拼接用户输入构建的,如sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"
,就会判定为存在 SQL 注入风险并采取措施。 - 详细过程:WAF 通过检查应用程序与数据库交互的代码(如果能够获取到这部分信息),或者通过分析 SQL 语句的语法结构来确定是否是参数化查询。它会查看查询语句中是否有参数占位符,以及用户输入是否正确地填充到这些占位符中,而不是直接嵌入到 SQL 命令部分。
- 输入数据类型和长度检查
- 原理:正常的用户输入通常有一定的数据类型和长度范围。WAF 会根据应用程序的业务逻辑,对输入数据进行类型和长度验证。对于 SQL 注入,攻击者输入的恶意 SQL 代码可能会超出正常数据的类型和长度范围。
- 举例:如果一个应用程序的用户名字段设计为只接受字母数字字符,且长度不超过 20 个字符。WAF 会检查每个用户名输入是否符合这个要求。如果收到一个长达几百个字符,且包含 SQL 关键字的输入,就会怀疑这是 SQL 注入尝试并进行拦截。
- 详细过程:WAF 首先会获取应用程序对于每个输入字段的数据类型和长度要求的配置信息(可以是手动配置或者通过分析应用程序的元数据得到)。然后,对于每个请求中的输入数据,它会检查其类型(如字符串、数字、日期等)是否符合预期,并且长度是否在规定范围内。如果不符合,就会触发相应的防护机制,如拒绝请求或者对输入进行清理后再放行。
- 语义分析
- 原理:WAF 会对输入数据进行语义分析,理解输入在 SQL 查询语境中的含义。它会识别 SQL 语句的结构,包括关键字(如 SELECT、INSERT、UPDATE 等)、操作符(如 =、<、> 等)、表名和列名等元素。通过这种分析,它可以判断输入是否试图改变 SQL 查询的原意,从而进行 SQL 注入攻击。
- 举例:如果输入数据中包含修改 SQL 查询的关键部分,如改变查询的条件逻辑或者尝试访问未授权的表,WAF 可以通过语义分析识别出来。例如,攻击者试图通过输入 “’; DELETE FROM users;–” 来删除用户表中的数据,WAF 通过语义分析可以识别出 “DELETE FROM users” 这个具有破坏性的 SQL 命令部分,从而拦截该请求。
- 详细过程:WAF 使用语法解析技术来分解输入数据中的 SQL 语句结构。它会构建一个语法树来表示 SQL 语句的各个组成部分,然后分析每个节点的语义。对于复杂的 SQL 注入尝试,如嵌套查询或者多语句攻击,WAF 会遍历整个语法树,检查是否存在恶意的语义结构。同时,它还会结合应用程序的数据库架构信息(如果有),判断输入是否符合应用程序对数据库操作的合法语义范围。