この優れた「UTF-8」の質問から、私はこれについて読みました。
残念ながら、送信した文字列を保存したり、どこでも使用したりする前に、送信されたすべての文字列が有効なUTF-8であることを確認する必要があります。PHPのmb_check_encoding（）でうまくいきますが、それを忠実に使用する必要があります。悪意のあるクライアント は必要なエンコーディングでデータを送信できるため、これを回避する方法は実際にはありません。PHPにこれを確実に実行させるためのトリックは見つかりませんでした。
今、私はまだエンコーディングの癖を学んでいます、そして私は悪意のあるクライアントがエンコーディングを悪用するために何ができるかを正確に知りたいです。何を達成できますか？誰かが例をあげることができますか？ユーザー入力をMySQLデータベースに保存する、または電子メールで送信するとします。この機能を使用しない場合、ユーザーはどのように害を及ぼす可能性がありmb_check_encodingますか？
mb_check_encoding機能を使用しない場合、ユーザーはどのように害を及ぼす可能性がありますか？
これは長すぎるエンコーディングについてです。
UTF-8設計の不幸な癖のために、ナイーブなビットパッキングデコーダーで解析された場合、単一のASCII文字を含むより短いバイトシーケンスと同じ文字になるバイトシーケンスを作成することが可能です。
たとえば、文字<は通常バイト0x3Cとして表されますが、長すぎるUTF-8シーケンス0xC0 0xBC（またはさらに冗長な3または4バイトシーケンス）を使用して表すこともできます。
この入力を受け取り、Unicodeを無視するバイトベースのツールで処理すると、そのツールで使用されている文字処理ステップが回避される可能性があります。正規の例は、ネイティブバイト文字列を持つPHPに0x800xBCを送信することです。予想されるバイトシーケンス0x3Cが存在しないため、htmlspecialchars文字をHTMLエンコードするための一般的な使用はここでは失敗します。<したがって、スクリプトの出力には、過度にエンコードされたが含まれ、<その出力を読み取るブラウザは、シーケンス0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 as andheyprestoを読み取る可能性があります<script。XSS。
オーバーロングはずっと前から禁止されており、最近のブラウザでは許可されなくなりました。しかし、これは長い間IEとOperaにとって真の問題であり、すべてのブラウザが将来それを正しく実行するという保証はありません。そしてもちろん、これはほんの一例です。バイト指向のツールがUnicode文字列を処理する場所であれば、同様の問題が発生する可能性があります。したがって、最善のアプローチは、最も早い入力フェーズですべてのオーバーロングを削除することです。
これは複雑な攻撃のようです。ドキュメントをチェックするmb_check_encodingと、「無効なエンコーディング攻撃」に注意が向けられます。「無効なエンコーディング攻撃」をグーグルで検索すると、いくつかの興味深い結果が得られます。これについて説明します。
この種のデータがサーバーに送信されると、送信される文字を解釈するために何らかのデコードが実行されます。これで、サーバーはいくつかのセキュリティチェックを実行して、潜在的に有害である可能性のあるいくつかの特殊文字のエンコードされたバージョンを探します。
無効なエンコーディングがサーバーに送信された場合でも、サーバーはデコードアルゴリズムを実行し、無効なエンコーディングを評価します。これは、セキュリティチェックが、デコードアルゴリズムを実行したときに有害な文字を生成する可能性のある無効なバリアントを検索しない可能性があるため、問題が発生する場所です。
UNIXシステムで完全なディレクトリリストを要求する攻撃の例：
http://host/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al|
アルゴリズムで何が起こっているかについてのより詳細な技術的説明が必要な場合は、いくつかのリンクがあります。
http://www.cgisecurity.com/owasp/html/ch11s03.html#id2862815