まとめ http://togetter.com/li/622571
一般社団法人JPCERTコーディネーションセンター 松本悦宜さん
JPCERT/CCは昨年10月に「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」を公開しました。本セッションでは、この調査報告書をもとに、Webアプリケーション開発者が 知っておきたいHTML5および関連する周辺技術のセキュリティ対策についてご紹介します
Html5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書
従来影響なかったものが、html5対応によって脆弱性になったり 検証/教育が不十分だったり
- XHRがクロスオリジン対応に
pjax のときとか。 http://example.com/#//evil.com/
以前は、単にJSのエラーだったが、HTML5 からは実行される。 Ajax通信先のリストははホワイトリストにしてコーディングすべし。
-
新属性について button[formaction] + autofocus でスクリプト実行
-
ブラウザサイドの input[type] バリデーションはあてにしない 攻撃者がHTMLを書き換え可能なため サーバー側バリデーションは相変わらず必須.
-
iframe sandboxes 抜本的ではないので、セキュリティ対策として使うべきではない
-
Contents-Security-Policy ヘッダ サイト内の細かい動作を指定できる 「インラインJSの無効」など 脆弱性対策には有効だが、実装との折り合いが難しそう
吾郷 協さん
「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」でも紹介されているOffline Applicationのキャッシュポイズニングですが、内容に疑問があったため個人的に調査してみました。ここでは調査から得られた具体的な攻撃シナリオ、ユーザ、ベンダーそれぞれの対応方法、リスク評価、「調査報告書」に対するツッコミを紹介したいと思います。
Html5 Security Cheat Sheat. Owasp
Appcache を使っていると、リクエストが改ざんされた際、被害が拡大する
- 攻撃コードの永続化
- サーバーにリクエストが飛ばない事によって検出が困難になる
- クライアントが気づきにくい
でもこれって、 Appcache というより MitM 攻撃の話じゃね？ リクエスト改ざんできたら Appcache とか以前の話じゃね？ サイトは常時SSLにすべきか
ネットエージェント株式会社 はせがわようすけさん HTML5による処理量のクライアント側へのシフトに伴い、攻撃者の狙う対象もクライアント側、とくにSame-Origin Policyを迂回する受動的攻撃へ
Cors. Cross origin Resource Sharing
img cross origin 属性
- XHR がクロスオリジン対応に Origin ヘッダは telnet とかでいくらでも偽装可能
IEは死ぬべき。
IE9でもContents-Type ヘッダよりも拡張子が優先される http://example.com/hoge.json/a.html みたいな
window.onerror = function (errMsg) { // errMsg を攻撃サイトに送る }
とかでセキュア情報をとれる。
X-Contents-Option. No-sniff ヘッダをつけると、このへんの挙動をコントロールできる。 (json と jsonp で同じエンドポイントを使っている時は header も書き換えないと動かない)
「XSSフィルターは無効に」させるECサイトは死ぬべき。
その他、便利なレスポンスヘッダ
- x-frame-option
- iframe のオリジンをチェック
- X-download-options
- IEの「開く」ボタンによる脆弱性対策
- Strict-Transport-Security
- 常にHTTPSでアクセスさせる