2

Ruby と Rails に足を踏み入れたので、助けてくれてありがとう。

ActiveRecord::Baseの Rails API には、 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 は両方とも、クエリに挿入する前に user_name とパスワードをサニタイズします。これにより、攻撃者がクエリを回避してログインを偽造 (またはさらに悪いこと) できないようになります。」

インジェクション攻撃を防ぐ上で、この入力のサニタイズがいかに良いことか、私は完全に理解しています。私が理解していないのは、入力データを前処理するために呼び出される特別なメソッドがないことを考えると、この暗黙的なサニタイズがどこでどのように行われているかです。さまざまなメソッドの例は、ほぼ同じセマンティクスを持っているように見えますが、形式の違いは、解析方法が原因で安全性に大きな影響を与えます。これらの形式のバリエーションは、エスケープ文字を含む文字列を一重引用符と二重引用符で囲むことの違いと実質的に似ていると思います。しかし、これを実現するために内部で実際に何が起こっているのかを一般的な用語で (または、インタープリター内ではなく論理レベルで) 理解することで、より賢く、より速くなるのを手伝ってくれる人はいますか?

また、これらの違いは、基盤となる Ruby ではなく、Rails 固有の構造にどの程度依存しているのでしょうか?

ありがとうございました！

4

1 に答える 1

3

入力サニタイズは、準備済みステートメントまたはパラメーター化ステートメントとして知られる Active Record によって提供される機能です。

ほとんどのデータベース アクセス ライブラリはこれをネイティブに提供しますが、Active Record は 文字列マングリング メカニズムを使用してこの機能をエミュレートすることを選択します。build_whereinを参照して、(そのエイリアスを介して) inactive_record/relation/query_methods.rbに戻ります。（ミューは研究には短すぎることに感謝します。）sanitize_sql_for_conditionssanitize_sqlactive_record/base.rb

アプリケーションでクエリ文字列を文字列として作成するという古いスタイルの方法の代わりに、パラメーターを使用した静的テンプレートクエリを使用します。クエリを呼び出すときにパラメータを指定すると、Active Record は SQL エンジンが実行できる安全なクエリを作成します。

このタスクは自分で行うことができます。無数の PHP プログラマーは、同様のPDO データベース アクセス レイヤーを避けることを選択しています。しかし、多くのプログラマーはこれを正確に把握できていません。過去 3 年間で約 1500 の SQL インジェクションの欠陥が発見されており、私のローカルCVE データベースには、MITRE が追跡を開始して以来、SQL インジェクション攻撃に対して脆弱なプログラムのインスタンスが 5000 を超えていることが示されています。これらのほとんどすべては、手動で独自の SQL コードを書くことを選択し、入力を適切にサニタイズしなかった人々によるものです。(私はそれぞれを個別に調べたわけではありませんが、SQL インジェクション攻撃を可能にする ORM やデータベース アクセス レイヤーに欠陥があったことを思い出すことはできません。しかし、保守的な側に立つために、「ほぼすべて」を選択しました。)

仲間のスタッカーJeff Atwood は、古いスタイルの SQL クエリgotoをデータベース プログラミングの 1 つと見なしています。

パラメーター化されていない SQL は、データベース プログラミングの GoTo ステートメントです。それをしないでください、そしてあなたの同僚もそうしないようにしてください.

于 2012-03-06T01:57:07.207 に答える