Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について
先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い（テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え）ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り
Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について
昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文（プレインテキスト）ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう？ まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか？ それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか？ それだと、@ を含む URL があった場合に
CSSクロスドメインの情報漏えいの脆弱性「CSSXSS」とは ― ＠IT
あるWebページにアクセスしたら、自分のYahoo! JAPAN IDやHatenaのID、mixiで使っている名前などが表示された。何の縁もゆかりもないページにこれらのプライベートな情報がなぜ表示されてしまったのだろうか。 これは「CSSクロスドメインの情報の漏えいの脆弱性（CVE-2005-4089）」という、Webブラウザがスタイルシート（CSS）を呼び出す機能にある脆弱性を利用した攻撃だったのだ。この脆弱性は通称「CSSXSS（CSS Cross Site Scripting）」とも呼ばれている。 CSSインポート時にCSS以外のファイルがテキストとして読み込める 最近のWebページは、文書の構造をHTML形式で記し、フォントや色やレイアウトなどの視覚的な表現をスタイルシートで記述するというHTMLの仕様に従っていることが多い。 HTMLファイルから外部のスタイルシートを呼び出すた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
