テーブル構造/データベース構造が不明な場合のSQLインジェクション
mysqlを使用していることを発見した攻撃者は、この情報のみを使用してSQLインジェクション攻撃を行うことができますか？テーブル/データベース名がわからない場合、どうしてそれを見つけることができますか？それは可能ですか？それを避ける方法は？ありがとう
Philippの発言に加えて、SQLインジェクション攻撃はDBの構造を知らずに行われることがよくありますが、脆弱性が公開されると、それを使用して構造を特定できます。
たとえば、かつて教えられた最初のSQLインジェクション文字列の1つは、以前は';shutdown--でした
これは、ユーザーが提供したデータがSQLクエリで引用符で囲まれていることを前提としているため、文字列の最初の引用符で閉じられ、次のセミコロンでステートメントが終了するため、エラーが発生する可能性があります。ただし、次のステートメントは引き続き実行され、shutdownになります。 --は、残りがコメントであることを示します。したがって、入力がサニタイズされていない場合、この文字列はサーバーをすぐにシャットダウンする可能性があります。
SQLサーバーなどの多くのDBシステムで同じ一歩前進して、システムテーブルのリストはよく知られており、クエリを実行していたアカウントが特権を持っていれば、それを使用してユーザー、テーブル、ストアドプロシージャをリストできます。ビュー、およびその他のSQL構成。それがリストされたら、それらをドロップ、エクスポートでき、テーブルまたはビューの構造もリストすることができます。
同様に、クエリは、認証をバイパスするように構成できます。たとえば、' or '1'='1' --などの文字列を使用できます。
上記のような文字列はWHERE句に挿入され、どのユーザー名またはパスワードが提供されても、これは真の評価となり、資格情報を提供せずにユーザーを認証できます。例えば。：
SELECT * FROM USERS WHERE UserName = '' or '1'='1' --
つまり、SQLインジェクション攻撃が成功すると、攻撃者はサーバー上でコードを実行できるようになります。これは、脅威のモデリングに関してサーバー自体に座っている場合と同じと見なす必要があります。
攻撃を回避するために、ほとんどのフレームワークとDBシステムには、パラメーター化されたクエリのメカニズムが用意されています。プラットフォームを確認する必要がありますが、通常、パラメーター化されたクエリが最も安全な方法です。自分でSQLクエリを構築する必要がある場合（たとえば、それを必要とする外部APIに渡す場合）、回避するように努めますが、適切にエンコードすることを検討してください。
場合によります。
- 一部のWebアプリケーションでは、構文的に正しくないSQLステートメントによりエラーメッセージが表示され、訪問者に表示されるHTML出力に転送される場合があります。これにより、攻撃者はクエリがどのように見えるかについていくつかの情報を入手できます。 （「SQLクエリで 'myapp_tbl_users'の近くにエラーがあります。」）これを回避するには、詳細なエラーメッセージを出力しないようにWebサーバーを構成します。
- SQLインジェクション攻撃により、データベースコンテンツがフロントエンドに出力される場合があります。彼らがそのような攻撃を見つけたとき、彼らはそれを使ってどのテーブルがその中に存在するかのように、データベースに関するメタ情報を出力することもできます。
- すべての攻撃者が外部にいると思い込まないでください。安全なシステムは、アプリケーションの動作を知っている内部の攻撃者に対しても安全でなければなりません。
- ソースコードを明らかにするWebアプリケーションに無関係な脆弱性がある可能性があります。これらは通常それほど重要ではありませんが、アプリにSQLインジェクションがある場合、攻撃者がデータベースの構造に関する情報を取得するのに役立つ可能性があります。
- 攻撃者は推測することができます。推測は自動化できます（可能なテーブル名を総当たりするスクリプトを実行します）。
ただし、これらの問題を回避する最善の方法は、最初からSQLインジェクションを回避することです。 SQLデータベースと通信するには、文字列を連結するよりも多くの優れた方法があります。ストアドプロシージャ、準備されたステートメント、またはORMラッパーを使用します。
はい- INFORMATION_SCHEMA を使用してデータベースの構造を見つけることができます。
this one などの多くのオンラインチュートリアルでは、単純なエクスプロイトからすべてのデータの抽出までのプロセスを説明しています。
防御側の観点からは、INFORMATION_SCHEMAテーブルへのアクセスを拒否できます。正当なアプリケーションがこれを使用することはないでしょう。ただし、この場合、Philippが示唆するように、攻撃者はテーブルと列の名前を総当たりにする可能性があります。アクセスを拒否するWebアプリは実際に見たことがありません。そもそもSQLインジェクションを防ぐためにあなたの努力を費やす方が良いです。