第44回HTML5とか勉強会「HTML5とセキュリティ」

第44回HTML5とか勉強会「HTML5とセキュリティ」 に参加してきたのでメモ。

今から始めるHTML5セキュリティ – 松本悦宜

  • 一般社団法人JPCERTコーディネーションセンターの紹介
  • 「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」
  • HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
  • アジェンダ – 報告書の概要
    • JavaScript API
    • XHR
    • ブラウザが実装してる関連機能
  • HTML5は開発者にとって非常に便利
    • => 攻撃者にとっても便利
  • 表現の幅が広がる
    • 攻撃の幅も大きく広がる
  • HTML5とセキュリティ
    • 従来のHTMLでは影響がなかったものも、HTML5で脆弱性になってしまうものもある。
    • それの周知

XHR Lv2

  • 従来はJavaScriptを読み込んだオリジンのみと通信が可能
  • HTML5(XHR Lv2)からクロスオリジンに対応
  • サーバ側の同意が必要
    • Access-Control-Allow-Origin
  • HTML5未対応ブラウザだとリクエスト自体が行われないが、対応ブラウザではできる
  • サイト内にオープンリダイレクタがあると任意のサーバと通信が出来てしまう
  • 問題と対策
    • クッキーを使ったアクセス制御
    • オリジンチェックをちゃんとする

新要素のJavaScript実行

  • video , Audio
  • img以外にもonerrorでできるようになる
  • formaction

type="email"

  • メールアドレスのチェックする input の属性
  • typeでチェックしても、それ以外の値がこないとは限らない
  • サーバ側でもちゃんとチェックをするべき

iframe sandbox

  • <iframe sandbox> で読み込む事をしても、iframeの中身自体は開けるのであんまり関係ない

セキュリティの関連機能 CSP

  • CSP
    • 読み込み可能なリソースのオリジンをレスポンスヘッダで指定出来る
    • XSS の可能性を低減する
    • 多種多様な制限が指定出来る
    • default-src – ディレクティブ
    • self -　ディレクティブソース ドメインや予約語がある
  • report-uri
    • CSPに違反した内容のレポートを送信できる
    • 違反レポートはJSONで送られる
  • 開発者が書いたものも結構動かない事があるのでちゃんとチェックする

Q&A

  • CSPを適応したコンテンツをキャッシュした場合どうなる?
    • => 不明
  • XHRとかの内容に対しても適応される
    • 基本サブリソースについても制限される

本当は怖いクライアントサイドキャッシュポイズニング – 吾郷 協

キャッシュポイズニング

  • キャッシュに攻撃コードを仕込んで継続的に攻撃する
  • クライアント側のキャッシュポイズニングについて

モバイル端末の普及

  • オフラインになる可能性が高いのでキャッシュが重要
  • 貸し借りの時のアカウント管理

ApllicationCacheが危険?

Application Cacheのキャッシュポイズニング

  • ユーザーが信用出来ないネットワークを使ってるのが前提
  • 既に危険だけど、Application Cacheによって被害が広がる

FAQ

  • 通信内容を差し替え出来るならAppCacheは無関係?
    • AppCache使っているとネットワークを変えても持続する
    • 攻撃だけではなく、監視ができる
  • SSLを使えば大体安全

攻撃者の気持ちになって考える

コンテンツ提供側の気持ちになって考える

  • 攻撃をうけてるのか判断出来ない
    • 確認要のコードも、攻撃者側が差し替え出来てしまう
  • 攻撃を開始したい場合、毎回必ずキャッシュを破棄する実装が必要
    • キャッシュを捨てる事になる…

OWASP/JPCERT の内容を見て

  • Application Cacheを使う前に確認しても、その部分を書き換えてしまわれると意味ない(信頼出来ないネットワークにおいて)

ブラウザベンダ

  • FirefoxはユーザーにApplication Cacheの利用を確認するけど、キャッシュポイズニング対策とは関係なさそう

MitMについて

どういう攻撃アプローチが考えられる?

  • キャリアの提供するAPの振りをすることはできないのか?
  • キャリアの提供するAPの設置店舗が悪意持ってないか?
  • 公衆無線LAN系
  • 人通りが多い所に自由に繋げられる無線LANを置いた場合

Bypass SOP in a time of HTML5 – はせがわようすけ

  • HTML5時代のSOP破り
  • Origin
  • XHR

Origin

  • RFC6454
  • スキーム + ホスト + ポート
  • ポートが入るのでportでオリジンは別として認識される

Same Origin Policy

  • SOP
  • オリジンが異なる場合に様々な制約
    • XHRの読み取り
    • Localsstorageの読み書きの範囲等色々
  • クッキー、ベーシック認証などはOriginベースじゃない

CORS

  • オリジンを超えてリソースを共有するための統一的なルール
    • XHR、 img +Canvas 、Web Font等
  • (enable-cors.org の人が書いてる書籍とかあるよ Manning: CORS in Action)

XHR + CORS

  • XHRにリクエストに Origin ヘッダーがつく
  • レスポンスに Access-Control-Allow-Origin ヘッダがある
  • クッキーをXHRで含めたい
    • xhr.withCredentials = true で送信先に指定したURLのクッキーが渡せる

CORS + Image

  • img要素に crossorign="anonymous" などでoriginを付けられる
  • 許可があると、表示だけではなく読み込み(画像の中身も取れる)
  • crossoring="use-credentials"　でクッキーの許可を指定できる
  • Access-Control-Allow-Origin : * 誰からも読み込みできるので、機密情報を含むコンテンツはダメ
  • * を指定した時にクッキーの指定を混ぜると不可思議な挙動をする

preflight – 新しい機能を使うときにサーバに確認するような仕組み

XHR

  • XHR Lv2でクロスオリジン通信が可能に
  • XHR周辺に税じゃy区制も多い
  • 攻撃者が用意した悪意あるコンテンツをうっかり表示してXSS等

意図せずクロスオリジン通信 -> XSS

  • location.hash.substring(1) に対してリクエストしてる場合
  • URLでリクエスト先を指定できるので、悪意ある所に通信させられる
  • 固定/ホワイトリストを持って通信先を制限する

意図せずクロスオリジン通信 -> データ漏えい

  • サーバ側で意図してないクロスオリジン通信
  • リクエストヘッダの Origin: で送信元を確認
  • Access-Control-Allow-Origin のみで 送信元を制限してる
    • ブラウザ以外だと自由にOrigin指定できるし、Originはユーザーの認証にならない
  • 対策は普通にクッキーを使って認証する

Ajaxデータを直接開いてXSS

  • JSONを直接開いた時にIEがHTMLとしてスクリプトを実行出来てしまうバグっぽい脆弱性
  • JSONならエスケープできなくない
  • 他のフォーマットだとエスケープは難しい
  • 対策 : X-Content-Type-Options: nosniff
    • コンテンツの中身ではなくヘッダーだけを見てフォーマットを認識するようになる
  • 攻撃パターンとしてはよくある
    • 攻撃出来るコンテンツを作らせて、HTMLとして開かせる

Ajaxデータ内の機密情報を取得

  • JSONハイジャッキング
  • JSON配列をVBScriptとして読み込み
    • 失敗 -> エラーメッセージに配列の内容がでてしまう
  • 対策: X-Content-Type-Options: nosniff をつける

セキュリティ関係のレスポンスヘッダ

  • X-XSS-Protection
    • XSS保護機能の制御 – IE, Chrom , Webkit
    • 0,1, mode=block(真っ白にする)
    • 無効にするのは基本なしで、 X-XSS-Protection:0でそのページだけを無効にするべき

X-Content-Type-Options: nosniff

  • Content-Typeを厳密に扱う
  • 非HTMLをHTML扱いしない
    • JSONをHTMLとして認識しない
  • 基本的に副作用ないので入れておいていい。
  • JSONとJSONPが混ざったAPIだけ上手くいかないけど

X-Frame-Options

  • クリックジャッキング
    • 標的サイトを透明に重ねて、意図しないクリック等を引き起こす攻撃
    • ソーシャルエンジニア的
  • X-Frame-Options で対策する
    • 全ての埋め込みを禁止する DENY
    • SameOrigin以外からの禁止
    • 指定Originからのみ許可
      • 一つのOrigin のみ しか指定できない
      • Firefoxは仕様とは違って複数受けられる
      • 複数のOriginをしたい場合は、パラメータでお茶を濁すぐらいしかない

CSP

  • ヘッダで指定されたソースからしか画像やJSを読み込めなくする
  • Chrome拡張やFirefoxOSではおなじみ
  • 実際の運用は大変

X-Download-Options

  • X-Download-Options: noopen
  • IE8移行でダウンロード時の開くボタンを非表示にする

Strict-Transport-Security

FAQ

その他

イベントに参加する前にSoba.jsでBrowserifyとgulpの触感について発表した(かなり雑で大したこと書いてないです)

メモ

  • MarkdownLife

FAQ

  • Q: JSer.info x周年イベントとかやらないの?
    • どっかに呼ばれればやるかもしれない
  • Q: JSer.info に記事載せて欲しい的な要望ってとおるの?
  • Q: JSer.infoって共同編集者とか募集してるの?
    • JSer.infoについてで書いてますが一応仕組み的には出来ます
    • ただ何をどうしたらいいのかよくわからないのでIssuesを立てましょう