PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
はてなブログ | 無料ブログを作成しよう
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
勝手に補足：レガシーPHPのセキュリティ対策，大丈夫ですか？未修正の脆弱性（2） - ockeghem's blog
第4回 未修正の脆弱性（2）：レガシーPHPのセキュリティ対策，大丈夫ですか？｜gihyo.jp … 技術評論社という記事を読みました。とても重要なことが記載されている一方で、記述の間違い及び記述もれがあるため、読者の便宜のため勝手に補足したいと思います。具体的に、PHP4系の最終版PHP4.4.9にてパッチの提供されない4つのぜい弱性についての話題です。一部のぜい弱性はPHP5.2系でもパッチが出る見込みがないものです。 CGIのDoS 元記事ではCVE-2009-3660として紹介されていますが、CVEおよびNVDのサイトを見ると、Efront 3.5.4以前の脆弱性とあります。明らかに該当しないので調べてみると、CVE-2008-3660の間違いのようですね。2008を2009とTYPOしたのでしょう。 脆弱性の中味ですが、元記事に以下のように書かれています。 この脆弱性は不正なパス
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の新しいround関数にバグをみつけた - hnwの日記
PHP 5.3.0以降、PHPのround関数の挙動はChristian Seilerさんが提案したRFCに従って一新されています。この新しいround関数の仕様上の問題もしくはバグを見つけました。 以前の記事「PHP5.3.0alpha3のround関数の実装がPHP5.2.6と変わった」でこの新しい実装は「今までよりは良い実装」ではないかと書きましたが、撤回すべきかもしれません。ベースのアイデアとしては以前の記事にも書いた通り悪くないと思うのですが、考え漏れがあるような気がしています。 たとえば次のサンプルコードを見て下さい。 <?php ini_set("precision",19); var_dump(1000000000000000.125); var_dump(round(1000000000000000.125)); サンプルコード中の1000000000000000.125
PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 - 徳丸浩の日記(2011-03-29)
_PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 前回のブログ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり」にて、PHP5.3.6（本エントリ執筆時点での最新版）からPDOにてサポートされた文字エンコーディング指定がWindows版では正しく動作しないことを報告しました。Linuxでは正常に動作するので不思議だなという話になっていたのですが、千葉征弘さん(@nihen)が調べてくださった結果がtwitter上で発表されました（toggerによるまとめ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合にまつわる件」）。この件につき、当ブログでも報告します。 問題点の復習 PHP5.3.6以降のPDOでは、データベースに接続する際の文字エンコーディングを
PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり - 徳丸浩の日記(2011-03-22)
_PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり PHP5.3.6からPDO/MySQLにてデータベースの接続文字列にて文字エンコーディングが指定可能となりました。この機能を検証した結果、Linux上では正常な動作を確認しました。Windows版でも一見動作するようですが、動的プレースホルダ内部のエスケープ処理に不備があり、Shift_JISでデータベースと接続している際にSQLインジェクション脆弱性の可能性があります。 きっかけ @haruyamaさんのツイートがきっかけで、PHP5.3.6からPDOの文字エンコーディング指定が有効となったことを知りました。 PHP 5.3.6以降では PDO/MySQLのDSNでのcharset指定が有効になったようです. (MySQL 4.1.11以降, MySQL 5.0.7以降, もし
『Webサイト制作者のためのPHP入門講座』という本を書きました - A Day in Serenity @ kenjis
Webサイト制作者のための PHP入門講座 作者: 鈴木憲治,安藤建一,小出範明出版社/メーカー: 技術評論社発売日: 2011/01/07メディア: 大型本購入: 9人 クリック: 732回この商品を含むブログ (10件) を見る どんな本？ Web デザインや HTML/CSS コーディングをメインにされている方でも、よくわからずに PHP のコードを触ることになり、というようなケースがあるかと思います。そんなとき、ある PHP のコードが何をしているかを把握できたら、もっと簡単にいろいろなことができるようになると思いませんか？また、ちょっとした目的のための PHP を自ら書けるようになったら、どうでしょう？ 本書は、そのような方々が PHP のスキルを基礎から身につけていくための PHP の入門書です。 PHP とは？から始まり、開発環境の構築、PHP の基礎を学習し、その後、実用的
CakePHPのSecurityComponentの脆弱性で任意のPHPコードが実行できる仕組み - disり用。
もはや懐かしい感じのあるCakePHPのセキュリティトークンから任意のPHPを実行できる脆弱性ですが、なぜこれで任意のPHPコードが実行可能になってしまうのか心配で夜も眠れない方の為に、実行される仕組みを解説してみようと思います。詳細とアドバイザリ、PoCは以下のものを参照しています。 http://co3k.org/diary/12 http://malloc.im/CakePHP-unserialize.txt http://malloc.im/burnedcake.py CakePHPのSecurityComponentが提供するCSRF対策のトークンは単一の識別子ではなく、':' でトークンと$lockedという謎の値が繋がれたものになっています。$lockedには配列をシリアライズしたものをROT13で変換したものが入っています。この$lockedに任意の値を入れることで任意のP
PHP: PHPの隠蔽 - Manual
PHPの隠蔽 一般に隠蔽という手段はセキュリティとしては弱いものだと言われています。 しかしこうした手法が望ましい場合もあります。 PHP を隠すための簡単な技法がいくつかあり、 システムの弱点を見つけようとする攻撃を遅延させることができる可能性があります。 php.ini ファイルで expose_php を off と設定すれば、 攻撃者が利用可能な情報を減らすことができます。 他の手段は、ApacheのようなWebサーバーで PHPに異なるファイル形式をパースさせるように設定することです。 これは、.htaccessディレクティブまたは Apacheの設定ファイル自体で指定します。 これにより、紛らわしいファイル拡張子を使用可能です。
PHPのescapeshellcmdの危険性 - 徳丸浩の日記
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本を書いています。初稿を一通り書き上げ、第2稿を作成中です。その過程で見つけたことを報告します。 PHPのescapeshellcmdはパラメータをクォートしないので呼び出し側でクォートする必要がありますが、escapeshellcmdの仕様がまずいために、呼び出し側でクォートしても突破できることが分かりました。 escapeshellcmdの仕様 PHPにはシェルのパラメータをエスケープする関数が2つあります。escapeshellargとescapeshellcmdです。escapeshellargは、エ
ウノウラボ by Zynga Japan: <?php を閉じてみる
こんにちは、7月からphpを始めた細川です。 phpの作法で<?phpではじめたファイルを?>で閉じない、というものがあります。これまで、あまり考えずに従ってきたのですが、よく考えてみると「タグを閉じない」というのは直感的には不作法です。 検索して調べてみると、以下のような記事が見つかりました。 http://zendframework.com より引用 PHP コードのみからなるファイルでは、終了タグ ("?>") は決して含めてはいけません。これは必須なものではなく、 終了タグを省略することで、ファイルの最後にある空白文字が出力に影響することを防ぎます。 「決して」含めてはいけない。ということで、わりと大事のようです。 そこで、実際にタグを閉じると何がおこりうるのか調べてみることにしました。 まず、以下のようなphpファイルtest.phpを用意しました。
非PHPerのためのPHP入門決定版 「パーフェクトPHP」 : DSAS開発者の部屋
エキスパートPythonプログラミングの書評 を書いていただいたGREEのsotarokさんから、「パーフェクトPHP」を献本していただきました。 ありがとうございます。 KLabでは多くのWebサイトをPHPで構築しているのですが、私はあまりWebアプリ開発には 関わっておらず、チューニングが必要な場面でだけプロファイル結果を見てチューニングしたり、 社内専用PHPエクステンションを書いたりしているだけで、しっかりとPHPの言語を勉強した ことはありませんでした。 array の実装は判っても、 array_* 関数とか全然覚えていません。 これを機に、ちゃんと言語としてのPHPを勉強することにしました。 まず、この本はプログラミング初心者向けの本ではありません。関数やオブジェクト指向がなぜ 必要なのかなどのいわゆる入門者向けの話題はバッサリ切り捨てています。おかげで、すでに 他の言語で
CakePHPのSecurityComponentに深刻なセキュリティホールが見つかりました
すでにご存知の方も多いと思うのですが、CakePHPに深刻なセキュリティホールが見つかりました。 SecurityComponentの実装に問題があり、結果、外部から任意のコードを実行させることができるという深刻な内容です。 セキュリティホールの概要や攻撃手順については以下のエントリが詳しいですので、ご一読を。 CakePHP の PHP コード実行の脆弱性を使って CakePHP を焦がす なお、今回の問題はSecurityComponentを利用していない場合は発生しません。 もしSecurityComponentを利用している場合は、以下のいずれかの方法で早急に対策してください。 1. CakePHP1.2.9 or 1.3.6にアップグレードする。 この脆弱性を受けて修正バージョンが出ています。 CakePHP 1.3.6 and 1.2.9 released | The Bake
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでセキュリティを真面目に考える
)
インターネット Web サーバー構築ガイドライン | IIS | マイクロソフト 技術情報
JavaとPHPの文法比較
