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

Transcript

1. 2014/03/19-20 本田 崇
2. !  Takashi Honda 本田 崇(ほんだ　たかし) ◦  セキュリティも開発もやる兼業エンジニアです。 !  Business - ◦  C/Sアプリ開発 5年 ◦  Webアプリ開発 5年 ◦  Webアプリ脆弱性検査 7年 !  Private - ◦  『脆弱性はどこにある?』をテーマに
 Webアプリケーションのセキュリティ
 についてつぶやいています。
 (twitter @hagurese) ◦  C#でFiddlerアドオンを作ったり、
 JavaでAndroidアプリを作ったり
 しています。
3. !  Webアプリ脆弱性検査でよく検出される危険な脆弱性 クロスサイト スクリプティング (XSS) SQLインジェクション (その他のインジェクション) クロスサイト リクエストフォージェリ (CSRF / XSRF) アクセス 制御の問題
4. !  検査～報告～評価～対策計画～対策実施～再検査 クロスサイト スクリプティング (XSS) SQLインジェクション (その他のインジェクション) 開発者 (XSS) 意外と箇所が多いけど対策はちゃんと分かる。 個別に対策ではなく全体で対策できないものか・・・。 (SQL) 急いで対策しないと・・・。 一旦は個別に対策するけど、ホントは 全体で対策した方がいいな・・・。 クロスサイト リクエストフォージェリ (CSRF / XSRF) (CSRF) 攻撃方法がトリッキーで分かりにくい けど対策はシンプルで分かりやすい。 システム全体に影響するので 対策した後のテストが大変そうだ・・・。 検査員 これなら大丈夫ww
5. !  混沌、混乱、誤解、不平不満… 検査員 開発者 (検査前) アクセス制御はちゃんと作ってあります。 バッチリ問題ないはずですよ～。 ネットワークでもしっかり防いでいます し・・・。 (報告) 怖さが伝わらないかも・・・。 直し方もお伝えするのが難しいな・・・。 システム全体に展開していただける だろうか・・・。 アクセス 制御の問題 (再検査) ああ、やっぱり直ってない・・・orz (検査) アクセス制御の定義を確認でき ないと事象の判断が難しい・・・。 検査環境によって検出できたり、 できなかったりします。 ツールでは見つけられないこと が多いです。 (評価) ちゃんと作ったはずなのに指摘されるなんて・・・。 フレームワークがやってくれてるのではないの？ こんなの大した問題ではないのでは・・・。 (対策) どう対策したらいいのかさっぱり分からないよ・・・。 この対策でちゃんとできているだろうか・・・。 何だか他の場所にもあるような気がしてきた・・・。
6. 本日はWebアプリケーションのアクセス制御に ついて突っ込んでお話ししたいと思います。 !  アクセス制御の問題 !  アクセス制御の基本 !  12の事例に学ぶアクセス制御 !  まとめ
8. !  Webアプリケーションのアクセス制御を回避すること で、本来はアクセスできない機能や情報に攻撃者が アクセスしてきます。 管理者権限のユーザーでなければ
 アクセスできないユーザー管理機能に
 アクセスし、ユーザーの一覧データを
 CSVファイルにエクスポートする。 ECサイトで他人の購入履歴を閲覧する。 入札システムで自社が入札を行う前に
 ライバル会社の入札内容を閲覧する。
9. !  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 アクセス制御の問題は 大変危険!!!
10. !  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 - 機能レベル 　　　アクセス制御の欠落」
11. !  共通脆弱性タイプ一覧CWE
 （Common Weakness Enumeration） ◦  IPA/情報セキュリティ/共通脆弱性タイプ一覧CWE概説
 (http://www.ipa.go.jp/security/vuln/CWE.html) 「CWE-264 - 認可・ 　　　　権限・アクセス制御」
12. !  STRIDE手法(セキュリティ脅威の評価モデル) ◦  Microsoft Security Engineering and Communications Group 2006(http://msdn.microsoft.com/ja-jp/magazine/ cc163519.aspx) 「特権の昇格 　(Elevation of Privilege)」
14. !  「あるサブジェクト（能動体、人間やプロセス）が、どのオブ ジェクト（受動体、システムやファイル）に対して、どのアク セス（読み／書き／実行）ができるかを許可したり拒否し たりする機能を指す。」 !  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)
15. !  どのようにアクセス制御するのか? ◦  アクセスの可否を判定します。 OKならば要求された機能を 実行します。 NGならば要求された機能を 実行せず、エラーにします。 判定式　result := ACF(x) : {OK, NG} xは何か?
16. !  何を見て判定するのか?(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)
17. !  どのように判定するか? ◦  判定論理　→　プログラムコード ◦  判定基準(アクセス制御ポリシー) 　→　マスタデータ 判定論理 コンテキスト 判定基準 判定結果 コンテキストを評価 コンテキスト間の関連、整合性を評価 コンテキストを基準に対して照会 判定論理の挙動を パラメータ化
18. !  いつ判定するのか? ◦  外部に作用を及ぼす④更新の前までに判定します。
19. !  どうやってアクセス制御を実装したらよいのか? !  IPA 「セキュアプログラミング講座」 / Webアプリケーション編
 / 第2章 アクセス制御 / アクセス認可
 (http://www.ipa.go.jp/security/awareness/vendor/ programmingv2/contents/102.html) 詳しく書いてあります!? 必読です!!
20. 1.  操作無効のボタン・リンクを有効化 2.  URLを直接指定 3.  リクエストを直接指定 4.  後続処理のURL・リクエストを直接指定 5.  検索結果一覧表示から詳細表示にてオブジェクトIDを指定 6.  ニュース機能の詳細表示にてオブジェクトIDを指定 7.  削除済みのオブジェクトIDを指定 8.  リスト選択でリストにない項目IDを指定 9.  ダウンロードコンテンツのURLを直接指定 10.  ブラウザから渡される制御パラメータを改ざん 11.  データ項目の参照・更新制御 12.  不完全なエラー処理
21. !  管理者ユーザーでログインした場合に使用できる「管理者用 メニュー」は、一般ユーザーでは「操作無効」です。 操作無効 ※画面はイメージです。実際のものとは異なります。
22. !  一般ユーザーでログインした攻撃者が、ブラウザの開発者 ツールを使用して「disabled=“disabled”」を削除します。 削除
23. !  「管理者用メニュー」が操作可能になります。 操作可能!!
24. !  有効になった「管理者用メニュー」から画面操作を行った場 合、管理者用機能を使用できます。 開発者 ではボタン・リンクを非表示してしまおう～ ＼(＾o＾)／ 迷わずクリック!! 検査員 それではダメなんですorz
25. !  一般ユーザーでログインした場合には「管理者用メニュー」は 表示されません。
26. !  攻撃者は、管理者用機能を示すURLを直接指定します。 ◦  ブラウザのアドレスバーにURLを入力します。 ◦  事前にURLを知っている必要があります。 !  よくあるパス名、連番や命名規則によって体系化されたIDのパス名 !  オープンソースのWebアプリケーション !  カスタムアプリケーションの関係者(開発者、元管理者など) https://appsecapac.org/2014/admin/
27. !  管理者用機能を使用できます。 開発者 POSTメソッドでFORMパラメータを渡せば、アドレスバーに URLを入力するだけでは機能を使用できなくなるよね～ ＼(＾o＾)／ 検査員 いえいえ。 それもダメなんですorz
28. !  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ソース
29. !  攻撃者は、任意の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リクエスト ※クッキーは一般ユーザーでログインしたときに設定されたもの
30. !  管理者用機能を使用できます。 検査員 サーバー側でアクセス制御をチェックします。 　ブラウザ側では、セキュリティを目的としたアクセス制御は期待できません。 　ユーザビリティ向上を目的とした操作の制御はある程度期待できます。
31. !  「トップメニュー」 → 「管理者用ページ」のリクエストでは、 サーバ側でアクセス制御をチェックしています。 開発者 サーバー側でチェックしたから、もう安心だ～ ＼(＾o＾)／ 検査員 確かに、でも・・・
32. !  攻撃者は、管理者用機能のリクエスト(ダウンロード処理)を直 接指定します。 ◦  システムには「メニュー」 → 「検索」 → 「一覧表示」 → 「入力」 → 「確 認」 → 「完了」　といった処理フローがあります。 ◦  処理フローの先頭でチェックした後はアクセス制御をチェックしていませ ん。 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リクエスト
33. !  後続処理のリクエストを指定した場合、管理者用機能を使用 できます。 検査員 全てのリクエストにてサーバー側でアクセス制御をチェックします。 処理フローの先頭でチェックするだけでは不十分です。 先頭でチェックした結果をセッションで記憶して利用することもできます。 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レスポンス
34. !  ショッピングサイトの購入履歴機能はログインしているユー ザーの購入履歴データを表示します。 ※画面はイメージです。実際のものとは異なります。
35. !  他のユーザーの購入履歴が表示されることはありません。 　　　クリック!!
36. !  攻撃者は、詳細表示のリクエストに含まれる購入履歴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;…
37. !  他のユーザーの購入履歴を閲覧できます。 検査員 購入履歴IDに該当する購入履歴のユーザーID項目がログインして いるユーザーIDと一致することをチェックします。 検索結果をサーバ側のセッションで記憶しておき、その中から詳細 表示する方法もあります。
38. !  ニュース機能は、指定された「掲示期間」に該当するニュース を一覧表示します。 ◦  ニュースには「掲示期間」を指定するとことができます。
39. !  「掲示期間」範囲外の日時では、ニュースは表示されません。 クリック!!
40. !  攻撃者は、「詳細表示」のリクエストに含まれるニュース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; …
41. !  「掲示期間」外のニュースを閲覧できます。 検査員 ニュースIDに該当するニュースオブジェクトの掲示期間項目の範囲 内にシステム日付が該当することをチェックします。 ニュースの一覧表示結果をサーバ側のセッションで記憶しておき、 その中から「詳細表示」する方法もあります。
42. !  フォーラム投稿表示機能では、削除済みの投稿は表示され ません。 ◦  管理者は不適切な投稿を削除します。 http://acshopping.test/boards/topic/5 http://acshopping.test/boards/topic/1 クリック!!
43. !  攻撃者は、フォーラム投稿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;…
44. !  削除済みの投稿が表示されます。 検査員 フォーラム投稿IDに該当するオブジェクトの状態項目が「有効」であ ることをチェックします。 フォーラム投稿の一覧表示結果をサーバ側のセッションで記憶して おき、その中から「詳細表示」する方法もあります。
45. !  マルチテナント方式の販売管理システムでは、各テナントの管 理者ユーザーがリストに表示された自社の店舗を選択した場 合、その店舗の売上情報を表示します。 クリック!!
46. !  攻撃者は、リクエストに含まれる店舗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>
47. !  他社の店舗売上が表示されます。 検査員 店舗IDに該当する店舗オブジェクトがログインしているユーザーの テナント配下の店舗であることをチェックします。 事例5.はオブジェクトIDで該当のオブジェクトを参照していますが、 こちらは店舗IDで店舗に紐づく売上の集計を参照しています。
48. !  コンテンツをアップロードすると、Webサーバのホーム ディレクトリ配下に静的に格納します。 http://acshopping.test/images/iphone.jpg
49. !  アクセス制御ポリシーに従い、表面上は表示/非表示が切り 替わります。 管理システムでのアクセス制御設定
50. !  アクセス制御ポリシーに従い、表面上は表示/非表示が切り 替わります。 管理システムでのアクセス制御設定
51. !  攻撃者は、コンテンツの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リクエスト
52. !  コンテンツをダウンロードできます。 検査員 動的ページを介してアクセス制御をチェックし、 コンテンツをダウンロードします。 Webサーバのホームディレクトリ外にコンテンツを 格納します。
53. !  ログイン成功時に「クッキー」に「権限レベル」を設定しており、 全てのリクエストにて渡された「権限レベル」の値をサーバー 側でチェックしています。
54. !  攻撃者は、「クッキー」で渡される「権限レベル」の値を改ざん します。 ◦  「権限レベル」 = { 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…
55. !  管理者ユーザーとして画面を操作することができます。 検査員 ブラウザから渡される「制御パラメータ」は改ざんされる恐れがあります。 セッション管理を行い、サーバ側で保持するのが原則です。 「制御パラメータ」とは、アクセス制御の判定条件として直接評価される パラメータです。 ・権限レベル ・ログイン済みフラグ
56. !  データ項目「レーティング」は参照のみ、更新不可です。 編集不可 　　　　　　　クリック!!
57. !  攻撃者は、更新処理のリクエストを改ざんします。 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
58. !  データ項目「レーティング」が更新されます。 検査員 データ項目レベルのアクセス制御にも注意する必要があります。 ・参照すべきでないデータ項目をレスポンスしないこと 　「画面に表示しない」だけではダメ!! ・更新すべきでないデータ項目がリクエストに渡されても 　更新しないこと 開発者 でも、この事例そんなに怖くないのでは??? 今までの中にもさほど怖くないものもあったような・・・ 検査員 ですよね～。 アクセス制御がないのは確かですが、そもそも必要か どうかを明確に定義しなければ判断できません。 ところで、アクセス制御の定義書はございますか?
59. !  リダイレクトを用いた画面遷移を行う方式のシステムにて、オ ブジェクトIDを改ざんしたところ、アクセス制御のチェックで NGとなりエラー画面にリダイレクトされます。
60. 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;…
61. !  アクセス制御チェックの結果を元にリダイレクトします。 チェックOKなら通常の画面に リダイレクトします。 チェックNGならエラー画面 にリダイレクトします。
62. !  アクセス制御のチェックがNGの時に、セッションに保持したオ ブジェクトを破棄していません。 購入履歴が破棄されない。
63. !  攻撃者は、リダイレクト先のURLを「エラー画面」から
 「通常の画面」に改ざんします。 改ざん
64. !  チェックNGとなったはずのオブジェクトが通常の画面に表示
 されました。 検査員 アクセス制御のチェックNG時のエラー処理では、処理全体をロール バックします。一時的にセッションに保持したデータをクリアします。
66. [システム設計～実装テスト工程] !  ブラウザ側のアクセス制御には頼らないこと !  ブラウザ側の制御はユーザビリティ向上が目的だと認識する。 !  全てのリクエストにてサーバ側でアクセスの可否を判定
 すること !  「A4 –安全でないオブジェクト直接参照」 !  「A7 – 機能レベルアクセス制御の欠落」 !  制御パラメータをブラウザから渡さないこと !  セッション管理を行い、サーバ側で保持すること !  データ項目の参照・更新制御に注意すること !  アクセス制御エラー時の処理に注意すること
67. [システム設計工程] !  従来のC/SアプリとWebアプリは違うと認識すること ◦  ブラウザからやってくるリクエストは信用できない。 ◦  HTTPはオープンなプロトコル、HTML、CSS、JavaScriptは解析可能 !  フレームワークに隠蔽されたHTTPを意識すること ◦  全てのHTTPリクエストでアクセス制御できているのが望ましい。 [要件定義～システム分析工程] !  アクセス制御を漏れ抜けなく洗い出し、誤りなく定義すること ◦  あるべき仕様が定義されなければ、あるべき実装は期待できない。 ◦  定義されていなければ、検査時にも判断がつかない場合がある。
69. !  コンタクト先 ◦  twitter @hagurese ◦  お気に入りにセキュリティ
 ツイートをまとめてます。 ◦  お気軽にDMしてください。