AnonymousはどのようにUTF-16を使用したかASCII to fool PHP escaping？
数か月前、アノニマスはSQLインジェクションを使用して児童ポルノサイトを削除しました。私は この記事 を読みましたが、Anonymousは「サーバーは強化されたPHPエスケープで使用している）」と主張しましたが、「UTF-16でそれをバイパスすることができました= ASCII encoding。 "正確にはどういう意味ですか？同様の攻撃からサイトを保護するにはどうすればよいですか？
まず第一に、「UTF-16 ASCII encoding」は、UTF-16とASCIIが相互に排他的なエンコーディング方式であるため、矛盾しています。しかし、おそらく彼は単にUnicodeを使用してフィルタリングメカニズムをバイパスする方法。
一般的な原則は次のとおりです。ASCII-"A"は65番、 "z"は122番にエンコードされた文字をよく考えます。しかし、それだけが文字エンコード方式ではありません。世界では英語のアルファベットだけでなく、それよりもはるかに多くの文字を表す必要があるため、シンハラ語からクリンゴン語まで、あらゆる言語のほとんどすべての文字を表現できるUnicodeが使用されています。
それらすべての文字（約110万個、すべてが使用されているわけではありません）を数値形式で表すことは、実際の課題です。 32ビットを使用することもできますが、4バイトのうち3バイトは通常ゼロであるため、スペースの無駄になります。可変長を使用することもできますが、その場合、一定時間の部分文字列操作は実行できません。そのため、UTF-16（おそらく、16ビット文字を使用していると推測される）の標準がいくつか存在します。
基礎となるフレームワークがそれらをサポートすることが多いとしても、すべてのプログラマーが複数の文字セットを処理するという考えに慣れているわけではありません。そのため、文字が通常はUTF-8またはASCIIで表されるという仮定を使用して、フィルタリングルールまたは予防措置が確立されることがあります。
したがって、フィルタは、たとえば\"などの特定の文字列を検索します。これは、ASCIIおよびUTF-8では、パターン{92,34}に対応します。しかし、UTF-16では見た目は異なりますが、実際には{0,92,0,34}です。これは、予期していなかったフィルターによってスリップするほど十分に異なるものです。
また、フィルターはUTF-16を認識しませんが、基盤となるフレームワークは認識します。そのため、コンテンツは他とまったく同じように正規化および解釈され、クエリはフィルタリングされずに続行できます。
追加して編集：
PHPは文字エンコーディングの処理が非常に悪いことに注意してください。どちらかといえば、それは問題を過小評価しています。PHPデフォルトでは、すべての文字列をASCII、つまりstrstrやpreg_replaceなどの内部関数を意味するのは、すべての文字列がASCIIエンコードされていると単純に想定しているためです。それが危険なほど不適切に聞こえる場合は、それが原因です。ただし、その防衛のために、PHPはUTF-16よりも1年ほど前から存在しており、これはすべてPHPバージョン6。
それまでの間、 mbstring ライブラリはこの欠陥に対処するために作成されましたが、広く配備されておらず、理解もされていません。この拡張機能を利用できる幸運な場合は、php.iniファイルで mbstring.overload を使用して、内部の文字列処理関数をマルチバイト対応の代替機能に強制的に置き換えることができます。これは、php_admin_valueファイルの.htaccessディレクティブを使用してアクティブにすることもできます。
別の便利な関数は mb_internal_encoding であり、これはPHPによって内部的に使用されるエンコーディングを設定して文字列を表します。Unicode互換の内部エンコーディングを使用することで、多少の不快感を軽減できます。私が読んだ少なくとも1つの参照（しかし、残念ながら現在は見つかりません）は、内部エンコーディングをUTF-8に設定することで、それらを単一のエンコーディングに正規化する受信文字列で追加の処理を有効にすることを示唆しています。参照は、PHPがこの点で可能な限り愚かに動作し、エンコーディングに関係なくデータを変更せずに単純に丸呑みし、余波に対処できるようにすることを示唆しています。前者はより理にかなっていますが、私はPHPについて知っていますが、後者も同様に可能性が高いと思います。
最後の選択肢として;私はこれを冗談で部分的にのみ述べていますが、PHPを使用せずに、より優れた設計のアーキテクチャを採用することです。このような人気のあるフレームワークを考え出すことは困難です。 PHPあります。言語、実装、開発チーム、プラグインアーキテクチャ、セキュリティモデル-本当に残念ですPHPそのまま展開されますが、もちろんこれは単なる意見です。
これがアノニマスが使用した方法であるかどうかはわかりませんが、 http://bugs.mysql.com/bug.php?id=2224 を参照してください
Connector.Net（MySQLのマネージド.Netドライバー）にバグがあったようです。リンクされたバグレポートから：
.net文字列はUTF-16でエンコードされています。文字列はWindows-1252（SBCSエンコーディング）に変換され、ネットワーク経由で送信されます。この変換中に、チェックされていない可能性のあるUnicode文字は一重引用符になります。
バグレポートには、問題のUnicode文字を含む文字列がリストされ、次のように述べられています。
具体的には、2番目の文字列では、問題の引用符はUnicode文字8242（ "\ u8242"）です。この文字列がサーバーによって受信されると、引用符は単一引用符（ASCII 96）になり、クエリを中断し、SQLインジェクション攻撃として使用される可能性があります。
リンクされたバグは2009年に修正されたバグの複製としてマークされましたが、悪用されたサーバーがこの問題が発生した古いバージョンのMySqlを実行していた可能性があります。
この記事では、サイトが適切なSQL入力のフィルタリング/エスケープではなく、「強化」手法に依存しているという結論に達しました。児童ポルノサイトのSQLコードに欠陥がなかったという証拠はありません。
いわゆる強化されたPHPフィルターをバイパスすることは、多くの場合非常に簡単です。たとえば、ModSecurityは非常に簡単にバイパスされ、そのような入力フィルターを回避するために攻撃者によって常に使用される多くのメソッドがあります。
悪意のある入力をチェックする前に入力を正しくURLデコードしないプラグインとしてWebサイトのコードに含まれているフィルターもあります。
例えば： %5e
に見られるように：
id=0%5E(select%20position(0x61%20in%20(select%20id%20from%20users%20where%20num=1))=1)
「％bf％5c％27」、「％bf％27」、「％ef％bb％bf」、「％8c％5c」などのこれらのキャラクターで遊ぶことで、いわゆるハードニングをバイパスして、注入。
さらに悪いことに、ホワイトリストフィルターは、次のようなホワイトリストで許可されている文字で$ _GETを再帰的に更新します。
$cleansed = preg_replace( "/[^\s{}a-z0-9_\.\-]/i", "", urldecode( $get ) );
次に、これを検討します。id= -1％20ui * o + s | e | l | e | c | t + 1、^ 2、* 3、[4、[5、] 6、] 7、<8、<9 、> 10>
フィルタリング前のurldecodingのアイデアは良い考えですが、ブラックリストに載っている文字が取り除かれ、そのままの形で注入ベクトルが配信されるという点ではまったく意味がありません。
実際、この方法は、攻撃者がいわゆるPHP=硬化剤やmodsecurityのようなフィルタリングmodsのようなもの）をバイパスする能力を高めることができます。
最後に、リクエストは特定の方法で作成され、入力フィルタリングをバイパスします。これらの防御がバイパスされると、実際のサイトコード自体に、最初に障害のあるDB入力コーディングがなければならず、インジェクションベクトルは、攻撃者の主張、この場合は匿名。
単なるワイルドな推測です。これらはASCII文字列をUTF-16でエンコードできます。このようにして、危険なユーザー入力のチェックに使用された可能性のあるルーチンがだまされたり、バイパスされたりします。その後、文字列が解釈され、悪意のある入力は行われませんでした。フィルタリングされます。
これは、開発者が安全でないコーディング手法を使用しているか、一部のライブラリ/アプリケーションが古く、したがって危険であるように聞こえます。それは匿名のハッカー/スクリプトがバイパスの魔法を持っているようなものではなく、すべて実験に関するものです。
ほとんどの場合、ゼロデイやすべてをハッキングする新しい手法があれば、人々にそれを知らせません。彼らはしばしば、一部のプログラマー/管理者の能力不足のために機能し続ける古い学校のテクニックを使用しています。セキュリティは重要です。