SQL を別の言語と組み合わせて使用する場合、どのデータをエスケープする必要がありますか? ここで質問を読んだところですが、ユーザーからのデータのみをエスケープする必要があることを理解していました。
また、すべての SQL ステートメントをエスケープする必要がありますか? 例: INSERT、UPDATE、SELECT
SQL を別の言語と組み合わせて使用する場合、どのデータをエスケープする必要がありますか? ここで質問を読んだところですが、ユーザーからのデータのみをエスケープする必要があることを理解していました。
また、すべての SQL ステートメントをエスケープする必要がありますか? 例: INSERT、UPDATE、SELECT
ほとんどのプログラミング言語は、データベースに統一された方法で接続するためのコードを提供します(たとえば、JavaのJDBCやPerlのDBI )。これらは、プリペアドステートメントを使用して必要なエスケープを実行するための自動技術を提供します。
SQLのすべてのタイプのクエリは、適切にエスケープする必要があります。「ユーザー」データだけではありません。注意しないと、自分自身に注射することは完全に可能です。
たとえば、擬似コードで:
$name = sql_get_query("SELECT lastname FROM sometable");
sql_query("INSERT INTO othertable (badguy) VALUES ('$name')");
そのデータは「ユーザー」に触れたことはなく、ユーザーによって送信されたこともありませんが、依然として脆弱性があります - ユーザーの姓がO'Brien
.
すべての SQL クエリは適切にサニタイズする必要があり、それにはさまざまな方法があります。ユーザーが SQL インジェクションを使用してコードを悪用しようとするのを防ぐ必要があります。インジェクションは、ユーザー入力、サーバー変数、Cookie の変更など、さまざまな方法で行うことができます。
次のようなクエリがあるとします。
"SELECT * FROM tablename WHERE username= <user input> "
ユーザー入力がエスケープされていない場合、ユーザーは次のようなことができます
' or '1'='1
この入力でクエリを実行すると、実際には常に true になり、機密データが攻撃者に公開される可能性があります。しかし、インジェクションを使用できるもっと悪いシナリオは他にもたくさんあります。
OWASP SQL インジェクション ガイドを参照してください。それらは、それらの状況を防ぐ方法とそれに対処するさまざまな方法の優れた概要を持っています.
また、「ユーザーデータ」が何であるか、または実際に由来するものであると考えることに大きく依存すると思います。個人的には、ユーザー データはパブリック ドメインで利用可能なデータであると考えています (これが悪用のみによるものであっても)。
Marc B は、特定の状況では自分のデータを汚す可能性があることを強調しています。そのため、SQL データに関しては、後悔するよりも常に安全である方がよいと思います。
直接のユーザー入力 (つまり、Web フォームなどから) に関しては、データが SQL クエリに近づく前に、追加のレイヤー サーバー側の検証が常に必要であることに注意してください。