タグ

phpとセキュリティに関するyocchi24のブックマーク (12)

  • 正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう

    正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/

  • 書籍「気づけばプロ並みPHP」にリモートスクリプト実行の脆弱性

    書籍「気づけばプロ並みPHP」のサンプルスクリプトにリモートスクリプト実行の脆弱性があるので報告します。 はじめに Yahoo!知恵袋の質問を読んでいたら、以下の質問がありました。 気づけばプロ並みPHP (著)谷藤賢一 (発行)リックテレコムP112の画像をアップロードする機能でエラーがでます。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11119835496 より引用 質問に対しては回答が既についてクローズされていましたが、引用されているソースを見て任意のファイルを任意のファイル名で、Web公開ディレクトリにアップロードできることに気づきました(下記)。 <?php // 略 $pro_gazou=$_FILES['gazou']; // 略 if($pro_gazou['size']>0) { if ($pro_

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

  • ウェブアプリのセキュリティをちゃんと知ろう

    7. ウェブアプリの入力、処理、出力入出力ウェブサーバウェブアプリ(PHP など)外部 API サーバ(Facebook API 、決済会社など)入出力処理入出力データベースサーバ(MySQL など)ウェブブラウザ 10. ウェブサーバーを通したウェブブラウザからの入力の仕様を考えようPHP に入ってくる値は何かを知る可変長のバイト列 (文字列ではない!!)GET パラメータPOST パラメータアップロードファイルリクエストヘッダ (Cookie など)実際の処理に渡すべき値は何かを考える文字列か、バイト列か?文字コードは何か?(ウェブサーバーでバイト列を処理することってあまりないので、 PHP では基的に文字コードのバリデーションは必要だと思って良い)長さはどうか?どういう文法や構造を持つデータ?入力された値を実際の処理に渡すべき値かどうかを確認することを「バリデーション」という 11

    ウェブアプリのセキュリティをちゃんと知ろう
  • 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 アプリケーションのセキュリティについてのメモ

    このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH

    yocchi24
    yocchi24 2011/08/24
    いまさらだけど、参考にしてるPHP用Webアプリのセキュリティのまとめ
  • もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog

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

    もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
    yocchi24
    yocchi24 2011/08/23
    セキュリティの参考に!書かれているスクリプトの中からセキュリティホールを見つけて修正するっていうのは研修にもいいかも。
  • PHPでセキュリティを真面目に考える

    オープンソースカンファレンス2011 Hokkaido #osc11do 「PHPセキュリティを真面目に考える」 LOCAL PHP部 佐藤琢哉(@nazo) http://labs.nazone.info/Read less

    PHPでセキュリティを真面目に考える
    yocchi24
    yocchi24 2011/06/13
    このレベルのセキュリティ知識が無いヤツはウチの会社には要らない。知識が無い人は必読。IPAのサイトも必読。
  • 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 ユーザじゃない

    yocchi24
    yocchi24 2010/11/18
    Cakeよく使うので必読。
  • 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定

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

    yocchi24
    yocchi24 2010/09/28
    PHP使いは必読
  • PHPで予め許可したタグと属性以外を除去できるライブラリ「kses」:phpspot開発日誌

    CSS3のでのボックス要素デザインを圧倒的に簡単化できる「CSS3 Click Chart... 次の記事 ≫:アプリやWEBサイトに使えそうなフリーな244個のアイコンセット kses - PHP HTML/XHTML filter | Download kses - PHP HTML/XHTML filter software for free at SourceForge.net PHPで予め許可したタグと属性以外を除去できるライブラリ「kses」。 外部からの入力値は基的にhtmlspecialcharsでタグを無効化するのが通常の考え方ですが、掲示板なんかで特定のタグを許可したいという場合があります。 PHPにはstrip_tagsというようなタグを除去しつつ、特定のタグのみを残すという関数が標準であったりしますが、これだと属性までは制御しきれません。 更には、<a href=

    yocchi24
    yocchi24 2010/06/29
    フォームで限定タグを許したいときに便利!
  • PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)

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

  • 1