ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
XSS対策に入力時エスケープは非常にややこしい
to-RさんのXSSの脆弱性を限りなくなくす方法を読んでなんかもにょもにょしたのでエントリーを書く。多分、to-Rさんはこれから書くことに関して理解してて、あの対策を行なってるのかもしれないけど、それでも書く。自分の勉強も兼てるので変なところがあれば教えていただけるとありがたいです。 入力時エスケープは非常にややこしい 確かに、入力値に必ずエスケープしておけば、XSS対策漏れにはなるかもしれない。けれど非常にややこしいことになる。 例えば、受け取ったデータの文字列に対して文字数制限のバリデーションを行なうときにわざわざアンエスケープの処理を行なわないといけないし、DBへの保存の際にもアンエスケープが必要になる。ブログとかでフォームから受け取ったデータのうち、一部のタグは許容するときとかもかな。 ベストの対策はアプリの性質に合わせたエスケープなんだけども、これって完全になくすにはかなりの几帳
入力時に文字参照に変換するのがよろしくない理由 | 水無月ばけらのえび日記
「Twitterのクロスサイト・スクリプティング(XSS)対策は変だ (www.tokumaru.org)」。文字参照に変換した状態で DB に格納しているというのは、けっこう良くある話だろうと思います。この手のエスケープしすぎによる化けは、twitter に限らず、よく見かけますので……。 ※HTML のエスケープに限らず、入力欄に \ を入れて検索すると \\ に化けて、検索ボタンを押すたびに \ が増殖していくという面白いシステムも良くありますね。 一昔前のフリーの掲示板 CGI などでは、フォームの値を読み取るところで < → < " → " のように文字参照に変換してしまうのが一般的でした。この手のアプリケーションは、 絶対に HTML にしかデータを出力しないフォームからの入力以外のデータを処理しない作者が一人で開発しているので、出力時の処理も把握しているという
XSSを修正しないという事 (Kanasansoft Web Lab.)
今読み返すと、あちこちに変な日本語が混じっていますね。 訂正するのも嫌らしいのでそのままにしておきます。 はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。 このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。 そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。 このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。 これを踏まえて以下記述します。 「#」ではじまるのがはてなブックマークのコメントです。 #2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？ #2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？ 申し訳ないです。
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rauru Blog » Blog Archive » SNMP で XSS