Shibuya.XSS アウトラインメモ
Shibuya.XSS テクニカルトーク#1 : ATND に参加してきたので、その時のメモ。
Shibuya.XSS
DOM Based XSSの傾向と対策 – mala
Shibuya.XSSで発表してきました – 金利0無利息キャッシング – キャッシングできます – subtech
機械的なスキャンで見つけづらいXSS
- location.hash経由で発火が多い、
- サーバ側にアクセスログが残りづらい
- ビーコンでlocation.hashを記録する事も可能だけど、実行順序で潰される事がある
location.hashでの問題
- XHR2
どんな時に見つけにくい
- パラメーターをパースして利用してる場合
- ソースを読まないと見つけにくい。
- 難読化されてるとしんどい
- レガシーコード
どうするのがいいのだろうか
- バリデーション?
バリデーションが必要な状況
- openにファイル名渡す -> パイプでコマンド実行可能
- ファイル開く関数とコマンド実行を分けて使うべき
- 役割に応じて「それだけを行うように」する
バリデーションが必要なライブラリ
- 直接使うときは安全に倒す
そもそも安全にすることを考える
- 外部リソース読み込めないようには無理
コーディング規約での対処
- jQueryの場合
- セレクタの使い方を徹底する
- findを使って$関数の直接使用を避ける
- $関数は汎用的すぎ
コーディング
- XHRのリクエストは必ず絶対パス+動的パス
- 絶対パスが/のみだと突破できる
- /api/的な感じに
問題点
- HTML5等で今まで安全だったかもしれないものが崩壊して、可能な攻撃が増える
DOM XSS撲滅装置
- location.hashにタグが会った場合は消す等
- その文字列を使わないことが保証されてるなら割りと効果的
- 広告やブログパーツ等、自分で治せないもの等の緊急的
- 潜在的なXSS
パスワードを盗めるか?
- ブラウザのパスワード自動入力機能でパスワードを盗める場合がある
- セッション乗っ取り + パスワード盗み
パスワードの盗み方
- 自動でフィルインされた値を読み取る
- 自動的に盗むことが可能
- 自動フィルイン + クリックジャッキング -> 半自動
- フォームの宛先を攻撃サイトに誘導
事例
?to=javascript:eval(location.hash)#攻撃コード
- ログイン後のリダイレクトのURL先でjavascript:を実行可能
対策
-
そのパスワードを入力するドメインをサブドメインで独立させる
- ログイン機能だけを持ったサブドメインを作成する
- 他のjsを入れない、厳しめのルール
フェールセーフ設計
- サンドボックス
- パスワードを入力するページは外部jsを完全排除するとか
- パスワード入力ページはそれ専用のサブドメインへ
ブラウザ側のリスク軽減
- XSSフィルタ
- パスワードの自動フィルイン対策
- 元々危険だったものが更に危険になる => 理解されないことが多い
攻撃パターン
- iframeで埋め込む -> サードパーティクッキー有効なら発動
- 短縮URL + replaceStateでURL偽装
- ポップアップWIndowとサードパーティ
ユーザー側の対策
- NoScript
- 複雑なルールを設定しないと安全に利用できない
-
攻撃者が嫌う設定を使う
- サードパーティクッキーオフ、ポップアップのブロク、リダイレクトの防止
- 初見のURLは全部シークレットモードで開くとか
まとめ
- DOM Based XSSはたくさんある
- XSSがあっても安全にすることを考える
焼肉、刺身
- XSS発見者には肉か刺身をおごる慣例(*人徳が必要)
x-autocompletetypeの実験 by はまちちゃんさん
- x-autocompletetypeのデモ
- http://hamachiya.com/junk/x-autocompletetype.php
サニタイズ言うぞキャンペーン – TAKESAKO
mixiの新着検索ページでXSSで1件
- いぬぼくxSS
7年前と少し違う状況
- jQuery
- XHR2
サニタイズ的なものが必要になる場合がある。
kintone
- ライブラリ除いて10万行ぐらい
社内勉強会
- jQueryは甘え
Closure Templateのエスケープ機能について
- サニタイズコンテント
- JavaScriptでHTMLのパーサー的に書かれてる
- 問題を起こしそうな文字列などが定義されてる
Closure Template – Contextual Autoscape
- JavaScriptエスケープとHTMLエスケープ等の区別をおこなってくれる
- CSS、属性値等で異なるエスケープを行う
- 無毒化とかを文脈依存で対処される
- http://d.hatena.ne.jp/teppeis/20120318/1332092081
オフレコ – 春山
- ベンチャーから始めると、フローの把握ができてない所が存在する
- そのフローの把握が重要
JS Array Hijacking with MBCS – hasegawa
Shibuya.XSS テクニカルトーク#1 開催しました。 – 葉っぱ日記
- Array形式のJSONをジャックする
- Firefox 修正済み
- UTF-8をShift-JISで解釈すると壊れた解釈をしてしまう問題
Mozillaはポテンシャル的な脅威にも対処してくれる
- Content-Typeとcharset をちゃんとつける
LT
mixi scrap Challenge
- 学生向けのセキュリティイベント
- 用意したmixiクローンサイトに攻撃してもらって脆弱性を見つけてもらう
イベント用に使ったサイト
- イベント用のmixiサイトをクローンしてXSSを探してもらう
-
日記ページにあるXSSを探して、スタッフアカウントに対して攻撃URLを送ってもらう
- 得点方式
問題
- ネギ男に、イラクとnicknameがalertされるURLを踏ませて下さい
- ネギ男に….
みたいな問題形式
実際のサービスのクローンを舞台にして
- 盛り上がった
-
より実践的な体験をしてもらえた
- XSSをみつけるだけではなくSNSの使用を考慮して実践的な内容になった
- 問題をつくやすかった
- git-grep “XSS” revertで過去に対応してXSS問題から引き出す
AjaxアプリケーションのXSS対応入門 – 徳丸
- 入門書にもAjax的な問題
- X-Content-Type-Options: nosniff
JSONハイジャック
- JSONを罠サイトからスクリプト要素を呼び出す
- 通常はただのデータなので、読み取りはできないはず…
- JSONハイジャックで読み取りができてしまう => 既にブラウザは対策済み
- Androidだとまだ発生する(4.0.3だと問題ない)
対策
- ヘッダチェックが無難
- あんまりいい方法がない
- 外部APIは基本的に信用しない
CSS HTML Attribute Reader – kyo_ago
The Sexy Assassinで紹介されてるCSS HTML Attribute Readerがどこまで危険か検証してみた http://bit.ly/HU74ad
- CSS Attributeでパスワードの取得 -moz-anyと合わせ技
- 外部からCSS書けるということ自体が問題
- :visited の履歴取得も最近のブラウザは対策されてる
ロングIPアドレス
- ドット無しでドメインを書くことができる
- ドットを無効化しても、数字だけでドメインを書く事ができるので問題が起こる場合があるかも
セキュリティ小ネタ – send
http://d.hatena.ne.jp/send/20120405/p1
rootkit
- rootやadminが使えなくなってた
-
対策
- 別の所からpsやkill等のバイナリを持ってきてきて殺してた
-
chattrされてた
- 細かい改ざんをやっていた
- 対策として改ざん検知などの導入で数ヶ月使った
よく狙われる脆弱性
JSだとimg onerror
- src属性指定後すぐ発火してしまう
- ドキュメントに追加しなくても発火してしまってる(高速)
- onerrorは除去しにくいので対策しにくい
余談
- 最初にサブドメイン以下にtest. やadmin.とかを見る
- crossdomein.xml
パスワード入力はやっぱり別ドメインに分けるべき
DOS
くよくよくよくよ
- セキュリティを使うと守ると考えるは違う
メモ : Mou + Github.css
お知らせ欄
JavaScript Primerの書籍版がAmazonで購入できます。
JavaScriptに関する最新情報は週一でJSer.infoを更新しています。
GitHub Sponsorsでの支援を募集しています。