Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

そろそろ押さえておきたい AngularJSのセキュリティ

22,651 views

Published on

ng-mtg#6 AngularJS勉強会の発表資料です。

Published in: Technology
  • Be the first to comment

そろそろ押さえておきたい AngularJSのセキュリティ

  1. 1. そろそろ押さえておきたい AngularJSのセキュリティ ng-mtg#6 AngularJS勉強会 2014年7月25日 (1.3.0-beta.16対応版)
  2. 2. 西村 宗晃 a.k.a. nishimunea html5j Webプラットフォーム部 部員 HTML5 Experts.jp コントリビューター セキュリティキャンプ全国大会 2014 講師 FxOS コードリーディング 部員 1
  3. 3. 2
  4. 4. 3
  5. 5. 4 ノウハウを共有して、様々なプラットフォームで 動かすための知識を培おうではないか! WebはPCの世界を抜け出し 様々なプラットフォームで動き始めています by めこ部長
  6. 6. 本日お話する内容 5 AngularJSで対策できる脆弱性とその実装方法 • DOM Based XSS • Cross-Site Request Forgery (CSRF) AngularJSでは対策できない脆弱性 (スコープ外) • サーバ側での対策が必要となる脆弱性 • ブラウザやプロトコル由来の脆弱性 ※CSRFはサーバ側での対策を要しますが今回の発表ではスコープ外とします
  7. 7. DOM Based XSS
  8. 8. XSSの種類 • サーバ側で発生するXSS - 反射型XSS - HTTPのリクエストに含まれるスクリプトが、 レスポンスのHTMLにそのまま埋め込まれることで発生 - 持続型XSS - HTTPのリクエストに含まれるスクリプトが一旦サーバに保存され、 そのデータを元にHTMLを出力する際にスクリプトが埋め込まれることで発生 • クライアント側で発生するXSS - DOM based XSS - 外部から取得したデータを元にJSでHTMLを動的生成する際に、 データに含まれるスクリプトがDOMツリーへ出力されることで発生 7 ※DOM based XSSも反射型と持続型に分類すべきという意見もあります https://www.owasp.org/images/f/f4/ASDC12-Unraveling_some_of_the_Mysteries_around_DOMbased_XSS.pdf
  9. 9. 参考:angularjs.orgにあった反射型XSS 8 ※撮影のためIEのXSSフィルターを無効化しています。本件はGoogleに報告し、既に修正済みです そのままレスポンスとして出力される URLに仕込んだスクリプトが… <script>alert(‘XSS’)</script>
  10. 10. DOM Based XSS発生のメカニズム 9 Web Messaging $location Referrer Web Socket $cookies $http, $resource ngModel Web Storage ngBindHtml ngInclude element.innerHTML document.write jQLite.html jQLite.append window.eval new Function XSS スクリプトを 含むデータ データバインドで DOMを生成 攻撃者 被害者 データの入力経路 DOMツリーへの出力経路 ※図中の入力経路、出力経路は一例です
  11. 11. DOM Based XSSの対策 10 • 動的にDOMを生成する際は信頼できるデータのみを使用する - そのままDOMに挿入しても安全だと開発者が保証できるデータのみを使用する • それ以外の場合は、データを出力するコンテキストに応じた対策を施す - HTMLの要素内容としてデータを出力する場合 - createTextNodeでテキストノードとして出力する(またはHTMLエスケープ) - HTMLマークアップとして出力する際は、スクリプトが実行される 恐れの無い要素と属性のみを許可する - HTML要素の属性値としてデータを出力する場合 - setAttributeで属性値として出力する(またはHTMLエスケープ) - イベントハンドラ属性などのスクリプトが実行可能な属性値は動的に生成しない - URLを出力する際は安全なURLであることを検証する - http(s)://で始まるURLかホワイトリストに該当するオリジンのみを許可する
  12. 12. Strict Contextual Escaping (SCE) 11 • コンテキストに応じたエスケープ機能を提供するAngularJSの機能 • AngularJS v1.2以降ではデフォルトで有効 利用可能なコンテキスト コンテキストの適用例 HTML <div ng-bind-html=" HTML "></div> CSS <div style=" CSS "> URL <a href=" URL ">Link</a> リソースURL <script src=" リソースURL "> JS <div onclick=" JS "> ※ここで言うエスケープとは指定されたコンテキストでデータが適切に 表示されるように文字列を変換する処理の総称を意味します。 詳細は https://docs.angularjs.org/api/ng/service/$sceを参照
  13. 13. 明示的な信頼に基づくエスケープ処理 12 • 安全が保証できる値に明示的な信頼を与えることができる - 信頼されていない値は自動的にエスケープして出力される - 逆に言えば、安全が保証できない値に信頼を与えることは脆弱性につながる var input = '<a href="javascript:alert(1)">Link</a>'; console.log($sce.getTrusted($sce.HTML, input)); var trustedData = $sce.trustAs($sce.HTML, input); console.log($sce.getTrusted($sce.HTML, trusted)); エスケープして出力される <a>Link</a> 信頼を与えた値はそのまま出力される <a href="javascript:alert(1)">Click</a> 値に明示的な信頼を与える
  14. 14. データバインド時にコンテキストを自動判別 • $sceを中心に複数のモジュールが連携してデータのコンテキストを自動判別 13 $compile • テンプレートを解析してexpression 展開箇所のコンテキストを判別。判 別したコンテキストに応じたエス ケープ処理を$interpolateに指示 • 各ディレクティブのtemplateURLを $sceでエスケープ • ディレクティブの属性値に含まれる URLを$$sanitizeUriでエスケープ • イベントハンドラ属性のexpression 展開を検出&回避 $parse • expressionを解析して危険なオブ ジェクトの参照を検出&回避 $$sanitizeUri • URLのエスケープ機能を提供 $interpolate • コンテキストに応じたexpressionの 解析機能を提供 • expressionで展開されるデータを $sceでエスケープ $sce • リソースURLとHTMLのエスケープ 機能を提供 $sanitize • リソースURLとHTMLのエスケープ 機能を提供 • HTMLの属性値に含まれるURLを $$sanitizeUriでエスケープ $sceDelegate • $sceの主要機能を実装 プロバイダ使用関係
  15. 15. • AngularJSではデータをHTMLとして出力する手段が制限されている - HTMLを出力できるのはng-bind-htmlと<iframe srcdoc>のみ - その他のデータバインドはデータをテキスト値として出力する - 例:ng-bind, <div>{{expression}}</div> HTMLに対するデータバインド 14 • スクリプトの実行可能なHTML要素や属性は除去される(サニタイズ) - 内部処理に$sanitizeを使うのでngSanitizeモジュールをDIする必要がある - スクリプトが実行される危険性のあるHTML要素や属性は削除される - 例:<script>alert(‘XSS’);</script><b>Hello</b> World 危険な要素は除去される var app = angular.module('myApp', ['ngSanitize'] ); ※ngSanitizeモジュールをDIしないとunsafeエラーが発生します https://docs.angularjs.org/#!/error/$sce/unsafe
  16. 16. HTMLに対するデータバインド 15 • サニタイズにはngSanitizeのホワイトリストが使用される - ホワイトリストに無いHTML要素や属性は削除される - 安全な要素でもホワイトリストに含まれていないものがある - <video>などはリストに無いので削除対象となる - 属性値に不正なURLが含まれる場合は属性ごと削除される - 全てのURLが検査対象ではない - background, cite, href, longdesc, src, usemap属性のみが検査対象 - つまり<html manifest>, <video poster>などのURLは検査対象とならない - 例:<a href="javascript:alert('XSS');" >Link</a> ※ホワイトリストの詳細は$sanitizeのスクリプトコードを参照 https://github.com/angular/angular.js/blob/master/src/ngSanitize/sanitize.js href属性はホワイトリストで許可されているが 不正なURLが含まれているので削除される
  17. 17. HTMLに対するデータバインド 16 • HTMLのバインド時はexpressionによる文字列の結合が禁止される - expressionの解析処理が複雑化することによりミスが生じ、 XSSを許容するケースが生じる可能性があるため - expressionの解析ミスによりJSが実行できてしまう問題が実際にあった <form ng-attr-action="{{'javascript:'}}alert(1)"><button>XSS</button> ※攻撃方法および攻撃可能バージョンの詳細は以下のサイトを参照 http://code.google.com/p/mustache-security/wiki/AngularJS 結合すると javascript:alert(1) となるので本来は無害化されるべき
  18. 18. • AngularJSはCSSのエスケープをサポートしていない - style要素やstyle属性に挿入したデータはそのままCSSの構文として出力される - 最近のブラウザではCSSの構文でスクリプトを実行できないためと思われる CSSに対するデータバインド 17 • IEのQuirksモードではAngularJSの実行が禁止される - CSS expressionsによるJSの実行が可能であるため <style>body {color:expression(alert(1));}</style> QuirksモードではCSSの宣言で JSを実行することができる ※以前はCSS expressions以外にもOperaの-o-linkプロパティで JSを実行する方法がありましたが現在は使えません http://html5sec.org/#9
  19. 19. • ホワイトリストに合致しないURLは無効化される(サニタイズ) - aHrefSanitizationWhiteList - <a href>に指定可能なURLのホワイトリスト - http:, https:, ftp:, mailto:, tel:, file:で開始するURLのみを許可 - imgSrcSanitizationWhiteList - <img src>に指定可能なURLのホワイトリスト - http:, https:, file:, blob:, data:image/ で開始するURLのみを許可 - 上記のホワイトリストに合致しないURLは頭にunsafe:を付けて無効化される - 例:javascript:alert(1)  unsafe:javascript:alert(1) URLに対するデータバインド 18 • ホワイトリストは変更可能 - $compileProviderがホワイトリストを参照/変更する関数を提供している ※Firefox OSアプリで使う場合は「app:」を、Chromeアプリで使う場合は「chrome-extension:」を ホワイトリストに追加する必要があります
  20. 20. • ホワイトリストとブラックリストに基づいてサニタイズされる - ページを構成するリソースを取得する際に適用される - img以外のsrc属性、<form action>、SVGのxlink:href、ng-include、 $httpや$resourceの取得先URL、ディレクティブのtemplateUrlプロパティ - ホワイトリストとブラックリストを用いてサニタイズする - デフォルトではページと同一オリジン('self')のみを許容 - URLコンテキストより厳しい制限がかかる リソースURLに対するデータバインド 19 • ホワイトリストとブラックリストは変更可能 - $sceDelegateProviderが両リストを参照/変更する関数を提供している
  21. 21. • ホワイトリストにはワイルドカードを指定できる - リストには「*」と「**」という2種類のワイルドカードが指定できる - ** は全ての文字にマッチする - ** はURLの末尾のみで使用する - 安全な例  http://example.com/templates/** - 危険な例  http://**.example.com/ リソースURLに対するデータバインド 20 ※両リストに指定可能なパターンの詳細は以下のURLを参照 https://docs.angularjs.org/api/ng/service/$sce http://evil.com/q=.example.com も許可されてしまう
  22. 22. • JSの動的生成は禁止される - <script>の要素内容や、イベントハンドラ属性に対するexpressionの展開は禁止される - onで始まる属性、もしくはformaction属性へのデータバインドが禁止される - 代わりにng-clickなどのイベントハンドラディレクティブが使用できる - scope外の関数にはアクセスできないのでXSSの被害を軽減できる JSに対するデータバインド 21 • 任意のコードを実行可能なオブジェクトはexpressionで参照できない - constructor, window, element, Objectなどはexpressionから参照できない - Functionコンストラクタを用いて任意のJSが実行する方法が以前指摘されたため {{constructor.constructor('alert(1)')()}} ※最新版では__proto__の参照や、call, apply, bind関数も実行が禁止されています 以前はFunctionコンストラクタを 参照することでscope外の関数が実行できた
  23. 23. • XSS対策を自分で行う必要がある - SCEによる保護は期待できない - SCEはビルトインのディレクティブに最適化されている - カスタムディレクティブが出力するHTML要素や属性には コンテキストの自動判別も適用されない - 例:<a href>のコードを流用して<video poster>ディレクティブを作成する場合 カスタムディレクティブを作る際の注意点 22 var htmlAnchorDirective = valueFn({ compile: function(element, attr) { if (!attr.href && !attr.name) { attr.$set('href', ''); } $setはposter属性をURLとして判別 しないので自分でURLをケアする
  24. 24. • コンテキスト毎にデータの取扱い方針を決めておく カスタムディレクティブを作る際の注意点 23 コンテキスト データの取扱い方針(例) HTML • 原則として要素内容はjQLite.text()で出力 • HTMLとして出力する際は$sce.getTrustedHtml()でサニタイズ • 属性値を出力する際はjQLite.attr()かjQLite.prop() を使用 • イベントハンドラと<iframe srcdoc>に対するデータバインドを禁止 CSS • style要素やstyle属性はテンプレートに対するデータバインドで出力 (styleタグを組み立ててHTMLとして出力しない) URL • $$sanitizeUriで無害化したURLを出力 リソースURL • $sce.getTrustedResourceUri()でサニタイズ JS • 信頼できるデータのみを出力
  25. 25. • HTMLとURLを出力する場合 カスタムディレクティブの実装例 24 .directive(‘myDirective’,[‘$sce’,‘$$sanitizeUri’, function($sce, $$sanitizeUri) { return function (scope, element, attrs) { //HTML Content element.html($sce.parseAsHtml(attrs.inputExpression)(scope)); //URL Attribute element.attr('src', $$sanitizeUri(attrs.inputUri)); } }]); expressionを安全な HTMLにしてからDOMへ出力 URLをサニタイズして から属性値として出力
  26. 26. • ディレクティブにSCEが適用されていることを確認する - 例:angular-translateはデフォルトでHTMLをエスケープせずそのまま出力する - $translateProvider.useSanitizeValueStrategyでエスケープを有効にする必要がある カスタムディレクティブを使う際の注意点 25 デフォルトでは HTMLエスケープ無効
  27. 27. • SCEの無効化 - $sceProvider.enabled(false)でSCEを無効化できる - 無効化するとHTMLとリソースURLがサニタイズされなくなるので注意 SCEに関するその他のこと 26 • Content Security Policy(CSP)の利用 - CSPとは、XSSをはじめとする一般的な脆弱性のリスクを軽減するブラウザの保護機能 - CSPを適用する場合、AngularJSのHTMLテンプレートに以下の変更が必要 - ng-appの指定箇所にng-cspを併記する - https://code.angularjs.org/snapshot/angular-csp.css をロードする - CSPを有効にすると実行速度が30%低下するそうなので速度が求められる場合は注意
  28. 28. Cross-Site Request Forgery (CSRF)
  29. 29. CSRF発生のメカニズム 28 • 退会APIを例とする。このAPIは退会画面で利用されることを想定している 退会する 本当に退会するの? 退会はこちら 退会処理中です 退会しました 退会APIを実行 CookieでセッションIDが通知される
  30. 30. 退会する 本当に退会するの? 退会はこちら CSRF発生のメカニズム 29 • 退会APIを例とする。このAPIは退会画面で利用されることを想定している • 罠サイトがAPIを実行した場合、ユーザを意図せず退会させることができる 秘密の画像 ♡罠サイト♡ 退会APIを実行 CookieでセッションIDが通知される 退会処理中です 退会しました 被害者
  31. 31. AngularJSのCSRF対策 30 • 正規のページからのリクエストであることを示すトークンをXHRに付加する 退会する 本当に退会するの? 退会はこちら 退会処理中です 退会しました サーバはXSRF-TOKENという トークン(乱数値)をCookieにセット AngularJSはトークンをX-XSRF-TOKENという リクエストヘッダに付けて退会API(XHR)を実行 サーバは受信したトークンが 正しい場合のみ退会処理を許可
  32. 32. AngularJSのCSRF対策 31 • 正規のページからのリクエストであることを示すトークンをXHRに付加する • 有効なトークンが付いていなければ、サーバ側でリクエストを拒否する 不正なリクエスト を検出しました 乱数値が不正なので 退会リクエストを拒否 退会する 本当に退会するの? 退会はこちら 秘密の画像 ♡罠サイト♡ 罠サイトはリクエストに正しい 乱数値を付けることができない 被害者
  33. 33. AngularJSでCSRF対策する際の注意点 32 • クロスオリジンのXHRにはX-XSRF-TOKENヘッダが付かない - $httpや$resourceのリクエストを送信する際に自分でヘッダを付ける - CORSに基づいてヘッダを受信するための実装がサーバ側にも必要 $scope.method = 'POST'; $scope.url = 'https://api.example.com/resign.php'; $scope.headers = {'X-XSRF-TOKEN': $scope.token }; $http({method: $scope.method, url: $scope.url, headers:$scope.headers}); リクエストヘッダに有効な トークン値をセットする ※恐らくカスタムヘッダ付きのCORSリクエストはプリフライトを発行してしまうためだと思われます https://github.com/angular/angular.js/issues/1004
  34. 34. 謝辞 本資料は竹迫良範様(サイボウズ・ラボ)、佐藤鉄平様(サイボウズ)、 国分裕様(MBSD)に技術レビューをして頂きました。 心より感謝いたします。 お問い合わせはこちら 33

×