quote（）に対するSQLインジェクション？

Question

注：これは、仮想マシン内に作成されたサイトを持つプロジェクトです。それは私が取り組んでいる上級カレッジプロジェクトです。実際の現実のウェブサイトを悪用しようとはしていません。これは、たとえ与えられた機能であっても、そのような悪用がどれほど強力であるかを理解する教育的な目的のためです。ウェブサイトの脆弱性を悪用する必要

私は現在、（VMの内部で、安全で制御された環境の下で）プロジェクトに取り組んでいます。 1つはSQL文を利用することです。目標は、ユーザー名と間違ったパスワードを入力してもログインできることです。私はこのような運がないまま数時間だけ作業しています。私はかなりの研究をしました利用可能な脆弱性を確認することができます。

人は自分のユーザー名とパスワードを（この場合には、それは何もすることができます）送信すると、関数は、次の準備SQL文で実行されます。

$quotedがある

$query = "SELECT Salt FROM Accounts WHERE Username = '$quoted'"; 

：

$quoted = $this->db->quote($user); 

これは基本的に提供されるすべての一重引用符に対して追加の一重引用符を追加します。もともと\' OR 1=1 --さ$user変数で

SELECT Salt FROM Accounts WHERE Username = '\'' OR 1=1 -- ' 

：（など' OR 1=1'、などなど）、他の可能性を試しにもかかわらず、私が作ってみた最も近いものはこれです。最初と最後の引用符は、エスケープされた一重引用符の後に追加の引用符とともにquote（）関数によって自動的に追加されます。しかしこれは適切なSQL構文とは思われません。これはおそらくユーザー名として$userの入力全体を解釈しているためです。

この後に別の準備文がありますが、それはsaltで連結されたパスワードのmd5ハッシュに依存しています。そして、実際にmd5に一度注射できるようにする方法はないと思いますハッシュを返します。好奇心の声明は次のとおりです。

$query = "SELECT * FROM Accounts WHERE Username = '$user' AND Password = '$hash'; 

$hash = md5($pass.$salt)となります。

誰でも可能性を見極めたいですか？たぶん私はそれを見落としているかもしれませんが、私はすべてを試したような気がします。

EDIT：私はこれを解決しました。それは、注射を利用するために別の機能を働かせることと関連していました。最終的には、注射コード（2次注入）のユーザー名が追加され、ログインが行われました。ログインプロシージャは最初のクエリのユーザ名を引用しましたが、2番目のクエリはユーザ名を引用しませんでした。したがって、ユーザーは自動的にログインします。SQLで

Answer 1

バックスラッシュは、使用中のDBMSにかなり依存して、腹を立て対象となっています。

標準SQLは意味を持たないものとみなされます。文字列内の引用符をエスケープするには、引用符を二重にします。

• 入力：\' OR 1=1 --
• 出力：'\'' OR 1=1 --'

一部のDBMSが実際にバックスラッシュのための意味を定義することができ、使用しているquote方法は、その原則に従っているようです。しかし、さらに複雑にするためには、通常は不確定な数の中間言語（PHP、ODBCなど）があり、これらも文字列を変更する可能性があり、純粋なSQLでは意味のないバックスラッシュにも意味が適用される可能性があります。

X' OR 1=1 --（バックスラッシュの代わりにXを使用）を入力した場合、バックスラッシュをXに置き換えて同じマッピング文字列を取得します。攻撃が成功するには、quote()メソッドが必要です。 DBMSがバックスラッシュで何をするのか混乱するかもしれませんが、それはquote()メソッドのバグに相当します。

Unicodeエスケープシーケンスを埋め込むことができた場合、より多くの牽引力を得ることができます。たとえば、U + 0027（小数点第39位）は一重引用符です。この種の細かいことは、あなたにquote()を渡すかもしれませんが、おそらくそうではありません。 quote()のような方法の背後にあるアイデアは、予想されたもの以外の何かを意味するテキストを振ってはいけないということです。文字のための最小限のUTF-8エンコーディングは、サーバーのバグのために問題を引き起こす可能性がありますが、そのすべてではありません。 Unicode標準では、無効なUTF-8エンコーディングを受け入れるべきではないことが明らかになっています。—セキュリティ情報の近くにはどこでも真実です。

引用符で囲まれたハッシュの出力は、特に攻撃者が決してその塩を見ない場合には、有効に注入できないということは間違いありません。