12 Case Studies for the Access Controls of Web Application #appsecapac2014

2014/03/19-20 本田崇

!  Takashi Honda 本田崇(ほんだ　たかし) ◦  セキュリティも開発もやる兼業エンジニアです。 !  Business -
◦  C/Sアプリ開発 5年 ◦  Webアプリ開発 5年 ◦  Webアプリ脆弱性検査 7年 !  Private - ◦  『脆弱性はどこにある?』をテーマに  Webアプリケーションのセキュリティ  についてつぶやいています。  (twitter @hagurese) ◦  C#でFiddlerアドオンを作ったり、  JavaでAndroidアプリを作ったり  しています。

!  Webアプリ脆弱性検査でよく検出される危険な脆弱性クロスサイトスクリプティング (XSS) SQLインジェクション (その他のインジェクション) クロスサイトリクエストフォージェリ (CSRF
/ XSRF) アクセス制御の問題

!  検査～報告～評価～対策計画～対策実施～再検査クロスサイトスクリプティング (XSS) SQLインジェクション (その他のインジェクション) 開発者 (XSS) 意外と箇所が多いけど対策はちゃんと分かる。
個別に対策ではなく全体で対策できないものか・・・。 (SQL) 急いで対策しないと・・・。一旦は個別に対策するけど、ホントは全体で対策した方がいいな・・・。クロスサイトリクエストフォージェリ (CSRF / XSRF) (CSRF) 攻撃方法がトリッキーで分かりにくいけど対策はシンプルで分かりやすい。システム全体に影響するので対策した後のテストが大変そうだ・・・。検査員これなら大丈夫ww

!  混沌、混乱、誤解、不平不満… 検査員開発者 (検査前) アクセス制御はちゃんと作ってあります。バッチリ問題ないはずですよ～。ネットワークでもしっかり防いでいますし・・・。 (報告)
怖さが伝わらないかも・・・。直し方もお伝えするのが難しいな・・・。システム全体に展開していただけるだろうか・・・。アクセス制御の問題 (再検査) ああ、やっぱり直ってない・・・orz (検査) アクセス制御の定義を確認できないと事象の判断が難しい・・・。検査環境によって検出できたり、できなかったりします。ツールでは見つけられないことが多いです。 (評価) ちゃんと作ったはずなのに指摘されるなんて・・・。フレームワークがやってくれてるのではないの？こんなの大した問題ではないのでは・・・。 (対策) どう対策したらいいのかさっぱり分からないよ・・・。この対策でちゃんとできているだろうか・・・。何だか他の場所にもあるような気がしてきた・・・。

本日はWebアプリケーションのアクセス制御について突っ込んでお話ししたいと思います。 !  アクセス制御の問題 !  アクセス制御の基本 !  12の事例に学ぶアクセス制御 !  まとめ

!  Webアプリケーションのアクセス制御を回避することで、本来はアクセスできない機能や情報に攻撃者がアクセスしてきます。管理者権限のユーザーでなければ  アクセスできないユーザー管理機能に  アクセスし、ユーザーの一覧データを  CSVファイルにエクスポートする。 ECサイトで他人の購入履歴を閲覧する。入札システムで自社が入札を行う前に 
ライバル会社の入札内容を閲覧する。

!  JVN iPedia 脆弱性対策情報データベース  (http://jvndb.jvn.jp/index.html) ◦  CVSSによる深刻度 !  CVSS（共通脆弱性評価システム：Common Vulnerability
Scoring System) ◦  IPA/情報セキュリティ/共通脆弱性評価システムCVSS概説  (http://www.ipa.go.jp/security/vuln/CVSS.html) 深刻度 CVSS基本値レベルⅢ (危険) 7.0～10.0 レベルⅡ (警告) 4.0～6.9 レベルⅠ (注意) 0.0～3.9 アクセス制御の問題は大変危険!!!

!  OWASP 「OWASP TOP 10 – 2013 日本語版」 ◦  OWASP
/ OWASP Top 10 – 2013 日本語版  (https://www.owasp.org/images/7/79/ OWASP_Top_10_2013_JPN.pdf) 「A4 - 安全でない　　　オブジェクト直接参照」「A7 - 機能レベル　　　アクセス制御の欠落」

!  共通脆弱性タイプ一覧CWE  （Common Weakness Enumeration） ◦  IPA/情報セキュリティ/共通脆弱性タイプ一覧CWE概説  (http://www.ipa.go.jp/security/vuln/CWE.html) 「CWE-264 -
認可・　　　　権限・アクセス制御」

!  STRIDE手法(セキュリティ脅威の評価モデル) ◦  Microsoft Security Engineering and Communications Group 2006(http://msdn.microsoft.com/ja-jp/magazine/
cc163519.aspx) 「特権の昇格　(Elevation of Privilege)」

!  「あるサブジェクト（能動体、人間やプロセス）が、どのオブジェクト（受動体、システムやファイル）に対して、どのアクセス（読み／書き／実行）ができるかを許可したり拒否したりする機能を指す。」 !  Wikipedia / アクセス制御 /
コンピュータセキュリティのアクセス制御 (http://ja.wikipedia.org/wiki/アクセス制御) !  「システム内のリソースに対するアクセス要求に対し、その可否を制御することによって、セキュリティの目的を達成するための技術である。」 !  IPA 2004 情財第 736 号 / アクセス制御に関するセキュリティポリシーモデルの調査報告書 / 2.1.2 アクセス制御(http:// www.ipa.go.jp/security/fy16/reports/access_control/ documents/PolicyModelSurvey.pdf)

!  どのようにアクセス制御するのか? ◦  アクセスの可否を判定します。 OKならば要求された機能を実行します。 NGならば要求された機能を実行せず、エラーにします。判定式　result :=
ACF(x) : {OK, NG} xは何か?

!  何を見て判定するのか?(xは何か?) ◦  要求のコンテキスト機能(Verb)に対する要求のコンテキストその他 (Else) 主体
(Subject) 対象 (Object) 判定式　result = ACF(S,V,O,E)  　　　　　　　　　　= ACFV (S,O,E) コンテキストの組み合わせは7通り  [S], [O], [E], [S-O], [S-E], [O-E], [S-O-E] その他(E:else)の要素 (システム日付、通信経路など) 要求の対象(O:object)とその属性(所有者、状態、期間など) 要求の主体(S:subject)とその属性(権限、ロールなど) 要求されている機能(V:verb)

!  どのように判定するか? ◦  判定論理　→　プログラムコード ◦  判定基準(アクセス制御ポリシー) 　→　マスタデータ判定論理コンテキスト判定基準
判定結果コンテキストを評価コンテキスト間の関連、整合性を評価コンテキストを基準に対して照会判定論理の挙動をパラメータ化

!  いつ判定するのか? ◦  外部に作用を及ぼす④更新の前までに判定します。

!  どうやってアクセス制御を実装したらよいのか? !  IPA 「セキュアプログラミング講座」 / Webアプリケーション編  / 第2章アクセス制御
/ アクセス認可  (http://www.ipa.go.jp/security/awareness/vendor/ programmingv2/contents/102.html) 詳しく書いてあります!? 必読です!!

1.  操作無効のボタン・リンクを有効化 2.  URLを直接指定 3.  リクエストを直接指定 4.  後続処理のURL・リクエストを直接指定 5.  検索結果一覧表示から詳細表示にてオブジェクトIDを指定
6.  ニュース機能の詳細表示にてオブジェクトIDを指定 7.  削除済みのオブジェクトIDを指定 8.  リスト選択でリストにない項目IDを指定 9.  ダウンロードコンテンツのURLを直接指定 10.  ブラウザから渡される制御パラメータを改ざん 11.  データ項目の参照・更新制御 12.  不完全なエラー処理

!  管理者ユーザーでログインした場合に使用できる「管理者用メニュー」は、一般ユーザーでは「操作無効」です。操作無効 ※画面はイメージです。実際のものとは異なります。

!  一般ユーザーでログインした攻撃者が、ブラウザの開発者ツールを使用して「disabled=“disabled”」を削除します。削除

!  「管理者用メニュー」が操作可能になります。操作可能!!

!  有効になった「管理者用メニュー」から画面操作を行った場合、管理者用機能を使用できます。開発者ではボタン・リンクを非表示してしまおう～＼(＾o＾)／迷わずクリック!! 検査員それではダメなんですorz

!  一般ユーザーでログインした場合には「管理者用メニュー」は表示されません。

!  攻撃者は、管理者用機能を示すURLを直接指定します。 ◦  ブラウザのアドレスバーにURLを入力します。 ◦  事前にURLを知っている必要があります。 !  よくあるパス名、連番や命名規則によって体系化されたIDのパス名 !  オープンソースのWebアプリケーション
!  カスタムアプリケーションの関係者(開発者、元管理者など) https://appsecapac.org/2014/admin/

!  管理者用機能を使用できます。開発者 POSTメソッドでFORMパラメータを渡せば、アドレスバーに URLを入力するだけでは機能を使用できなくなるよね～＼(＾o＾)／検査員いえいえ。それもダメなんですorz

!  POSTメソッドを用いてFORMパラメータを渡すため、URLを指定するだけでは管理者用機能を使用できません。 <form name="admin" method="POST" action="./page/" enctype="application/x-www-form-urlencoded"> <input type="hidden"
name="func" value="admin"> <a onclick=“javascript:document.forms[‘admin’].submit()”> ADMIN</a> </form> HTMLソース

!  攻撃者は、任意のHTTPリクエストを作成して、サーバーに送信することが可能です。 POST https://appsecapac.org/2014/page/ HTTP/1.1 Referer: https://appsecapac.org/2014/ Content-Type: application/x-www-form-urlencoded
Host: appsecapac.org Content-Length: 10 Cookie: wfvt_3032309459=52e3b9f192d… func=admin HTTPリクエスト ※クッキーは一般ユーザーでログインしたときに設定されたもの

!  管理者用機能を使用できます。検査員サーバー側でアクセス制御をチェックします。　ブラウザ側では、セキュリティを目的としたアクセス制御は期待できません。　ユーザビリティ向上を目的とした操作の制御はある程度期待できます。

!  「トップメニュー」 → 「管理者用ページ」のリクエストでは、サーバ側でアクセス制御をチェックしています。開発者サーバー側でチェックしたから、もう安心だ～＼(＾o＾)／検査員確かに、でも・・・

!  攻撃者は、管理者用機能のリクエスト(ダウンロード処理)を直接指定します。 ◦  システムには「メニュー」 → 「検索」 → 「一覧表示」 →
「入力」 → 「確認」 → 「完了」　といった処理フローがあります。 ◦  処理フローの先頭でチェックした後はアクセス制御をチェックしていません。 POST https://appsecapac.org/2014/page/ HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: appsecapac.org Content-Length: 17 Cookie: wfvt_3032309459=52e3b9f192d… func=admin.export HTTPリクエスト

!  後続処理のリクエストを指定した場合、管理者用機能を使用できます。検査員全てのリクエストにてサーバー側でアクセス制御をチェックします。処理フローの先頭でチェックするだけでは不十分です。先頭でチェックした結果をセッションで記憶して利用することもできます。 HTTP/1.1 200 OK
Content-Length: 123456 Content-Type: application/octet-stream Expires: -1 Server: Apache Content-Disposition: inline; filename=export.xml <appsecapac><users><user><id>00000001</id><name>... HTTPレスポンス

!  ショッピングサイトの購入履歴機能はログインしているユーザーの購入履歴データを表示します。 ※画面はイメージです。実際のものとは異なります。

!  他のユーザーの購入履歴が表示されることはありません。　　　クリック!!

!  攻撃者は、詳細表示のリクエストに含まれる購入履歴IDの値を改ざんします。 ◦  事前に購入履歴IDを知っている必要があります。 !  推測可能なオブジェクトID(日付や連番など) GET http://acshopping.test/orderdetails/5 HTTP/1.1
Host: acshopping.test Referer: http://acshopping.test/customer/orders Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;… HTTPリクエスト GET http://acshopping.test/orderdetails/3 HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/customer/orders Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;…

!  他のユーザーの購入履歴を閲覧できます。検査員購入履歴IDに該当する購入履歴のユーザーID項目がログインしているユーザーIDと一致することをチェックします。検索結果をサーバ側のセッションで記憶しておき、その中から詳細表示する方法もあります。

!  ニュース機能は、指定された「掲示期間」に該当するニュースを一覧表示します。 ◦  ニュースには「掲示期間」を指定するとことができます。

!  「掲示期間」範囲外の日時では、ニュースは表示されません。クリック!!

!  攻撃者は、「詳細表示」のリクエストに含まれるニュースIDを改ざんします。 ◦  事前にニュースIDを知っている必要があります。 GET http://acshopping.test/20140201 HTTP/1.1 Host: acshopping.test
Referer: http://acshopping.test/ Cookie: ASP.NET_SessionId=idtbjidawiwgmwrv02cwn54t;… HTTPリクエスト GET http://acshopping.test/20140321 HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/ Cookie: ASP.NET_SessionId=idtbjidawiwgmwrv02cwn54t; …

!  「掲示期間」外のニュースを閲覧できます。検査員ニュースIDに該当するニュースオブジェクトの掲示期間項目の範囲内にシステム日付が該当することをチェックします。ニュースの一覧表示結果をサーバ側のセッションで記憶しておき、その中から「詳細表示」する方法もあります。

!  フォーラム投稿表示機能では、削除済みの投稿は表示されません。 ◦  管理者は不適切な投稿を削除します。 http://acshopping.test/boards/topic/5 http://acshopping.test/boards/topic/1 クリック!!

!  攻撃者は、フォーラム投稿IDを改ざんします。 ◦  事前にフォーラム投稿IDを知っている必要があります。 GET http://acshopping.test/boards/topic/5 HTTP/1.1 Host: acshopping.test Referer:
http://acshopping.test/customer/orders Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;… HTTPリクエスト GET http://acshopping.test/boards/topic/4 HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/customer/orders Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;…

!  削除済みの投稿が表示されます。検査員フォーラム投稿IDに該当するオブジェクトの状態項目が「有効」であることをチェックします。フォーラム投稿の一覧表示結果をサーバ側のセッションで記憶しておき、その中から「詳細表示」する方法もあります。

!  マルチテナント方式の販売管理システムでは、各テナントの管理者ユーザーがリストに表示された自社の店舗を選択した場合、その店舗の売上情報を表示します。クリック!!

!  攻撃者は、リクエストに含まれる店舗IDを改ざんします。 ◦  他社の店舗IDを事前に知っている必要があります。 HTTPリクエスト POST http://acshopping.test/Admin HTTP/1.1 Host: acshopping.test
Content-Type: application/x-www-form-urlencoded Content-Length: 17 Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;… shopId=C0050S0001 POST http://acshopping.test/Admin HTTP/1.1 Host: acshopping.test Content-Type: application/x-www-form-urlencoded Content-Length: 17 Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;… shopId=C0121S0002 HTMLソースに記述された自社店舗一覧 <select> <option value="C0121S0001">Tokyo</option> <option value="C0121S0002">Osaka</option> <option value="C0121S0003">London</option> <option value="C0121S0004">Paris</option> <option value="C0121S0005">NewYork</option> </select>

!  他社の店舗売上が表示されます。検査員店舗IDに該当する店舗オブジェクトがログインしているユーザーのテナント配下の店舗であることをチェックします。事例5.はオブジェクトIDで該当のオブジェクトを参照していますが、こちらは店舗IDで店舗に紐づく売上の集計を参照しています。

!  コンテンツをアップロードすると、Webサーバのホームディレクトリ配下に静的に格納します。 http://acshopping.test/images/iphone.jpg

!  アクセス制御ポリシーに従い、表面上は表示/非表示が切り替わります。管理システムでのアクセス制御設定

!  攻撃者は、コンテンツのURLを直接指定します。 ◦  事前にコンテンツのURLを知っている必要があります。 GET http://acshopping.test/images/iphone.jpg HTTP/1.1 Host: acshopping.test Connection:
keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9 ,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit /537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537 .36 Accept-Encoding: gzip,deflate,sdch Accept-Language: ja,en-US;q=0.8,en;q=0.6 Pragma: no-cache HTTPリクエスト

!  コンテンツをダウンロードできます。検査員動的ページを介してアクセス制御をチェックし、コンテンツをダウンロードします。 Webサーバのホームディレクトリ外にコンテンツを格納します。

!  ログイン成功時に「クッキー」に「権限レベル」を設定しており、全てのリクエストにて渡された「権限レベル」の値をサーバー側でチェックしています。

!  攻撃者は、「クッキー」で渡される「権限レベル」の値を改ざんします。 ◦  「権限レベル」 = { 0: 一般ユーザー、9: 管理者ユーザー
} GET http://acshopping.test/ HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/ Cookie: ASP.NET_SessionId=riy0n2ir3vm410abeuu3cael; aclv=0… HTTPリクエスト GET http://acshopping.test/ HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/ Cookie: ASP.NET_SessionId=riy0n2ir3vm410abeuu3cael; aclv=9…

!  管理者ユーザーとして画面を操作することができます。検査員ブラウザから渡される「制御パラメータ」は改ざんされる恐れがあります。セッション管理を行い、サーバ側で保持するのが原則です。「制御パラメータ」とは、アクセス制御の判定条件として直接評価されるパラメータです。・権限レベル・ログイン済みフラグ

!  データ項目「レーティング」は参照のみ、更新不可です。編集不可　　　　　　　クリック!!

!  攻撃者は、更新処理のリクエストを改ざんします。 POST http://acshopping.test/Admin/ProductReview/Edit/2 HTTP/1.1 Host: acshopping.test Cookie: ASP.NET_SessionId=0diwftbjzf5sxlhs20td3yzm; ...
save=save-continue&Id=2&Title=%E3%81…%80%82&IsApproved=true HTTPリクエスト POST http://acshopping.test/Admin/ProductReview/Edit/2 HTTP/1.1 Host: acshopping.test Cookie: ASP.NET_SessionId=0diwftbjzf5sxlhs20td3yzm; ... save=save-continue&Id=2&Title=%E3%81…%80%82&IsApproved=true &Rating=1

!  データ項目「レーティング」が更新されます。検査員データ項目レベルのアクセス制御にも注意する必要があります。・参照すべきでないデータ項目をレスポンスしないこと　「画面に表示しない」だけではダメ!! ・更新すべきでないデータ項目がリクエストに渡されても　更新しないこと開発者でも、この事例そんなに怖くないのでは???
今までの中にもさほど怖くないものもあったような・・・検査員ですよね～。アクセス制御がないのは確かですが、そもそも必要かどうかを明確に定義しなければ判断できません。ところで、アクセス制御の定義書はございますか?

!  リダイレクトを用いた画面遷移を行う方式のシステムにて、オブジェクトIDを改ざんしたところ、アクセス制御のチェックで NGとなりエラー画面にリダイレクトされます。

HTTPリクエスト GET http://acshopping.test/orderdetails/3 HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/customer/orders Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;…
HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: http://acshopping.test/error_accessdenied Server: Microsoft-IIS/7.5 Content-Length: 0 HTTPレスポンス HTTPリクエスト GET http://acshopping.test/error_accessdenied HTTP/1.1 Host: acshopping.test Referer: http://acshopping.test/customer/orderdetails/3 Cookie: ASP.NET_SessionId=o0ijy1o5hky4yeta033s0i3w;…

!  アクセス制御チェックの結果を元にリダイレクトします。チェックOKなら通常の画面にリダイレクトします。チェックNGならエラー画面にリダイレクトします。

!  アクセス制御のチェックがNGの時に、セッションに保持したオブジェクトを破棄していません。購入履歴が破棄されない。

!  攻撃者は、リダイレクト先のURLを「エラー画面」から  「通常の画面」に改ざんします。改ざん

!  チェックNGとなったはずのオブジェクトが通常の画面に表示  されました。検査員アクセス制御のチェックNG時のエラー処理では、処理全体をロールバックします。一時的にセッションに保持したデータをクリアします。

[システム設計～実装テスト工程] !  ブラウザ側のアクセス制御には頼らないこと !  ブラウザ側の制御はユーザビリティ向上が目的だと認識する。 !  全てのリクエストにてサーバ側でアクセスの可否を判定  すること !  「A4
–安全でないオブジェクト直接参照」 !  「A7 – 機能レベルアクセス制御の欠落」 !  制御パラメータをブラウザから渡さないこと !  セッション管理を行い、サーバ側で保持すること !  データ項目の参照・更新制御に注意すること !  アクセス制御エラー時の処理に注意すること

[システム設計工程] !  従来のC/SアプリとWebアプリは違うと認識すること ◦  ブラウザからやってくるリクエストは信用できない。 ◦  HTTPはオープンなプロトコル、HTML、CSS、JavaScriptは解析可能 !  フレームワークに隠蔽されたHTTPを意識すること ◦ 
全てのHTTPリクエストでアクセス制御できているのが望ましい。 [要件定義～システム分析工程] !  アクセス制御を漏れ抜けなく洗い出し、誤りなく定義すること ◦  あるべき仕様が定義されなければ、あるべき実装は期待できない。 ◦  定義されていなければ、検査時にも判断がつかない場合がある。

!  コンタクト先 ◦  twitter @hagurese ◦  お気に入りにセキュリティ  ツイートをまとめてます。 ◦  お気軽にDMしてください。

12 Case Studies for the Access Controls of Web ...

12 Case Studies for the Access Controls of Web Application #appsecapac2014

More Decks by OWASP Japan

Featured

Transcript