タグ

SecurityとPHPに関するHeavyFeatherのブックマーク (36)

  • 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_

  • 試そう!PHPコードを解析して修正点を指摘·phpca MOONGIFT

    phpcaはPHPを静的に解析して小さなミスやコードの修正点を指摘してくれるソフトウェアです。 PHPを書く際にどう書けば小さなミスによるバグの発生を防げるでしょうか。一定の基準に沿って記述することで整然としたコードを実現し、可読性をあげることでバグの混入を防ぐことができます。そこで使いたいのがphpcaです。静的にPHPファイル(ディレクトリ単位も可)を解析し、修正すべき場所を指摘してくれます。 解析処理を実行しています。PHPのパスと、解析したいファイルやディレクトリ名を指定して実行します。解析処理中は随時メッセージが出力されます。 メッセージ例です。タブの利用や行の使い方に関してなどメッセージが表示されます。 ?>がない場合もメッセージが出ます。これはPHPの書き方としては逆かも知れません(確かない方が良いという話なので)。 PHPを書く上でありがちなミスやバグにつながりそうな指摘を

  • PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)

    PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます(公式リファレンス)。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境

  • 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から参照することができます。以下に、おおまかな流れを図示します。まずはバ

    PHP5.3.7のcrypt関数のバグはこうして生まれた
  • もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog

    たにぐちまことさんの書かれた『よくわかるPHPの教科書(以下、「よくわかる」)』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方(以下、徳丸)」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸でも強調しているように、入力値検証はアプリケーション要件(仕様)に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します(「よくわ

    もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
  • 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のsocket_connect()関数における *つまらない* 脆弱性の話 - ockeghem's blog
  • CakePHP の PHP コード実行の脆弱性を使って CakePHP を焦がす - co3k.org

    2010/11/13 に出たらしい http://bakery.cakephp.org/articles/markstory/2010/11/13/cakephp_1_3_6_and_1_2_9_released を読んでびっくりしたんですが、 Twitter を軽く検索した限りだと CakePHP ユーザでない僕が気づいているのに (日の) CakePHP ユーザさんたちがどうも気づいていないっぽいのでわかりやすくまとめてみることにしました! CakePHP には任意の PHP コードが実行できる致命的な脆弱性があります! 影響のあるサイト結構ありそうですが悪用厳禁です! ※通常リリースの告知のなかにこんな致命的な脆弱性に関する情報を思いっきりわかりにくく書いちゃうのはひどいなあと思うので、ユーザの方は CakePHP に文句を言うといいと思います。僕は CakePHP ユーザじゃない

  • 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの

  • ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win

    ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
  • Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記

    以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS

    Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
  • PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)

    _既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト(言語、フレームワークなど)か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ

  • PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT

    PHPは広く数多のWebサーバでインストールされ、使われている。設定ファイルは殆どそのままで使われていることが多いのではないだろうか。だが4.2より前のバージョンではregister_globalsのデフォルトがOnになっていたなど、利便性とセキュアであることとの関係で潜在的な問題はあるかも知れない。 php.iniのセキュリティチェックに 見直すのはPHPの設定ファイルであるphp.iniだが、多数の設定があるのでぱっと見では設定の善し悪しが分かりづらいかも知れない。そこで使うのがPHP Security Consortiumだ。 今回紹介するオープンソース・ソフトウェアはPHP Security Consortium、PHPセキュリティ設定を見直すソフトウェアだ。 PHP Security ConsortiumはPHPで作られたソフトウェアで、phpinfo()から得られる情報を使っ

    PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT
  • XSS、SQLインジェクションを発見する·Pixy MOONGIFT

    PHPはWebシステムの中で広く使われているポピュラーなスクリプト言語だ。だが、手軽に習得し、開発が行えるとあって成果物のレベルが様々であり、中にはセキュリティ上問題のあるコードが多数存在することがある。そうしたセキュリティ上の問題を解決する手法やフレームワークもあるが、ごく簡単なシステムでは使われることがないだろう。 SQLのコードを精査し、問題の発見につなげる そのようなものを放置しておくと、いつ何時問題がわき上がるか分からない。そうした不安を取り除くためにもPixyを使ってみよう。 今回紹介するオープンソース・ソフトウェアはPixy、XSS、SQLインジェクションを発見するスキャナソフトウェアだ。 最初に断っておくと実際試してみたところでは100%の解決にはつながらなさそうなのでご注意いただきたい。PixyはJavaで作られたソフトウェアで、PHPファイルを指定して実行するとソースフ

    XSS、SQLインジェクションを発見する·Pixy MOONGIFT
  • PHP逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog

    404方面でも絶賛されていたPHP逆引きレシピを購入した。書はとても丁寧な仕事で素晴らしいと思ったが、セキュリティに関しては若干残念な思いをしたので、それを書こうと思う。 目次は以下のようになっている。 第1章 準備 第2章 PHPの基構文 第3章 PHPの基テクニック 第4章 ファイルとディレクトリ 第5章 PEARとSmarty 第6章 Webプログラミング 第7章 クラスとオブジェクト 第8章 セキュリティ 8.1 セキュリティ対策の基 8.2 PHPの設定 8.3 セキュリティ対策 第9章 トラブルシューティング 第10章 アプリケーション編 PHP逆引きレシピ オフィシャルサポート 書は、タイトルの示すように、コレコレしたいという目的ごとにPHPでの書き方が書かれている。よくある逆引き辞典タイプのだが、類書に比べて丁寧に書かれている印象を受けた。私が感心したのは、PH

    PHP逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog
  • i-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)

    _携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止

  • PHP プログラマが "@" を使うべきでない 5 つの理由 - 肉とビールとパンケーキ by @sotarok

    #釣りっぽいタイトルですが大まじめです via. PHP 逆引きレシピ - 肉とご飯と甘いもの @ sotarok で、 @ (エラー制御演算子といいます!)はねーよ的な話をしましたが、著者の方から、「@に対して批判的になる理由が記載されていない」とのメールをいただきました。確かにその通りでした。実は理由を下書きのときには書いたのですが、長くなってしまったので削ってポストしたのですが、かえってわかりづらくなってしまいましたね.すみません。 ということで、PHPプログラマが、エラー制御演算子「@」使うべきでない 5 つの理由を述べます. 始める前に、質的なところ 色々理由はつけようと、やっぱり前回述べた、 終的に$qに入るものが同じであることと、コードとして同じ意味であるかは、別じゃないでしょうか。 が一番質的な話で、それ以上の話ではありません。 つまり、発生する可能性があるとわかってい

    PHP プログラマが "@" を使うべきでない 5 つの理由 - 肉とビールとパンケーキ by @sotarok
  • PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog

    なぜPHPアプリにセキュリティホールが多いのか?:第25回 PHPのアキレス腱にて、大垣靖男氏がPHPSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし,実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために,来はsession_regenerate_id関数をログイン

    PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
  • 携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog

    最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、書にはブログやSNSなど認証が必要なアプリケーションも登場する。書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て

    携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
  • 121. IPアドレスから所在地探し

    IPアドレスから所在地を調べたいと思ったことはありませんか?今回は,IPアドレスからその場所がどこなのかPHPで調べる方法をご紹介します。 それには,GeoIPライブラリが必要になります。PHPからこのライブラリの機能を使うには, PEARのNet_GeoIPをインストール Peclの拡張モジュールをインストール Apacheのモジュールとしてインストール という3種類の方法があります。 今回はPeclの拡張モジュールを使います。対象はLinux系OSになります。 1.GeoIPライブラリををインストール MaxMind社のホームページから,GeoIPライブラリをダウンロードし,インストールします。 cd /usr/local/src wget http://www.maxmind.com/download/geoip/api/c/GeoIP.tar.gz tar xzvf GeoIP.t

    121. IPアドレスから所在地探し
  • 「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog

    はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル

    「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog