scrapbox 調査

認証とwebsocket周り

websocketは外部ドメインからでもつなげる、allowCredentialsも通る

ユーザー情報などは自称、ページidなどが分からないと編集出来ないのでまあ問題なさそう

自分の情報を取得するためのAPIは認証がちゃんとかかっている

----

ソースコード記法の問題

code:hello.txt

任意のファイルを出力可能

asciiのみでFlashファイルを生成するrosetta flashという手法が知られている。これはFlash Playerのアップデートで出来なくなった、ということになっているが、asciiのみのFlashの一部を0x80以上に置換することで引き続き有効なFlashとして再生することが出来る。

JSONPを使って攻撃できるという方法は概ね出来なくなったが、ある程度任意に文字列出力できる、かつ、バイナリを含めることが可能なAPIやfile uploadがあればflashの生成が可能。

X-Content-Type-Options: nosniffを使って防ぐことが出来る、ということになっているが、実はswfの中からswfを呼び出す機能を使うと、このnosniffによる制限が迂回されてしまうということが判明した。(Shibuya.XSS#8 kinugawamasatoのトーク)

scrapboxで出来ないか試してみたが、なかなかうまく行かなかった。ソースコード記法でバイナリを含めることが難しく、1byteだけバイナリを混ぜてもutf-8 validな文字に置換されてしまう。chromeだと再生がうまくいかなかった(URLLoaderでswfを呼び出したときにinitイベントが発生しない) Firefoxだと殆ど発生しないのだけど、まれにロードに成功することがあった。条件が不明。ロードに成功した場合は me.json を取得することで、外部サイトからログイン済みユーザーのメールアドレス等が取得可能。

修正方法は、nosniffが機能しないので、content-disposition:attachmentをつけるか別ドメインで表示する、ということになるが、attachmentはブラウザでその場で表示できず、downloadになってしまうので嬉しくない。nosniffに依存して添付ファイルの表示の安全性を担保しているサービスは多いので(nosniffも本来は不要でcontent-typeがちゃんとしてればHTML表示以外は問題起きない) Adobeに文句を言ってsecurity issueとして圧力をかけると良さそう。ファイルをtext/plainとして表示する機能を作っただけで危険になる、という状況は、どう考えてもFlash Playerの存在のほうがおかしい。

Flash Playerはコード実行など危険な問題の修正を優先して行っているので、こういったWebサイト作成者側に影響があるような問題は、長期間直らないことがある。主要なブラウザでデフォルト無効になるのを待つほうが早そうである。