色を色で見ないで｜1 pixel｜サイバーエージェント 公式クリエイターズブログの、特に「主役は特別」の項がおもしろかった。これぐらいなら、ぼくにも実践できる。各ページの主役が何なのか、あらためて考えるきっかけにもなる。
さっそく、FirefoxとGoogle Chromeに(un)clrd – The world wide web in black and white!を入れてみた。しばらくグレースケールの世界で暮らしてみるのも楽しそうだ。
2014年02月
クックパッドのサイト上で、レシピへのリンクテキストに、つくれぽ件数を追加するユーザスクリプトです。
以下の点を直しました。
- Google Chromeでも動くようにした
- つくれぽ件数が1000件を超えると「0件」と表示されるバグを修正
ぼく自身はクックパッドを見ないので、不具合があるのに気づきませんでした。何かお気づきの方は遠慮なく @iwamot まで、癒し系の動物画像を添付の上、お知らせください。
使ってはいけない理由の一、「セッション cookie を HttpOnly 付きで発行している場合」については、高木さんの書かれている「3. cookieは漏れないが、HTMLテキスト（hiddenパラメタを含む）は漏れる脆弱性」であり、「hiddenパラメタにcookieと同じセッションIDを入れておくことが新たな脅威を生むことはない」。
使ってはいけない理由の二、「BREACH attack の影響を受ける場合」については、「4. cookieは漏れないが、hiddenパラメタは漏れ、しかしそれ以外のHTMLテキストは漏れない脆弱性」にあたる。この脆弱性を放置するのであれば、『「セッションIDをそのままhiddenに入れないほうがよい」という理屈は成り立つ』。
ただ、海老原さんの書かれているように、「この場合はまず BREACH への対策をするべき」だ。セッションIDと同じでなかろうと、漏れてしまっては、CSRF対策用トークンの意味がない。
そのうえで、また「著しく特殊な脆弱性が将来生ずる可能性があると心配するならば」、「セッション ID を SHA-2 ファミリのハッシュ関数あたりを通して」使えばよい。
2014-02-19
HTMLに埋め込まれたCSRF対策用トークンが漏れやすいのであれば、セッションIDと同じでなかろうと、そもそも埋め込むべきではない。「ソーシャルエンジニアリング的な手法」経由のCSRF攻撃なら受けても仕方がない、という判断もありえるだろうが、僕はいやだ。
対策は簡単だ。フォーム送信時に、Cookieに保存されたセッションIDをJavaScriptで参照し、パラメータに加えるだけでよい。「Kazuho@Cybozu Labs: CSRF 対策 w. JavaScript」に書かれているとおり。スクリプトが無効のクライアントには申し訳ないが、それ以外の対策が思いつかない。
「CSRF対策用トークンをHTMLに埋め込んでもいい時代は終わりつつある」。と、まとめてみた。
2014-02-20
Webアプリの開発者が気にすべき点は以下の通り。
- CookieにHttpOnlyを付けるべきかどうか
- XSSへの保険的対策として付けるべき
- XSS脆弱性がなければ問題ないのだから付けなくてよい
- HTMLへのセッションID埋め込みを避けるべきかどうか
- 漏れやすいから避けるべき
- 漏れにくいから埋め込んで構わない
- HTMLへのCSRF対策用トークン埋め込みを避けるべきかどうか
- 漏れやすいから避けるべき
- 漏れやすいが影響度は低い（あるいは軽減できる）から埋め込んで構わない
- 漏れにくいから埋め込んで構わない
1-1を採るなら、2-1、3-1または3-2を採るのが自然だ。教科書的には、こちらを選ぶしかないように思う。
1-2を採る場合、XSS以外によるHTML漏洩の可能性をどのくらい見積もるかによって、2と3の選択肢が変わってくる。漏れやすいと思えば2-1、3-1または3-2、漏れにくいと思えば2-2、3-3。
2014-02-20 #2
まだ論点があるのか。
- Cookieが漏洩した場合に備えて保険的対策を講じておくべきかどうか
- 漏れやすいから講じるべき
- 漏れやすいが根本的対策はないから（あるいはユーザの利便性を損なうから）講じなくて構わない
- 漏れにくいから講じなくて構わない
もう、どうしたらいいのかね。1-1、2-1、3-2、4-2あたりが時代の趨勢なのか。
- 1-1.
- CookieにはHttpOnly属性を付ける
- 2-1, 3-2
- CSRF対策用トークンはHTMLに埋め込むが、セッションIDそのままは不可
- 4-2
- CookieからのセッションID漏洩は気にしない
2014-02-21
セキュリティの専門家の間でも見解が分かれてしまうのだから、セキュリティにばかりかまけていられないWebアプリ開発者は、えいや、と自らの信じるところを選ぶしかない。Webセキュリティ、実にめんどうくさい。
プロフィール
ENECHANGE株式会社VPoT兼CTO室マネージャー。AWS Community Builder (Cloud Operations)。前職はAWS Japan技術サポート。社内外を問わず開発者体験の向上に取り組んでいます
最新記事
アクセスの多い記事
カテゴリ別アーカイブ
月別アーカイブ
ブログ内検索
