sqlmap 時間ベースの注入の分析を実装する方法

1. はじめに

SQL インジェクションを検出するにはどうすればよいですか?

私の答えは次のとおりです。当事者 A がセキュリティを行っている場合、SQL インジェクションの検出は比較的簡単に実行できます。

1) エラー挿入の検出。

2) 誤検知が比較的多いため、ブール値エラー レポートを挿入しないでください。

3) 時間ベースのタイムインジェクションを実行し、運用とメンテナンスに連絡して、スローログデータベースの記録、スリープの監視、ベンチマークキーワードの監視を行います。スリープの小数点にスキャンタスクのID番号を追加できます。時間、位置決めに便利です。 (追記: この方法で SQL インジェクションの 99% を見つけることができます)

したがって、時間ベースのタイム インジェクションを実行するときは、時間エラーを非常に厳しく制限します。ただし、@chengable はパーティ B でセキュリティ関連の作業を行っており、時間ベースの時間注入は通常は不可能です。主に最初にインジェクションポイントの存在をフィルタリングし、その後 sqlmapapi.py を検出していることがわかります。また、以前にテストに sqlmap を使用しました。遭遇した問題は、多くの誤検知と長いスキャン時間でした。その後、sqlmapapi.py を試しました。問題は、スキャン時間が長すぎることと、json 形式のインジェクションをサポートしていないことでした (詳細) 。ただし、sqlmap の時間注入は比較的正確です。sqlmapapi.py を使用したくない場合はどうすればよいでしょうか?ここでは、sqlmap の時間ベースの注入ロジックを削除します。

2. sqlmap の時間ベースのインジェクションの簡単な分析

不満: sqlmap のコードは標準化されておらず、醜く、大きいです。ある人に sqlmap のソースコードを読んで勉強することを勧められたのですが、今思えば早々に諦めていました。

したがって、怠け者でソース コードを見たくない場合は、 --technique=T -v 3 を追加して、最初に sqlmap 検出ペイロードを確認してください。

スクリーンショットからわかるように、私は怠け者でいくつかの方法を見つけたようです:

最初に、sqlmap は sleep の注入ペイロードを詰め込みました:

最初に sleep(5) を詰め込み、実行されたことが判明した後、次に sleep(0) を詰め込み、最後にもう一度スリープ(5)に詰め込みました。

次に、推測します。一般的なチェックの考え方は、最初に sleep(5) を実行し、2 番目の遅延が成功した場合は sleep(0) を実行することです。遅延が見つからない場合は、sleep(5) を続行します。遅延が再び成功すると、注入がある可能性があることを示すリマインダーが表示されます:

最後に、非常に賢いのは、誤検知を防ぐために、sqlmap は if 判定条件を使用して誤検知を除外していることです。上の図から、sqlmap は式が真であるかどうかを 2 回テストし、式が真でなくなるかどうかを 2 回テストしていることがわかります。現在の状況に基づいて誤検知を判断するための 2 番目の遅延まで。

3. ソース コードの詳細な分析

ソース コードに戻って見てみましょう: 前のキーワードのいくつかに基づいて、コードを直接見てみましょう。 。たとえば、検索前に * と思われる #** が表示され、最初のステップのコードが表示されます:

sqlmap/lib/controller/checks.py:

ここで私が見つけたものは、私が以前に推測したものに非常に近いです。

ペイロードの場所、特に if 条件を含むペイロードを探すか、キーワード クエリを使用して、ここで見つけます:

sqlmap/xml/payloads/time_blind.xml:

#各 if 条件のペイロードがベクトル フィールドにあることがわかります。

4. 閉鎖

閉鎖注入点の前の文字が注入可能かどうかの鍵となります。

観察された tools/sqlmap/xml/boundaries.xml なので、ここでさまざまなクロージャーの状況も参照する必要があります:

5.遅延があるかどうかの判定

5.1 方法 1

前回の awvs の注入を参考に、より分かりやすい検出方法を考えました。ペイロードを注入しない通常のテスト 6 回の消費時間を取得し、その平均値をネイティブ リクエスト時間 (ori_time) として計算します。

注入時間が sleep(5) の場合、現在時刻から ori_time を減算して sleep_time とします。 sleep_time が 4 未満の場合、遅延は発生していないとみなされます。 (ここでは、ori_timeがネットワークの影響を受けて大きくなることを考慮して、閾値を4秒に調整しています)

注入時間がsleep(0)の場合、現在時刻からori_timeを減算してsleep_timeとします。 sleep_time が 2 より大きい場合は、遅延に誤ったアラームがあることを意味します。

5.2 方法 2

sqlmap コードをもう一度見てください。理解できない数学的問題が使用されています (詳細)

フォローアップ: リクエスト。 queryPage --->wasLastResponseDelayed ロジックは、ペイロードを挿入せずに 30 個の通常テストの消費時間を取得し、kb.responseTimes に入れるというものであることがわかります。標準偏差を偏差として 30 倍計算し、偏差に基づいて最も遅い応答時間を lowerStdLimit として計算します:

30回の平均にTIME_STDEV_COEFF*標準偏差(偏差)を加えた値で、TIME_STDEV_COEFFは7に設定すると99.9999999997440%の判定精度が得られます。

最終的に現在のリクエストの消費時間が lowerStdLimit より大きいかどうかを判定します。大きい場合は遅延が発生していることを意味し、未満である場合は遅延がないことを意味します (また、 lowerStdLimit は 0.5 秒未満、 lowerStdLimit には 0.5 秒かかります)。

感情は方法 1 を選択するべきだと言い、理性は方法 2 を選択するべきだと言います。私は引き続き方法 2 を選択し、注入点を測定しました (詳細)。非常に安定したスキャンにより、インジェクションの脆弱性が見つかりました。

以上がsqlmap 時間ベースの注入の分析を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。