yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
(Last Updated On: 2016年3月3日)最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考：セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQL、MySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト～6バイト必要なのか
まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
問題：間違った自動ログイン処理
(Last Updated On: 2014年12月5日)問題：以下のコードはセキュリティ上大きな問題となる脆弱な処理が含まれています。セキュリティ上のベストプラクティス、他の自動ログインの実装方法と比較し、以下のコードの脆弱性を詳しく述べよ。 if (serendipity_authenticate_author( $serendipity['POST']['user'], $serendipity['POST']['pass'], false, $use_external)) { if (empty($serendipity['POST']['auto'])) { serendipity_deleteCookie('author_information'); return false; } else { $package = serialize( array('username' =>
yohgaki's blog - PHP_SELFはそのまま出力できない
(Last Updated On: 2018年8月13日)追記：現在のPHPでは$_SERVER[‘PHP_SELF’]はクエリ文字列（?以降のクエリパラメータ）を含みません。しかし、index.php/<script>alert(1)</script>/aaa/bbb とすることは可能です。PHP_SELFと同様の変数は以下です。 $_SERVER[‘PATH_INFO’] $_SERVER[‘PATH_TRANSLATED’] 時々見かけるのでブログでも問題を指摘します。 PHPの$_SERVER配列に入っているPHP_SELF要素はPATHINFOも含めてしまうため、そのまま出力するとXSSに脆弱になる場合があります。 phpinfo()がXSSに脆弱だ、と指摘する人がいるので（元々phpinfo()の出力は管理者・開発者のみ参照できるようにしておくべきですが..)現在のPHPはPH
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
yohgaki's blog - PHPの現行リリースに重大な脆弱性（PHP4.4.0以下、PHP5.0.5以下） - まとめ
(Last Updated On: 2018年8月13日)追記 2007/11/06: 現在のリリース版（4.4.7, 5.2.4）ではこの脆弱性は修正されていす。これより以前のPHPでも修正されていますが、別の脆弱性があるので最新リリース版の使用をお奨めします。 追記：PHP 5.1.1、PHP 5.1.2にはPHP 5.1.0で追加された対策がなぜか削除されています。PHP5でosCommerce等、register_globals=onが必須のアプリケーションやimport_request_variable関数を使用したregister_globals=off対策を行っている古いPHPスクリプトなどを動作させる場合には注意が必要です。register_globals=onが必要なアプリケーションへの対処が参考になります。 よろしければWebサイトセキュリティ対策入門も参考にしていただ
PHPの現行リリースに重大な脆弱性（PHP4.4.0以下、PHP5.0.5以下） – その2
(Last Updated On: 2018年8月13日)追記：まとめ用のエントリも追加しました下記URLもご覧ください。 http://blog.ohgaki.net/index.php/yohgaki/2005/11/09/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_2 まず先のブログエントリで私が誤解していたため解りづらい状態になっていました。register_globals=offであればアドバイザリ（http://www.hardened-php.net/advisory_202005.79.html）の影響は受けません。この場で深くお詫びいたします。 いくつかのパターンが考えられますが今回Hardened-PHPプロジェクトからのアドバイザリで指摘されている問題によって影響を受ける環境は次のようになります。 影響を受ける環境1 regist
PHPに重大な脆弱性（PHP4.4.0以下、PHP5.0.5以下）
(Last Updated On: 2018年8月3日)このページ情報は不正確です。このページを参照された方は まとめ http://blog.ohgaki.net/index.php/yohgaki/2005/11/09/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_2 を参照して頂けるようお願いいたいたします。 PHPの脆弱性リスト PHPに深刻な脆弱性がある事が発表されました。今まで見つかったPHPの脆弱性の中でも「最悪」の脆弱性です。全てのPHPユーザは今すぐ対処を行う必要があります。 http://www.hardened-php.net/advisory_202005.79.html http://www.hardened-php.net/advisory_192005.78.html http://www.hardened-php.net/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
