タグ

securityとPHPに関するslywalkerのブックマーク (9)

  • サポート終了後のPHPを使用しているWebサイトは8割 - IPA

    IPA(独立行政法人情報処理推進機構)は、IPAが脆弱性の届出を受けたWebサイトで使用されているWebサーバ関連ソフトウェアのバージョン確認を実施し、その結果を踏まえ、サイト運営組織および管理者向けに「サーバソフトウェアが最新版に更新されにくい現状および対策」を4月25日からIPAのWebサイトで公開した。 IPAが、2013年4月15日から2014年1月16日にかけてJPCERTコーディネーションセンターが発表した四半期別のインシデント報告対応レポート4通をもとに算出したところ、Webサイトの改竄が7,409件発生したことがわかった。 それらの中には閲覧者のウイルス感染やWebサイトからの情報漏洩が発生しているが、原因の1つにWebサーバ構築に用いられているソフトが古いバージョンのままで、脆弱性が未修正であったことが挙げられる。 これを受け、IPAは「PHP」「Apache」「IIS」

    サポート終了後のPHPを使用しているWebサイトは8割 - IPA
  • 正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう

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

  • 文字コードの脆弱性はこの3年間でどの程度対策されたか?

    4. デモ1:半端な先行バイトによるXSS • 半端な先行バイトとは – Shift_JIS、EUC-JP、UTF-8などマルチバイト文字の1 バイト目だけが独立して存在する状態 – 次の文字が、マルチバイト文字の2バイト目以降の文 字として「われる」状況になる – input要素などの引用符「”」をわせて、イベントハ ンドラを注入する攻撃 Copyright © 2010-2014 HASH Consulting Corp. 4 5. デモ1:PHPソース <?php session_start(); header('Content-Type: text/html; charset=Shift_JIS'); $p1 = @$_GET['p1']; $p2 = @$_GET['p2']; ?> <body> <form> PHP Version:<?php echo htmlspeci

    文字コードの脆弱性はこの3年間でどの程度対策されたか?
  • PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋

    下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 (以下、原文の和訳です) 原文:http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な

    PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
  • PHP 5.3 でネイティブ関数の引数型エラー時の返り値が変更になったけど大丈夫? - co3k.org

    PHP 5.5.0 リリースおめでとうございます。 タイミング的に PHP 5.5 の話だと読み間違えた方 (もしくは「こいつ間違って PHP 5.3 って書いてやがるプギャー」と思った方) におかれましては、このテキーラはサービスだから、まず飲んで落ち着いてほしい。 はい。ということで、驚くべきことに、いまから、真顔で、 PHP 5.3 の変更点の話をします。でも PHP 5.5 が出るにあたってコードを見直す方もいるでしょうし、なんというかついでに気に掛けていただければと。 何の話か PHP 5.3 の「下位互換性のない変更点」として、マニュアルに以下のように示されている件についての話です。 引数を解釈する内部API が、PHP 5.3.x に同梱されている全ての拡張機能に 適用されるようになりました。つまり、互換性のないパラメーターが渡された場合、 この引数を解釈するAPIは NUL

  • Andi Gutmans氏,PHP,クラウドコンピューティング,セキュリティを語る

    原文(投稿日:2013/06/05)へのリンク ZendはWeb上の100万近いサイトやブログで幅広く使用されている PHP フレームワーク以外にも,Zend Server や Zend Server in the Cloud, Zend Unlimited, Zend Framework, Zend Studio, Zend Developer Edition, Zend Developer Cloud, Zend Guard などを開発している。 同社の共同創設者でCEOの Andi Gutmans 氏が,InfoQとの独占インタビューに応じてくれた。クラウドコンピューティングに関する氏自身の見解に加えて,セキュリティやサイトをハッカーから保護するために取るべき行動指針など,PHPに関するさまざまな側面について語っている。 InfoQ: クラウドコンピューティングの意味について,分かり

    Andi Gutmans氏,PHP,クラウドコンピューティング,セキュリティを語る
  • PHP unserialize()が__destruct()を実行する?

    CakePHPセキュリティホール(まだの方はご対応を!)から、unserialize()が話題になっています。 このセキュリティホールは、外部から送信された値をチェックせずにunserialize()したことが引き金になっており、安全でない値をunserialize()することの危険性が指摘されています。 下記エントリでは、コードを交えてunserialize()から__destruct()が実行される過程が解説されています。 PHP5 __destruct() and unserialize() function – TokuLog 改メ tokuhirom’s blog 念のための補足なのですが、unserialize()から__destruct()が呼ばれるわけではありません。 下記コードは、PHP5.3.3で実行しています。 unserialize()から実行される関数 unse

  • PHP5 __destruct() and unserialize() function - TokuLog 改メ tokuhirom’s blog

    http://co3k.org/diary/12 このへんみておもったこと。 unserialize() 関数はオブジェクトの unserialize もできるのだが、5 以後では __destruct() が導入されているので、その unserialize したオブジェクトの __destruct() がよばれてしまう。この際に、たとえば cache の処理などで __destruct() でファイルにデータをかきこむ、などの処理をしていると、そのファイルが汚染されてしまったりするということがおきうる。 で、実際に cakephp ではそういう状況になって、任意のコードが実行可能になった、と。 まとめると 5 以後では unserialize() をユーザーからの入力にたいしてはかならず検証してからおこなうようにするべき。 っていうか、ユーザーの入力にたいしては unserialize(

  • 第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp

    前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“⁠UTF-8⁠”を指定することをお勧めします。サイトによってはSJIS、EUC-JP

    第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp
  • 1