脆弱性診断で検出される問題について（エンジニア向け）

脆弱性診断とは何かについて詳しく知りたい⽅は脆弱性診断とは(エンジニア向け)と脆弱性診断とは(⾮エンジニア向け)もぜひご参照ください。

別の記事でも触れた脆弱性診断で検出される問題について、ここではもう少し技術的な観点から解説していきます。重複する部分もありますが、脆弱性の発⽣原因は以下の通りに分類して考察していきます。

脆弱性の発⽣原因の分類

明確な定義はありませんが、Webサイトを構築・運⽤する上で発⽣する脆弱性は以下の6つのパターンに⼤別することができます。

1. Webアプリケーションの設計にまつわる問題
2. Webアプリケーションの実装にまつわる問題
3. サーバー設定に関する不備
4. 古いソフトウェアを利⽤することで⽣じる問題
5. Webシステム全体を構成する際に⽣じる問題
6. その他（サプライチェーン攻撃やテストデータの残存などにまつわる問題）

1.Webアプリケーションの設計にまつわる問題

Webサイトの仕様にかかわる問題です。このようなWebアプリケーションは、仕様が脆弱なため想定通りの動作を行っていますが、サイバー攻撃には脆弱な状態になっています。このような問題はセキュリティ知識が不⾜しているために、Webアプリケーションの要求定義や設計段階の考慮漏れで混⼊してしまいます。またこの問題は仕様に深くかかわっていることが多いため、開発後に修正する場合、⼤きな⼿戻りが発⽣してしまう特徴があります。

例えばよくある例として、オブジェクト（主体）とサブジェクト（操作）の整合性がとれていないために⽣じる認可制御の不備や仕様として定めたビジネスロジック⾃体に⾒落としがある、あるいは正常な遷移以外に想定外の操作を許してしまうクロスサイト・リクエスト・フォージェリの問題など、許容できないリスクを持つ脆弱性が混⼊する可能性があります。

【脆弱性の例】

• 認可制御の不備
• ビジネスロジックの迂回
• クロスサイト・リクエスト・フォージェリ

また本問題を保有するWebサイトではセキュリティ対策が⼗分に考慮されていない傾向にあるため、インシデント発⽣時に追跡するために⼗分なログデータが保存されていなかったり、攻撃者からの脅威に対する緩和策や防御機能が不⾜していることがあります。

【防御策の例】

• アカウントロック機能
• ２要素認証
• ログデータの保管
• 強固なパスワードポリシー
• 信頼性の⾼い暗号化方式の採⽤
• 重要情報の保護（データの暗号化など）

上記のような機能を盛り込むことは、⼀⾒すると時間がかかりコスト増のように感じるかもしれませんが、今やインターネットに公開するということは、常にリスクにさらされているといえますので、このようなセキュリティ対策はランニングコストとして必要なものととらえるのが望ましいです。そのため、Webサイトを構築する際には、開発当初の要求仕様やサイト設計時から、⼗分にセキュリティ対策を考慮して開発していくことが望ましいといえます。

【本問題を検出できるサービス】

• Webアプリケーション・マニュアルによる脆弱性診断
• バグバウンティ

2.Webアプリケーションの実装にまつわる問題

SQLインジェクションやクロスサイト・スクリプティングなどWebアプリケーションの脆弱性がこの問題に当てはまります。特にデータの⼊出⼒部分の実装に多く混⼊する問題で、安全性が考慮されているフレームワークを利⽤した開発でも完全に抑⽌するのが難しい脆弱性でもあります。

【能動的攻撃を招く脆弱性の例】

• SQLインジェクション
• パス・トラバーサル
• OSコマンド・インジェクション

【受動的攻撃を招く脆弱性の例】

• クロスサイト・スクリプティング
• オープンリダイレクト
• CRLFインジェクション

能動的攻撃（アクティブ攻撃）を受ける脆弱性については、直接、Webアプリケーションに攻撃を加えるため、危険性が⾼いことが直感的にわかる問題だと思います。⼀⽅、能動的攻撃（パッシブ攻撃）については被害に遭うユーザーの関与が必要になる脆弱性であるため、発⽣状況によっては⼀⾒、無害にように思えるケースがあります。

例えばSelf XSSと呼ばれるクロスサイト・スクリプティングでは、攻撃⽂字列が表⽰される個所が攻撃者のみ閲覧可能な場所であるため無害とされますが、この⾒極めはなかなか難しいところがあります。近年ではSelf XSSと⾒なされて放置されていたクロスサイト・スクリプティング脆弱性を他の受動的攻撃と組み合わせて情報漏洩を引き起こすなど攻撃の複雑化が進んでいるため、安易に問題がないと判断して対処を怠ると思わぬ事態を引き起こす危険性があります。

またオープン・リダイレクトなどについてもただ別のサイトに転送されるだけと捉えて対策をしなかったために利⽤者に被害が及ぶなど、脆弱性が存在するWebサイトの所有者や運営者責任をとわれるケースがあります。

上記のように⼀⾒無害に思えるような受動的攻撃を受ける脆弱性であってもしっかりと対策を実施することが望ましいといえます。また本問題については、開発メンバーに対して問題を作り込まないようにガイドラインを策定して共有して未然に防⽌するといった対策が理想的です。しかし現実問題として難しいことが予想できますので、開発完了後などに脆弱性診断を行うことで問題を洗い出した上で対処するといったアプローチも有効です。

【本問題を検出できるサービス】

• Webアプリケーション・マニュアルによる脆弱性診断
• Webアプリケーション・ツールによる脆弱性診断
• バグバウンティ

3.サーバー設定に関する不備

Webアプリケーションを動作させるためのWebサーバーを構築する際にデフォルト設定や誤った設定（フレームワークやミドルウェア、OSなどを含む）のまま公開してしまうことで⽣じる問題です。近年ではクラウドサービスを使ってシステム全体を構築するケースが増えているため、各クラウドの設定⽅法の確認不⾜によって本問題が混⼊してしまうケースも増えています。

特に以下のようにSaaS、PaaS、IaaSに区分される中でAWSやAzureなどのIaaSサービスについては、仮想環境のみを提供するサービスであるため、その上に構築したOSやミドルウェアなどの設定やネットワークにかかわる設定などはサービス利⽤者が行わなければなりません。

区分	特徴	提供サービス
IaaS	システムを構築するためのインフラ部分をクラウドで提供するサービス	仮想サーバーや仮想ネットワークなど
PaaS	Webアプリケーションを開発するためにのプラットフォーム部分を提供するサービス	フレームワークやミドルウェアなどの開発環境やデータベース環境など
SaaS	⽬的に応じたソフトウェアやアプリケーションを提供するサービス	グループウェアや会計ソフトなど

近年のソフトウェアではサーバーやネットワーク機器の設定の不備による影響を⼩さく抑えるように、デフォルト設定であっても堅牢化されていますが、しっかりと設定状況を確認しないで構築してしまうと以下のような脆弱性が⼊り込んでしまう恐れがあります。

【脆弱性の例】

• ディレクトリ・リスティング
• バナーグランビング
• デフォルトページの公開
• 管理画⾯の公開
• 公開ディレクトリへのログデータの配置
• その他、不要なファイルの開⽰

この問題単体で⽣じるリスクは抑えられている傾向にありますが、脆弱性が存在した場合に攻撃者にとって攻撃のヒントを与えてしまう、あるいはセキュリティ意識の低いサイトと誤認されることで不要な攻撃を招くなどの副次的な影響を伴うことがあります。そのため、この問題もWebサイトの公開前に脆弱性診断で設定がしっかりと施されているかをチェックすることが望ましいと⾔えます。

【本問題を検出できるサービス】

• Webアプリケーション・マニュアルによる脆弱性診断
• Webアプリケーション・ツールによる脆弱性診断
• バグバウンティ

4.古いソフトウェアを利⽤することで⽣じる問題

オープンソースコード（OSS）の普及やフレームワークの台頭により、⼀からWebアプリケーションを構築するのではなく、すでにある程度作りこまれたプログラムを再利⽤して開発するのが⼀般的になっています。

しかし、ご存じの通りバグのないプログラムを作り出すことは極めて難しいため、 OSSやフレームワークなどにも、現状では気付かれていないだけでいくつものバグが潜在しています。また、バージョンアップに伴い新たなバグが混⼊することも考えられます。

セキュリティ的に問題のあるバグが脆弱性になりますので、上記の通り利⽤しているソフトウェアやコンポーネントには潜在的な脆弱性が含まれている可能性が⾼いため、基本的には常に最新のバージョンのものを⽤いるか、すでに既知の脆弱性が確認されている場合はセキュリティパッチを適⽤することが必要です。

利⽤しているソフトウェアのバージョン管理をしっかりと行なっていないと、以下のような脆弱性の存在するソフトウェアを利⽤してしまっているといった状況を招いてしまいます。

【脆弱性の例】

• Log4j
• Spring4Shell
• ImageTragick
• Heartbleed
• 上記以外にもCVEなどが割り当てられた各種の既知の脆弱性を含むソフトウェア

なお、古いソフトウェアを使っていた場合に即、実害に⾄るかどうかはケースバイケースになります。該当する脆弱性が能動的攻撃に分類される問題であれば、攻撃者に気づかれた時点で攻撃を受ける危険性がありますが、能動的攻撃を受けるタイプの脆弱性であった場合は攻撃が成⽴するための条件が必要になります。

また脆弱性の種別だけではなく、利⽤⽅法や設定⽅法によっても発動するしないが分かれるため、何かしらのオプションを設定している、あるいは特定のモジュールを読み込んでいる場合に問題が発⽣するなどの条件がつくことがあります。

そのため、以下のような脆弱性診断を実施した場合に結果報告書には「既知の脆弱性に対して攻撃を受ける危険性がある」など攻撃を受ける可能性を⽰唆する結果になることがあります。

【本問題を検出できるサービス】

• プラットフォーム・ネットワーク診断
• Webアプリケーション・マニュアルによる脆弱性診断
• Webアプリケーション・ツールによる脆弱性診断
• バグバウンティ

5.Webシステム全体を構成する際に⽣じる問題

これは、Webサービスを提供する上で必要となる周辺サービス（SSO、DNS、メール、ファイルサーバー、データベース、ロードバランサ、リバースプロキシなど）との連携不備によって⽣じる問題です。

前述したWebアプリケーションやサーバー設定にまつわる脆弱性については脆弱性診断などで洗い出して対処しているWebサイトは多くあるように感じます。しかし、⼤規模システムや提供するサービス内容によっては、本内容の問題まで意識しなけらばいけないWebサイトにおいて本項の問題を⾒逃してしまっているサイトが散⾒されます。

【脆弱性の例】

• HTTPリクエスト・スマグリング
• ホップバイホップヘッダーによるバイパス
• メールヘッダ・インジェクション
• ホストヘッダ・インジェクション
• 動画データの不正ダウンロード
• シングルサインオンの連携不備

例えば2020年に問題となったドコモ⼝座の不正利⽤では、dアカウントにおいて本⼈確認をしないままドコモ⼝座が開設できて、かつ提携する⾦融機関と紐づけることができてしまったことで多額の⾦額が不正にチャージされてしまいました。

またHTTPリクエスト・スマグリングのようにフロントエンドのWebサーバーとバックエンドのWebサーバーのように負荷分散のために分けられたサーバー間で HTTPリクエストの解釈が異なることでキャッシュ汚染による情報漏洩や悪意のあるコードの混⼊などの問題が起きる、あるいはホップバイホップオプションヘッダーのように中継するために付与されるヘッダの設定に不備がある場合、悪⽤することで攻撃者に有益なヒントを与えてしまうなどの事態を引き起こすことがあります。

上記のあげた例はほんの⼀例ですが、様々な仕組みのシステムと連携することが珍しくない昨今のWebサービスでは、連携先も含めて脆弱性を洗い出すことが必要です。そのため、できるだけシステム全体を診断対象とすることが望ましいといえます。

【本問題を検出できるサービス】

• Webアプリケーション・マニュアルによる脆弱性診断
• Webアプリケーション・ツールによる脆弱性診断
• バグバウンティ

6.その他（サプライチェーン攻撃やテストデータの残存などにまつわる問題）

クラウド上で管理されているリポジトリデータやOSSで公開されているソースコードなど、現状では様々な情報をインターネットを通して取得することができます。しかし、これはリポジトリをPrivateとすべきところをPublicとして公開してしまうことで保護すべきソースコードが漏洩してしまう恐れがあったり、利⽤している OSSを解析されることで脆弱性が検出されてしまうことがあります。

また開発者のケアレスミスから商⽤環境で運⽤しているサイトにテストデータが残っていることで認証処理や認可制御をバイパスできてしまったり、閉鎖すべきテスト環境が公開されてしまっていることから踏み台に使われてしまうなどの事態が発⽣することがあります。

さらにサービス終了時に消去すべきDNSのCレコードが残っていることから、サブドメイン情報の乗っ取りのよるサブドメインテイクオーバー攻撃を受けてしまったり、信頼していたサードパーティースクリプトが、⾃サイトを攻撃する内容のスクリプトに置き換わっているなど、思いもしない経路からサイバー攻撃を受けることがあります。

【脆弱性の例】

• サブドメインテイクオーバー
• クラウドリポジトリからの秘匿情報の漏洩
• テストデータを悪⽤したロジックのバイパス
• サードパーティースクリプトの読み込み
• サプライチェーン攻撃

このようにソースコードのや利⽤しているコンポーネントのリポジトリデータま で、該当サービスを供 するすべての過程を通して攻撃する⼿法をサプライチェーン攻撃などと呼び、不要なテストデータを狙ったアタックやサードパーティ製品の⽋陥の悪⽤など多彩な経路で攻撃を仕掛けてきます。

またサービスが終了したドメイン情報を悪⽤したサブドメインテイクオーバー攻撃など、⾃サービスが終了した際にきちんとした後始末を行わないでいると思わぬセキュリティインシデントの被害者、もしくは場合によっては加害者になってしまうため、注意が必要といえます。

【本問題を検出できるサービス】

• Webアプリケーション・マニュアルによる脆弱性診断
• バグバウンティ

検出できるサービスと脆弱性分類の関係

ここまで6種類に⼤別して脆弱性について解説してきましたが、以下はこれらに対して有効な脆弱性診断サービスを対⽐させた表となります。提供するサービスやシステム構成に応じて必要なサービスの選定にお役⽴ていただければ幸いです。

【対⽐表】

1. Webアプリケーションの設計にまつわる問題	Webアプリケーション・マニュアルによる脆弱性診断 バグバウンティ
2. Webアプリケーションの実装にまつわる問題	Webアプリケーション・マニュアルによる脆弱性診断 Webアプリケーション・ツールによる脆弱性診断 バグバウンティ
3. サーバー設定に関する不備	Webアプリケーション・マニュアルによる脆弱性診断 Webアプリケーション・ツールによる脆弱性診断 バグバウンティ
4. 古いソフトウェアを利⽤することで⽣じる問題	プラットフォーム・ネットワーク診断 Webアプリケーション・マニュアルによる脆弱性診断 Webアプリケーション・ツールによる脆弱性診断 バグバウンティ
5. Webシステム全体を構成する際に生じる問題	Webアプリケーション・マニュアルによる脆弱性診断 Webアプリケーション・ツールによる脆弱性診断 バグバウンティ
6.その他（サプライチェーン攻撃やテストデータの残存などにまつわる問題）	Webアプリケーション・マニュアルによる脆弱性診断 バグバウンティ

なお、セキュリティエンジニアになる方法を詳しく知りたい人は、プログラミング学習のすべてがココに「SAMURAI ENGINEER Blog」を参考にしてください。
→セキュリティエンジニアになるには？具体的な目指し方をわかりやすく解説

まずは手軽にツールで脆弱性診断

本記事では、脆弱性診断で検出される問題やその重要性について紹介してきました。

セキュリティベンダーに依頼する脆弱性診断もある⼀⽅で低コストで実現できる⼿法としてツールでの脆弱性診断という選択肢もあります。

ツールでの脆弱性診断を通じてセキュリティレベルを強化したい企業様はぜひ弊社の脆弱性診断サービス「Securify Scan」を活⽤ください。

無償でのトライアル実施も行っておりますので、お気軽にお問い合わせください。