シーケンシャルフォームのSQLMap
POSTを介して投稿される特定のフォームがあります。フォームにはいくつかのフォーム要素があります。このフォームのアプリケーションでペネトレーションテストを行っています。フォームの値は特定のデータベースに保存されています。これはPHPアプリケーションであり、そのフォームを所有する開発者との話し合いを通じて学んだ興味深い部分は、プリペアドステートメントがPOSTデータを処理するためのそれぞれのクエリの処理に使用されていないことです。フォームを介して。
これにより、潜在的なSQLiを見つけることに疑いと希望を抱きました。
有効なセッションと他のフォームデータを含むSQLmapを実行しています。ただし、-v 5を使用すると、SQLMapが実際にはすべてのリクエストに対して302リダイレクト応答を取得していることに気付きました。さらに調査したところ、問題のフォーム（たとえばform3）は、シーケンスに従った後に取得されることがわかりました。
form1-> form2-> form3。
Form3に直接アクセスしようとすると（もちろん、ブラウザからでも、ログイン後に）、form1にリダイレクトされます。したがって、処理するform3データを実際に送信できるようにするには、上記のシーケンスに厳密に従う必要があります。
SQLmapでこのシーケンスを自動化する方法はありますか？または、上記のシナリオでform3にSQLiが存在するかどうかをテストする方法はありますか？
一般に、SQLiを見つけた場合、脆弱性を証明するためにデータベース全体をマップする必要はありません。実際、証明として必要な情報はごくわずかです。 SQLmapは、データベースをマッピングするための優れたツールですが、使いやすさにいくつかの制限があります。
一般に、Webアプリケーションスキャナーを使用してSQLiベクトル（OWASP ZAPプロキシスキャナーなど）を探すことをお勧めします。ただし、この場合、スキャナーでさえ、ターゲットフォームが送信される前に一連の有効な要求を常に実行するように構成するのが難しい場合があります。スキャナーには、既製のSQLiペイロードと応答分析技術の大規模なセットがあり、これは間違いなく使用する必要のあるリソースです。
すべてが失敗した場合は、単純なスクリプトと SQLi文字列のリスト を使用してジョブを実行できます。有効な静的入力で送信される以前の2つのフォームの自動化は、ほとんどの言語で簡単に実行できます。特に、応答の一部が必要ない場合はそうです。この後、パラメーターを挿入して3番目のフォームを送信できます。これで、興味深い応答が得られるまで、すべてのペイロードに対してこのプロセスを繰り返すことができます。少し変わったものは興味深い反応です。
多くの場合、エラーメッセージ、わずかに異なる応答、またはクエリ期間の違いで、 ブラインドSQLi 攻撃を開始するのに十分です。これは、脆弱性が存在することを示すために必要なすべての証拠が、クエリプロセスに関する情報を開示する方法で応答する一連の（この場合は）3つの要求であることを意味します。この1つの概念実証の一連の要求を考えると、攻撃者はデータベース全体をゆっくりと抽出するスクリプトを簡単に作成できます。テスターは実際にこれを行う必要はありません。
経験豊富なプログラマーであれば、 SQLmapプロジェクト の一部であるライブラリを活用できます。