最近ハッキングされたクライアントがいて、彼女のサイトにÂやÆのような変な文字が表示されていることに気付きました。データベースのwp_options
テーブルで、ハッカーがblog_charsetをUTF-7に変更したことがわかりました。私はそれをUTF-8に戻しましたが、その間にそれがUTF-7に設定された場合、それがセキュリティ上の脆弱性を引き起こす可能性があるかどうか疑問に思いました。
私は検索したところ、バージョン2.0.6で修正された WordPress UTF-7の脆弱性があることを発見しました 。私たちはWordPressの最新版を実行しているので、彼らはその悪用を利用することができなかったかもしれませんが、UTF-7に関連する他の悪用はありますか?本当に、ハッカーがblog_charsetを変更する理由は他にありますか。私は彼らがどうやって入ったのかを決定しようとしていました、そして、これがどういうわけか関連しているかどうか疑問に思います。
<
と>
は UTF-7 で+ADw-
と+AD4-
としてエンコードされています。今、次のことを想像してみてください。
誰かがコメントテキストとして+ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-
を送ります。それはエスケープされていないすべての衛生設備に合格します。
データベースはすべての受信データをUTF-8として処理します。すべてのUTF-7ストリームも有効なUTF-8であるため、これによってSQLエラーが発生することはなく、mysql_real_escape
またはhtmlspecialchars
には影響しません。
WordPressはヘッダtext/html;charset=utf-7
を送ります。
WordPressはエスケープされたデータを期待してコメントを表示します。しかし、これはブラウザによってUTF-7として扱われるので、JavaScriptが実行されます。
だから、はい、それはセキュリティ上の問題です。
UTF-7は、すべてのブラウザでサポートされているわけではありません。ほとんどの場合、テキストはWindows-1252(またはそのOSのデフォルトのエンコード)またはUTF-8としてレンダリングされます。主な問題は、エスケープがもううまくいかないことです。
エンコード値を元に戻すだけでは解決できません。通常の訪問者はそれを変更することはできませんので、開いているドアを見つけるためにあなたは 持っています 。
また、それが必要になるかもしれません(あなたのテーブルのすべてのエンコーディングを再変換する): https://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-照合-to-UTF-8