#脆弱性 | SQAT®.jp

2024年4月1日2024年4月1日

脆弱性管理とIT資産管理
-サイバー攻撃から組織を守る取り組み-

日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

増え続ける脆弱性

脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です（下グラフ参照）。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

増え続ける脆弱性画像 — NVD（米NIST：NATIONAL VULNERABILITY DATABASE）Static Resultsより2010～2023年の登録脆弱性件数

また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

脆弱性管理とその目的

情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

脆弱性管理の必要性

しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

脆弱性管理のライフサイクル

脆弱性管理の標準的な流れは以下の4つのプロセスになります。

各プロセスの概要とポイント


プロセス	概要	ポイント・留意点
資産の把握・管理	IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。	・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。・常にアップデートできていること、管理外の資産（シャドーIT）がないこと。
脆弱性情報の収集	資産管理情報をもとに、自組織に関係する脆弱性情報を収集。	・必要に応じて適切なタイミングで実施。・政府機関や製品ベンダといった信頼できるソースから収集。
脆弱性のリスク評価	脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。	・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
解消策の実行	実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。	・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

脆弱性管理におけるIT資産管理

脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

・ハードウェア： PC、サーバ、ネットワーク機器等
・ソフトウェア： OS、ミドルウェア、アプリケーション等
・ライセンス情報、購入・保守情報、廃棄情報
・利用者（利用部門）、利用状況

IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

脆弱性管理とIT資産管理の連携

IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

適切な脆弱性管理のためのポイント

前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。


漏れなく適時に一元管理	実態に即した評価と対応	プロセスの標準化と見直し
脆弱性管理を統括する部門に情報が集約されていること資産管理、脆弱性情報に漏れがないこと資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること　等	脆弱性情報とその解消策が信頼できる内容であること自組織への影響評価と解消策の要否・優先度の決定が適正に行われること解消策の実施が安全・確実な方法で行われること　等	脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること各プロセスでのトラブル発生時には適宜協議できる状態であること定期的、あるいは必要に応じて適宜手順の見直しを行うこと　等

“漏れなく”管理するには

ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

資産の把握・管理：ソフトウェアコンポーネントの管理

見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

■組み込みソフトウェアに起因する脆弱性が問題となった例：

2021年12月　

Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*1。
悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。

2023年12月

Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3。
リモートコード実行、クロスサイトスクリプティング、ＤｏＳ、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表（SBOM）」の活用が有効です。

SBOM （Software Bill of Materials）
特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
参考情報：https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0」（令和5年7月28日）が発行されていますので、参考にしていただくとよいでしょう。

資産の把握・管理：シャドーITの撲滅

先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

■シャドーITに起因する脆弱性が問題となった例：

2024年 2月

著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
根本的な原因は、自組織で管理すべきCNAMEレコード（ドメインの別名を定義する情報）が、放棄されたドメインを指定したまま放置されていたこと。

シャドーITを発見するには、ASM（Attack Surface Management）が有効です（下イメージ）。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

一般的なASMの特徴とイメージ

インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

脆弱性情報の収集：脆弱性診断で補完

資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム（下記例）に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

・外部に公開されているネットワークセグメント
・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
・主力業務に直結するミッションクリティカルなシステム　等

ASMや脆弱性診断の実施頻度

漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

ウェビナー開催のお知らせ

2024年4月10日（水）13:00～14:00
「DevSecOpsを実現！- ソースコード診断によるセキュリティ対策のすすめ –」
2024年4月17日（水）14:00～15:00
「変化する不確実性の時代における「安心・安全・安定のWebサイト運営」セミナー- Google提唱のサイト信頼性スコアとセキュリティ基準の詳細 –」
2024年4月24日（水）13:50～15:00
「知っておきたいIPA『情報セキュリティ10大脅威 2024』～セキュリティ診断による予防的コントロール～」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2024年1月15日2024年1月15日

クロスサイトリクエストフォージェリ（CSRF）の脆弱性　
-Webアプリケーションの脆弱性入門 4-

「クロスサイトリクエストフォージェリ（CSRF）」は、Webアプリケーションの脆弱性の一つです。この記事では、クロスサイトリクエストフォージェリが何であるか、その攻撃の具体的な仕組みや流れ、想定されるリスクについて解説します。またクロスサイトスクリプティング（XSS）の脆弱性との違い、実際にどのような予防策を取るべきかについても触れます。そしてどのようにして自分のWebサイトやアプリケーションを保護するかについて解説します。

前回までの内容

セッション管理の不備は、Webアプリケーションの脆弱性の一つです。セッションIDが日付・誕生日・ユーザ名など、推測可能なもの作られたりしているなどの問題があると、セッションハイジャック（攻撃者が他のユーザのセッションIDを盗み取り、そのIDを使用してユーザのアカウントに不正アクセスする行為）のリスクを高めます。セッションハイジャックが成立するリスクを高める要因となる脆弱性および攻撃方法には、セッションIDの固定化（セッションフィクセーション）やセッションIDの推測などがあります。脆弱性を悪用した攻撃を防ぐためには、セッションIDを推測困難な値にする、ログイン・ログアウト時に新しいセッションIDを発行する、ワンタイムトークン付与やIPアドレスによる確認などの対策が必要です。

アクセス制御の不備は、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。これにより権限昇格やパストラバーサル（パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスする行為）などのリスクが生じます。主な対策方法として、権限に基づく機能制限、適切なアクセス制御ポリシーの実装などが挙げられます。

セキュリティ対策の実施は常に最新のセキュリティ情報を踏まえて見直し、強化していくことが重要です。セキュリティ専門家に相談するなどして、適切な対策を実施しましょう。

前回記事「セッション管理の不備/アクセス制御の不備の脆弱性 -Webアプリケーションの脆弱性入門 3-」より

クロスサイトリクエストフォージェリ(CSRF)とは

クロスサイトリクエストフォージェリ（CSRF）は、攻撃者が罠として用意した偽サイトを用いてリンクや画像をクリックさせることで、ユーザが意図していないリクエストを強制的に行わせることができる脆弱性です。例えば、SNS（ソーシャルネットワーキングサービス）で「いいね！」をする、銀行の振り込み操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。

クロスサイトリクエストフォージェリ（CSRF）攻撃とは

クロスサイトリクエストフォージェリ攻撃の仕組みは、Webサイトでログインしたユーザからのリクエストがそのユーザが意図したリクエストであるかどうかを識別する仕組みがない場合、外部サイトを経由してユーザが意図しないリクエストを送信させ、それをサーバに受け入れさせるというものです。例えば、銀行のサイトにログインしている状態で攻撃者が仕掛けた罠サイトのリンクURLをクリックすると、ユーザの意図しない送金処理などが実行されてしまう恐れがあります。

クロスサイトリクエストフォージェリ（CSRF）攻撃のリスク

クロスサイトリクエストフォージェリ攻撃の特徴は、攻撃者によってユーザが意図しないリクエストを実行させられ、強制的に、情報の変更や購入処理を実行させられてしまうところにあります。注意すべきは、クロスサイトリクエストフォージェリは、システムやアカウントが保有する機能や権限によって様々な被害を受ける可能性があることです。例えば、ユーザの意図しない売買成立での金銭請求、ログイン情報の変更によるアカウントの乗っ取り、データ削除処理の実行によるデータ消失などがあげられます。

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）の違い

クロスサイトスクリプティングとクロスサイトリクエストフォージェリは、Webアプリケーションのセキュリティ脅威として知られていますが、その仕組みや対策には明確な違いがあります。クロスサイトスクリプティングの基本的な手法は、悪意のあるスクリプトをWebページに挿入し、他のユーザがそのページを閲覧する際にスクリプトが実行される攻撃です。主に出力に対するエスケープ処理の不備が原因で発生します。一方、CSRFは、ユーザがログインしている状態で、攻撃者が仕掛けた誘導URLをクリックさせることで、ユーザの意図しない操作を実行させる攻撃です。この攻撃は、セッション管理やトークンの処理が不適切な場合に主に発生します。企業や開発者は、これらの違いを理解し、それぞれの脅威に対する徹底的な対策や対応を導入することが求められます。注意深くシステムの保護と保守を行い、ユーザの情報を守ることが重要です。

クロスサイトリクエストフォージェリの原因

脆弱性が発生する原因は、Webサイト側でユーザからの正規のリクエストと外部サイトを経由して偽造されたリクエストを区別できないことにあります。セッション管理のためにCookie、Basic認証、またはSSLクライアント認証を使用しているWebサイトでは、このような問題が発生する可能性があります。特に、影響を受けるWebサイトのうち、ログイン後に重要な処理等を行うサイトは、大きな被害につながる可能性があるため、注意が必要です。

クロスサイトリクエストフォージェリ攻撃の対策

クロスサイトリクエストフォージェリ（CSRF）攻撃の対策として、送信されたリクエストが正しい画面遷移によるものであることを確認し、不正な場合には処理を実行しない仕組みを実装してください。画面遷移の制御に利用可能な要素としては、下記が挙げられます。

1. 推測困難かつランダムな文字列（トークン）

2. Originヘッダやカスタムヘッダの値

3. 再認証による本人確認

トークンはセッション単位のリクエストごとに有効とし、別のリクエストに対して使用不可としてください。

セキュリティ対策の取り組み

このような攻撃を理解し適切な対策を導入することは、Webセキュリティを保護する上で非常に重要です。また、クロスサイトスクリプティング攻撃により、クロスサイトリクエストフォージェリの緩和策が無効化される場合もあるため、多方面からの脆弱性対策の実施も重要です。企業担当者はこの攻撃の仕組みを理解し、常に最新の対策情報を取得して、安全な環境を保持する必要があります。特に自社のWebサイトを運営する場合、定期的な調査や検証を行い、対策を強化することが求められます。

まとめ

クロスサイトリクエストフォージェリ（CSRF）は、ユーザがログイン状態のWebサイトにおいて、攻撃者が偽造したリクエストを送信させることで、強制的に情報の変更や購入処理等を行わせるものです。例えば、SNSで「いいね！」をする、銀行の振り込み操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。この攻撃を防ぐためには、サイトが正規のリクエストと偽造されたリクエストを区別するために、正しい画面遷移によるリクエストであることを確認する仕組みを実装することが推奨されます。また、企業やサイトの運営者は、この問題をよく知って、対策をしっかりと行う必要があります。

Security Report TOPに戻る
TOP-更新情報に戻る

2024年1月15日2024年1月16日

診断結果にみる情報セキュリティの現状～2023年上半期　診断結果分析～

SQAT® Security Report 2023-2024年秋冬号

BBSecの脆弱性診断

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しており、高い網羅性とセキュリティ情勢を反映した診断を実現するため、セキュリティエンジニアおよびセキュリティアナリストが高頻度で診断パターンを更新し、診断品質の維持・向上に努めている。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2023年上半期（1月～6月）実施結果より、セキュリティ対策の実情についてお伝えする。

2023年上半期診断結果

Webアプリ/NW診断実績数

2023年上半期、当社では12業種延べ553企業・団体、3,396システムに対して、脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションにおいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上（緊急・重大・高）の割合は17.5％で、6件に1件近い割合で危険な脆弱性が検出されたことになる。

一方、ネットワーク診断では、なんらかの脆弱性があるとされたシステムは約半数だったが、そのうちの危険度「高」レベル以上の割合は23.8%で、5件に1件以上の割合であった。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2023年上半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

長年知られた脆弱性での攻撃

「Webアプリ編」について、1位、2位は前期同様「クロスサイトスクリプティング（以降：XSS）」と「HTMLタグインジェクション」となった。3位以下は、脆弱性項目は前期からあまり変化はないものの、「SQLインジェクション」が順位を上げた。

3位の「サポートが終了したバージョンのPHP使用の可能性」など、サポートが終了したバージョンのコンポーネント（プログラム言語、ライブラリ等）の使用がワースト10の4項目を占めている。サポート終了とはすなわち、新たに脆弱性が発見された場合でもコンポーネントの提供元は基本的に対処しないということであり、危殆化に対する利用者側での対策が困難となるため、継続利用は危険である。例えば、サポートが終了した製品についての脆弱性情報の公開が契機になり、攻撃コードが公開され、攻撃が活発化することも考えられる。最新バージョンへのアップデートを迅速に、定期的に実施すべきである。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

アクセス制御が不適切な認証機構の検出がランクイン

「ネットワーク編」のワースト10については、ワースト4までが前期と変わらず、5位、6位は順入れ替えという結果で、あまり大きな変動は見られなかったが、8位の「アクセス制御が不適切な認証機構の検出」が前期圏外からランクインした。「アクセス制御が不適切な認証機構」には、特権アカウントやデフォルトアカウント等を使用してログインできる脆弱性も含まれる。特権アカウントがデフォルトのまま、もしくは推測されやすい認証情報で設定されていた場合はさらに危険である。デフォルトアカウントやデフォルトパスワードを使用せず、推測されにくい複雑なパスワードを設定することや、ログイン画面に対するアクセスを強固に制御すること、特権アカウントは必要最小限のユーザにのみ付与することなどが推奨される。

カテゴリ別の検出結果詳細についてはこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月27日2024年1月9日

セッション管理の不備/アクセス制御の不備の脆弱性
-Webアプリケーションの脆弱性入門 3-

セッション管理の不備やアクセス制御の不備が存在すると、情報漏えいや不正アクセスのリスクが高まります。本記事では、セッション管理とアクセス制御についての基本的な知識から、脆弱性の概要、脆弱性を悪用した攻撃の手口、そして攻撃を防ぐための対策方法についてご紹介します。

前回までの内容

SQLインジェクションは、Webアプリケーションの脆弱性の一つです。攻撃者は不正なSQL文を挿入してデータベースを操作することにより、データベースの内容を改ざんし、顧客の情報を不正に取得します。SQLインジェクション攻撃はSQL文の組み立て方法に問題があり、攻撃者が挿入した不正なSQL文を誤った命令文として認識してしまうことで発生します。攻撃を受けてしまった場合、顧客情報や決済履歴などの機密情報が漏洩する恐れがあり、企業の信用やブランドイメージに大きなダメージを与えます。対策方法ととして、プレースホルダを使用したSQL文の構成、特殊文字のエスケープ処理、SQLエラー情報の非表示化、アカウントの適切な権限付与などがあります。これらの対策は、データベースのセキュリティを維持し、攻撃を防ぐために重要です。また、SQLインジェクションの脆弱性を検出する方法として、入力フィールドに本来許可されていない文字列を設定し、Webアプリケーションの反応を観察する方法があります。このようなテストを通じて、企業のセキュリティ担当者がSQLインジェクションの脆弱性に対する問題を理解し、社内で情報を共有し、適切な対策とることで、攻撃を未然に防ぐことが可能になります。また、Webサイトの機能追加や新しい攻撃手法の発見等によって生まれた新たな脆弱性には、定期的にセキュリティ診断を実施することで適切な脆弱性対策をすることができます。

前回記事「SQLインジェクションの脆弱性 -Webアプリケーションの脆弱性入門 2-」より

セッションとは

セッションとは、クライアントがサーバに接続してから切断（あるいはログインしてからログアウト）するまでの一連の流れのことです。この一連の流れを管理することをセッション管理と呼びます。セッション管理はユーザの識別や状態の維持のために必要とされます。例えば、オンラインショッピングサイトで商品をカートに追加した際、その情報はセッションとして保存されます。

セッション管理の不備とは

セッション管理の不備/アクセス制御の不備の脆弱性（2人とデータの紙アイコンマーク）イメージ

Webアプリケーションの中には、セッションID（ユーザを識別するための情報）を発行し、セッション管理を行うものがあります。このときセッションIDを固定化できたり、日付・誕生日・ユーザ名で作られたりしているなど、有効なセッションIDが推測可能であるといったセッション管理の不備があると、セッションハイジャックと呼ばれる攻撃が成立する危険性があります。これにより、攻撃者が本来のユーザになりすまして権利を行使することで、プライベートな情報の閲覧や、設定の変更などが行われる可能性があります。

セッション管理の不備の脆弱性を悪用した攻撃

セッションハイジャック

セッションハイジャックは、攻撃者が他のユーザのセッションIDを盗み取り、そのIDを使用してユーザのアカウントに不正アクセスする行為を指します。有効なセッションIDを推測あるいは奪取する手段が存在している場合に、セッションハイジャックが成立するリスクが高まります。

セッションハイジャックが成立するリスクを高める要因となる脆弱性および攻撃方法には、以下のようなものがあります。

セッションIDの固定化（セッションフィクセーション）

攻撃者が事前にセッションIDを設定し、そのIDをユーザに強制的に使用させることができる脆弱性を悪用してユーザのセッションを乗っ取る攻撃方法です。この攻撃は、ユーザがログインする前にセッションIDが設定され、その後も変更されない場合に発生します。

セッションIDの推測

セッションIDが日付や誕生日、ユーザ名で構成されていたり、連番で発行されていたりするなど、簡単に予測できるものであった場合、攻撃者はそのIDを推測してユーザのアカウントにアクセスできてしまいます。また、セッションハイジャックの原因は多岐にわたり、他の脆弱性を悪用されることで有効なセッションIDが奪取される場合もあります。

Webアプリケーション／ネットワークの脆弱性の悪用

攻撃者によりWebサイトの脆弱性を突かれ、不正にユーザとWebサイトの間に介入されたり、ネットワークを盗聴されたりするなどして、ユーザのセッションIDを奪取される可能性があります。代表的な攻撃手法のひとつには、以前の記事で解説した「クロスサイトスクリプティング」も挙げられます。また、通信のやり取りではセッションIDが暗号化されておらず、平文のままデータのやり取りをしている場合にも、攻撃者に狙われやすくなります。

セッション管理の不備の脆弱性を悪用した攻撃を防ぐための対策方法

セッションIDの取り扱いや、セッションの有効期限の設定などに問題がある場合、攻撃者がセッションを乗っ取ることが容易になり、機密情報を盗み見られたり、不正な操作をされたりするなどのリスクが発生します。では攻撃を防ぐためにどのような対策方法をとればよいのでしょうか。以下に例をご紹介いたします。

セッションIDを推測困難なものにする

攻撃者によってセッションIDを推測されてしまった場合、そのユーザになりすまして、本来アクセスできないサイトに第三者がアクセスできてしまう恐れがあるため、セッションIDは推測困難な値にする必要があります。

ログイン、ログアウトといった処理を行う際は、新しいセッションIDを発行する

ログイン時にセッションIDの正当性を検証することで、攻撃者があらかじめ用意したセッションIDを強制的に使用させられることを防ぎます。

セッションハイジャック対策

有効なセッションIDを奪われないようにすることだけでなく、セッションIDを奪われたとしてもセッションハイジャックを成立させないような環境を作るのが対策のポイントです。

セッションIDとワンタイムトークン付与によるユーザの確認：セッションIDとは別にログイン成功後にワンタイムトークンを発行し、画面遷移ごとにサーバ側で管理しているトークンと照合します。発行するワンタイムトークンは、推測困難かつランダムな文字列で構成する必要があります。
IPアドレスによるユーザの確認：ユーザを特定する情報として、IPアドレスを使用することが可能です。さらに、セッションIDをCookieで管理している場合には、Cookieにsecure属性およびHttpOnly属性を設定することで、攻撃者によるCookie情報奪取のリスクを緩和できます。

対策例としては、上記のとおりですが、セキュリティ専門家への相談も重要です。現在の技術環境では、常に新しい脅威が出現するため、対策は継続的に見直し、強化する必要があります。

アクセス制御の不備とは

アクセス制御の不備とは、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。例えば、一般ユーザとしてログインした際に管理者としての権利を行使できてしまう権限昇格、パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスすることが可能となるパストラバーサルなどです。不正アクセスや意図しない情報の公開をはじめとした、様々なリスクが生じます。

アクセス制御の不備の脆弱性

権限昇格

ログインすることなくユーザとしてシステムに対する操作を実行できたり、一般ユーザが本来与えられていない上位権限（管理者権限等）を一時的に取得することで、システムに対する不正な操作や機能の実行が可能になったりする問題。

パストラバーサル

外部からのパラメータでWebサーバ内のファイル名を直接指定するWebアプリケーションにおいて、URLパラメータを操作して不正なパス名を渡すことで、本来アクセスを許可されていないディレクトリやファイルに対して、攻撃者がアクセス可能になる問題。

不適切な情報の出力

本来権限が与えられているユーザのみアクセスできるものに対して、不正なユーザが本来許可されていない特定のURLにアクセスしたり、操作を行ったりすることで、外部に公開されていない情報（機密情報・ユーザ情報）が閲覧可能になる問題。

アクセス制御の不備を悪用した攻撃を防ぐための対策方法

主な対策方法は以下の通りです。

権限昇格

権限管理を行う際は、外部から値を操作可能なパラメータは使用せずサーバ側で行う実装とし、権限による機能制限を実装する際には、各機能へのアクセス時に実行者のアカウントと権限のチェックを実施します。

パストラバーサル

アプリケーションが取得するファイルは既定のディレクトリに保存し、アクセスするファイルパスを操作できないようにし、サーバ上でアプリケーションを実行するアカウントのアクセス権限を見直します。また、あらかじめ定義したホワイトリストに基づいた入力値検証を実施し、ファイル名に不正な文字列が含まれる場合は、適切なエラー処理を行うことが推奨されます。

不適切な情報の出力

外部への公開が不要なディレクトリやファイルは、外部からアクセスできないように適切なアクセス制御を行います。ログイン認証によるアクセス制御を実施する場合には、適切なセッション管理を伴った認証機構を実装してください。また、アプリケーションの動作に必要がないディレクトリやファイルは削除することを推奨します。

まとめ

セッション管理の不備/アクセス制御の不備の脆弱性（3人と上部にランプがついたアイコンマーク）イメージ

セッション管理の不備は、セッション管理に不備があることで、ユーザになりすまし、プライベートな情報の閲覧や、設定の変更などができてしまう問題です。対策方法としては、セッションIDを容易に推測できないものにし、ワンタイムトークンの発行やIPアドレスによるユーザの確認を行うなど、適切なセッション管理を実装することで、ユーザの情報やデータを安全に保護することができます。

アクセス制御の不備は、Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。ユーザに対して、あらかじめ与えられた権限から外れた操作を実行できないようにポリシーを適用することにより、情報の漏えいやシステムの不正操作を防ぎます。

セキュリティ対策を適切に実施することが、Webアプリケーションの安全性を高めるための鍵となります。ユーザの情報やデータを保護するために、セキュリティ専門家への相談、常に最新のセキュリティ情報の収集をすることなどが重要です。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月22日2023年12月27日

SQLインジェクションの脆弱性
-Webアプリケーションの脆弱性入門 2-

SQLインジェクション攻撃は多くの企業やシステムにとって大きな課題となっています。本記事では、SQLインジェクションの基本的な仕組みから、その主な原因とリスクについて解説します。また、企業での対策方法についても紹介します。SQLインジェクションの脆弱性のリスクを認識し、その対策方法を学びましょう。

前回までの内容

クロスサイトスクリプティング（XSS）とは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる（できる）事象を指します。このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼び、これは、ユーザのブラウザ上で不正なスクリプトを実行させ、個人情報等を漏えいさせるという仕組みです。XSSには「反射型」「蓄積型」「DOMベース」の3種類があり、それぞれ異なる方法で攻撃が行われます。XSSの主な原因は、出力の検証や処理が不十分であることです。攻撃者は、例えば、コメント欄や検索ボックスなどユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。対策としては、スクリプト言語における特別な意味を持つ文字や記号を置き換える「エスケープ処理」の実施や、Webアプリケーションファイアウォール（WAF）の活用等があります。また、セキュリティ診断を定期的に行い、リスクを可視化して適切なセキュリティ対策を実施することが重要です。

前回記事「クロスサイトスクリプティング（XSS）の脆弱性 -Webアプリケーションの脆弱性入門 1-」より

SQLインジェクションとは

SQLインジェクションは、Webアプリケーションの脆弱性の一つであり、多くの企業や中小企業がこの攻撃の影響を受ける可能性があります。具体的には、攻撃者が不正なSQL文を挿入することで、データベースを不正に操作することを指します。例えば、攻撃者は不正な文字列や記号を入力値として使用し、データベースの内容を改竄したり、顧客の情報を不正に取得したりすることができます。

SQLインジェクション攻撃の基本的な仕組み

SQLインジェクション攻撃は、不正な文字列や特殊文字を入力値として使用し、データベースの処理や検索を操作する脅威の一つで、悪意のある第三者が、通常の入力欄に異常な構文や文字を注入することで、情報の取得や変更が可能です。

SQLインジェクションの脆弱性が発生する主な原因とリスク

SQLインジェクションは、WebアプリケーションでのSQL文の組み立て方法に問題がある場合に、攻撃者が挿入した不正なSQL文を誤った命令文として認識してしまうことで発生します。SQLインジェクション攻撃により、インシデントが発生した場合、企業の顧客情報や決済履歴などの機密情報が第三者に漏えいする恐れがあります。その結果、企業のセキュリティ対策姿勢が疑われ、インシデントによる直接的な被害だけでは済まない、信用の失墜やブランドイメージの低下といった大きな痛手を受ける恐れがあります。

SQLインジェクション攻撃の事例

2022年に報告されたSQLインジェクションによる情報漏えい事例を紹介します。

国内オンラインショッピングサイトではSQLインジェクションによる攻撃を受け、サービス登録ユーザの氏名、生年月日、メールアドレス、住所などの詳細な個人情報等、275万件以上の情報が漏えいしました*1。その結果、被害の対象となった顧客へのお詫び状の送付、専用のお問い合わせ窓口の設置、個人情報保護委員会や警察への報告、再発防止策の検討を含めたセキュリティ強化、事故に関する継続的な調査対応等に追われました。

データベースの不正操作を許せば、事業活動に必要なデータをすべて消去されるといった最悪の事態も発生しうるため、SQLインジェクションの脆弱性を放置することは非常に危険です。

効果的なSQLインジェクション対策とその実践方法

SQLインジェクションの対策

重要な情報が集まるデータベースは、守るべき優先度がきわめて高く、SQLインジェクション対策としてさまざまな取り組みが行われています。

基本的な対策

プレースホルダを使用したSQL文の構成：プレースホルダは、SQL文における変数の位置を示すために使用され、実際の値は後から安全にバインドされます。特に、バインド処理を実装するライブラリの実装状況によってSQL構文が変化する「動的プレースホルダ」ではなく、SQLの準備段階からSQL構文が変化しない「静的プレースホルダ」の方が、より有効性の高い対策を実現できます。
特殊文字に対するエスケープ処理：運用上の制約等によりプレースホルダを使用したバインド処理が使用できない場合は、特殊文字に対するエスケープ処理を実施することで対策が可能です。なお、エスケープ処理では対策漏れが生じる可能性もあるため、可能な限りプレースホルダを使用することが推奨されます。

保険的な対策

SQLエラー情報の非表示化：エラーメッセージの内容にエラーを起こしたSQL文の情報、使用データベース、テーブル名、カラム名等が含まれる場合、攻撃者に対してSQLインジェクション攻撃を実行するための有益な情報を与えることになります。そのため、エラー情報はクライアントへ出力せずログファイル等で管理することが推奨されます。
アカウントへの適切な権限付与：アプリケーションがデータベースにアクセスする際には、命令文の実行に必要な必要最小限の権限を付与します。これにより、万が一SQLインジェクションが発生しても、被害を最小限に抑えることができます。

SQL文の組み立ては、データベースのセキュリティを維持する上で非常に重要です。セキュアなプラクティスを適用することで、データベースへの攻撃を防ぎつつ、アプリケーションのデータ操作を効率的かつ安全に行うことができます。

SQLインジェクションのテスト方法

システムにSQLインジェクションの脆弱性があるかどうかを調べる方法としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断するというやり方があります。この文字列を「診断文字列」と呼ぶことがあります。

企業のセキュリティ担当者をはじめ、SQLインジェクションの脆弱性に対する問題を理解し、社内で情報を共有し、適切な対策とることで、自組織がSQLインジェクション攻撃を受ける前に被害を未然に防ぐことが可能になるでしょう。

開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。こうした実情に対して有効なのは、Webアプリケーションの定期的なセキュリティ診断です。SQLインジェクションによるリスクを考えると、Webサイト運営者はぜひとも実施すべき対策といえるでしょう。

まとめ

SQLインジェクション攻撃は多くの企業やシステムのセキュリティ上の課題として存在しています。SQLインジェクションは、Webアプリケーションの脆弱性を突いて、不正なSQL文を挿入しデータベースを操作する技術です。主にSQL文の組み立て方法に問題があることで、情報の漏えいやデータの改ざんが可能となります。実際に、国内企業でも情報漏えい事例が発生しており、その影響は甚大です。対策として、プレースホルダの使用、エスケープ処理などが推奨されています。またSQLインジェクションの脆弱性を検出する方法として、定期的にセキュリティ診断を実施し、適切な対策を実施することで、Webアプリケーションのセキュリティを向上できます。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月20日2023年12月25日

クロスサイトスクリプティング（XSS）の脆弱性
-Webアプリケーションの脆弱性入門 1-

クロスサイトスクリプティングはWebアプリケーションの脆弱性の1つです。この記事では、クロスサイトスクリプティングとは何か、その仕組みや種類、そしてそれに関連する脆弱性や攻撃手法について詳しく解説します。さらに、クロスサイトスクリプティングとクロスサイトリクエストフォージェリとの違いや、クロスサイトスクリプティング攻撃を防ぐための対策方法も紹介します。

Webアプリケーションの脆弱性入門

脆弱性は、プログラムの不具合や設計ミスによって発生するセキュリティ上の欠陥です。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクがあります。Webアプリケーションの主な脆弱性にはSQLインジェクション、クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）、セッション管理の不備、アクセス制御の不備があります。脆弱性が悪用されると、機密情報の漏洩、データの改ざん、サービスの停止や遅延、金銭的損失、企業の信頼喪失などの深刻な影響をもたらす可能性があります。対策方法としては、正しい権限管理の実施、定期的なセキュリティチェックの実施、最新のセキュリティパッチの適用などが挙げられます。これらの対策により、脆弱性の早期発見と修正が可能になり、攻撃のリスクを減らすことができます。企業のセキュリティ部門担当者は、社内の機密データや取引先の顧客情報等を守るためにも、脆弱性対策に取り組むことが重要です。

前回記事「Webアプリケーションの脆弱性入門」より

クロスサイトスクリプティング（XSS）とは

クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる（できる）事象を指します。

このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼びます。まず悪意のある第三者が事前にターゲットのWebサイトに特定の文字列のスクリプトを入力値として挿入すると、そのWebサイトにアクセスしたユーザのブラウザ上で挿入したスクリプトが実行されます。これにより、第三者によってブラウザを不正に操作され、ユーザの個人情報が漏えいする、という仕組みになっています。

クロスサイトスクリプティング（XSS）の種類

クロスサイトスクリプティングの脆弱性には主に3つの種類があります。

反射型XSS…攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの
蓄積型XSS…攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの
DOMベースXSS…Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）の違い

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）は、Webアプリケーションのセキュリティ脅威として知られていますが、その仕組みや対策には明確な違いがあります。クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。主に出力の検証が不十分な場合に発生します。一方、クロスサイトリクエストフォージェリ（CSRF）は、ユーザがログインしている状態で、攻撃者が仕掛けた誘導URLをクリックさせることで、ユーザの意図しない操作を実行させる攻撃です。この攻撃は、セッション管理やトークンの処理が不適切な場合に主に発生します。

クロスサイトスクリプティングの脆弱性が発生する原因

クロスサイトスクリプティング（XSS）の脆弱性の主な原因は、出力の検証や処理が不十分であることです。悪意のある攻撃者が特定の文字列やスクリプトを入力し、その内容が未検証のままWebページに表示される場合、クロスサイトスクリプティング攻撃が実行されるリスクが高まります。特に、公開されている企業のWebサイトやアプリケーションで、ユーザからの入力値が適切に処理されず、そのままWebページへの出力処理される場合、情報の漏洩や不正な操作が可能となります。

クロスサイトスクリプティングの脆弱性による影響

脆弱性を放置した場合の影響は、情報の漏洩から不正な操作まで多岐にわたります。攻撃者が悪意のあるスクリプトを挿入することで、顧客の情報を搾取したり、企業の内部情報にアクセスしたりする可能性があります。

クロスサイトスクリプティング攻撃の手法と例

クロスサイトスクリプティング攻撃の手法は、攻撃者が悪意のあるスクリプトを入力し、その内容がそのままWebページへの出力処理に使用されることで、ユーザのブラウザ上でスクリプトが実行されるというものです。例えば、コメント欄や検索ボックスなど、ユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。

クロスサイトスクリプティングの脆弱性への対策

根本的な対策とその重要性

クロスサイトスクリプティングの対策は、リクエストに不正な文字列が含まれていても、それをスクリプトとして機能させないことです。Webページに出力する要素に対して、スクリプト言語等において、その言語にとって特別な意味を持つ文字や記号を別の文字列に置き換える「エスケープ処理」を行います。

対策の重要性は、企業の信頼性や顧客情報の保護に直結しています。特に、自社のWebアプリケーションが公開されている場合、定期的なセキュリティ調査や対策の更新が不可欠です。最後に、社内での知識共有や外部の専門家との相談を通じて、最新の脅威や対策についての知識を更新し続けることが求められます。

WAFを活用したクロスサイトスクリプティングの防御方法

WAF（Webアプリケーションファイアウォール）は、Webアプリケーションへの様々な攻撃を検知し、防御する機能を持っています。通信をリアルタイムで監視し、攻撃と判断された通信を遮断することで、Webサイトの脆弱性が悪用されるのを防ぎます。クロスサイトスクリプティング攻撃やSQLインジェクション攻撃などには、Webアプリケーションへの入力値のチェックなどを行うWAFを用いた防御も考えられます。WAFの導入により、Webサイトのセキュリティレベルを向上させ、ユーザ情報の漏洩やサービスの停止を防げる可能性も高まります。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決とはならない点に注意が必要です。

まとめ

クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。クロスサイトスクリプティングの脆弱性の主な種類には「反射型」「蓄積型」「DOMベース」があり、それぞれ異なる攻撃方法が特徴です。また、XSSとクロスサイトリクエストフォージェリ（CSRF）は両方ともWebアプリケーションの脅威として知られていますが、攻撃の仕組みや対策が異なります。クロスサイトスクリプティングの脆弱性は、出力の検証が不十分な場合に発生し、情報の漏洩や不正な操作が可能となるリスクがあります。対策としては、出力の検証、エスケープ処理などが求められます。

基本的な対策は、Webサイトにおいて、セキュリティ診断によるチェックを定期的に実施してリスクを可視化し、適切なセキュリティ対策を実施することにより、脅威から自社や顧客の情報を保護することとなります。また、企業や組織は、セキュリティ対策の実施や知識の更新をする必要があります。Webアプリケーションのセキュリティを向上させるための知識として、また、日々の開発や運用の中での参考として、本記事を活用してください。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月15日2023年12月20日

APIのセキュリティ
―Webアプリでもスマホアプリでも安全なAPI活用を―

APIはAI、IoT、モバイル、クラウド利用において今や必要不可欠です。利便性があり、利用者も増える一方で、APIを狙ったサイバー攻撃の数も増加傾向にあります。本記事では、APIとは？API連携の仕組みやスマホアプリとの関連、活用のメリットについて触れつつ、APIのセキュリティ対策の一つとして、脆弱性対応の方法ついて解説します。

APIとは

APIとは「Application Programming Interface」の略です。プログラムの機能をその他のプログラムでも利用できるようにするための仕組みです。

ソフトウェアやアプリ、プログラム同士を、APIを介して機能連携させるのが「API連携」です。あるソフトウェアに他のソフトウェアの機能を埋め込むイメージです。API連携によってソフトウェア同士が相互にデータと機能を共有できるようになります。

【APIの活用例】

社内業務システム：チャットAPIを活用してコミュニケーション
会員サービスサイト： SNSアカウント認証APIでログイン
ネットショップ：クレジットカード・認証APIで決済
飲食店サイト：地図情報APIで店舗位置情報表示 × 予約受付APIで予約対応

API活用のメリット

APIには、以下のようなメリットが考えられます。

Web API

「Web API」は、HTTPやHTTPSといったWeb技術により実現される、インターネットを介して情報をやりとりするAPIです。連携するAPI同士が異なるプログラミング言語で構築されていても通信でき、Webブラウザ上でも稼働するWeb APIは汎用性が高く、最も多く活用されているAPIです。

複数のWeb APIを組み合わせて新しいサービスを生み出す”マッシュアップ”が多く行われており、多くの人々が、日々その恩恵を受けていると言えるでしょう。インターネット上には膨大な数のWeb APIが公開されており、今後もマッシュアップは続くものと考えられます。

スマホアプリとAPI

Web APIは、Webアプリケーションばかりでなく、スマートフォンアプリ（スマホアプリ）でも多く活用されています。

例えば、経路案内アプリでは交通機関・運賃・時刻等の情報を的確に検索してくれるAPIが、家計簿アプリでは電子マネーによる決済やクレジットカード決済などの情報を取得して計算してくれるAPIが使用されています。

スマホアプリは、外部との通信をせずにスマホ端末単体で動作するものよりも、インターネットに接続しながら使用するものが圧倒的に多く、ユーザが利用している画面の裏でインターネットを介してサーバとのやりとりが行われており、そこでＷｅｂＡＰＩが稼働しているのです。

スマホアプリのセキュリティについて、SQAT.jpでは以下の記事で解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ瓦版「攻撃者が狙う重要情報の宝庫！ ―スマホアプリのセキュリティ―」

増え続けるAPI活用

国をあげてDXの取り組みが推進されている昨今、AI、IoT、モバイル、クラウド利用において、APIの積極的な活用は不可欠です。

クラウド環境上で動作するアプリ、クラウドネイティブアプリケーションを例にとると、APIを使用している割合は高く、今後さらに増大することが予想されるとの調査結果があります（下図）。

APIに対するセキュリティ脅威

利便性が高いAPIですが、利用が増えれば、そこに存在する様々なデータを攻撃者が狙ってきます。APIに対するセキュリティ脅威の例は以下のとおりです。

APIによって機能や取り扱う情報はそれぞれですが、金融情報のような資産に紐づくデータ、医療情報のような機微情報に関するデータなど、流出して悪用されると深刻な被害につながりかねません。APIを開発・利用する上で、セキュリティは必ず考慮する必要があるということです。

APIのセキュリティ脅威について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ玉手箱「APIのセキュリティ脅威とは」

APIを狙ったサイバー攻撃の増加

APIに対する攻撃は増加傾向にあるとの観測結果が報告されています（下グラフ）。

なお、このグラフで多くの割合を占めている「ローカルファイルインクルージョン」は、攻撃者が対象システムのローカル上のファイルを読み込ませることで、領域外のファイルやディレクトリにアクセスできるようにしてしまう脆弱性です。情報漏洩、任意のコード実行、認証回避、DoS（サービス運用妨害）などの被害につながる恐れがあります。攻撃されたAPIサーバを「踏み台」とした内部/外部ネットワークへのさらなる攻撃やマルウェア感染などが想定されるため、危険度の高い脆弱性と言えます。

また、100ヶ国を対象にしたアンケート調査では、API攻撃による情報漏洩を経験している組織が90％以上にのぼるとの結果も報告されています（下グラフ）。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASP（Open Web Application Security Project）が、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したもので、今回は2019年の初版リリースから4年ぶりの第二版となります。

APIのセキュリティ対策

ここまで見てきたＡＰＩセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

開発中、リリース後、更新時といったいかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

また前段の「スマホアプリとAPI」でも述べたように、APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

BBSecでは

スマホアプリ脆弱性診断

悪意ある第三者の視点で、対象アプリに影響を及ぼす恐れのある脅威と関連リスクをあぶり出します。実機を使った動的解析とAPK（Android）・IPA（iOS）ファイルの静的解析を実施します。

Webアプリケーション脆弱性診断

また、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。弊社診断エンジニアによる、より広範囲で網羅的な診断を検討している方は、手動で診断する、「Webアプリケーション脆弱性診断」がおすすめです。

ウェビナー開催のお知らせ

2024年1月24日（水）13:50～15:00
「Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年11月10日2024年2月1日

ASM（Attack Surface Management）と脆弱性診断
― セキュリティ対策への活用法 ―

今、インターネット上に公開されるIT資産がサイバー攻撃者に狙われ、被害が拡大しています。サイバー攻撃者は事前に偵察行為をし、攻撃の的を探し、特定します。特に、脆弱性が存在しているWebシステムやネットワーク機器などは攻撃者にとっても悪用しやすく、侵入するための入口となってしまいます。では、自組織が狙われないようにするために、私たちはどのような対策をとればよいのでしょうか？本記事では、ASM（Attack Surface Management）と脆弱性診断を併用した、それぞれの実施の活用方法について解説いたします。

アタックサーフェス（攻撃対象領域）とは

サイバー攻撃に対する防御について語られる際に出てくる言葉の1つに、「アタックサーフェス」があります。

アタックサーフェスは、直訳すると”攻撃面”となりますが、サイバーセキュリティの文脈では、「攻撃対象領域」といった意味合いで使用され、サイバー攻撃の対象となり得る様々なIT資産、攻撃のポイントや経路等を指します。

組織が事業活動を行う上で使用するIT資産には、ハードウェアもソフトウェアも含まれます。IT資産にサイバー攻撃の足掛かりとなる攻撃ポイント・経路が存在すると、サイバー攻撃者は容赦なくそこを狙ってきます。

【アサックサーフェスの例】

攻撃事例とアタックサーフェス

実際のサイバー攻撃やインシデントの事例とそのアタックサーフェスを確認してみましょう。


年	事　例	アタックサーフェス
2020年	国内上場企業のドメイン名を含むサブドメインテイクオーバー（使用が終了したドメイン名の乗っ取り）の被害事例が2020年7月までに100件以上発生*5	ドメイン管理の不備
2023年	2022年5月以降、特定のセキュア・アクセス・ゲートウェイ製品の脆弱性を狙ったものと見られる標的型サイバー攻撃が断続的に発生*2	ネットワーク機器の既知の脆弱性
2023年	国内自動車メーカーの関連会社で保有する顧客約215万人分の車両等の情報が10年近く公開状態になっていたことが判明*3	クラウド設定の不備

拡大するアタックサーフェス

クラウド利用、DXの推進、テレワークの一般化……ITインフラ環境の柔軟性は高まる一方です。これに伴い、Webシステムやネットワーク機器といった外部との境界にあるアタックサーフェスは、拡大し続けています。つまり、外部にいるサイバー攻撃者が組織のシステムを侵害するチャンスが広がっていると考えられます。

サイバー攻撃者によるアタックサーフェスへのアプローチ

サイバー攻撃者が攻撃のため、最初に行う活動の典型が、「偵察」です。攻撃に利用可能な様々な情報を探索し、どの組織を標的とするか、どのような攻撃手法をとるか、といったことを定めるのに役立てます。

偵察活動で駆使される技術として、合法的に入手可能な公開情報を収集して調査・分析する手法—OSINT（「オシント」Open Source Intelligence：オープンソースインテリジェンス）が注目されています。

サイバー空間における脆弱性探索行為

前述のサイバー攻撃者による偵察活動が行われていることの裏付けとして、日本の各機関からも以下のような観測が定期的に報告されています。

【観測報告の例】


発表元		観測内容
国⽴研究開発法⼈情報通信研究機構（NICT）	2022年1～12月	調査⽬的と判定されるスキャンの数は12,752のIPアドレスから約2,871億パケットあり、これにサイバー攻撃のための偵察活動が含まれていると考えられる*4
JPCERT/CC	2022年10月～2023年6月	IoT機器を主な標的とするマルウェアMirai型パケットについて、海外および日本からの探索活動が継続して報告されている。探索元IPアドレスの一部について、動作している機種の特定に成功したことも*5
	2023年4～6月	Laravel（Webアプリケーションフレームワーク）の設定情報窃取を試みる通信を確認*6
警察庁	2023年1～6月	脆弱性のあるIoT機器の探索を目的としたものと見られるアクセスの増加を確認
	2023年1～6月	脆弱性のあるVPN機器の探索を目的としたものと見られるアクセスを断続的に確認

ASM（アタックサーフェスマネジメント）で自組織を守る

サイバー攻撃者の偵察行為で、自組織が攻撃対象として選定されないようにするにはどうすればよいでしょうか。

サイバー攻撃から⾃組織を守るために、インターネット上で意図せず公開してしまっているアタックサーフェスとなり得るIT資産を特定し、セキュリティ対策に活用する手法が、「ASM（Attack Surface Management：アタックサーフェスマネジメント）」です。

ASM導入ガイダンス

経済産業省は、ASMを「組織の外部（インターネット）からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」と定義しており、2023年5月29日に「ASM（Attack Surface Management）導入ガイダンス～外部から把握出来る情報を用いて自組織のIT資産を発見し管理する～」を発行しています。

企業のセキュリティ担当者や情報セキュリティを管掌する経営層（CIO、CISO等）に向けて、企業・組織に対してサイバー攻撃の起点となり得るIT資産を適切な方法で管理できるよう促すため、ASMの解説、ASMを実施するためのツールや必要なスキル、体制、留意点等がまとめられています。また、国内企業のASM取り組み事例も掲載されています。

ASMにより得られる効果

ASMにより以下のようなことが確認できます。

ASMのプロセス

ASMで具体的にどのようなことを実施するかというと、前述の経済産業省によるガイダンスでは、次のようなプロセスが紹介されています。「攻撃面」とは、「アタックサーフェス」のことです。

プロセス(1)　攻撃面の発見：

インターネットからアクセス可能なＩＴ資産として、IPアドレスやホスト名を発見。

・組織名（法人名等）より、オフィシャルWebサイトや検索プロトコルであるWHOISを利用して当該組織のドメイン名を特定・ドメイン名を特定したら、ＤＮＳ検索や専用ツールの使用によりＩＰアドレス・ホスト名の一覧を取得

プロセス（2）攻撃面の情報収集：

前プロセスの結果より通常のインターネットアクセスで取得可能な方法でOS、ソフトウェア、ソフトウェアのバージョン、開放されているポート番号といったＩＴ資産の情報を収集。

プロセス(3) 攻撃面のリスク評価

前プロセスで収集した情報を既知の脆弱性情報と突合せするなどして、脆弱性が存在する可能性を識別。

ASMのプロセスとしてはここまでですが、セキュリティ対策としては、ASMを実施して自組織のセキュリティリスクを把握した後の工程として、リスクの深刻度に応じた対応要否や優先度、具体的な対応内容等を決め、セキュリティリスクの低減に努める必要があります。

ASMと脆弱性診断の違い

さて、「IT資産の脆弱性検出やリスク評価を行う」となると、脆弱性診断と重なるイメージがあるのではないでしょうか。

ASMと脆弱性診断の関係性を表す、次のような図があります。脆弱性管理において、それぞれに役割があることが伺えます。

ASMと脆弱性診断の違い画像 — 出典：経済産業省「 ASM（Attack Surface Management）導入ガイダンス～外部から把握出来る情報を用いて自組織のIT資産を発見し管理する～」（令和5年5⽉29⽇）P.11　図 2-2 ASM と脆弱性診断の違い

両者の違いをまとめると以下のようになります。いずれもセキュリティ対策における取り組みですが、非常にざっくりと、ASMは“管理対象でないものも含めて広く浅く”、脆弱性診断は“特定した対象に対して深く詳細に”という印象で捉えられるのではないでしょうか。

ASMと脆弱性診断の併用・使い分けを

脆弱性管理において、ASMと脆弱性診断のどちらかを行っていればOK、ということではありません。脆弱性診断では、自組織が特定したシステムや機器に対して脆弱性を洗い出しますが、脆弱性診断の対象となるということは、組織自身が当該IT資産を管理下にあるものと認識していることになります。一方、ASMでは、そもそも管理外であるにもかかわらず当該組織のIT資産としてインターネット上に公開されてしまっているもの、つまり気づかぬまま管理から漏れてしまっているものを発見することができます。

そのため、両者の特長を理解した上でその目的に応じて、例えば、ASMによって脆弱性が存在する可能性があると発見したら、対象となる機器やシステムに対して脆弱性診断を実施して脆弱性の特定を行う、といった両者の併用・使い分けが推奨されます。

ASM・脆弱性診断ともに有効な実施方法の検討を

ASMも脆弱性診断も、ただ実施すればよいというものではなく、効果的に、かつ継続して行うことが重要です。そのためにはノウハウやスキルが必要となります。

ASMや脆弱性診断を自組織で実施しようとなると、以下のような注意点が挙げられます。

例えば、自組織ではASMや脆弱性診断をどう活用したいか検討することの方に労力を割き、ＡＳＭや脆弱性診断の実施や結果の分析については、その活用目的に合致した対応が望める外部のセキュリティサービスを探して依頼するなど、定期的に見直しをすることが重要です。

日々進化していくITインフラ環境において便利になる反面、攻撃者にもそのチャンスが広がっています。攻撃者から自組織を守るためにも、ASMと脆弱性診断の実施を組み合わせることは有効な選択肢の1つといえるでしょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

SQAT脆弱性診断サービス

システムに存在する脆弱性は、時として深刻な被害につながる看過できない脅威で、事業継続性に影響を与えかねません。BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。

ウェビナー開催のお知らせ

2023年11月22日（水）13:00～14:00「今さら聞けない！PCI DSSで求められる脆弱性診断あれこれ」
2023年12月6日（水）13:00～14:00「今さら聞けない！ペネトレーションテストあれこれ」
2023年12月13日（水）14:00～15:00「今さら聞けない！スマホアプリのセキュリティあれこれ」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年6月16日2024年4月12日

ChatGPTとセキュリティ
-サイバーセキュリティの観点からみた生成AIの活用と課題-

2022年11月にOpenAIによって公開された生成AI「ChatGPT」の利用者は、リリース後わずか2か月で1億人を突破しました。2023年になってからもその勢いは止まらず、連日のようにニュースで取り上げられ、人々の注目を集め続けています。ChatGPTを含めた生成AIは、今後のビジネスにおいて重要な役割を果たし、企業の競争力にも関わってくると考えられます。本記事では改めてChatGPTとはいったい何なのか？そしてサイバーセキュリティの観点からみたインパクトとリスクについて解説します。

ChatGPTとは？

ChatGPTとは、端的に言えば「人間が作った質問に自然な文章で回答を返してくれる、OpenAIが開発した人工知能システム」のことです。ChatGPTの主要機能は「人間同士の対話を模範すること」であり、その得意とするところは、「人間が自然と感じる回答の生成」です。

応答してくれる言語については、主要なものに対応しており、日本語で問いかけた場合は日本語で回答が返ってきます。

ChatGPTの返答イメージ

なぜそのようなことが可能かというと、人間の脳の神経回路の構造を模倣した「ニューラルネットワーク」を利用*7しており、大量のウェブページ、ニュース記事、書籍、社交メディアの投稿など、多様なテキストを学習しているからです。つまり膨大なデータで学習し、人間の脳を模倣した処理によって、人間が使う自然な言葉で、入力した言葉に対して回答を返してくれるのです。

多種多様な生成AI

生成AI（ジェネレーティブAI）とは
生成AIとは、学習したデータをもとに、画像・文章・音楽・デザイン、プログラムコード、構造化データなどを作成することができる人工知能（AI）の総称です。近年は様々な組織から多種多様な生成AIが開発、リリースされており、日進月歩の進歩を遂げています。なお、ChatGPTの「GPT」は「Generative Pre-trained Transformer」を意味しており、Gは生成を意味するGenerativeです。

ChatGPTは2023年6月現在、2つのバージョンが存在しています。2022年の11月に公開された無料で利用できるChatGPT3.5というバージョンと、2023年3月に公開された有償での利用が可能なChatGPT4というバージョンです。ChatGPT4は3.5に比べて事実にもとづく回答の精度が40％向上しているとされている他、いくつかの機能が追加されています。

また、人工知能チャットボットとしてはChatGPTの他にも「Google Bard」、「Microsoft Bing AI」「Baidu ERNIE」その他様々なモデルが登場しています。他にも文章や画像から生成する画像生成AIとして「Midjourney」や「Stable Diffusion」、音声から文字起こしを行うChatGPTと同じOpenAIの「Whisper」といったものもあります。最近では、MicrosoftがWindows11へ「Windows Copilot for Windows 11」というChatGPTを利用した対話型のアシスタンスの導入を発表しています。

こうした生成AIにはカスタマーサービスでの利用、ソフトウェアの作成やメール文章の作成から、ちょっとした日常生活の疑問の解決、様々なビジネス上のシナリオ作成からテストまで、幅広い活用の幅があります。


種類	提供元	サービス名	URL
文章生成AI	OpenAI	ChatGPT	https://openai.com/blog/chatgpt
文章生成AI	Google	Bard	https://bard.google.com/
文章生成AI	Microsoft	Bing AI	https://www.microsoft.com/ja-jp/bing?form=MA13FJ
文章生成AI	Baidu	ERNIE	https://yiyan.baidu.com/welcome
画像生成AI	Midjourney	Midjourney	https://www.midjourney.com/home/?callbackUrl=%2Fapp%2F
画像生成AI	Stability AI	Stable Diffusion	https://ja.stability.ai/stable-diffusion
画像生成AI	OpenAI	DALL·E	https://openai.com/dall-e-2
文章生成AI （文字起こし）	OpenAI	Whisper	https://openai.com/research/whisper
音声生成AI	ElevenLabs	Prime Voice AI	https://beta.elevenlabs.io/

無数に存在するAIの画像 — 無数に存在するAI
出典：Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyondより引用

ChatGPTとサイバー攻撃

このような幅広い活用を期待されているChatGPTですが、一方でサイバー攻撃においても悪用が注目されてしまっているという側面もあります。

ChatGPTのサイバー攻撃での悪用を考えるときに、まず考えられるのはフィッシング攻撃における悪用です。ある調査では「見慣れたブランドであれば安全なメールだと思っている」という人が44％いると報告されています。そのような人が被害にあいやすい、「もっともらしく見える、文面に不自然なところのない一見して信ぴょう性の高い文面」を、攻撃者はChatGPTを利用して簡単に作り出すことができます。加えて、攻撃者が標的の普段利用している言語を解さず、そこに言語の壁が存在したとしても、これもやはりChatGPTを利用することで容易に乗り越えることが可能となります。このような精巧なフィッシングメールを、攻撃者はこれまで以上に少ない労力で大量に生成可能となります。

また、ChatGPTにマルウェアで利用できるような悪意のあるコードを生成させようと検証する動きがあり、ダークウェブ上では前述のフィッシングでの悪用を含めて、活発な調査、研究が進められているという報告もあります。このような言語的、技術的なハードルの低下は、ノウハウのない人間でも攻撃の動機さえあれば、ChatGPTを利用することで簡単にサイバー攻撃が実行できてしまうという脅威につながります。

ChatGPTの活用におけるその他のセキュリティ課題

ChatGPTに対するセキュリティの観点からの懸念点は、他にもあります。

情報漏洩リスク

業務上知りえた機密情報や、個人情報をChatGPTに入力してしまうリスクです。ChatGPTに送信された情報は、OpenAIの開発者に見られてしまったり、学習データとして使われたりして、情報漏洩につながってしまう可能性があります。2023年3月末には、海外の電子機器製造企業において、ソースコードのデバッグや最適化のためにChatGPTにソースコードを送信してしまったり、議事録を作ろうとして会議の録音データを送信してしまったりという、情報漏洩が報道*2されています。

正しくない情報の拡散リスク

ChatGPTは過去に学習した情報を利用して回答しているため、間違った情報や意図的に歪められた汚染情報、セキュアではない情報にもとづいた返答をしてしまう可能性があります。また、蓄積情報についても大部分が2021年までの情報とされており、回答が最新情報とは限らない点にも注意が必要です。例えば最新の脆弱性情報について質問しても、間違っていたり、古い情報で回答をしてしまったりする可能性もあります。

ChatGPTのセキュリティ課題

ChatGPTのセキュリティでの活用

ここまでセキュリティの観点からChatGPTのリスクに注目してきましたが、ChatGPTは応答学習型のセキュリティ教育や、セキュリティの疑問に答えてくれるセキュリティボットの開発、インシデント発生時のセキュリティアシストや、脅威動向の把握など、セキュアな社会構築への貢献も期待されています。また、OpenAIからもAIを活用したセキュリティに関する「OpenAI cybersecurity grant program」という最大100万ドルの助成金プログラムを開始すると発表がされています。このことからも、AIを用いたサイバーセキュリティの強化や議論促進が今後進展していくものと考えられます。

基本的な対策こそが重要

AIとサイバー攻撃について述べてきましたが、気を付けないといけないのは、ChatGPTがなくても、攻撃者もマルウェアも既に存在しており、脆弱性があればそこを突いて攻撃が行われるのだということです。ChatGPTはあくまでサイバー攻撃の補助として悪用されているだけであり、ChatGPT自体が脅威なのではありません。危険なのはChatGPTではなく、サイバー攻撃を行う者や、脆弱性を放置するなど対策を怠ることです。

今後、ハードルが下がったことで、技術力の低い攻撃者が参入しやすくなり、攻撃の数は増えるかもしれませんが、過去からある基本的なセキュリティ対策を講じていれば、多くの攻撃は未然に防げることに変わりはありません。個人情報の漏洩や正しくない情報の拡散といったリスクについても、セキュリティポリシーの遵守や、きちんと情報の裏付けを取る（ファクトチェック）といった基本的な行動規範がリスクを緩和してくれます。基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。いたずらに怖がるのではなく、基本的なセキュリティ対策を踏まえたうえで、上手にAIと付き合っていくことが必要ではないでしょうか。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年4月21日2023年10月4日

BBSec脆弱性診断結果からみる
― 脆弱性を悪用したサイバー攻撃への備えとは ―

Webサイトは、重要なデータの宝庫であり、サイバー攻撃者にとっては宝の山です。攻撃者はWebアプリケーションやシステムに存在する脆弱性を突いた攻撃を仕掛けます。では、自組織のシステムに脆弱性が存在した場合、攻撃者に悪用されづらくするためには何ができるでしょうか。本記事では、多くの企業・組織への診断実績がある弊社の視点で、サイバー攻撃への備えの一つとして、脆弱性診断を活用した予防的措置をご紹介いたします。

脆弱性を悪用したサイバー攻撃

事業活動に欠かせないIT環境では、様々な個人情報や機密情報等が保管・やりとりされており、サイバー攻撃者にとってそれらは宝の山です。そのため、今この瞬間もあらゆる企業・組織がサイバー攻撃の脅威にさらされています。

そして残念ながら、多くのWebアプリケーションやシステムには脆弱性が存在している可能性があります。宝の山に、宝を盗める抜け穴、つまり脆弱性があるとなれば、悪意ある者に狙われてしまうのは当然といえます。

サイバー攻撃者はどのような脆弱性を狙うのか

では、サイバー攻撃者が狙う脆弱性とは、どのような脆弱性でしょうか。
それは攻撃者にとって「悪用がしやすい」、そして「うまみがある」脆弱性です。そのような脆弱性があるWebアプリケーションやシステムは、攻撃対象になりやすく、攻撃者にとって魅力的な標的です。

そして、攻撃者にとって「悪用がしやすい」「うまみがある」脆弱性とは、簡単に攻撃ツールやエクスプロイトコードが入手できる「蔓延度」、どれだけ甚大な被害をもたらすことができるのかという「危険度」、そしてどれだけ他の機能やシステム、あるいは世間にインパクトを与えることができるのかという「影響度」の3つを軸にして捉えることができます。

また、そうした攻撃者にとって魅力的な脆弱性が多数ある場合、一度の攻撃のみならず、何度も複数の脆弱性を突いて攻撃を行われる可能性があります。

脆弱性を突いた攻撃が成功した攻撃者のイメージ画像（自販機から飲み物が出てくる＝攻撃成功）

別の側面から見れば、攻撃者にとって魅力的な脆弱性がないWebアプリケーション・システムであれば、標的にされる可能性が少なくなるということです。

自販機に魅力的な脆弱性（攻撃してもうまみがない脆弱性）がないのをみて攻撃をあきらめる攻撃者のイメージ画像

サイバー攻撃者にとって攻撃対象にしづらいシステムとは？

ここまでみてきたように、攻撃者は「蔓延度」「危険度」「影響度」を軸に魅力的な脆弱性を判断することがあります。つまり裏を返せば、Webアプリケーションやシステムの脆弱性の「蔓延を防ぐ」「危険度を下げる」「影響度を下げる」ことで、攻撃者に脆弱性を悪用されにくくすることができます。そのためには各組織で脆弱性対策を行うことが必須となります。システムの欠陥をつぶし、脆弱性をなくすことが最も重要です。

古くから「無知は罪なり」という言葉もあります。情報セキュリティにおいては“まず知ること”が必要不可欠となります。脆弱性に対処するためには、「自組織のセキュリティ状況を見直し、リスク状況を把握して攻撃に備える」ことが重要です。

脆弱性の放置はサイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。サイバー攻撃によるインシデントは、組織にビジネスの機会の喪失、信用の失墜といった損失につながる可能性があるため、脆弱性の放置はそういった損失の潜在的な原因となります。

システムに存在する脆弱性の有無を確認するために有効な手段の一つが、脆弱性診断です。脆弱性診断により、日々変化する脅威に対する自組織のシステムのセキュリティ状態を確認できるため、適時・適切の対策が可能です。

BBSecの脆弱性診断サービス

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しています。検出された脆弱性に対するリスク評価は5段階にレベル付けしてご報告しており、リスクレベルによって脆弱性対策の優先順位を判断しやすいものとなっています（右表参照）。

2022年下半期診断結果（多く検出された脆弱性ワースト10）

2022年下半期、BBSecでは12業種延べ510企業・団体、3,964システムに対して、脆弱性診断を行いました。結果として、なんらかの脆弱性が検出されたシステムのうち、5件に1件ほどはリスクレベル「高」以上の脆弱性が含まれているのが現状です。そのリスクレベル「高」以上の脆弱性を検出数順に10項目挙げると、下表のとおりになります。

2022年下半期におけるWebアプリ編ワースト10の上位3項目は、上半期同様、攻撃者にとって悪用しやすくうまみのあるインジェクション系の脆弱性がランクインしています。いずれもよく知られた脆弱性ばかりなため、悪用された場合、世間に基本的なセキュリティ対策を怠っている組織と認識され、信用失墜につながります。

また、アプリケーション等のバージョンアップを行わず、古い脆弱なバージョンを使用し続けているWebアプリケーションも多く存在し、ワースト10のうちの4項目がそういった脆弱性でランクインしています。すでに他組織で悪用された実績のある脆弱性を放置した状態となっている等、攻撃者にとっては同様の攻撃を複数の組織に対して行うだけで成果が出るので、こちらも悪用しやすくうまみのある脆弱性といえます。

ネットワーク編のワースト10でも過去と同じような脆弱性がランクインしていますが、9位の「SNMPにおけるデフォルトのコミュニティ名の検出」は初のランクインとなりました。SNMPは、システム内部のステータスや使用ソフトウェア等の各種情報取得に利用されるプロトコルで、管理するネットワークの範囲をグルーピングして「コミュニティ」としています。コミュニティ名には、ネットワーク機器のメーカーごとに「public」等のデフォルト値がありますが、SNMPにおけるコミュニティ名はパスワードのようなものであるため、デフォルトのままだと、これを利用して攻撃者に接続され、攻撃に有用なネットワークの内部情報を取得される恐れがあります。

脆弱性診断を活用した予防措置

ここまでお伝えしたように、攻撃者はより悪用しやすくうまみのある脆弱性を狙ってくる中で、自組織のWebアプリケーション・システムに脆弱性が存在するのか、また存在した場合どういったリスクのある脆弱性なのかを知り、脆弱性対策を行うことは組織として重要なことです。

脆弱性を悪用したサイバー攻撃への備えとして、BBSecとしては、脆弱性診断を推奨します。下図の攻撃方法は一例となりますが、影響範囲として機会損失から業務停止まで引き起こされる可能性がある、という実態はどの攻撃方法でも同じです。脆弱性を悪用された場合、どの攻撃方法であってもそういった被害が出る可能性があるため、悪用されやすい脆弱性は早急に対応しなければなりません。

早急に対応するポイントは「自組織のシステム状態を知り、優先順位をつけながら必要な対策をする」こととなるのですが、自組織におけるセキュリティ対策の有効性確認には、専門家の目線をいれることをおすすめしています。

脆弱性を悪用したサイバー攻撃に対して、予防的にコントロールするといった観点も含め、よりシステムを堅牢化していくために脆弱性診断の実施をぜひご検討ください。

半期（6か月）毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
最新号のダウンロードはこちら。

SQAT脆弱性診断サービス

Webアプリケーション脆弱性診断-SQAT^® for Web-

Webサイトを攻撃するハッカーの手法を用いて、外部から動的に脆弱性を診断することで、攻撃の入口となる可能性のある箇所を検出します。診断は最新のセキュリティ情報に基づき実施されますので、開発時やリリース前ばかりでなく、既存システムに対する定期的な実施といった、現状の脆弱性対策の有効性を確認するために活用することをおすすめしています。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

ネットワーク脆弱性診断-SQAT^® for Network

悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。ネットワークを標的とした攻撃のリスクを低減するため、脆弱性を徹底的に洗い出し、システムの堅牢化をご支援します。システムの導入・変更・アップグレード時のほか、運用中のシステムに対する定期チェックにご活用いただけます。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

Security Report TOPに戻る
TOP-更新情報に戻る