実際に危険な例 データの変更が出来るドメインに XSS がある 秘匿されたデータが閲覧できるドメインに XSS がある 声優の住所を公開するサイトがある 実際には危険ではない例 ameblo.jp に XSS がある Twitter クライアントの Consumer Key と Consumer Secret を第三者が取得できる 声優の携帯電話の情報をブログからまとめて公開するサイトがある 後者は大して危険ではないですし、こういうものを危険だ危険だといっていると真に危険なものについて話している人の声が届くべきところに届かないことになります。 ところで実際のところ、インテリジェンスなるもの大半は公開情報を検索可能な形に編集し意味のあるデータを作成する行為であり、声優の携帯電話に対してインテリジェンスの暴力を声優に翳すなと言う批判は成立するのだと思います。 例えば鹿野優以の使っていた携帯電話
最近僕が発見し、修正されたTwitterの脆弱性を3つ紹介します。 1.旧Twitterの文字列処理に絡んだXSS 去年の夏くらいに、Twitter Web上で € 〜 ÿ の文字参照が含まれるツイートをXMLHttpRequestで読み込んだ際に表示が乱れるという問題に気付き*1、その時はこれは脆弱性には繋がらないだろうという判断をしたのだけど、今年の4月になって改めて調べたところ貫通しました。 表示が乱れるというのは、€ 〜 ÿ の文字参照が含まれるツイートがあると、一部の文字が\XXXXの形式に化けたり、ツイート周辺の「"」が「\"」になったりするものだったのですが、今回は「"」が「\"」になる点が脆弱性を発生させていました。 この条件でXSSさせようと思ったら、ツイートを細工してURLや@や#などオートリンクが作成される部分にうまいことイベン
2010年09月22日21:30 カテゴリLightweight Languages 構造化テキストの間違ったエスケープ手法について 昨晩のtwitter XSS祭りは、ふだんもtwitter.comは使わない私には遠くの祭り囃子だったのですが、せっかくの自戒の機会なので。 Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について 正しいアプローチは、全てのルールを同時に適用することです。 これは残念ながら(おそらく)必要条件であっても十分条件ではありません。 こういう(かなりええかげんな)正規表現でtweetをparseしていたとします。 re_http = '(?:https?://[\\x21-\\x7e]+)'; re_user = '(?:[@][0-9A-Za-z_]{1,15})'; re_hash
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
