ruby - Rails 中输入的隐式清理 : Why do these examples from the API work the way they do?

Question

感谢您在我开始学习 Ruby 和 Rails 时的帮助。

在 Rails API 中 ActiveRecord::Base ，有一个关于条件的部分，旨在简单地涵盖与 ActiveRecord 交互的语法。但是他们使用的示例包括一个非常有趣(对我来说)的 Ruby/Rails 输入清理入门:

class User < ActiveRecord::Base
  def self.authenticate_unsafely(user_name, password)
    where("user_name = '#{user_name}' AND password = '#{password}'").first
  end

  def self.authenticate_safely(user_name, password)
    where("user_name = ? AND password = ?", user_name, password).first
  end

  def self.authenticate_safely_simply(user_name, password)
    where(:user_name => user_name, :password => password).first
  end
end

在这个示例代码之后，他们解释说:

"The authenticate_safely and authenticate_safely_simply both will sanitize the user_name and password before inserting them in the query, which will ensure that an attacker can’t escape the query and fake the login (or worse)."

我完全明白这种输入净化在防止注入(inject)攻击方面是一件好事。我不明白的是，如果没有调用特殊方法来预处理输入数据，这种隐式清理是在哪里发生的以及如何发生的。各种示例方法似乎具有几乎相同的语义，但由于它们的解析方式，形式上的差异对安全性有巨大影响。我假设这些形式上的变化类似于在包含转义字符的字符串周围使用单引号和双引号之间的区别实际上。但是任何人都可以帮助我变得更聪明、更快，通过一般术语(或者更确切地说:在逻辑层面，而不是在解释器内部)理解幕后到底发生了什么才能做到这一点？

此外，这些差异在多大程度上取决于特定于 Rails 的结构，而不是底层的 Ruby？

谢谢!

Answer 1

输入清理是 Active Record 提供的一项功能，称为 prepared statements or parameterized statements .

大多数数据库访问库 native 提供此功能，但是，Active Record 选择使用字符串处理机制模拟此功能。请参阅 active_record/relation/query_methods.rb 中的 build_where 并回溯到 sanitize_sql_for_conditions(通过其 sanitize_sql 别名)在 active_record/base.rb 中。 (非常感谢 mu is too short 的研究。)

与在应用程序中将查询字符串构建为字符串 的旧式做法不同，您有一个带有参数的静态模板 查询。当您调用查询时，您提供参数，Active Record 将为 SQL 引擎构建一个安全的查询来执行。

您可以自己完成这项任务——无数 PHP 程序员选择避开他们类似的 PDO database access layer .然而，许多程序员无法正确理解:there are roughly 1500 SQL Injection flaws在过去三年和我的本地发现CVE database自 MITRE 开始跟踪以来，显示了 5000 多个易受 SQL 注入(inject)攻击的程序实例。几乎所有这些都完全归因于选择手动编写自己的 SQL 代码并且没有正确清理输入的人。 (我没有亲自检查每一个，但我不记得在 ORM 或数据库访问层中看到任何允许 SQL 注入(inject)攻击通过的缺陷。但为了保守起见，我选择了“几乎所有”。)

堆友Jeff Atwood equates old-style SQL queries as the goto of database programming :

Non-parameterized SQL is the GoTo statement of database programming. Don't do it, and make sure your coworkers don't either.