アジャイルでの脆弱性診断サイクル~Securifyを使ったWebアプリケーション診断~
物欲と食欲が無限大の「ぎだじゅん」です。
ライフイズテックという会社でサービス開発部 インフラ/SREグループに所属しています。
リモートでずっと自宅で仕事をしていると、定期的に部屋のレイアウトを変えてリフレッシュしたくなりますよね。
年齢的にも長い人生を過ごしてきたこともあり、自分の部屋にはいろいろ思い出の詰まった捨てられないモノがたくさんあり、断捨離できない私はミニマリストのような洗礼された部屋には到底たどり着けません。
そんなモノにあふれる自分の理想の部屋のレイアウトは、Tiny Desk Concertのように、壁にモノがたくさんレイアウトされているおもちゃ箱のような部屋です。
このTiny Desk Concertとは、アメリカの公共ラジオ局であるNPR（National Public Radio）がYoutubeなどで配信しているライブ映像で、NPRのオフィス内のデスクのある一角の狭い空間でアーティストが演奏を披露する企画です。
世界の著名なアーティストや注目株のニューカマーなどが、大がかりなPAや照明がない小さな空間でオーディエンスもスタッフのみという中で、普段のライブのような演出のきかない状況でアーティスト自身の技量が浮き彫りになってとても面白いです。
アメリカのラジオ局の企画ですが、日本からもコーネリアスやCHAI、上原ひとみなどが出演しています。
以下は先日解散したCHAIと、昨年の5月に東京でのライブを見て感動したDOMi & JD BECKによるTiny Deskのライブ映像ですが、狭い空間でも壁一面のモノに囲まれて気持ちをポップにさせるかのようで、映像を観る方もテンションが上がります。
自分もこの空間のように、捨てられない大好きなモノを壁に並べてレイアウトしていますが、モノが多くてレイアウトを変更するにも労力と時間を要するため、レイアウト変更ができずにいます。
また、ホコリが細かい箇所にたまったりするので、お掃除もとても大変です。
継続的なレイアウト変更や掃除って難しいですよね・・・。
そんなわけで若干リフレッシュできなくなってきた今の空間の中で、この投稿を頑張って書いてます。
本題です。
前回のおさらい
前回、DevSecOpsの実現に向けた取り組みについて説明しました。
その中でアプリケーション開発におけるセキュリティ対策について、以下のようなサービスを活用して実現している旨を紹介しました。
アプリケーション開発における対策
Snyk Open Source によるOSSパッケージやライブラリの脆弱性チェック（SCA）
Snyk Code によるコードの脆弱性チェック（SAST）
ビルドやリリース工程における対策
Snyk Container におけるコンテナイメージの脆弱性チェック（SCA）
Securify によるWebアプリケーションの脆弱性チェック（DAST）
これらのサービスを使って、Webアプリケーションに潜む脆弱性に対して、シフトレフトの考え方で、開発サイクルの中でセキュリティの取り組みを早い段階でおこなうことで、リリース直前でセキュリティに関する脆弱性検出によりリリースを延期するなどのリスクを軽減させています。
前回は、Snykを使ってアプリケーション開発者が作成するコードや、オープンソースライブラリ、コンテナイメージの安全性を継続的に確保していることを紹介しましたが、今回はアジャイルでの開発サイクルの中で、公開するWebアプリケーションに対して、どのように脆弱性診断をしているかを紹介します。
アジャイル時代のWebアプリケーション診断
昨今のWebアプリケーションによるプロダクトでは、速いスピードで変わっていく消費者のニーズや新しいテクノロジーに対応していくため、アジャイルでのスプリント開発のように機能開発や修正において「設計」→「コーディング」→「テスト」→「リリース」の開発サイクル全体を小さくて短い期間の単位で進めていく必要があります。
Webアプリケーションにおいては、サービスリリース時はもちろんのこと、機能追加や修正した箇所には脆弱性が潜んでいる可能性があることからも、この開発サイクルの中で継続的にWebアプリケーションに対しての脆弱性の診断を行うことはとても重要です。
診断の工程の中でDAST(Dynamic Application Security Testing/動的アプリケーションセキュリティテスト)と呼ばれる診断では、実際にアプリケーションが動作している環境に対して、外部からの攻撃をシミュレーションした操作によって脆弱性がないかをチェックを行います。
実際の環境（または同等の環境）に対して診断を行うため、実際に公開されるサービス上に潜む脆弱性を洗い出せることからも、とても有効な診断と言えます。
継続的に実施するにあたっての課題
一般的なWebアプリケーションの脆弱性診断では、対象のWebアプリケーションへのリクエストを想定したシナリオを用意したり、APIの仕様に合わせて診断対象先のURLをシミュレートしたリストを用意して診断を行います。
そのため、スプリント開発の中で継続的に診断をおこなうには、追加した機能に対してシナリオを都度追加や修正したりする必要があるため、継続的に診断を実施するには手間がかかるケースがあります。
また、Webアプリケーションの脆弱性診断では、本来はセキュリティの専門的な知識を持つ人が調査して結果や対策をレポートすることからも、自社ですべてを運用するには難易度は高く、外部の専門業者へ依頼するとなると頻度やコストからも現実的に厳しいところがあります。
とはいえ、できる限り開発サイクルの中で継続的に診断を実施することは重要ですので、これらの課題を解決できそうなツールやサービスがないかを調べ、弊社ではSecurifyというサービスを導入しました。
Securify
Securifyは、スリーシェイク（3-shake）が提供するセキュリティ診断サービスです。
Securifyでは以下の診断サービスを提供しています。
Securifyの診断環境からWebアプリケーションやAPIに対しての脆弱性を診断
SaaSのドライブ（GoogleドライブやOneDriveなど）にあるファイルの公開状態を診断
設定が公開状態になっていないかなどWordPressに特化した設定不備の脆弱性を診断
弊社では、前段で説明したDASTの役割として継続的に診断するためにこちらのサービスの中で「Webアプリケーション診断」を活用しています。
ちなみに、Securifyの「Webアプリケーション診断」は、経済産業省の「情報セキュリティサービス基準」の脆弱性診断サービスに適合しているそうです。
Securifyの「Webアプリケーション診断」は、前段でもあった継続的な診断実施に対する課題も含め、以下のメリットがあり導入にいたりました。
簡単な設定で診断対象を自動でクローリングして診断するため、シナリオの追加作成がほぼ不要
アカウント認証のあるWebアプリケーションも診断可能
一般的な診断項目を網羅
分かりやすい診断結果の出力（検出された脆弱性に対しての修正方法の提案など）
クローリングできない箇所があっても個別にシナリオ診断も可能
診断回数ではなく診断対象単位（FQDN単位）での課金体型
熱量が高いサポート
これらに該当する項目について、以下にて説明します。
1. 簡単な設定で利用可能
一般的なWebアプリケーションの脆弱性診断では、診断対象の箇所をシナリオとして作成する必要などがありました。
Securifyの「Webアプリケーション診断」では、基本は診断対象のWebアプリケーションのURLのドメイン（FQDN）を登録して、プロジェクトで診断開始するページなどを指定して開始するだけの簡単な設定で、Webアプリケーション内をクローリングして診断対象先を自動で見つけて診断をおこなってくれます。
また、Webアプリケーションによっては、サービスアカウントによる認証を経て利用するものもありますが、Securifyではこのログイン認証部分をChromeのデベロッパーツールによるレコーダー認証 を使って認証フェーズのシナリオをJSON形式で作成することで、認証後のWebアプリケーション内もクローリングして診断してくれます。
どのような設定で利用開始できるかを説明します。
Step1: ドメイン所有者の確認
診断対象のWebアプリケーション（サイト）が診断実施者の所有するものかを確認するため、対象のURLのドメイン（FQDN）に対して、以下のいずれかの認証をおこないます。
DNSレコードによる認証（DNSにて指定のTXTレコードを設定する）
TXTファイルによる認証（サイト上に指定のテキストファイルを設置する）
Step2: プロジェクトの作成
診断対象ごとにプロジェクトとして作成して、プロジェクトの中で各種診断の設定や診断結果を管理します。
Step3: 診断対象の指定（基本設定）
作成したプロジェクト内で診断対象の設定をおこないます。
最初に、「新規登録」メニューから「WEBアプリ診断」を選択すると、以下の設定画面が表示されます。
ここではプロトコルと、ホスト名、ポート番号（プロトコルがHTTPSの場合は大抵443だと思いますが、443以外も指定可能）を指定し、あとは診断開始するパスを指定します。
ホスト名は、Step1で登録して所有者確認ができたドメイン（FQDN）がセレクトメニューで選択できるようになります。
診断開始するパスは後で説明しますが、認証設定などを介して診断される場合などで診断をスタートさせたいページがあれば、診断開始するページのパスを指定します。
Step4: その他の３つの設定
Step3までの設定でおおよその診断は開始できますが、診断対象の環境内容に応じて以下の設定もおこなうことで、Webアプリケーション上での認証を通過しての診断や、診断完了の通知、複数のURLドメイン（FQDN）で構成されている場合に他のドメインも診断に含むように追加することができます。
＜認証設定＞
診断対象のWebサイトでBasic認証やログイン認証がある場合はここで設定をおこないます。
「Basic認証」では、認証用の「ユーザ名」と「パスワード」を入力します。
「ログイン認証」では、Chromeブラウザのデベロッパーツールにあるレコーディング機能を使ってログインの認証までの工程をレコーディングすることで生成されるJSON形式のシナリオファイルを使います
そのシナリオファイルをここでアップロードすることでログインした後のWebアプリケーションをクローリングできるようになります。
（詳しくは レコーダー認証 と レコーダー認証のトラブルシューティングガイド をご覧ください）
ここの画面で「Basic認証あり」や「ログイン設定あり」を選択して設定
認証設定ができたら、右上の「疎通確認」ボタンを押すと設定した内容で認証が通るかを確認できます。
＜通知設定＞
通知設定では完了の通知先を「メールアドレス」や「Slack」、「Teams Webhook」の通知方法から選択して通知設定ができます。
通知先は、「メールアドレス」の場合は、チームページの「メンバー管理」で登録したメンバーのメールアドレスから選択できるようになり、「Slack」と「Teams Webhook」の場合は、チームページの「通知設定」から登録してそれぞれの連携先の認証（アプリ追加）をすることで、選択できるようになります。
＜詳細設定＞
詳細設定では以下の設定を必要に応じて設定します。
この詳細設定の中で注意しておきたい必要な設定が「攻撃的な診断を許可」と「診断スコープの設定」です。
「攻撃的な診断を許可」については、有効にすることで攻撃的なチェックやフォームへの投稿によるチェックなどがおこなわれるため、攻撃パターンの内容での投稿が大量にデータベースやログに記録される場合があります。
有効にしたほうがより実際の攻撃に近い診断が可能となりますが、本番環境への診断はサービスへの影響が出ますのでご注意ください。
「診断スコープの設定」は、診断対象のWebアプリケーションで複数のURLドメイン（FQDN）が対象となる場合に、Step3 の「診断対象の指定」のホスト名で設定したURLドメイン（FQDN）以外の対象のドメイン（FQDN）をここで指定します。
例えばシングルページアプリケーション（SPA）などの構成の場合は、フロントアプリケーションとバックエンドのAPIとでURLドメイン（FQDN）が異なる場合があります。
その場合は Step1 の「ドメイン所有者の確認」で両方のURLドメイン（FQDN）を登録しておき、Step3 の「診断対象の指定」のホスト名では、フロントアプリケーションのURLドメイン（FQDN）を指定し、この「診断スコープの設定」ではバックエンドのAPIのURLドメイン（FQDN）を指定します。
いろいろ書きましたが、最初に利用したときにほとんどマニュアルを見ずに診断開始までおこなえて、とてもわかりやすいUIで直感的に操作できました。
これらの設定をして「即時診断」を実施すると、診断が開始できます。
とっても簡単な設定で診断開始できるのがSecurifyの大きな特徴です。
2. 診断項目について
SecurifyのWebアプリケーション診断では、SQLインジェクションやOSコマンドインジェクションのようなインジェクション攻撃、クロスサイトスクリプティング、パストラバーサル、アプリケーションやサーバ環境の設定不備などを検出してくれます。
また、診断項目はセキュリティに関する専門家により、セキュリティ対策における最前線の情報を収集して、これらの診断機能を常時アップデートしているそうです。
3. 分かりやすい診断結果
また、わかりやすくで詳細な診断結果も大きな特徴の一つです。
セキュリティ専門家からの説明などはない代わりに、開発経験のあるエンジニアなどであれば理解できるような内容で、検出された脆弱性の危険度レベルや概要、どのようにして検出されたかの内容や代表的な修正方法の提案などをWeb画面上でフィードバックしてくれます。
（PDF形式によるレポート出力も可能です）
「診断結果」より確認できる内容では、検出された脆弱性の一覧から、それぞれの脆弱性に対してのフィードバックなどを確認できます。
これらの診断結果にあるスコアや危険度レベル、フィードバックの内容から開発エンジニア側と相談して対応の優先順位や対応方針などのトリアージを行います。
画面上の上の部分では検出された脆弱性を5つのレベルで判定してくれたり、結果をスコア表示してくれます。
また、「検出結果」の一覧では検出された脆弱性に対して「対応」または誤検知や受容などによる「除外」のようにステータスを付与して管理もできます。
「フィードバック」の内容では、検出された脆弱性の概要の説明だけでなく、実際に判断した根拠となるリクエスト/レスポンスの表示や代表的な修正方法の提案についても提示してくれることで、開発エンジニアに対しても検出された脆弱性や対策方法の例について、わかりやすく説明してくれます。
「診断パス」の画面では診断でクローリングしたパスも一覧で確認できるので、診断箇所に漏れがないかの精査を一覧から確認ができます。
4. 手動でのシナリオ診断も可能
自動で診断対象をクローリングしてくれる便利さはとても素晴らしいですが、診断パスの一覧などを確認して、診断対象から漏れている箇所がある場合もあります。
（フォームなどの入力で正しい値を入れないと先に進めないようなページなど）
そのような場合も、Chromeブラウザのデベロッパー ツールにあるレコーディング機能を使って漏れのあった箇所の工程をレコーディングしてJSON形式のシナリオファイルを作成して、該当の箇所単位で「シナリオ診断」を設定して実施することでカバーもできます。
その他にも、Webアプリケーション診断では、以下の機能も提供しています。
APIを対象としたAPI診断(REST API)
Webアプリケーションのバックエンド（API）に対してのみ診断したいなどのケースにおいて、Web上にアップロードされたOpenAPI の定義ファイル（yaml形式のファイル）のURLを指定することで、定義ファイルに記載されているAPIに対して診断を行う
Securify APIによる診断開始
Securifyの公開APIを利用し、APIを通して診断開始を指示させることで、CI/CDパイプラインの中で開発環境などにデプロイしたタイミングで自動で診断を開始させるようなことで、リリースサイクルに組み込むことも可能
5. 料金体系について
セキュリティ専門家によるWebアプリケーションの脆弱性診断サービスなどでは、専門家が専門的なツールを使ってシステムの脆弱性を調査し、調査結果をレポートにまとめて結果報告する手厚いサービスもあります。
ただ、1回あたりの診断費用がとても高額であることや、現在の開発サイクルの中で継続的に実施するのはコストやスケジュール的にも現実的ではありません。
SecurifyのWebアプリケーション診断サービスにおいては、料金体系が実施回数あたりの課金ではなく、診断対象のFQDN数による課金のため、弊社の開発サイクルにおいて継続的な診断を実施しても料金が据え置きなのが、とてもありがたいです。
ただ、課金対象がFQDN数で変わるため、シングルページアプリケーション（SPA）の構成などでよくあるような、フロントページ用のFQDN（例えば https://example.jp ）とバックエンドのAPI用のFQDN（例えば https://api.example.jp ）のように、複数のFQDNで構成されているWebアプリケーションでは、構成されるFQDN数が課金対象となります。
6. サポートについて
Securifyのカスタマーサポートについては、基本は営業時間帯でのメール対応のみ（STARTERプラン、BASICプラン）ですので、一般的なSaaSサービスと同じような内容と思います。
ただ、これまでのSecurifyの方とのやり取りの中で、利用者の問題に対して、真摯に向き合って対応してくれている印象がありました。
最初にSecurifyの導入を検討するにあたって無料のプランにて検証を行いました。その時の検証ではWebアプリケーションのログイン認証が診断では突破できず、認証後のWebアプリケーション内のクロールができず診断できなかったことから導入を見送っていました。
しかし、しばらくたって営業担当の方から連絡をいただき、診断でのログイン認証処理の仕様が変わったことで診断できるようになったかもしれないので、再度検証してほしいと連絡がありました。
再度試させていただいたところ、ログイン認証を突破して診断ができるようになっていました。
弊社以外にも同様の問題を抱えていた企業が多かったのかもしれませんが、検証時の問題で導入を見送っていたことを覚えてくれていて、契約してないのに対応できたことを連絡してくれたり、日々使っている中で課題などがないかを聞いてくれたりと、Securifyの関係者がみんなでよいサービスにしようとする熱量を感じ、私も自社サービスを運用しているメンバーの一員として見習わなければと勉強させてもらっています。
ということで、Webアプリケーション診断を継続的に行うようにSecurifyを使っての診断を開始しました。
現状では診断頻度はまだ開発側の状況と調整しながら試行錯誤はしていますが、継続的な診断へ向けて少しずつ進めております。
専門家による脆弱性診断も必要だけど
このSecurifyなどのDASTによる診断は、Webアプリケーションの一般的な攻撃のシミュレーションによって定型化された攻撃パターンに該当する脆弱性を自動的に検出するものになります。
実際にハッカーなどの攻撃者が脆弱性やシステムの設定不備、セッション管理や認可制御の不備などを利用して、Webアプリケーションが稼働するシステム内へ侵入できるかや、侵入後にシステム内にあるデータや機密情報などを実際に盗み出すことができるかどうかなどまではDASTの診断だけでは判断は難しいです。
これらの課題に対応できるものとして、ペネトレーションテストや専門家による手動診断などもありますが、脆弱性診断に関する知識やスキルのある専門家にてシステムやアプリケーションの仕様を把握したうえで診断方針や範囲を決定して、一定の期間をかけて診断を行うため、スプリント開発でのリリースの都度でのテスト実施はとてもできません。
これについては、サービスのメジャーバージョンアップ時や定期的な監査目的で年次のタイミングで行うのがよいと考えています。
すぐにペネトレーションテストや専門家による手動診断を実施するのは準備などから時間がかかったりすることもあるので、公開しているWebアプリケーションサービスに対して脆弱性の診断をしていない方などは、まずはSecurifyのような自動の脆弱性診断から導入することをお勧めします。
最後に
今回、シフトレフトによる施策の中で継続的にWebアプリケーションの脆弱性診断を実現するために使用しているサービス「Securify」を紹介しました。
前回紹介したSnykや今回紹介したSecurifyは基本はチェックや診断の回数による課金ではないため、開発サイクルが早くてチェックを実施する回数が多くなりそうな現在の開発プロセスにはもってこいのサービスだと思います。
なお、Securifyについては、スリーシェイク（3-shake）の導入事例でインタビューもしていただきましたので、こちらも是非ご覧ください。
写真はAIで生成された人物です（嘘）。
余談ですが note さんでもSecurifyを活用されているようです。
Webアプリケーションの脆弱性診断も、部屋の掃除と同様に埃がたまらないように継続的に行うことが大事ですね。
いろんなサービスベンダーさんと仲良くなれる今の会社はとてもいい会社なので、興味のある方はこちらも是非見てみてください。
あと、気軽にご参加いただけるカジュアルなイベントもたまに実施していますので、興味のあるイベントがあれば、ぜひ参加してみてください。