Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie とある診断員と色々厄介な脆弱性達
Ähnlich wie とある診断員と色々厄介な脆弱性達 (20)
Mehr von zaki4649
とある診断員と色々厄介な脆弱性達
- 1. Web Application Vulnerabilities すみだセキュリティ勉強会 2014 #3 @tigerszk 2014/09/14
- 2. 自己紹介 セキュリティエンジニアやってます。 脆弱性診断業務を担当しており、専門はWebセキュリ ティです。 趣味で脆弱性の検証したり、最近はCTFイベントなどに 参加してたりします。 TwitterID: tigerszk
- 3. Webアプリの脆弱性ってどんなの？ Webアプリの脆弱性達 SQLインジェクション OSコマンドインジェクション パス名パラメータの未チェック/ディレクトリ・トラバーサル セッション管理の不備 クロスサイト・スクリプティング CSRF HTTPヘッダ・インジェクション メールヘッダインジェクション アクセス制御や認可制御の欠落 IPA「安全なウェブサイトの作り方」より https://www.ipa.go.jp/security/vuln/websecurity.html 例えばこんなのがありますね
- 4. どうやって見つけるの? ブラックボックステスト 疑似攻撃を試行し、対象システムの挙動から脆弱性 の存在有無を調査する ホワイトボックステスト 設計書、仕様書、コンフィグファイル、ソースコードな どを精査して脆弱性を洗い出す 今回はこっちのお話
- 5. 一般的なWebアプリの診断方法 ツール診断＋マニュアル診断の ハイブリッド診断 とかってよく言われていますね。
- 6. 診断ツールのやっていること ブラックボックステストの診断ツールは、本来手動で もできる検査作業を単純に自動化しただけです。 作業時間短縮＆作業内容の標準化などのために 一般的にツールを利用しています。 ただ、診断ツールは万能なものではないので、Web アプリ診断はツールを使うだけでは網羅的に診断を することができません。
- 7. 診断ツールにも苦手な部分がある 診断ツールを上手く使うにはポイントがあります。 利用する診断ツールが「得意とする部分」、「苦 手とする部分」をちゃんと理解しておくこと 診断ツールが「苦手な部分」については、手動で の診断作業を行います。
- 8. 手動でやる診断作業は何やるの？ •診断ツールを上手く使うためのサイト分析 •診断ツールが検出した脆弱性の確認 •診断ツールでは正常に検査できないと想定さ れる箇所・機能の診断 •診断ツールでは検出することが難しいと想定 される脆弱性項目の診断
- 9. 本日のテーマ 脆弱性を見つける手動の診断作業はなかなか 楽しく、個人的にはWebアプリ診断の醍醐味な のかなと思っています。 今回はその内のいくつかの脆弱性について見つ け方や過去自分が遭遇した事例についてお話し たいと思います。
- 10. 使うもの 手動診断には定番のローカルProxyを利用します。 HTTP Response HTTP Request HTTP Response HTTP Request ローカルProxy 「Burp Suite」 http://portswigger.net/burp/ 「OWASP ZAP」 https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project 「Fiddler」 http://www.telerik.com/fiddler メジャーなローカルProxy達
- 11. 今回ご紹介する脆弱性達 これらの脆弱性は一般的に診断ツールでは検 出しにくい脆弱性だと思います。 •セッション管理の不備 •認可制御不備 •パラメータ値の改ざん
- 12. セッション管理の不備
- 13. セッション管理って？ Ｗｅｂアプリではユーザの状態管理を行う仕組みとして セッション管理機構というものがあります。 Aさん id:user pass：password A子さんと判別 Aさんに公開するべき情報 … A子さんと判別 sessionid=abc123 sessionid=abc123 A子さんを認証 セッションIDがセット sessionid=abc123
- 14. 不備ってどういうこと？ •「セッション管理の不備」とはアプリ側が提供し ているセッション管理の仕組みがよろしくない 作りをしているということです。 •よろしくない作りをしている場合には、攻撃者 にセッションIDの値を推測されたり盗難される 可能性が高まってしまいます。
- 15. セッションＩＤがパクられると 「セッションハイジャック」されてしまう Aさん Aさんに公開するべき情報 Aさんに公開するべき情報 攻撃者 盗難 or 推測 なりすまし A子さんと判別 A子さんと判別 sessionid=abc123 sessionid=abc123
- 16. 診断作業のやり方 診断対象アプリにおいて、一体何の値が、セッ ションIDとして用いられているのかをまず分析し て特定します。 特定した値が、ちゃんと適切な作りになっている のかを確認していきます。
- 17. よろしくない作りの例 強度が弱いセッションIDを発行している –推測されやすい値が利用されてる –ユーザごとに毎回固定の値が利用されてる ユーザ認証時にセッションIDが再発行されていない URLにセッションIDが埋め込まれている 値が格納されているCookieにhttponly属性やsecure 属性が付加されていない …etc
- 18. 過去にエンカウントしたもの-その1- 過去色々酷いセッションIDを見かけました。 –ユーザごとに固定でかつ数字だけで構成 –ユーザID、MSN番号などがモロそのまま –↑だと流石にちょっと後ろめたかったのか、base64エンコー ドしたり asciiコードに変換したりと若干小細工をしているもの –単純な生成ルールのもの(例：ユーザID＋タイムスタンプ)
- 19. 過去にエンカウントしたもの-その2- 折角フレームワークのセッション管理利用していても… 折角フレームワークとかのセッション管理機構を利用していても、ユーザ の判別はなぜか別の外部パラメータを利用している残念ケースとかもあ ります。しかも値が数字とかorz... セッション管理？なにそれおいしいの？ –ご丁寧に毎回cookieでIDとPASSをそのまま送信しているサイトを 過去目撃して絶句しました。 –蓋をあけたら認証はJavaScriptでやっていて、そもそも何も管理さ れてない。 ※この二つについては脆弱性のカテゴリ的には「セッション管理の不備」というよ りかは「アクセス制御の不備」の方が正しいかもしれません。
- 20. 昔、心が折れそうになった時 セッションIDが固定で4ケタくらいの数字だった とある診断員：「これは非常にまずいので、すぐに直してください！開発言語やフレー ムワークが提供しているセッション管理機構を利用してくださいね。」（報告会などで小 一時間説明） 担当者：「わかりました！すぐ修正します！」 修正の結果、その数字がただBase64エンコードされた値になってた 再修正の結果、今度はその数字がただMD5でhash化された値に なってた とある診断員：「、、、とりあえずbase64は簡単にデコードできますよ。いやいやいや、そも そもそういうことじゃなくて、これだと根本的に何も変わってないのですよ。さっきも説明し ましたがry、、、」（伝わってなかったと思ったのでもう一回打ち合わせで小一時間説明） 担当者：「わかりました！すぐ修正します！」
- 21. 対策方法 •基本的には開発言語やフレームワークなどで提供さ れているセッション管理機構利用しましょう。 •そしてその上で適切にセッションIDを利用するような 実装にしましょう。 –ユーザ認証時に再発行する。 –URLパラメータへの格納は避ける。 –HTTSを利用して通信するようにしてかつ、値が格納されている。 Cookieにhttponly属性やsecure属性が付加する。
- 22. 認可制御不備
- 23. 脆弱性の説明 •「認可」とは認証済みの利用者に対して権限 を与えることです。 •この認可の制御に不備があった場合、本来そ のユーザに与えている権限以上の操作が出来 てしまう為、情報漏洩やデータの改ざんなどに つながる可能性があります。
- 24. 診断作業のやり方 事前に必要なもの(通常調整して用意します。) –診断対象サイトにどのような権限があるのかの情報 –違う権限のアカウント情報 実施すること –特定の権限のみが閲覧可能な画面や実行できる機能 を判別します。 –違う権限のアカウントでアクセスしてみて、パラメータ 値などの差分を比較して分析します。
- 25. 1.パラメータ値に登録データなどに紐づくような 値が指定されている場合、その値を操作して みる。 2.本来権限のない機能にURLを変更して直接 アクセスしてみる。 3.パラメータ値で権限クラスを指定していると 推測される場合に、値を変更、追加などを 行ってみる。 典型的なのは以下３パターン
- 26. 1のパターン menu.php 購入履歴 登録情報 ログアウト profile.php?id=18 ユーザ名：太郎 mail：aa@vultest.com 住所：++++**** 電話番号： 09012345678 idの値を改ざん 別ユーザの情報 が見えてしまう！ ログイン後の画面 自分の登録情報が表示 profile.php?id=19 ユーザ名：次郎 mail：bb@vultest.com 住所：----==== 電話番号： 08098765432 別ユーザの登録情報が表示
- 27. 2のパターン 管理者でログイン 購入履歴 登録情報 ログアウト 管理者機能 http://example.jp/menu.php 一般ユーザでログイン http://example.jp/menu.php ユーザ情報一覧 アカウント停止 ロック解除 http://example.jp/admin.php 管理者機能 購入履歴 登録情報 ログアウト リンクは存在せず本来は アクセス不可 管理者機能に アクセスできて しまう！ 直接URLを指定してアクセス
- 28. 3のパターン 「flag=admin」をURLに 追加してアクセス 管理者用の メニューが選択 できてしまう！ 管理者でログイン http://example.jp/news.php?flag=admin お知らせ閲覧 投稿 編集 削除 一般ユーザでログイン http://example.jp/news.php お知らせ閲覧
- 29. 参考 こちらのスライドではもっと細かく権限不備の事例につ いて解説されているので要チェックです！ 「12の事例に学ぶWebアプリケーションのアクセス制御」 http://sssslide.com/speakerdeck.com/appsecapac2014/12-case- studies-for-the-access-controls-of-web-application
- 30. 過去にエンカウントしたもの 全体的にこの脆弱性は今でもそこそこ多く出会います。対策がゆるい アプリが多い気がしますし、対策方法自体が良くわかっていない人も 結構多い気がします。 そもそも開発側で権限をちゃんと定義していることが少ない気がしま す。まともな資料をもらった記憶があまりなく、診断時に大体自分で調 べている気がします。 無課金ユーザで課金ユーザにのみ提供されている機能を使い放題な アプリとかありました。しかもJavaScript制御でメニューがクリックでき ないようになっているだけで、ソース中にバッチリリンクが記載されてお り、その気があれば誰でも2のパターンでいけてます。 診断対象アプリの権限が複雑すぎて、それぞれのユーザ権限では何が できて良くて、何ができちゃダメなのかさっぱりわからなくて泣きそうな 時がありました。傾向として内部で利用する業務用アプリとかにこうい うのが多い気がします。
- 31. 対策方法 そもそも要件定義などの際にユーザの権限については 明確にしておく必要があります。（どの権限ユーザがど の機能、どのリソースに対してアクセスできるのかな ど。） 操作を行っているユーザが適切な権限を持ったユーザ であるかちゃんと確認するロジックを実装しましょう。 権限情報やユーザ情報などについては外部パラメータ で持たずセッション変数に格納してサーバ側で保持す るようにしましょう。
- 32. パラメータ値の改ざん
- 33. 脆弱性の説明 •Webアプリケーションが本来想定をしているも のとは、違うパラメータ値を受け渡した場合に、 想定してないセキュリティ不備が発生する可能 性があります。
- 34. 見つけ方 診断する前に まず、そもそもこのアプリは何をするものなのか、内容を良く理解す ることが大切な気がします。 やること –一通りサイトを適当にクロールしてみます。 –パラメータ表をなどを眺めます。 –とりあえずなんか色々いじってみます。 必要なもの –勘 –過去の経験 –ひらめき
- 35. パラメータを改ざんすることで色々夢が広がりました。 –なんと商品の値段が0円になり無料でお買い物が！ –ポイントを無限に増やせた！ –キャンペーン期間に関係なく、限定アイテムをGET！ –ゲームのチートができた！ –バッチ処理がこけてすごく怒られた！ カートに商品を入れた際になぜか在庫から減る仕様とかになっていて、た めしに9999個商品をカートにいれたら他の客がその商品を購入できなく なりました。 情報を閲覧する処理で、キー値となっているパラメータごと消去すると、全 然別のユーザ情報が表示されることとかありました。（恐らく、ＤＢ側の一番 上のレコードの情報が検索結果として返ってきたのではないかと推測。） 折角頑張って見つけても、「後の運用時の確認で、矛盾が拾えるんで大丈 夫っス！」とか元気よく言われて、結局直してくれなくて悲しい気分になる。 （特に決済処理とかのはこの傾向がある。。。） 過去にエンカウントしたもの
- 36. 対策方法 外部から受け渡す必要がないパラメータはサーバ側 （セッション変数、データベース内、ソースコードにハー ドコーティングなど）で保持するようにしましょう。 URLやhiddenパラメータ、クッキー、HTTPヘッダなど については基本的にクライアント側で全て書きかえる ことが可能なので、それを想定した実装にすることが 必要です。
- 37. まとめ やっぱりWebアプリはちゃんと実装しないと怖 いですね。セキュアコーディングを意識して開発 しましょう！ 安全なWebアプリを作る上では、どういう観点 で、防御しなければならないか理解するために 攻撃側の視点も必要だと思います。 少しでもWebセキュリティーに興味を持っていた だければ幸いです！