HPF手法を使用したWAFSQL回避
私はWAF回避テクニックに関する記事を読んでいました http://www.slideshare.net/devteev/methods-to-bypass-a-web-application-firewall-eng 。この記事では、2つの手法について説明しています
- HPP（HTTPパラメーター汚染）
- HPF（HTTPパラメーターの断片化）
HPPは理解しやすかったのですが、HPFと、HPFとSQLインジェクションの断片化の違いとその仕組みについて混乱しています。
それは このブログ投稿 それがどのように機能するかでかなりよく説明されています。本質的に、このようなURLクエリを作成して、後続のSQLクエリの個々の部分をより多くのクエリパラメータに分割できる場合（したがって、名前のfragmentation部分）、 WAF（Web Application Firewall） 要求をドロップすることになっていること、またはそのような試行が検出されたときに実行するように設定されていることを判別する際に問題が発生する可能性があります。
これを悪用する1つの方法は、1つの入力パラメーターの最後にbegin comment/*を追加し、end comment次のものの始めに*/。 WAFは、全体像（すべての入力パラメーターの積として出力されるSQL構文）を考慮していない場合、2つのパラメーターを許容可能と見なします。
これにより、2つの入力パラメーター間のSQLコードの一部が、RDBMSのSQLエンジンによって無視される可能性があります。無視された（コメントアウトされた）部分がSQLクエリ結果のフィルタリングである場合（たとえば、... WHERE user=$param1 and start_date>=$param2...は... WHERE user=$param1/* and start_date>=*/$param2...になり、WAFが許容できると見なす可能性のある$ param1値を悪用するベクトルを提供します。また、$ param2値が使用されるまで他のフィルターを無視します）、そのようなエクスプロイトの最終製品は、開発者が開示することを意図していなかった情報を開示する可能性があります。
HPP攻撃 一方、単一のパラメーター名が何度も繰り返される場合、WAFによる入力パラメーターの解釈と要求処理Webアプリケーションの違いを利用しようとしています。たとえば、このURLクエリが?q=acceptable+request&q=not+acceptable+requestの両方によって解析および分析されると考えてみましょう。 WAFは、最初の入力パラメーターを分析して次のパラメーターを無視するパラメーターと見なす場合がありますが、Webアプリケーションは正反対のことを行う場合があります。
例としてURLのみを使用していることに注意してください。入力パラメーターは、HTTP要求ヘッダーの他の部分（Cookie、POST）で要求できます。またはGETリクエストフィールド、...）、後でWebアプリケーションによって解析される場所によって異なります。