私はいかにしてOperaブラウザのCookie Monster Bugを確認したか - ockeghem's blog
昨日の日記「都道府県型JPドメインがCookieに及ぼす影響の調査 | 徳丸浩の日記」にも書きましたが、Operaブラウザの最新版（11.51）には、地域型ドメインの場合にCookie Monster Bugがあります。以下は、三重県の志摩市のドメイン(www.city.shima.mie.jp)上で domain=mie.jpのCookieをセットした様子です。 この状態で三重県津市(www.info.city.tsu.mie.jp)のホームページにアクセスしたところ、このCookieが送信されることをネットワークキャプチャにて確認しました。 Operaブラウザは独自の方法でCookie Monster Bugに対応しているというのが業界の常識だと思っていましたので、当初この現象を見て驚きました。大げさに言えば「ニュートリノが光速を越えた」ことに匹敵する（大げさ過ぎ）ような驚きでしたので
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
「体系的に学ぶ 安全なWebアプリケーションの作り方」3月1日発売です - ockeghem's blog
去年の5月末に「本を書く」という宣言をしてから8ヶ月以上掛かってしまいましたが、ようやく体系的に学ぶ 安全なWebアプリケーションの作り方が脱稿し、3月1日に発売される運びとなりました。 現時点で一番詳しい本の目次は、出版元のオフィシャルページにありますが、このブログでもおいおい詳しい内容を紹介したいと思います。また別途サポートページを立ち上げる予定です。 本書の目次は以下の通りです。 1章 Webアプリケーションの脆弱性とは 2章 実習環境のセットアップ 3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー 4章 Webアプリケーションの機能別に見るセキュリティバグ 5章 代表的なセキュリティ機能 6章 文字コードとセキュリティ 7章 携帯電話向けWebアプリケーションの脆弱性対策 8章 Webサイトの安全性を高めるために 9章 安全なWebアプリケーションのた
NSFOCUSセミナー - ockeghem's blog
NSFOCUSという中国のセキュリティ会社が日本に進出してインテカーセキュアソリューションズという会社を設立することになり、セミナーで講演することになりました。NSFOCUS社の日本での主力製品は、DoS攻撃防御システム(Anti-DoS)やWAF(Web Application Firewall)ですが、セミナーでは、脆弱性診断とWAFの話がメインになります。時節柄アンチDoS製品に興味を持たれる方も多いと思いますが、WAFにもアンチDoS機能が入っているように伺っています（オプションかもしれません）。 日時 2010年3月15日(月) 14:00〜17:00（13:30受付開始） 場所 新宿パークタワー S側 30階 桔梗（KIKYO）ルーム 基調講演 誤解だらけのWebアプリケーションセキュリティ対策〜発注から事後対策まで〜 講演1 最先端の診断サービスとは?〜セキュリティ先進国、中
ockeghem(徳丸浩)の日記 - XSS対策:どの文字をエスケープするべきなのか － コメント#1
ITproの連載中に、id:hasegawayosukeさんから以下のようなコメントをいただいていました。 対策遅らせるHTMLエンコーディングの「神話」：ITpro - 葉っぱ日記 全ての文字をエスケープしようなどと非現実的なことは言わないけれど(とはいえMicrosoft Anti-Cross Site Scripting Libraryのようにほとんど全ての文字を実体参照に置き換えるものもあるので、あながち非現実的とも言えないのかも知れない)、エスケープ対象を「'」「"」「<」「>」「&」の5文字に限定しているのは何かこの記事に書かれていない理由があるはずだと思ったからです。 はてぶの方は見ていましたが、日記の方を見落としていまして、お返事が遅れました(_ _)。 なぜ、「<」、「>」、「&」、「"」、「'」の5種類の文字をエスケープするのかについては、色々考えるところがあります。
XSS対策:JavaScriptのエスケープ(その3) - ockeghem's blog
5/14の日記XSS対策:JavaScriptのエスケープ(その2) - ockeghem(徳丸浩)の日記に対して、id:hasegawayosukeさんからコメントを頂戴した。その内容は、JavaScriptに対応していないブラウザの場合に対する考慮が抜けているという趣旨だと理解した。 元の日記にも書いたように、私自身はJavaScriptの動的生成は(特殊な場合を除いて)好ましくないと考えているが、始めた以上は最後まで検討しようと思う。 解決すべき課題の整理 まず、解決すべき課題を整理しよう。元の日記では、JavaScriptを動的生成する(ただし、文字列リテラル内のデータに限る)場合のXSS対策として二段階のエスケープが必要であることを説明した。具体的には、(1)JavaScript文字列リテラルのエスケープとして、「"」、「'」、「\」のエスケープの実施、(2)HTMLとしてのエス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
