徳丸さんのブログに対するコメント
(Last Updated On: 2018年8月4日)最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。 本題のブログはこちらです。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CREATE TABLE form_id (sha1 TEXT PRIMARY KEY, created TEXT NOT NULL) sha1がトークン、createdが生成日時を保持します。 シンプルな構造ですが、これだとトークンは、ユーザーやセッションを超えて、アプリケーション全体
PHPのセッションアダプション脆弱性克服への道のり
(Last Updated On: 2018年8月13日)PHP Advent Calender用のエントリです。 PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。 まずは危険性と対策を紹介します。 セッションアダプションの危険性 セッションアダプションとは外部などから設定されたセッションIDを受け入れ初期化する脆弱性です。一番分かりやすい例はTrans SIDを有効にして http://example.com/index.php?PHPSESSID=1234567890 とアクセ
OSC東京とOSC高知のプレゼン資料の公開
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
PHPのSessionモジュールの脆弱性
(Last Updated On: 2018年8月13日)たまたま目に止まったブログがあるので紹介します。 PHP:session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性 http://www.tokumaru.org/d/20080818.html#p01 [php]session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能 http://www.tokumaru.org/d/20080819.html#p01 この危険性はStrict Sessionパッチが作られた頃にも議論されていました。このパッチを摘要するとセッションアダプション脆弱性も修正します。もし、互換性なので要件で厳格なSession管理ができない場合でもセッションIDに利用可能な文字は安全な文字のみに限定されるのでパストラバーサルなどの
LAMPセキュリティを向上させる方法
(Last Updated On: 2008年3月24日)LAMPはLinux, Apache, MySQLとPHPまたはPerl, Pythonを利用したWebシステムの総称として利用されている用語です。 特にLinux/Apache/MySQL/PHPはよく見かけるシステム構成です。ホスティングサービスを提供する会社でこの構成をサポートしていない会社を探すのが難しいくらいではないかと思います。広く使われていますが、「十分に安全な状態」と言える状況で運用されているケースはほとんどありません。 関連エントリ LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠 誤解を招く記事 – LAMPセキュリティを強化する4つの方法 脆弱性情報を収集する 全てのソフトウェアにセキュリティ上の問題が含まれている、と考えて間違いありません。利用しているソフト
企業ユーザはPHP4からPHP5への移行は慎重にすべき
(Last Updated On: 2018年8月13日)2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。 私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。 しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。 PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP5に移行するとマイナーバージョンアップに追随しないとならない PHP5.3のリリースが準備されている PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP4からPHP5への移行でチェックしなければなら
FreeBSD7はPostgreSQL, MySQLユーザにとって救いになるか?
(Last Updated On: 2018年8月14日)クリックして7.0%20Preview.pdfにアクセス にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。 PostgreSQL 8.2.4 – 11ページ ピーク性能でおよそ3800transactions/secほど。 Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速（数値にして数倍）になったようです。 グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル（16ページ）によると On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よ
Apache httpd脆弱性のリスク評価は不十分
(Last Updated On: 2008年1月24日)先日Apache httpdサーバにセキュリティ脆弱性を修正したリリースが公開されました。 例えばSecuniaのApache httpd 2.2の脆弱性ページをみると先日リリースされた2.2.8で修正された脆弱性のセキュリティリスクは低く評価されています。 http://secunia.com/advisories/28046/ ここにはmod_negotiation脆弱性の記述がありません。mod_negotiationはここに掲載されているmod_proxy_ftp,mod_status,mod_proxy_balancer,mod_imagemapと違い、多くの環境でデフォルトで有効となっていると考えられるモジュールです。 Minded Security Labs: Advisory #MSA01150108 Apache
サーバシグニチャは隠すのが当たり前
(Last Updated On: 2007年9月4日)私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。 最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います？公開または推測できるバージョン情報に決まっています。 フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用／設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。 犯罪者が攻撃に利用している、利用する可能性が
トラックバックスパムの防止方法
(Last Updated On: 2007年3月10日)ボットによるコメントスパム防止はCAPTCHAによって行えますが、同じ事をトラックバックスパムにも利用できます。 通常のトラックバックURLは固定アドレスになっていますが、トラックバック送信の鍵をクエリパラメータに含めます。当然鍵は使い捨てでブルートフォース攻撃ができない、URL取得ページ・鍵にします。鍵付きのトラックバックURLを取得するにはCAPTCHA画像の値を送信ないとURLを取得できないようにすればOKです。 # もちろん使った鍵を削除し、鍵には十分に短い有効期限を設定する それでもSPAMを受け続けるなら鍵付きトラックバックURLをメールアドレスに送信するようにすると良いです。 同じような仕組みのスパム対策はどこかにあるでしょうか?
Category: the Month of PHP Bugs - yohgaki's blog
Link: http://blog.php-security.org/archives/91-MOPB-Exploits-taken-down.htmlドイツで他人のコンピュータを攻撃するソフトウェアの公開などを禁止する法律が施行されたためMOPBの攻撃コードが削除されました。 ダウンロードリンクは在りますがダウンロードしたファイルの中身は以下のようになっています。 Dear Visitor, since Friday 10th, August 2007 a new and very troubling law is enforced in germany. It is no longer legal to create and/or distribute so called hacking tools in germany. This includes port scanners lik
ミイラ取りがミイラに – Zone-H Defaced
(Last Updated On: 2006年12月26日)Zone-Hのページが改ざんされたそうです。詳しくはこのエントリタイトルのリンク先を見て頂くとして In a short recap, our faults were: 1) Having a staff member who was not wise enough to recognize a Hotmail XSS attack. 2) Not finding the uploaded, but useless at that time, php shell. Zone-H contains 80 gigs of files, but this no excuse. 3) Not acknowledging in time the JCE component advisory (and we all make our livi
httpOnlyをFirefoxで
(Last Updated On: 2018年8月13日)PHP 5.2.0のsetcookie/setrawcookie関数からhttpOnly属性をクッキーにつける事ができるようになりました。httpOnly属性はMicrosoftが独自に拡張した仕様で、JavaScriptからクッキーの値を使用できなくする機能です。httpsでのみクッキーを送信するsecure属性に似ています。 Microsoftの独自拡張なのでIEでは利用できましたがFirefoxでは利用できません。しかし、アドオンを使用することでhttpOnly属性をFirefoxでも利用できるようです。 httpOnly by Stefan Esser Adds httpOnly cookie support to Firefox by encrypting cookies marked as httpOnly on the
PEAR DBのPostgreSQLドライバにセキュリティホール
(Last Updated On: 2006年9月12日)この脆弱性は本家にはレポートしてあるのですが簡単な1行パッチなのにまだCVSにさえ適用されていません。詳しく解説したつもりなのですがシングルバイト圏の開発者には理解が難しい(?)か私の説明が悪かった(?)のかも知れません。とりあえず「作業中」との旨のメールが帰って来ていますが遅すぎなので特に影響が大きいと思われる日本のサイト向けとして問題の概要と対処方法を書いておきます。 文字エンコーディングを利用したSQLインジェクションに詳しい方ならどのような条件でSQLインジェクションが可能になるか簡単に分かります。addslashesやstr_replaceによるエスケープが危険であることは広く知られている既知の問題といえると思います。英語で記述されたブログ等にもエンコーディングとエスケープの問題を取り扱ってるページもあります。あまり長期間
リモートファイルの読み込みが可能なPHPアプリ多数
(Last Updated On: 2006年8月24日)PHPには require(‘http://example.com/script.php’); と外部のURLからデータを読み取りローカルのスクリプトとして実行する機能があります。以下のようなスクリプトが致命的であることは以前にも書きました。 require($_REQUEST[‘type’].’.php’); allow_url_fopen設定で読み取りの可否を変更できるようになっているのですが、ストリームのphp://inputは制限できないので、allow_url_fopenの設定に関わらずリモートスクリプトが実行できてしまう仕組みになっています。(「php://inputによりPHPスクリプトインジェクションが可能になる」とした方がより正しいですね） 最近、この不正なリモートスクリプトの読み取り・実行が行える脆弱性を調べてい
まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
クロスドメインのHTML読み取り(IEのバグ CSSXSS）とCSRF
(Last Updated On: 2014年12月5日)追記：このブログを記載する理由となったURLを記載された方が内容を削除されたようです。「間違っている」と言われるのは心外である、と思ったことは確かですがページの内容が削除されるのは私の本意ではありません。書かれていた情報はとても役に立つ情報だと思います。非常に残念なので再度掲載されることを望みます。（本当 —– セキュリティ対策ではよくあることですが、条件の見落としによりセキュリティ対策を行っていても脆弱性が発生することがあります。「Webアプリセキュリティ対策入門」に書かれているCSRF対策にも「クロスドメインのHTML読み取り(IEのバグ）」の問題が修正されていない為、書籍に記載した対策を行ってもバグを持つIEに対してはCSRFに脆弱になります。 しかし、このバグの影響を持って「Webアプリセキュリティ対策入門」のCSRF対策を
htmlspecialchars/htmlentitiesの正しい使い方
(Last Updated On: 2018年8月16日)追記：このエントリは古い情報です。今のHTMLエスケープの情報は以下の新しいエントリを参照してください。 PHPのHTMLエスケープ PHP_SELFはそのまま出力できないに htmspecialchars($str, ENT_QUOTES); じゃなくて、 htmspecialchars($str); で終わらせてしまった場合の、 問題例が非常に欲しいです！！ とコメントを頂きました。 htmlspecialcharsとhtmlenties関数はENT_QUOTESを指定しないとENT_COMPAT（セキュリティ上問題があるが互換性を維持）が指定された状態と同じ動作をします。 ENT_QUOTESは”と’の両方をHTMLエンティティに変換するオプションです。ENT_COMPATは”のみHTMLエンティティに変換します。 JavaS
Wikiを復旧
(Last Updated On: 2018年8月13日)先日、PHPをPHP 5.0.6相当からPHP 5.1.3相当にバージョンアップしたところ一部に動作不良があったのでデバッグしていたコードの消し忘れがありました。コンテンツに”AAAAAAA”と表示して終了している状態になっていました。デバッグ途中で時間が来たのでデバッグコードが残ったものrsyncしたようです。（汗 現在は直っていますが、PHP 5.0.6からPHP 5.1.3相当へのバージョンアップでは思いもよらない部分で問題が発生したりしました。 if (expr) expr; と{}でブロックにしていないと文法的には正しくてもT_ELSEが無いとエラーになったりしていました。エラーが発生する場合と発生しない場合があります。全てのブロック無しif文でエラーが発生する訳ではありません。 コーディングスタイルを if (expr)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
