この投稿は、2024年JINSのアドベントカレンダー6日目の記事です。
診断外注したいけど・・・
みなさん脆弱性診断ってみたことありますか？
Webサイトをリリースするときは当然診断するかと思いますが、弊社でもリリース時に毎回実施しています。
といっても内製で診断部隊を抱えているわけではなく、診断サービスのあるベンダーへ依頼するのですが、「じゃあ診断してほしいんでよろしく！」・・・で終わるわけではないので今回はそんなお話です。
何をどこまで診断してほしいのか
診断するにあたってまずは計画を立てなきゃなのですが、要はどんなサービス、システムがあるのでどの部分をここまで診断したい、と明確化する必要があります。
(作りが単純なサイトであれば、TopページのURLのみからクローリングして診断箇所をベンダーが洗い出してくれる場合もあります。)
脆弱性診断ってどんなのがあるの？
どの診断ベンダーもたいていは診断サービス下記を提示しています。
まずは今回診断したいシステムはどれに当てはまるかを考えます。
- Webサイトへの診断
- REST APIへの診断
- モバイルアプリの診断
- (ペネトレーションテスト) ※これは弊社ではやったことないので割愛、いつかやりたいです
何を見積もるんだっけ？
ここを考えるにはそもそも脆弱性診断って何をやってるんだっけ？を考える必要があります。
脆弱性っていろいろありますが、例えば・・・
- XSS -> javascriptの文字列を無理やり入力する
<script>alert(1)</script>
- SQLインジェクション -> SQL文の文字列を無理やり入力する
name' OR 'a'='a
- コマンドインジェクション -> OSコマンドの文字列を無理やり入力する
;/bin/sleep 20;
いずれも、何かの文字列を無理やり入力しています。
つまり、攻撃者が自分たちのシステムに無理やり何かを入力するとしたらどこか、を洗い出します。
さきほどの診断サービスごとに当てはめると以下。
- Webサイトへの診断ではWebページの画面数(もっというと各ページ上の入力ボックス)
- REST APIへの診断ではAPIの数(もっというと各APIのパラメータ)
- モバイルアプリの診断ではアプリの種類と画面数(※ただアプリは入力値検査よりバイナリ解析メイン)
システム構成から考えよう
診断対象の数を洗い出した後は、どこまで診断対象にするかを考える場合もあります。
よくあるのがAPIが公開/非公開あるもの。
非公開だったら診断必要ないかというと絶対にそうではなく、SSRFなども考えられるため可能であれば診断したいところです。
とはいえこの場合判断難しく、例えばフロントのWebページでの入力値に非公開側が左右されるので診断対象とする場合や、非公開側へアクセスする方法を診断ベンダーに提供できずやむなく診断対象外にする場合などそれぞれだったりします。
必要な情報を集めよう
診断対象が決まったところで、後は診断してもらうのに必要な参考情報を集めましょう。
いつもはだいたい以下の情報を取りまとめしています。
- 画面遷移図
- URL一覧
- API仕様書
- 各APIパラメータ
- リクエストサンプル
- 認証方法
- 診断中禁止項目はあるか
- 大量にリクエストを行わないでほしい
- データ登録操作はしないでほしい
- etc...
- 構成している技術スタック(使用言語やフレームワーク、インフラ構成など)
- WAFは診断中は外すこと(運用開始後に万が一WAFが迂回され攻撃うけることを想定)
そして発注へ・・・
以上でベンダーに診断を依頼します。
ただし、最後に大事なポイントが。
診断ベンダーにも対応スピード、対応人員に限りがあるので時間に余裕をもって依頼しましょう。
よくあるペースとしては、
- 診断3か月前にベンダーへ打診
- 診断1か月前に情報が出そろい正式見積もり
- 約1か月程度で診断実施および診断報告書受領
- 必要に応じて再診断
この調整がうまくいかないと診断時期見直しやリリース時期のリスケになったりします。
あと、冬場は年度末だからかよくベンダー側診断員が出払っているっぽいです。
早め早めで動きましょう。
というわけで今回はここまでになります。
それではまた次の機会にお会いしましょう～
Discussion