Неявная санация входных данных в Rails: почему эти примеры из API работают так, как они работают? - PullRequest
2 голосов
/ 06 марта 2012

Спасибо за вашу помощь, когда я загружаю свой путь в 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

Следуя этому примеру кода, они объясняют, что:

"Оба параметра authenticate_safely и authenticate_safely_simply будут очищать имя пользователя и пароль перед вставкой их в запрос, что гарантирует, что злоумышленник не сможет выйти из запроса и подделать логин (или, что еще хуже)."

Я полностью понимаю, что эта дезинфекция входных данных является хорошей вещью для предотвращения инъекционных атак.Что я не понимаю, так это где и как происходит эта неявная дезинфекция, учитывая, что нет специальных методов, вызываемых для предварительной обработки входных данных.Различные примеры методов, по-видимому, имеют почти идентичную семантику, и все же различия в форме оказывают огромное влияние на безопасность из-за способа их анализа.Я предполагаю, что эти изменения в форме похожи в действительности на разницу между использованием одинарных и двойных кавычек вокруг строки, содержащей escape-символы.Но может ли кто-нибудь помочь мне стать умнее, быстрее, понимая в общих чертах (или скорее: на логическом уровне, а не внутри интерпретатора), что на самом деле происходит под капотом, чтобы сделать это так?

Кроме того, в какой степени эти различия зависят от конструкций, специфичных для Rails, а не от лежащего в основе Ruby?

Спасибо!

1 Ответ

3 голосов
/ 06 марта 2012

Очистка ввода - это функция, предоставляемая Active Record, известная как подготовленные операторы или параметризованные операторы .

Большинство библиотек доступа к базам данных предоставляют это изначально, однако Active Record выбирает эмулировать эту функцию с использованием механизмов манипулирования строками. См. build_where в active_record/relation/query_methods.rb и вернитесь к sanitize_sql_for_conditions (через псевдоним sanitize_sql) в active_record/base.rb. (Большое спасибо мю слишком мало для исследования.)

Вместо старой практики построения строк запроса в виде строк в приложении у вас есть статический шаблон запрос с параметрами. Когда вы вызываете запрос, вы предоставляете параметры, и Active Record создаст безопасный запрос для выполнения механизмом SQL.

Вы могли бы выполнить эту задачу самостоятельно - множество PHP-программистов решили отказаться от своего аналогичного уровня доступа к базе данных PDO . Однако многие программисты не могут понять это правильно: существует примерно 1500 недостатков SQL-инъекций , обнаруженных за последние три года, и моя локальная CVE-база данных показывает более 5000 экземпляров программ, уязвимых для атак SQL-инъекций. с тех пор как MITER начал отслеживать. Почти все это было полностью связано с людьми, которые решили писать свой собственный код SQL вручную и не должным образом дезинфицировали свой ввод. (Я лично не проверял каждый из них, но не могу вспомнить каких-либо недостатков в ORM или слоях доступа к базам данных, позволяющих проходить через SQL-инъекции. Но чтобы быть консервативным, я выбрал «Почти все».)

Fellow stacker Джефф Этвуд приравнивает SQL-запросы старого стиля как goto программирования баз данных :

Непараметрический SQL - это оператор GoTo программирования баз данных. Не делайте этого, и убедитесь, что ваши коллеги этого не делают.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...