2012/02/15、 JVN から JVN#35256978: cforms II におけるクロスサイトスクリプティングの脆弱性 が公開されました。これはクレジットされているとおり、海老原と、同僚の渡辺優也君が勤務中に発見した脆弱性です。 脆弱性自体はどこにでもあるような普通の XSS ですが、実はこの脆弱性、 2010 年 10 月に exploit コードが公開され、それから 1 年 4 ヶ月後の 2012 年 2 月まで修正版が提供されていなかったものです。 このような危険な状態が長期間続いていたのには、様々な理由があります。ここでは、その説明と、どうすれば事態が防げたかということについて検討したいと思います。 脆弱性の概要 本題に入る前に、主に cforms II のユーザ向けに脆弱性自体の概要についてざっくり説明します。前述のとおり、未修正の状態で exploit コードが公開

備考 2012/02/16 11:36 2012/02/15 05:01 に公開した最初の版に比べ、以下の変更を加えています。 「影響を受ける PHP のバージョン」についての言及部分をはじめ、「脆弱性の概要」を大幅見直し 「この脆弱性の原因」の章を追加 「再現？　したが」の章を追加 なにはともあれ再現は確認できたので「（困り度: 暇なときにでも）なんか手元で再現しない件」の章は全文削除 2012/02/14、あの忌々しいバレンタインの日に JVN iPedia に追加された以下の記事をご存じでしょうか。 JVNDB-2012-001388 PHP における SQL インジェクション攻撃を行われる脆弱性 PHP は、環境変数のインポート中の magic_quotes_gpc ディレクティブへの一時的変更を適切に処理しないため、容易に SQL インジェクション攻撃を行われる脆弱性が存在します

2012/01/25 (日本時間では 17 時からの 24 時間) に開催された Mozilla CTF に参加してきました。 このエントリが 2 週間後の投稿になってしまったのは、モンハン 3G で忙しかったからです。モンハン楽しいですね！　初モンハンでしたが村クエ全部クリアしてやっと初心者脱出かなというところです。　いま HR 44 です！　今度誰か一緒に狩りに行きませんか！　そんな話はどうでもいいですね！ さて、 CTF とはなんぞやという方は「 プレイ・ザ・ゲーム！ CTFが問いかけるハックの意味 － ＠IT 」をご覧いただくといいと思います。 CTF はこれがはじめてだったんですが、腕試しくらいの軽い気持ちで思い切って単身で参戦しました。 別作業しながらの参戦だし、開催中も普通に 8 時間ほどガッツリ睡眠取ってたのですが、スコアボードを見てみると 33 位 (1700 Point

Symfony Advent Calender 2011 JP 18日目です。前回は @hidenorigoto さんでした。リダイレクト・インターセプションは 2.0.0 が出る前のどこかのタイミングでデフォルトでオフになって焦った記憶があります。投稿処理などをしたタイミングでプロファイラを見る機会が多いので、有効にしておくと便利ですよね。 さて、 18 日目となるこのエントリでは、セキュリティの観点から Symfony2 の機能について簡単に観ていくことにします（本当はしっかり見ていくつもりだったのですが、時間的制約から急遽簡単になりました！）。 ここでは Symfony Standard Edition v2.0.7 のインストール直後の構成、依存ライブラリを前提として解説します。また、 Web アプリケーションセキュリティに関する基本的な知識を持っていることを前提として説明します。

We are sorry, the page you requested cannot be found.

このエントリでは、海老原が 11/11 に発見した、「F001 の PC サイトビューアを利用して EZ 番号の作業がおこなえる」という脆弱性について説明します。 この脆弱性を利用されると、たとえば、「かんたんログイン」などの機能を提供する勝手サイトにおいて、 au 端末を利用したユーザになりすまされてしまうといった被害が発生しえます。 本問題の解決に向けてご協力いただいた 徳丸さんのブログエントリ にも詳しく触れられていますのでそちらもご一読ください。 おさらい 徳丸浩さんの以下のエントリで説明されているとおり、 au の 2011 年秋冬モデルの端末でおこなわれる（と宣言されている）変更が、「かんたんログイン」等の用途で使われている EZ 番号の詐称を許す可能性があるのではないかと多くの方々の間で懸念されていました。 IPアドレスについてはKDDI au: 技術情報 > IPアドレス帯

仕事で「フレームワークで使ってる CSRF 対策用トークンがセッション ID を基にいろいろ組み合わせた文字列のハッシュなんだけれども、なんでセッション ID 直接使わないんだよう」的な話が出たので、なんでだろうなーと考えつつ理由について検討してみたので以下に一部晒してみます（社内向けに書いたものなのでいろいろ雑だったりするのはごめんね）: 推測ですが、セッション ID が GET パラメータとかに含まれたりする可能性を避けたかったんじゃないかなあとか思います（フォームは GET でも使われうることを想定している）。 GET パラメータにセッション ID のような種類の情報は含めるべきではありません。 あと、セッション ID が盗まれた場合でも CSRF 攻撃を受けないようにするという意図もありそうな気がします。攻撃者がセッション ID を知っている状況で CSRF 攻撃を選択する状況につ

僕は今年に入ってからたまたま発見したセキュリティ脆弱性を積極的に報告するようにしはじめました。当然、検証の際には法を遵守するよう心がけていますし、他にも、検証の過程で誤って被害を与えてしまうことがないように、たとえば SQL Injection 脆弱性の発見は避けるなどの自分ルールを決めて、素人なりに細々とやっています。 さて最近、 昨今の学校のセキュリティ事情【第一章 学校のPC(生徒使用PC)について】 - toriimiyukkiの日記 http://d.hatena.ne.jp/toriimiyukki/20110907/1315406102 というエントリを見つけまして、これをふむふむと読んでいたところ、: ふと、自分の学校のユーザーリスト(下記のコマンドで取得)を見てると「testuser」なる者があった。 net group [グループ名] で、試したところ「****」という

平素はJUGEMに格別のご高配を賜り、厚く御礼申し上げます。 この度、PHPSESSIDが付与された管理者ページURLから外部サイトにアクセスした場合、 外部サイトのアクセス解析に残ったログから、お客様のブログ管理者ページに 他の方がログイン出来た可能性が判明いたしました。 お客様にご心配をお掛けする事となり、誠に申し訳ございません。 本件に関する詳細についてご報告させていただきます。 なお、この不具合に関しましては下記の条件下で発生することを 確認いたしております。 【弊社で確認した発生する条件】 （１）ご利用のブラウザのプライバシー設定が規定値より高く設定されていた場合 （２）セキュリティソフト等でCookieがブロックされてしまった場合 【第三者がログイン出来た条件】 上記（１）（２）のいずれかの条件を満たしたお客様が、JUGEM管理者ページ内から外部サイトへ 遷移した場合に、その外

We recently experienced a directed attack on SourceForge infrastructure (http://sourceforge.net/blog/sourceforge-net-attack/) and so we are resetting all passwords in the sf.net database — just in case. Our investigation uncovered evidence of password sniffing attempts. We have no evidence to suggest that the sniffing attempt was completed successfully.   But, what we definitely don’t want is to

Yesterday our vigilant operations guys detected a targeted attack against some of our developer infrastructure.  The attack resulted in an exploit of several SourceForge.net servers, and we have proactively shut down a handful of developer centric services to safeguard data and protect the majority of our services. Our immediate priorities are to prevent further exposure and ensure data integrity

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 ユーザじゃない