セキュリティ情報:PHP5.4.8、PHP5.3.18以前にhashdos脆弱性
チェック用スクリプト hashdosの状態を確認するためのスクリプトを作成してみましたので、Webサイトのチェックにご活用下さい。 このスクリプトを任意のファイル名（PHPスクリプトとして実行できる拡張子）でチェック対象Webサーバーに保存して下さい。Webブラウザを用いて、このスクリプトを実行すると、結果が表示されます。JavaScriptを有効にして下さい。チェック終了後はスクリプトを削除して下さい。 <?php if (@$_GET['mode'] === 'check') { header('Content-Type: text/plain'); echo (int)count($_POST); exit; } $max_input_vars = ini_get('max_input_vars'); $postnumber = (int)$max_input_vars + 10;
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
2. 本日お話しする内容 • 鉄則1: PHP自体の脆弱性対処をしよう • 鉄則2: Ajaxの脆弱性対処をしよう • 鉄則3: 競合条件の脆弱性対処をしよう • 鉄則4: htmlspecialcharsの使い方2012 • 鉄則5: escapashellcmdは使わないこと • 鉄則6: SQLインジェクションの対処 • 鉄則7: クロスサイト･スクリプティングの対処 • 鉄則8: クロスサイト・リクエスト・フォージェリの対処 • 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも • 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
PHPの脆弱性を突く攻撃が横行、アップデートの早期適用を
PHPの更新版となるPHP 5.4.3／5.3.13では2件の脆弱性が修正された。このうちこのうちの1件では既に攻撃の発生が伝えられている。 オープンソースの開発言語PHPの更新版となるPHP 5.4.3／5.3.13が5月8日付でリリースされた。同リリースでは2件の深刻な脆弱性に対処している。このうちの1件は既に攻撃の発生が伝えられていることから、セキュリティ企業などがパッチの適用を急ぐよう呼び掛けている。 8日のリリースではPHPをCGIモードで利用している場合に影響を受ける脆弱性を修正したほか、PHP 5.4.3では「apache_request_headers()」に存在するバッファオーバーフローの脆弱性にも対処した。2件目の脆弱性はPHP 5.3系は影響を受けないという。 CGI関連の脆弱性は、3日にリリースされたPHP 5.3.12／5.4.2で解決されたはずだった。しかし後に
CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)
CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。 概要 CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。 例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。 test.cgi foo bar baz この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-s
PHP 5.3.12とPHP 5.4.2、脆弱性が完全には修正されていないことが判明 | スラド デベロッパー
PHPをCGIとして使用する場合にリモートからコマンドライン引数を指定してPHP-CGIバイナリーを実行できるという脆弱性(CVE-2012-1823)が発見され、PHP開発チームはPHP 5.3.12とPHP 5.4.2を公開した。しかし、脆弱性が完全には修正されておらず、改めて脆弱性情報データベースにCVE-2012-2311として登録されたとのこと( threatpostの記事、 Die Eindbazenの記事、 Yet Another PHP Security Blogの記事、 徳丸浩氏のブログ記事)。 この脆弱性は2004年から発見されずに存在していたもので、Apache mod_cgiを使用している環境などが影響を受けるという。悪用されるとリモートからローカルディスク上のファイルを実行されたり、DoSを実行されたりする可能性がある。攻撃者がサーバーにファイルをアップロードでき
CVE-2011-4885:ハッシュ衝突を悪用できる脆弱性 « PHP6.jp
PHP5.3.9では、脆弱性CVE-2011-4885が修正された。この脆弱性を悪用すると、サーバに過度の負荷を掛け、サービスを提供できない状態にできます。この不具合はPHP5.0系、PHP5.1系、PHP5.2系にも含まれていますが、PHP5.3系以外の修正版は提供されていません。 セキュリティーホールの概要 GETやPOSTで渡された変数はハッシュ構造に格納される。変数名に細工を加えることでハッシュの衝突が生じる。全ての変数のハッシュが衝突した場合、N個の変数の格納には、O(n2)の時間がかかるため、CPUに大きな負荷が発生する。 セキュリティーホールの修正 設定項目にmax_input_vars(デフォルト値1000)が追加された。計算量はO(n2)なので、1000個ぐらいの変数が衝突しても、現代のサーバなら問題ない。 バージョンアップせずに対応する方法 PHP5.3系を使っていれば
第46回 セキュリティ対策を考える上で欠かせないコンテクスト | gihyo.jp
円滑なコミュニケーションには、共通の用語・概念が必要です。用語・概念が違うようではコミュニケーションは不可能です。 前回は「バリデーションがセキュリティ対策である」ことを主題として、セキュリティ対策に対する考え方の基本について解説しました。前回の記事でセキュリティ対策とは何か理解できた方も多いと思います。しかし、まだ理解できていない方も居るようなので、セキュリティ対策についてもう少し解説します。次になぜコンテクストが重要なのか解説します。 今回も「ISO/IEC TR 13335−1 ITセキュリティマネジメントのガイドライン - 第一部：ITセキュリティの概念及びモデル」の解説になります。ISO規格ではITセキュリティ関連規格は27000シリーズに集約されますが、ITセキュリティの概念はこちらのほうがわかりやすくまとまっています。ITセキュリティの概念としては、ISO/IEC 13335
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
ウェブアプリのセキュリティをちゃんと知ろう
7. ウェブアプリの入力、処理、出力入出力ウェブサーバウェブアプリ(PHP など)外部 API サーバ(Facebook API 、決済会社など)入出力処理入出力データベースサーバ(MySQL など)ウェブブラウザ 10. ウェブサーバーを通したウェブブラウザからの入力の仕様を考えようPHP に入ってくる値は何かを知る可変長のバイト列 (文字列ではない！！)GET パラメータPOST パラメータアップロードファイルリクエストヘッダ (Cookie など)実際の処理に渡すべき値は何かを考える文字列か、バイト列か？文字コードは何か？(ウェブサーバーでバイト列を処理することってあまりないので、 PHP では基本的に文字コードのバリデーションは必要だと思って良い)長さはどうか？どういう文法や構造を持つデータ？入力された値を実際の処理に渡すべき値かどうかを確認することを「バリデーション」という 11
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
PHPのイタい入門書を読んでAjaxのXSSについて検討した(2)～evalインジェクション～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。タイトルはXSSとなっていますが、今回紹介する脆弱性はXSSではありません。 作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（本書P20の図1-23）。 Ajaxのアプリケーションでは、XMLHttpRequestメソッド等でデータを要求し、サーバーはXML、JSON、タブ区切り文字列など適当な形式で返します。ブラウザ側JavaScriptでは、データ形式をデコードして、さまざまな処理の後、HTMLとして表示します。以下に、Ajaxのリクエストがサーバーに届いた後の処理の流れを説明します。 サーバー側でデータを作成、取得 データ伝送用の形式（XML、JSON、タブ区切り文字列等）にエンコード
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
PHP5.3.7のcrypt関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証 - ockeghem's blog
phpMyAdmin（3.3.10.2未満、3.4.3.1未満）には、リモートから任意のスクリプトが実行可能な脆弱性があります。このエントリでは、この脆弱性が発生するメカニズムと対策について報告します。 概要 phpMyAdminには下記の2種類の脆弱性の組み合わせにより、リモートから任意のスクリプトを実行させられる脆弱性があります。 CVE-2011-2505 CVE-2011-2506 該当するバージョンは以下の通りです。 phpMyAdmin バージョン3.3.10.2未満 phpMyAdmin バージョン3.4.3.1未満 影響を受ける条件は、上記バージョンのphpMyAdminを使用していることに加えて、以下をすべて満たす場合です。 setup/index.phpとsetup/config.phpを外部から実行できる phpMyAdminのconfigディレクトリが存在し、PHP
PHPにおけるファイルアップロードの脆弱性CVE-2011-2202 - ockeghem's blog
PHPの現行バーション（PHP5.3.6以前）には、ファイルアップロード時のファイル名がルート直下の場合、先頭のスラッシュを除去しないでファイル名が渡される問題があります。CVE-2011-2202として報告されています。 後述するように影響を受けるアプリケーションは少ないと思われますが、念のためアプリケーションの確認を推奨します。また、次バージョンPHP5.3.7のRC1で修正されていることを確認しましたので、PHP5.3.7正式版が公開され次第、できるだけ早期に導入することを推奨します。 ※このエントリは、http://blog.tokumaru.org/2011/06/PHP-file-upload-bug-CVE-2011-2202.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。
PHPのsocket_connect()関数における *つまらない* 脆弱性の話 - ockeghem's blog
Scan Tech Report（無償版）を読んでいたら、PHP には、socket_connect() 関数の脆弱性（CVE-2011-1938）があると紹介されていました。調査の結果、この脆弱性の影響を受けるPHPのバージョンとして公開されている情報は間違っているようなので報告します。 概要 Scan Tech Reportには以下のように説明されています。 PHP には、socket_connect() 関数の処理に起因してバッファオーバーフローを引き起こしてしまう脆弱性が報告されました。 http://scan.netsecurity.ne.jp/archives/51983960.html バッファオーバーフローというと影響が大きそうでびっくりしますが、この脆弱性はあまり話題になっていません。その理由は、この脆弱性が悪用されるシナリオがほとんどあり得ないからです。 もう少し、詳し
問題点の概要 - 「PHPで作成する携帯会員サイトの基本」の諸問題(1) - 徳丸浩の日記
_問題点の概要 CodeZineから発表されている「PHPで作成する携帯会員サイトの基本」という記事はツッコミどころ満載で、既にいくつかの問題が修正されているのだが、まだ残っている問題があることや、修正内容にも疑問があるので、いくつか指摘してみたい。ざっと書いたところ、ものすごく長くなりそうだったので、小出しで「連載」の形で書く。忙しいので途中でやめるかもしれない。今回は、問題点の概要を報告する。 くだんの記事をざっと見たところ、以下の問題を見つけた。 IPアドレス制限のない「かんたんログイン」 Net_UserAgent_Mobileを用いて携帯電話の端末IDを取り出し、かんたんログインを実装しているが、ゲートウェイのIPアドレス経由であることを確認していない。以下のリストは、端末IDを取り出しているところ（4ページ目）。 $agent = Net_UserAgent_Mobile::s
第28回 あまり語られないセキュリティの基本 ── トラストバウンダリ | gihyo.jp
何事も基本が一番大切です。システム開発／コンピュータプログラミングも同じく基本が大切です。基本を守らないシステム設計やコーディングは問題発生の原因となる可能性が高いことは経験上理解できると思います。 セキュリティ対策の基本も非常に大切ですが、何故か基本はあまり語られていません。今回は安全性確保の基本中の基本を紹介したいと思います。 あまり語られない核心 正しいセキュリティ対策を行うには、セキュリティ問題の原因を理解する必要があります。 セキュリティ対策の記事などでは個々のセキュリティ問題に対する具体的な原因と対策が紹介されていることが多いです。私のブログも含め個人ブログなどでは「こういう場合はこうする」といった簡単な対処例が紹介されることが多いです。例えば、「SQLインジェクション対策にはプリペアードクエリだけを使えば大丈夫」などです。 読者の方もセキュリティ対策はどうすればよいのか、具
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでセキュリティを真面目に考える
