【第1回】「OWASP Top 10とは?アプリケーションセキュリティの基本を押さえよう」

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

近年、Webアプリケーションを狙ったサイバー攻撃が急増しており、企業にとってWebアプリケーションのセキュリティ強化は欠かせない課題となっています。その中で、世界中のセキュリティ専門家が指標として活用しているのが「OWASP Top 10」です。

今回は、Webアプリケーションの代表的な脆弱性をまとめた「OWASP Top 10」を通じて、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的とし、背景から各脆弱性カテゴリの説明、実例、対策方法までを全3回のシリーズに分けて解説します。

OWASPとは

OWASP(Open Worldwide Application Security Project)は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。開発者やセキュリティ専門家によって構成されており、セキュリティに関するツールやドキュメントなどを無償で提供しています。OWASPは中立かつオープンな立場から情報を発信しており、多くの企業や政府機関がそのガイドラインを信頼し、採用しています。

OWASP Top 10とは

OWASP Top 10は、Webアプリケーションにおける代表的なセキュリティリスクをランキング形式でまとめたもので、最も重要な10の脆弱性カテゴリを示しています。このリストはおよそ3年ごとに更新されており、業界の最新動向や実際の脅威傾向を反映しています。このTop 10は、アプリケーション開発やセキュリティ教育、脆弱性診断の指針として世界中で活用されており、情報システム部門にとってはセキュリティの共通言語ともいえる存在です。

OWASP Top 10:2021概要

OWASP Top 10:2021で挙げられているリスクとその概要について、SQAT.jpでは以下の記事でも取り上げています。あわせてぜひご覧ください。
OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

以下は、2021年に発表された最新版のOWASP Top 10のリストです。

項目番号リスク名概要
A01Broken Access Control
(アクセス制御の不備)
アクセス制御の不備により、本来アクセスできない情報や機能へアクセスされるリスク
A02Cryptographic Failures
(暗号化の不備)
暗号化の不備による機密情報の漏洩や改ざん
A03Injection
(インジェクション)
SQLインジェクションなど、外部から不正なコードを注入されるリスク
A04Insecure Design
(セキュアでない設計)
セキュリティを考慮しない設計により生じる構造的リスク
A05Security Misconfiguration
(セキュリティ設定のミス)
設定ミスや不要な機能の有効化に起因する脆弱性
A06Vulnerable and Outdated Components(脆弱かつ古いコンポーネントの使用)脆弱性を含む古いライブラリやフレームワークの使用
A07Identification and Authentication Failures(識別と認証の不備)認証処理の不備により、なりすましや権限昇格が発生する
A08Software and Data Integrity Failures(ソフトウェアとデータの整合性の不備)ソフトウェア更新やCI/CDの不備により改ざんを許すリスク
A09Security Logging and Monitoring Failures(セキュリティログとモニタリングの不備)侵害の検知・追跡ができないログ監視体制の欠如
A10Server-Side Request Forgery (SSRF)(サーバサイドリクエストフォージェリ)サーバが内部リソースにアクセスしてしまうリスク
出典:OWASP Top 10:2021より弊社和訳

各リスク項目の代表的な脅威事例

項目番号実例企業・事例概要
A01Facebook (2019)他人の公開プロフィールがIDの推測とAPI操作により取得可能だった*8
A02Turkish Citizenship Leak(2016)暗号化されていなかったデータベースから約5,000万人の個人情報が流出*9
A03Heartland Payment Systems (2008)SQLインジェクションにより1億件以上のクレジットカード情報が漏洩*10
A04パスワードリセットの仕様不備(複数事例)多くの中小サイトで、トークンなしにメールアドレス入力のみでリセット可能な設計が確認されている
A05Kubernetes Dashboard誤設定事件(Tesla 2018)管理用インターフェースが公開状態になっており、社内クラウドで仮想通貨マイニングに悪用された*11
A06Equifax (2017)古いApache Strutsの脆弱性(CVE-2017-5638)を放置していたことで1.4億件以上の個人情報が漏洩*12
A07GitHub (2012)認証処理の不備により、セッションを乗っ取られる脆弱性が悪用され、一時的にユーザが他人のリポジトリにアクセス可能に
A08SolarWinds サプライチェーン攻撃(2020)正規のソフトウェアアップデートにマルウェアが仕込まれ、多数の政府機関や企業を含めた組織に影響を与えた
A09Capital One (2019)AWS環境の不適切なログ監視により、Web Application Firewallの設定ミスから約1億600万人分の情報が流出*13
A10Capital One (同上)SSRF攻撃によりAWSメタデータサービスへリクエストが可能となり、内部資格情報を窃取された*14

企業はOWASP Top 10をどう活用すべきか

OWASP Top 10は、単なる「参考資料」ではなく、企業が自社のセキュリティ対策を体系的に見直すための実践的な指針として活用できます。以下に、企業の情報システム部門担当者等が実際に取り入れるべき活用方法を紹介します。

開発プロセスへの組み込み(セキュア開発)

アプリケーション開発において、設計段階からOWASP Top 10を参考にすることで、設計段階から脆弱性を防ぐ「セキュア・バイ・デザイン(Secure by Design)」の思想を組み込むことが可能です。とくにA04「Insecure Design」などはアプリケーション開発の初期段階での対策が鍵となります。

脆弱性診断の評価基準として

外部のセキュリティ診断会社や自社診断の基準としてOWASP Top 10を採用することで、リスクの見落としを防ぎつつ、業界標準の診断を実現できます。

セキュリティ教育・啓発資料として

企業の社員のセキュリティリテラシーを高めるため、開発者・インフラ管理者・経営層を含めたセキュリティ教育プログラムにOWASP Top 10を取り入れることも有効です。定期的な研修やハンズオン形式での演習と組み合わせることで、具体的な攻撃手法や防御策を理解しやすいため、セキュリティ意識の向上につながります。

OWASP Top 10はセキュリティ対策の出発点

OWASP Top 10は、Webアプリケーションの開発やセキュリティ対策に取り組む企業にとって、最も基本かつ重要な指標です。サイバー攻撃の多くは、実はこうした「基本的な脆弱性」から発生しており、OWASP Top 10で挙げられているリスクを理解することがリスク低減の第一歩になります。特に情報システム部門や開発チームは、OWASP Top 10を設計・開発・テスト・運用の各フェーズに取り入れ、継続的なセキュリティ対策を行う必要があります。また、社員へのセキュリティ教育や脆弱性診断サービスの評価基準としても有効活用することで、より実効性の高いセキュリティ体制を構築できるでしょう。

第2回では、API特有の脅威にフォーカスした「OWASP API Security Top 10」をご紹介します。APIを活用している企業にとって、見逃せない内容となっていますので、ぜひあわせてご覧ください。


―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」へ続く―

【連載一覧】

―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」―
―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

脆弱性診断の効果を最大化するポイント解説 – やりっぱなしを防ぐサイバー保険による脆弱性管理と診断サイクルの作り方

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2025年3月13日「脆弱性診断、やりっぱなしになっていませんか?高精度診断と充実サポートでリスクを最小化〜サイバー保険で安心 診断から守るまでを徹底解説〜」というセミナーを開催しました。今回はその講演内容のポイントについてご紹介します。

登壇者:株式会社ブロードバンドセキュリティのセキュリティサービス本部 サービス支援部 支援課 課長代理 木下祐希

サイバー攻撃の実態と脆弱性管理の重要性

まず脆弱性診断を実施する背景として、近年のサイバー攻撃の実態について理解する必要があります。かつては愉快犯も少なくなかったサイバー攻撃は、現在では金銭目的や企業・個人に対する悪意を持った攻撃が主流となっており、その手口も高度化・巧妙化しています。こうした環境において脆弱性とは何か、そしてなぜ脆弱性管理が重要なのかを把握することが対策の第一歩となります。

サイバー攻撃の変化は明確です。以前は「愉快犯」と呼ばれる、いたずら目的のハッカーやクラッカーも少なからずおり、DDoS攻撃で嫌いな企業のサーバーを落としたり、不特定多数にフィッシングメールを送りつけたりするような行為が中心でした。しかし現在は、より直接的な、個人情報や機密情報を盗み出して金銭化することを目的とした攻撃者が増えています。

ダークウェブの出現により、盗んだ情報を売却する市場ができました。攻撃者にとっては明確な金銭的利益を得る手段となり、より悪質で深刻な攻撃が増えているのです。

脆弱性の検出実態についても驚くべき数字が示されました。ブロードバンドセキュリティによる脆弱性診断を受けた企業の統計では、Webアプリケーションでは約90%、ネットワークでは約55%の企業で何らかの脆弱性が検出されています。さらに深刻なのは、リスクレベルが「高」以上の重大な脆弱性がWebアプリケーションで16.7%、ネットワークで21.6%も検出されているという事実です。

これは一度も診断を受けたことがない企業だけではなく、定期的に脆弱性診断を実施している企業も含めた数字です。攻撃手法は日進月歩で進化していますので、定期的な診断が必須なのです。

脆弱性とは、不正アクセスやコンピュータウイルスなどの攻撃により、システムの機能や性能を損なう原因となり得るセキュリティ上の問題箇所のことです。脆弱性が悪用されると、内部データの盗取や改ざん、削除、さらには他のコンピュータへの攻撃の踏み台にされるなど様々な被害が発生します。

「無知は最大の脆弱性」という言葉があるように、まず自社のシステムの状態を知り、必要な対策を講じることが何よりも重要です。脆弱性診断により、日々変化する脅威に対する自システムのセキュリティ状態を確認できるため、適時・適切な対策が可能になります。

脆弱性診断のやり方と診断実施時の課題

次に脆弱性診断の具体的なやり方と、企業が診断を実施する際に直面する課題について解説します。

脆弱性診断を住宅に例えると、ネットワーク脆弱性診断は土地や地盤の検査、Webアプリケーション脆弱性診断は建物自体の検査に相当します。企業が脆弱性診断を実施する際には、コスト面や専門知識の必要性など様々な課題がありますが、これらを適切に解決することが重要です。

脆弱性診断とは、窓のひび割れや水道管の老朽化など、故障・欠陥箇所を探すことに似ています。ネットワーク脆弱性診断は地盤や土壌など土地に関する検査、Webアプリケーション脆弱性診断は土地の上に建っている家を検査するイメージです。

この二つの診断タイプには共通する項目もありますが、視点が異なります。ネットワーク脆弱性診断は宅外から宅内に入るまでの故障・欠陥箇所を見つけるのに対し、Webアプリケーション脆弱性診断は宅内の方から見た観点での指摘となります。

企業が脆弱性診断を実施する際に直面する主な課題として、以下の4点が挙げられます。

  1. コストの問題:脆弱性診断は専門的な技術とツールを要するため、実施コストが高くなりがちです。
  2. 専門知識の必要性:診断結果を適切に解釈し、対策を講じるには専門的な知識が不可欠です。セキュリティの専門家が不足している企業では対応が遅れがちになります。
  3. 診断後のサポート不足:診断後に必要な修正や対策を行うためのサポートが不十分な場合が多く、結果的に脆弱性が放置されるリスクが高まります。
  4. 手動診断と自動診断のバランス:手動診断は時間とコストがかかる一方、自動診断は検出精度に限界があるため、両者の適切なバランスが求められます。

これらの課題に対処するため、「かかりつけ医」のような存在としてセキュリティベンダーとの関係構築が推奨されます。いざという時だけでなく、日頃からかかりつけ医のような存在としてセキュリティベンダーとの関係を構築することで、結果的に自社のセキュリティレベルの向上と維持が図れます。

「かかりつけ医」のメリットとしては、まず、病歴や体質(システム環境や脆弱性の状況)を把握しており、素早く適切に対応できること。そして、気軽に相談できるので、問題が早期発見しやすいこと。結果として、必要に応じて他の専門医(専門的なセキュリティサービス)への連携もスムーズになることも含め、メリットは多々あると言えます。

高精度な脆弱性診断とサイバー保険を含む継続的なサポート体制

脆弱性診断を効果的に行うためには、精度の高い診断と充実したサポート体制が不可欠です。高品質な脆弱性診断サービスには、有資格者による手動検査、網羅性の高い診断内容、わかりやすい報告書の提供、診断後のサポートなどの特徴があります。特に重要なのは、診断結果に基づいた対策の実施と、定期的な診断による継続的な脆弱性管理サイクルの確立です。

ブロードバンドセキュリティのSQAT®(Software Quality Analysis Team)脆弱性診断サービスを例に、効果的な脆弱性診断の要素が説明されました。まず「Quality(品質)」として、情報処理安全確保支援士やCISSP、CEH等の有資格者による手動/ツール検査を実施していること、OWASP TOP10やNIST SP 800シリーズ、IPAの「安全なWebサイトの作り方」などの標準を踏襲した網羅性の高い診断内容を提供していることが特徴です。

次に「Communication(コミュニケーション)」の観点では、診断実施部門だけでなく報告書のレビューを専門とする部門やツール開発部門が各役割に集中する体制を整え、専用ポータルサイトを通じた効率的な情報共有を実現しています。

さらに「Support(サポート)」面では、診断結果に関する問い合わせを診断実施後も受け付け、報告書納品日から3ヶ月間は再診断を無償で提供するなど、継続的なサポート体制を整えている点が強調できます。

付け加えると、同社の脆弱性診断サービスの特徴として、豊富な診断シグネチャ(検査パターン)、スピーディな報告(診断終了後4営業日以内の報告書納品)、情報収集力に裏打ちされた分析、多彩なオプションメニューなどが挙げられます。

手動診断とツール診断のそれぞれの特徴と使い分けについても説明します。

手動診断は網羅性、検査の深度、精度が高い一方でコストも高くなります。一方、ツール診断は低コストで実施できますが、検出できない項目もあります。両者の適切な組み合わせとして、「リリース時や年に一度は手動診断、日常的な監視はツール診断」といった使い分けが効果的です。

特に注目すべき点として、ブロードバンドセキュリティは三井住友海上火災保険株式会社との提携により、「サイバー保険付帯の脆弱性診断サービス」を提供しています。このサービスは、脆弱性診断契約日から1年間、情報漏えいやサイバー攻撃に起因する賠償損害および事故発生時に対策を講じた場合の費用損害を最大1,000万円まで補償するものです。

実際の初動対応には平均して1,000万円程度必要であると想定されています。この補償は脆弱性診断サービスにオプションとして付けるのではなく、対象となる診断サービスを受けると自動的に付帯します。

脆弱性診断を活かす継続的なセキュリティ対策

最後に、脆弱性診断を単発で終わらせるのではなく、継続的なセキュリティ対策として活用するためのポイントを紹介します。脆弱性は日々増加し、攻撃手法も進化し続けるため、一度の診断だけでは十分な対策とは言えません。診断対象の特徴や検査目的に合わせた適切な診断手法の選定と、定期的な脆弱性の洗い出しと棚卸が重要です。

脆弱性診断は一度実施したらそれで終わりというものではありません。脆弱性は日々新たな手法や種類が増加し続けるため、診断実施後に適切なセキュリティ対策を行っていたとしても、形を変えて再び脆弱性が生じる可能性は十分にあります。

継続的なセキュリティ対策のサイクルとして、以下のステップが推奨されています。

  1. 脆弱性診断の実施
  2. セキュリティ対策の実施
  3. 新たな脆弱性・攻撃手法の登場に注意
  4. 自組織の環境やシステム特性に適した診断の選定

このサイクルを繰り返すことで、持続的にセキュリティレベルを向上させることができます。また、診断対象の特徴や検査目的に応じて、手動診断とツール診断を適切に組み合わせることも重要です。

まとめ:効果的な脆弱性管理で高まるセキュリティ体制

脆弱性診断を「やりっぱなし」にせず、継続的な脆弱性管理の一環として活用することが、組織のセキュリティ体制強化には不可欠です。サイバー攻撃が高度化・巧妙化する現代においては、脆弱性診断の実施、診断結果に基づく対策の実施、新たな脆弱性への対応という一連のサイクルを確立することが重要です。自社の環境やシステム特性に合わせた適切な診断手法を選定し、定期的な診断を通じて継続的にセキュリティレベルを向上させていきましょう。

脆弱性をなくすこと(攻撃の的をなくすこと)が最も重要です。攻撃者は実際の攻撃行動に移る前に、クローリングツールなどを使って脆弱性をスキャンします。脆弱性の少ないシステムは攻撃者にとって「コストパフォーマンスが悪い」ターゲットとなり、結果的に攻撃を受けにくくなります。

サイバー保険も含めた総合的な脆弱性対策を構築することで、万が一の事態にも備えることができます。ブロードバンドセキュリティのように、高精度な診断と充実したサポート体制を持つセキュリティベンダーと連携することで、より効果的な脆弱性管理が可能になります。

脆弱性管理は単なるコスト要素ではなく、企業の競争力維持やリスク管理のための重要な投資です。サイバー保険の付帯のある脆弱性診断サービスを受けていても、被害があったときかかってしまう損害額を考えると費用対効果は決して悪くないと言えます。

最終的に、脆弱性診断を含む継続的なセキュリティ対策サイクルの確立は、お客様に安心して自社サービスを利用し続けてもらうための基盤となるのです。これからのデジタル時代において、適切な脆弱性管理は企業の信頼性と持続可能性を支える重要な要素であると言えるでしょう。

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

Security NEWS TOPに戻る
バックナンバー TOPに戻る

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

  • 2025年4月23日(水)14:00~15:00
    今知るべき!サポート切れのソフトウェアへのセキュリティ対策ガイド
  • 2025年4月30日(水)13:00~13:30
    CVSSとSSVCで実践する次世代脆弱性管理:サイバー攻撃対策セミナー2024
  • 2025年5月14日(水)14:00~15:00
    クラウド利用の落とし穴と対策とは?今こそ見直すべきクラウドセキュリティ対策-セキュリティ設定診断の活用方法をご紹介-
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    【緊急】Apache Tomcatの脆弱性 CVE-2025-24813-PoC公開&攻撃実例、迅速な対応を!-

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。


    はじめに

    Apache Tomcatは、多くのWebアプリケーションで利用されている人気のサーブレットコンテナですが、最新の脆弱性CVE-2025-24813が重大なリスクとして報告されています。既にPoC(Proof of Concept)が公開され、実際に攻撃に悪用されている事例も確認されています。これにより、リモートコード実行(RCE)や情報漏洩といった深刻な被害が発生する可能性が高まっています。

    脆弱性の詳細

    CVE-2025-24813の概要

    ・概要

    Apache Tomcatに存在する脆弱性で、ファイルパスの正規化の不備を突くことで、攻撃者が悪意のあるファイルをアップロードし、シリアライズ済みセッションのデシリアライズ処理時に任意のコード実行が可能となります。

    ・攻撃シナリオ

    攻撃者は、PUTリクエストを利用して、悪意のあるシリアライズ済みJavaセッションファイル(PoCとして公開済み)をTomcatのセッションストレージにアップロードします。その後、GETリクエストでJSESSIONIDを指定することで、Tomcatがこの不正なセッションファイルをデシリアライズし、悪意のあるコードが実行されます。

    ・リスク

    認証不要でリモートからコード実行が可能なため、攻撃者によってシステム全体が乗っ取られるリスクが高いです。さらに、アップロードされたファイルは、従来のセキュリティ対策(WAF等)で検知されにくいという特徴があります。

    • CVSSベーススコア

    ※現状の具体的な数値は各セキュリティ情報サイト等をご確認ください。(本記事ページ下部【参考情報】ご参照)

    推奨対策

    1. パッチ適用とアップグレード
      • アップグレードの実施
      脆弱性が修正された最新バージョンへのアップグレードを速やかに実施してください。Apache Tomcat のバージョンアップにより、脆弱性を根本的に解消できます。
    2. 設定変更による一時的な対策
      • デフォルト設定の見直し
      Webアプリケーションの設定ファイル(例:web.xml)で、デフォルトの書き込み機能を無効化するなど、一時的なセキュリティ強化策を講じることも有効です。
    3. セキュリティ管理の強化
      • 脆弱性管理プログラムの導入
      定期的な脆弱性診断と評価を行い、システムに内在する脆弱性を早期に検出し修正してください。
      • 管理者アクセスの制御
      管理者アカウントには多要素認証などの追加対策を実施し、アクセス権限を最小限に絞ることが重要です。

    緊急対応窓口のご案内

    万が一、CVE-2025-24813に関連する攻撃や不審な活動が自社内で確認された場合は、直ちに弊社緊急対応窓口までご連絡ください。迅速な対応と調査を通じて、被害の拡大を防ぐお手伝いをいたします。

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    まとめ

    Apache Tomcatの脆弱性CVE-2025-24813は、既にPoCが公開され攻撃に悪用されている深刻な問題です。お使いのTomcat環境が影響を受けている場合、速やかに最新パッチの適用やアップグレード、必要な設定変更を実施してください。また、万一の攻撃が確認された際には、弊社緊急対応窓口までお知らせいただくことで、迅速な支援を受けることが可能です。

    【参考情報】

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

  • 2025年3月26日(水)13:00~14:00
    予防で差がつく!脆弱性診断の話~脆弱性による脅威とその対策~
  • 2025年4月2日(水)13:00~14:00
    今さら聞けない!PCI DSSで求められる脆弱性診断-いよいよ未来日付要件が有効に!PCI DSSv4.0での脆弱性診断実施におけるポイントとは-
  • 2025年4月16日(水)14:00~15:00
    知っておきたいIPA『情報セキュリティ10大脅威 2025』~セキュリティ診断による予防的コントロール~
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

    前回までの内容

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

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

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

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

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

    クロスサイトリクエストフォージェリ(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 NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    セキュリティトピックス動画申し込みページリンクへのバナー画像

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

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

    前回までの内容

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

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

    SQLインジェクションとは

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

    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インジェクションの脆弱性(マルとバツのアイコンマーク)イメージ

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

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

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

    まとめ

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

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    セキュリティトピックス動画申し込みページリンクへのバナー画像

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

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

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

    Webアプリケーションの脆弱性入門(3つのブロックにアイコンマーク)イメージ

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

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

    クロスサイトスクリプティング(XSS)とは

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

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

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

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

    1. 反射型XSS…攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの
    2. 蓄積型XSS…攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの
    3. 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 NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    セキュリティトピックス動画申し込みページリンクへのバナー画像

    クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    今回は、クロスサイトスクリプティング(XSS)のような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について取り上げます。CSRFの脆弱性リスクやXSSとの違い、さらに実際の診断の現場での検出頻度や、見つかった際に行うべき対応、予防策についてもご紹介します。安全なWebサイト運用のために必読です。

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

    クロスサイトリクエストフォージェリ(Cross Site Request Forgery)は、Webアプリケーションの脆弱性の一つで、略称「CSRF」とも呼ばれます。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

    「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFの脆弱性を悪用することで、ユーザが意図していないリクエストを強制的に行わせることが可能になります。攻撃者は罠として用意した偽造サイトを用いてユーザーに意図しないリクエストを強制的に送信させます。結果として、ユーザーの認証情報を利用した不正な操作や、個人情報の流出が引き起こされる可能性があります。

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

    クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。クロスサイトリクエストフォージェリとクロスサイトスクリプティングは、どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、発見される頻度や攻撃による影響、対策方法は異なります。

    • XSS:Webサイトに悪意のあるスクリプトを埋め込む
    • CSRF:ユーザの意図しないリクエストを強制的に実行させる

    脆弱性診断の現場にみるCSRFの実態

    あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

    ブロードバンドセキュリティが2024年上半期に総数3,536のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は15%のシステムで検出され、その中にCSRFは44%含まれていました。つまりCSRFの脆弱性が存在したシステムは全体の6%になります。ここの数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

    CSRFによる攻撃と被害例

    CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

    もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

    意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

    対策を怠ると他サイトへの遷移ができなくなる可能性も

    また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*15 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

    セキュリティ企業が見るCSRFのリスクとは

    なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

    CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

    たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

    CSRFのリスクは低い? 高い?

    CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

    CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

    CSRF脆弱性への対策

    最も効果的な対策は「トークン」呼ばれる推測困難な文字列の使用です。

    • ユニークな推測困難な文字列を生成
    • リクエスト時に追加検証
    • PHP、Java、ASP.NETの主要フレームワークで実装可能

    CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

    事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

    注意!トークン実装の落とし穴

    フレームワークに機能があっても、実際のコーディング時に1行追加することを忘れがちです。「機能がある=安全」ではありません。

    開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

    前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約6%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

    まとめ:CSRFは名脇役、されど油断大敵

    • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
    • CSRFは単独では大きな脅威ではありませんが、他の攻撃手法と組み合わさることで深刻なセキュリティリスクになり得ます。
    • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
    • 定期的な脆弱性診断と、最新のセキュリティ対策が何より重要です。

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像