Web Application Vulnerabilities

すみだセキュリティ勉強会 2014 #3 @tigerszk

2014/09/14

自己紹介

セキュリティエンジニアやってます。

脆弱性診断業務を担当しており、専門はWebセキュリティです。

趣味で脆弱性の検証したり、最近はCTFイベントなどに参加してたりします。

TwitterID: tigerszk

Webアプリの脆弱性ってどんなの？

Webアプリの脆弱性達

SQLインジェクション

OSコマンドインジェクション

パス名パラメータの未チェック/ディレクトリ・トラバーサル

セッション管理の不備

クロスサイト・スクリプティング

CSRF

HTTPヘッダ・インジェクション

メールヘッダインジェクション

アクセス制御や認可制御の欠落

IPA「安全なウェブサイトの作り方」より https://www.ipa.go.jp/security/vuln/websecurity.html

例えばこんなのがありますね

どうやって見つけるの?

ブラックボックステスト

疑似攻撃を試行し、対象システムの挙動から脆弱性の存在有無を調査する

ホワイトボックステスト

設計書、仕様書、コンフィグファイル、ソースコードなどを精査して脆弱性を洗い出す

今回はこっちのお話

一般的なWebアプリの診断方法

ツール診断＋マニュアル診断の

ハイブリッド診断

とかってよく言われていますね。

診断ツールのやっていること

ブラックボックステストの診断ツールは、本来手動でもできる検査作業を単純に自動化しただけです。

作業時間短縮＆作業内容の標準化などのために一般的にツールを利用しています。

ただ、診断ツールは万能なものではないので、Webアプリ診断はツールを使うだけでは網羅的に診断をすることができません。

診断ツールにも苦手な部分がある

診断ツールを上手く使うにはポイントがあります。

利用する診断ツールが「得意とする部分」、「苦手とする部分」をちゃんと理解しておくこと

診断ツールが「苦手な部分」については、手動での診断作業を行います。

手動でやる診断作業は何やるの？

• 診断ツールを上手く使うためのサイト分析

• 診断ツールが検出した脆弱性の確認

• 診断ツールでは正常に検査できないと想定される箇所・機能の診断

• 診断ツールでは検出することが難しいと想定される脆弱性項目の診断

本日のテーマ

脆弱性を見つける手動の診断作業はなかなか楽しく、個人的にはWebアプリ診断の醍醐味なのかなと思っています。

今回はその内のいくつかの脆弱性について見つけ方や過去自分が遭遇した事例についてお話したいと思います。

使うもの

手動診断には定番のローカル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達

今回ご紹介する脆弱性達

これらの脆弱性は一般的に診断ツールでは検出しにくい脆弱性だと思います。

• セッション管理の不備

• 認可制御不備

• パラメータ値の改ざん

セッション管理の不備

セッション管理って？

Ｗｅｂアプリではユーザの状態管理を行う仕組みとしてセッション管理機構というものがあります。

Aさん

id:user pass：password

A子さんと判別

Aさんに公開するべき情報

…

A子さんと判別

sessionid=abc123

sessionid=abc123

A子さんを認証

sessionid=abc123 セッションIDがセット

不備ってどういうこと？

• 「セッション管理の不備」とはアプリ側が提供しているセッション管理の仕組みがよろしくない作りをしているということです。

• よろしくない作りをしている場合には、攻撃者にセッションIDの値を推測されたり盗難される可能性が高まってしまいます。

セッションＩＤがパクられると

「セッションハイジャック」されてしまう

Aさんに公開するべき情報 Aさん

Aさんに公開するべき情報 攻撃者

盗難 or 推測

なりすまし

A子さんと判別

A子さんと判別

sessionid=abc123

sessionid=abc123

診断作業のやり方

診断対象アプリにおいて、一体何の値が、セッションIDとして用いられているのかをまず分析して特定します。

特定した値が、ちゃんと適切な作りになっているのかを確認していきます。

よろしくない作りの例

強度が弱いセッションIDを発行している – 推測されやすい値が利用されてる

– ユーザごとに毎回固定の値が利用されてる

ユーザ認証時にセッションIDが再発行されていない

URLにセッションIDが埋め込まれている

値が格納されているCookieにhttponly属性やsecure属性が付加されていない

…etc

過去にエンカウントしたもの-その1-

過去色々酷いセッションIDを見かけました。

– ユーザごとに固定でかつ数字だけで構成

– ユーザID、MSN番号などがモロそのまま

– ↑だと流石にちょっと後ろめたかったのか、base64エンコードしたり asciiコードに変換したりと若干小細工をしているもの

– 単純な生成ルールのもの(例：ユーザID＋タイムスタンプ)

過去にエンカウントしたもの-その2-

折角フレームワークのセッション管理利用していても… 折角フレームワークとかのセッション管理機構を利用していても、ユーザの判別はなぜか別の外部パラメータを利用している残念ケースとかもあります。しかも値が数字とかorz...

セッション管理？なにそれおいしいの？ – ご丁寧に毎回cookieでIDとPASSをそのまま送信しているサイトを過去目撃して絶句しました。

– 蓋をあけたら認証はJavaScriptでやっていて、そもそも何も管理されてない。

※この二つについては脆弱性のカテゴリ的には「セッション管理の不備」というよりかは「アクセス制御の不備」の方が正しいかもしれません。

昔、心が折れそうになった時

セッションIDが固定で4ケタくらいの数字だった

とある診断員：「これは非常にまずいので、すぐに直してください！開発言語やフレームワークが提供しているセッション管理機構を利用してくださいね。」（報告会などで小一時間説明） 担当者：「わかりました！すぐ修正します！」

修正の結果、その数字がただBase64エンコードされた値になってた

再修正の結果、今度はその数字がただMD5でhash化された値になってた

とある診断員：「、、、とりあえずbase64は簡単にデコードできますよ。いやいやいや、そもそもそういうことじゃなくて、これだと根本的に何も変わってないのですよ。さっきも説明しましたがry、、、」（伝わってなかったと思ったのでもう一回打ち合わせで小一時間説明） 担当者：「わかりました！すぐ修正します！」

対策方法

• 基本的には開発言語やフレームワークなどで提供されているセッション管理機構利用しましょう。

• そしてその上で適切にセッションIDを利用するような実装にしましょう。 – ユーザ認証時に再発行する。

– URLパラメータへの格納は避ける。

– HTTSを利用して通信するようにしてかつ、値が格納されている。Cookieにhttponly属性やsecure属性が付加する。

認可制御不備

脆弱性の説明

• 「認可」とは認証済みの利用者に対して権限を与えることです。

• この認可の制御に不備があった場合、本来そのユーザに与えている権限以上の操作が出来てしまう為、情報漏洩やデータの改ざんなどにつながる可能性があります。

診断作業のやり方

事前に必要なもの(通常調整して用意します。)

– 診断対象サイトにどのような権限があるのかの情報

– 違う権限のアカウント情報

実施すること

– 特定の権限のみが閲覧可能な画面や実行できる機能を判別します。

– 違う権限のアカウントでアクセスしてみて、パラメータ値などの差分を比較して分析します。

1. パラメータ値に登録データなどに紐づくような値が指定されている場合、その値を操作してみる。

2. 本来権限のない機能にURLを変更して直接アクセスしてみる。

3. パラメータ値で権限クラスを指定していると推測される場合に、値を変更、追加などを行ってみる。

典型的なのは以下３パターン

1のパターン

menu.php

購入履歴 登録情報 ログアウト

profile.php?id=18

ユーザ名：太郎 mail：aa@vultest.com 住所：++++**** 電話番号：

09012345678

idの値を改ざん

別ユーザの情報が見えてしまう！

ログイン後の画面 自分の登録情報が表示

profile.php?id=19

ユーザ名：次郎 mail：bb@vultest.com 住所：----==== 電話番号：

08098765432

別ユーザの登録情報が表示

2のパターン 管理者でログイン

購入履歴 登録情報 ログアウト 管理者機能

http://example.jp/menu.php

一般ユーザでログイン

http://example.jp/menu.php

ユーザ情報一覧 アカウント停止 ロック解除

http://example.jp/admin.php

管理者機能

購入履歴 登録情報 ログアウト

リンクは存在せず本来はアクセス不可

管理者機能に アクセスできてしまう！

直接URLを指定してアクセス

3のパターン

「flag=admin」をURLに追加してアクセス

管理者用の メニューが選択できてしまう！

管理者でログイン

http://example.jp/news.php?flag=admin

お知らせ閲覧 投稿 編集 削除

一般ユーザでログイン

http://example.jp/news.php

お知らせ閲覧

参考

こちらのスライドではもっと細かく権限不備の事例について解説されているので要チェックです！

「12の事例に学ぶWebアプリケーションのアクセス制御」

http://sssslide.com/speakerdeck.com/appsecapac2014/12-case-studies-for-the-access-controls-of-web-application

過去にエンカウントしたもの 全体的にこの脆弱性は今でもそこそこ多く出会います。対策がゆるいアプリが多い気がしますし、対策方法自体が良くわかっていない人も結構多い気がします。

そもそも開発側で権限をちゃんと定義していることが少ない気がします。まともな資料をもらった記憶があまりなく、診断時に大体自分で調べている気がします。

無課金ユーザで課金ユーザにのみ提供されている機能を使い放題なアプリとかありました。しかもJavaScript制御でメニューがクリックできないようになっているだけで、ソース中にバッチリリンクが記載されており、その気があれば誰でも2のパターンでいけてます。

診断対象アプリの権限が複雑すぎて、それぞれのユーザ権限では何ができて良くて、何ができちゃダメなのかさっぱりわからなくて泣きそうな時がありました。傾向として内部で利用する業務用アプリとかにこういうのが多い気がします。

対策方法

そもそも要件定義などの際にユーザの権限については明確にしておく必要があります。（どの権限ユーザがどの機能、どのリソースに対してアクセスできるのかなど。）

操作を行っているユーザが適切な権限を持ったユーザであるかちゃんと確認するロジックを実装しましょう。

権限情報やユーザ情報などについては外部パラメータで持たずセッション変数に格納してサーバ側で保持するようにしましょう。

パラメータ値の改ざん

脆弱性の説明

• Webアプリケーションが本来想定をしているものとは、違うパラメータ値を受け渡した場合に、想定してないセキュリティ不備が発生する可能性があります。

見つけ方

診断する前に まず、そもそもこのアプリは何をするものなのか、内容を良く理解することが大切な気がします。

やること – 一通りサイトを適当にクロールしてみます。 – パラメータ表をなどを眺めます。 – とりあえずなんか色々いじってみます。

必要なもの – 勘 – 過去の経験 – ひらめき

パラメータを改ざんすることで色々夢が広がりました。 – なんと商品の値段が0円になり無料でお買い物が！ – ポイントを無限に増やせた！ – キャンペーン期間に関係なく、限定アイテムをGET！ – ゲームのチートができた！ – バッチ処理がこけてすごく怒られた！

カートに商品を入れた際になぜか在庫から減る仕様とかになっていて、ためしに9999個商品をカートにいれたら他の客がその商品を購入できなくなりました。

情報を閲覧する処理で、キー値となっているパラメータごと消去すると、全然別のユーザ情報が表示されることとかありました。（恐らく、ＤＢ側の一番上のレコードの情報が検索結果として返ってきたのではないかと推測。）

折角頑張って見つけても、「後の運用時の確認で、矛盾が拾えるんで大丈夫っス！」とか元気よく言われて、結局直してくれなくて悲しい気分になる。（特に決済処理とかのはこの傾向がある。。。）

過去にエンカウントしたもの

対策方法

外部から受け渡す必要がないパラメータはサーバ側（セッション変数、データベース内、ソースコードにハードコーティングなど）で保持するようにしましょう。

URLやhiddenパラメータ、クッキー、HTTPヘッダなどについては基本的にクライアント側で全て書きかえることが可能なので、それを想定した実装にすることが必要です。

まとめ

やっぱりWebアプリはちゃんと実装しないと怖いですね。セキュアコーディングを意識して開発しましょう！

安全なWebアプリを作る上では、どういう観点で、防御しなければならないか理解するために攻撃側の視点も必要だと思います。

少しでもWebセキュリティーに興味を持っていただければ幸いです！