Firefox 用の拡張機能を公開するサイト兼駄文(目指せ!! 打倒 真鍋かをり)norah'# - "You do your job. If you get results and people thank you for it, so much the better" norahmodel.exblog.jp トップ | ログイン US の Bugzilla で報告したところ(もじら組の Bugzilla に報告した所24時間経っても連絡が来なかった)、それは脆弱性ではなく仕様だと言われたので、これがいかに危険か開示します。 複数のバージョンのプラグインがインストールされている場合 Firefox はプラグインのバージョンでは無くプラグインのインストール先によって、どのプラグインを優先して使うのかを判断してしまう。 これはシステムの管理者が一括してプラグインの管理をする場合や、開発
本日起こった、ethna.jp や、jp2.php.net のサイトに、ActiveX や Flash の脆弱性をついた攻撃をする html を読み込む iframeを差し込まれるというトラブルが発生しました。 ちょっとかかわったので、流れを記録として残しておこうと思います。 ethna.jpの第一報 10:30ごろ、%Ethna のIRCチャンネルで、mikaponさんから、mlの保存書庫に不正な iframe が差し込まれているという報告がありました。 10:31 (mikapon) おはようございます 10:32 (mikapon) ethnaのサイトなんですが 10:32 (mikapon) mlの保存書庫の所にiframe埋め込まれてませんか？ ちょうど出社中の時間で、この発言をリアルタイムでは見れなかったのですが、土曜日に tiarra を入れたおかげで、発言を見ることが出来ま
iframeが仕込まれています。 918 ： ニーチュ(福岡県)：2008/06/02(月) 07:34:44.02 id:fDXxYyKb0 憶測も交えてもうちょっと。長くなるので分けます pp■cool0■biz/bmw/am1■htm?34-8681 ゆずソフトのサイトにiframeで仕込まれていたURL。以下の各種URLを呼び出す。 pp■cool0■biz/ax14■htm VBScriptコードを生成する。IE以外は関係ない。 ActiveXコントロールの脆弱性をつくもの。 2006年の脆弱性であり、Windows Updateを行っていれば感染することはない。 ↓参考URL http://www.microsoft.com/japan/technet/security/bulletin/MS06-014.mspx pp■cool0■biz/re10■htm JavaScrip
昨日の日記に対して、id:ikepyonさんからトラックバックを頂戴した。内容はそちら(Tipsと考え方とXSS対策)を読んでいただくとして、興味深いテーマなので少し突っ込んでみたい。 # 日によって「です・ます」で書いたり、「だ・である」で書いているのは気分の問題なので、あまり気にしないでいただきたい Tipsだけでなく、物事の本質を見極め、何が危険で、何が安全なのかということを考える必要があると思う。 昨日の記事は、(一般的な)XSS対策として、どの文字をエスケープするのが「本質的」だったかを考えたかったのであって、あれをTipsととらえると確かに失敗する。 JavaScriptのスクリプトなどが入っている場合も昨日と同じ方法論で考えることは可能である。まずはこれを検討してみよう。 スクリプトがonXXXのイベントハンドラとして記述されている場合 この場合は、HTMLタグの属性値として
ITproの連載中に、id:hasegawayosukeさんから以下のようなコメントをいただいていました。 対策遅らせるHTMLエンコーディングの「神話」：ITpro - 葉っぱ日記 全ての文字をエスケープしようなどと非現実的なことは言わないけれど(とはいえMicrosoft Anti-Cross Site Scripting Libraryのようにほとんど全ての文字を実体参照に置き換えるものもあるので、あながち非現実的とも言えないのかも知れない)、エスケープ対象を「'」「"」「<」「>」「&」の5文字に限定しているのは何かこの記事に書かれていない理由があるはずだと思ったからです。 はてぶの方は見ていましたが、日記の方を見落としていまして、お返事が遅れました(_ _)。 なぜ、「<」、「>」、「&」、「"」、「'」の5種類の文字をエスケープするのかについては、色々考えるところがあります。
前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“UTF-8”を指定することをお勧めします。サイトによってはSJIS、EUC-JP
Takayuki Nakamura's blog: OWASP Top 10 2007
2007年5月20日 OWASP Top 10 2007 http://www.owasp.org/index.php/Top_10_2007 PDF版↓ http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf 正式版が公開された。これまでのコンテンツを書き直して、それぞれに対しての防御方法についてまとめたもの。 こんな感じ↓ いつものごとく、訳は適当。意訳。加筆あり。抜けもあるだろうから、上記ＵＲＬから本物のコンテンツを見て欲しい。 Cross Site Scripting (XSS) 確認方法 データをクライアントに返す前に、入力チェックやHTMLエンコードが行われているか確認する。 自動検査の場合 自動検査ツールは、reflected XSS（パラメータ操作により入力したスクリプトがレスポンスに反映される形式のXSS）は検出できる
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
