第27回 見過ごされているWebアプリケーションのバリデーションの欠陥 | gihyo.jp
今回解説するWebアプリケーションのバリデーションの欠陥はPHPに限った問題ではありません。多くのプラットフォームのWebアプリケーションで見過ごされているバリデーション仕様の欠陥です。それは文字エンコーディングのチェックです。 文字エンコーディングバリデーションの必要性 筆者の知る限りでは、2004年に相次いで今まで知られていなかったアタックベクタ（攻撃経路）が見つかりました。2004年に多く見つかった新しいアタックベクタとは不正な文字エンコーディングを利用した攻撃です。不正な文字列を利用したJavaScriptインジェクションやSQLインジェクションの攻撃手法が公開されました。 文字エンコーディングを利用した攻撃自体は当時でも新しい攻撃手法ではありませんでした。文字エンコーディングを利用した攻撃は、少なくとも2000年から広く知られていた攻撃手法でした。ブラウザが文字エンコーディングを
PHP で簡単にサーバーを監視して一定ラインを超えたらメール通知するコード
ロードアベレージ通知するだけなら負荷監視ツールを入れるより、PHP なりで書くほうが楽で簡単とのことで友達に教えてもらいましたので、ひとつ書いてみました。以下のコードを loadave.php など適当な名前で保存して cron で定期実行すれば良いです。 <?php mb_language("ja"); mb_internal_encoding("UTF-8"); date_default_timezone_set('Asia/Tokyo'); $servername = 'localhost '; // サーバー名(任意) $mail1 = 'info@example.com'; // 通知先1 $mail2 = 'alert@example.com'; // 通知先2 $notice1 = '3.00'; // 通知ライン1 $notice2 = '5.00'; // 通知ライン2
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字コードに起因する脆弱性とその対策
