delicious days の提供する cforms II は、WordPress 用のプラグインです。cforms II には、クロスサイトスクリプティングの脆弱性が存在します。
2012/01/25 (日本時間では 17 時からの 24 時間) に開催された Mozilla CTF に参加してきました。 このエントリが 2 週間後の投稿になってしまったのは、モンハン 3G で忙しかったからです。モンハン楽しいですね! 初モンハンでしたが村クエ全部クリアしてやっと初心者脱出かなというところです。 いま HR 44 です! 今度誰か一緒に狩りに行きませんか! そんな話はどうでもいいですね! さて、 CTF とはなんぞやという方は「 プレイ・ザ・ゲーム! CTFが問いかけるハックの意味 - @IT 」をご覧いただくといいと思います。 CTF はこれがはじめてだったんですが、腕試しくらいの軽い気持ちで思い切って単身で参戦しました。 別作業しながらの参戦だし、開催中も普通に 8 時間ほどガッツリ睡眠取ってたのですが、スコアボードを見てみると 33 位 (1700 Point
PHP 5.4 Advent Calendar 2011 19 日目です。 前回は @cocoitiban さん でした。 htmlspecialchars() のオプション追加については個人的にも気になっていたところ(Symfony2 の https://github.com/symfony/symfony/commit/053b42158e2f887b54a3e87977303d219530082f というコミットで気づいた)で、ふむふむと読ませていただきました。たとえば、文書型を考慮するようになると SGML 的に (あれ、 HTML 的にだっけ?) 違法である NULL 文字とかがさっくり消えて、 IE が NULL 文字を無視したりして XSS に繋がりうる問題 が回避できるようになったりするんですかねえ。 さて、これまでの Advent Calendar で触れられてきたように
Symfony Advent Calender 2011 JP 18日目です。前回は @hidenorigoto さんでした。リダイレクト・インターセプションは 2.0.0 が出る前のどこかのタイミングでデフォルトでオフになって焦った記憶があります。投稿処理などをしたタイミングでプロファイラを見る機会が多いので、有効にしておくと便利ですよね。 さて、 18 日目となるこのエントリでは、セキュリティの観点から Symfony2 の機能について簡単に観ていくことにします(本当はしっかり見ていくつもりだったのですが、時間的制約から急遽簡単になりました!)。 ここでは Symfony Standard Edition v2.0.7 のインストール直後の構成、依存ライブラリを前提として解説します。また、 Web アプリケーションセキュリティに関する基本的な知識を持っていることを前提として説明します。
結論から言うと、 au 端末の EZ ブラウザで cookie が使えなくなって困ったりした経験をお持ちの方とか、そのあたりの情報を知っている方とかいらっしゃいませんか? という話です。 「あ、俺この問題遭遇しているよ!」とかあれば、技術的な話とか調査結果とかすっ飛ばして、このエントリの最下部、「同志募集」の節をご覧ください。 なんだそれ ことのはじまりは、 OpenPNE の Redmine に以下のチケットが登録されたことでした。 OpenPNE 3 - Bug(バグ) #2134: au の一部の端末でセッションが保持できない (ログインできない) - OpenPNE Issue Tracking System http://redmine.openpne.jp/issues/2134 このチケットで報告されている内容やその背景を要約すると、 OpenPNE 3 はセッション維持に
このエントリでは、海老原が 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 [グループ名] で、試したところ「****」という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く