【速報】PHP-5.5.2にて大垣さんのstrict sessionsが実装されました
大垣さんのツイートで、strict sessionsがPHPにマージされることを知りました。 やっとStrict Sessionがマージされました。8年越しです。... http://t.co/ZBuVTHunqy — Yasuo Ohgaki (大垣靖男) (@yohgaki) August 5, 2013 本日、PHP-5.5.2が公開されましたので、ChangeLogを確認したところ、確かに入っているようです。 Sessions: Implemented strict sessions RFC (https://wiki.php.net/rfc/strict_sessions) which protects against session fixation attacks and session collisions. PHP 5 ChangeLog より引用 8年越しのstrict
さくらDNSにサブドメインハイジャックを許す脆弱性
さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。 DNSサービスへのドメイン登録時における不具合について 障害内容 : 当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。 本問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。 この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。 (12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日（6月13日）には改修されましたので
PHPのescapeshellcmdを巡る冒険
以前、ブログ記事「PHPのescapeshellcmdの危険性」にて、escapeshellcmd関数の「余計なお世話」によって危険性が生まれていることを指摘しましたが、その後大垣さんによって修正案が提示され、結局「それはマニュアルの間違い」ということで決着が着いたようです。ところが、この議論とは別のところで、escapeshellcmdはPHP5.4.0で挙動が少し変わっていることが分かりました。 経緯 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正して
hashdos攻撃をmod_securityで防御する(CentOS+yum編)
このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。CentOS環境でyumによりApacheを導入しているサイトに対して、yumによりmod_securityを導入するというシナリオで説明します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。まだhashdosによる攻撃事例は報告されていないようですが、既に攻撃コード（PoC）が公表されているため、いつ攻撃が起こっても不思議ではない状況です。 PHPも影響を受けるプラットフォームであり、PHP5.3.9で対処予定となっていますが、まだPHP5.3.9はリリースされて
au の F001 に存在した EZ 番号詐称の脆弱性について - co3k.org
このエントリでは、海老原が 11/11 に発見した、「F001 の PC サイトビューアを利用して EZ 番号の作業がおこなえる」という脆弱性について説明します。 この脆弱性を利用されると、たとえば、「かんたんログイン」などの機能を提供する勝手サイトにおいて、 au 端末を利用したユーザになりすまされてしまうといった被害が発生しえます。 本問題の解決に向けてご協力いただいた 徳丸さんのブログエントリ にも詳しく触れられていますのでそちらもご一読ください。 おさらい 徳丸浩さんの以下のエントリで説明されているとおり、 au の 2011 年秋冬モデルの端末でおこなわれる（と宣言されている）変更が、「かんたんログイン」等の用途で使われている EZ 番号の詐称を許す可能性があるのではないかと多くの方々の間で懸念されていました。 IPアドレスについてはKDDI au: 技術情報 > IPアドレス帯
PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
secure.softbank.ne.jp廃止の舞台裏 | 水無月ばけらのえび日記
公開: 2011年7月11日2時10分頃 secure.softbank.ne.jpが廃止されたことに伴い、なぜ廃止しなければならなかったのか、その背景についての解説が相次いで公開されています。 secure.softbank.ne.jp ヤバイの話 (subtech.g.hatena.ne.jp)SoftBankガラケーの致命的な脆弱性がようやく解消 (takagi-hiromitsu.jp)ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る (blog.tokumaru.org)secure.softbank.ne.jp ヤバイの話+ (subtech.g.hatena.ne.jp)先月まで、ソフトバンクのケータイサイトで https://example.com/ へのリンクを辿ろうとすると、以下のような動作になっていました。 ソフトバンクのケータイでサイトにアクセスすると、ゲートウ
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
SoftBankガラケーの致命的な脆弱性がようやく解消 - 高木浩光＠自宅の日記
■ SoftBankガラケーの致命的な脆弱性がようやく解消 ソフトバンクモバイルのガラケーWebブラウザで、https:接続する際の仕様に変更があった。昨年10月に予告が発表され、元々は2月に実施される予定だったのが、6月30日に延期されていたもの。これまで、https:サイトへのリンクのすべてが https://secure.softbank.ne.jp/ 経由に書き換えられる仕様だったが、この機能が廃止された。 ソフトバンクモバイル、携帯サイトの仕様変更で注意喚起, ITmedia, 2011年6月30日 Yahoo! ケータイ、2011年2月に仕様変更 ユーザーとサイト開発者に注意喚起, ITmedia, 2010年10月15日 MOBILE CREATION - WEB & NETWORK SSL/TLS, ソフトバンクモバイル これは、昨年6月に、ソフトバンクモバイル宮川CTOに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
