はじめに: ウェブアプリケーションのセキュリティを、単に動作させるだけでなく、最後に徹底的に調査したのはいつですか？恐ろしい真実を述べます。アプリケーション内のすべてのフォームフィールド、APIエンドポイント、サードパーティスクリプト、および設定ファイルは、チェックされないまま放置されると攻撃ベクトルになる可能性があります。現代のウェブアプリケーションはこれまで以上に豊富で複雑であり、それは攻撃者にとっての攻撃対象領域が増大していることを意味します。実際、最近のデータによると、セキュリティインシデントのほぼ半分にウェブアプリケーションが関与しています。悪名高いOWASP Top 10のリスクから、新たに発見されたCVEに至るまで、ウェブの脆弱性は抽象的な理論ではなく、あらゆる規模の組織で実際に発生している侵害の背後にあります。
この記事の目的は、フロントエンドとバックエンドの両方の観点から、最も重要なWebアプリケーションの脆弱性に光を当てることです。よく知られているOWASP Top 10のリスクに加え、注目度の高いエクスプロイト（Log4Shellなど）や、開発者が実際のプロジェクトで犯しがちな一般的なコーディングミスについても取り上げます。各脆弱性について、それが何であるか、実際の例やインシデントを挙げ、その軽減方法を概説します。また、Aikidoのデベロッパーファーストなセキュリティプラットフォーム（コードスキャン、シークレット検出、SAST、IaCスキャンなどの機能を含む）が、これらの問題が本番環境で発生する前に検出または防止するのにどのように役立つかについても説明します。
リスト：
1. インジェクション攻撃（SQL、コマンド、LDAP）
2. クロスサイトスクリプティング（XSS）
3. 認証の不備
4. アクセス制御の不備
5. セキュリティ設定のミス
6. 機密データの露呈とシークレットの漏洩
7. 既知の脆弱性を持つコンポーネントの使用
8. クロスサイトリクエストフォージェリ（CSRF）9. サーバーサイドリクエストフォージェリ（SSRF）
10. 安全でないデシリアライゼーション
Webアプリケーションの脆弱性とは何ですか？
Webアプリケーションの脆弱性とは、Webアプリの設計、実装、または設定における弱点や欠陥であり、攻撃者がシステムを侵害するために悪用できるものです。これらは、インジェクションの欠陥のようなコーディングバグから、管理コンソールを開いたままにするような設定ミス、ユーザーがセキュリティチェックをバイパスできるロジックの問題まで多岐にわたります。一部の脆弱性は、攻撃者がデータを盗んだり、ユーザーアカウントを乗っ取ったりすることを可能にし、また、サーバー全体の侵害やユーザーへのマルウェア拡散を可能にするものもあります。多くの「古典的な」バグは何年も前から知られており（OWASP Top 10リストにまとめられています）、技術スタックの進化や単純なヒューマンエラーにより、依然として広く存在しています。
以下では、すべての開発者とDevSecOpsチームが認識しておくべき主要なWebアプリケーションセキュリティ脆弱性を詳しく見ていきます。これは存在するすべてのバグを網羅したリストではなく、今日一般的に見られる最も一般的で危険な問題と、それらを回避するためのヒントをご紹介します。
Webアプリケーションの主要な脆弱性（フロントエンド＆バックエンド）
以下の脆弱性は、OWASP Top 10と最近の現実世界のエクスプロイトから抽出されています。それぞれがWebアプリケーションにとって深刻なリスクを表しています。一つずつ見ていきましょう。
1. インジェクション攻撃 (SQL、コマンド、LDAPなど)
概要： インジェクションの脆弱性は、信頼できないデータがコマンドまたはクエリの一部としてインタープリタに送信されるときに発生します。最も悪名高いのは、SQLインジェクション（SQLクエリ内の悪意のある入力）とOSコマンドインジェクション（サーバー上で実行される悪意のある入力）です。アプリケーションが適切な検証なしにユーザー入力をデータベースクエリ、シェルコマンド、LDAPクエリ、またはORMフィルターに直接含めると、攻撃者は独自のコマンドを「インジェクション」できます。これにより、データ盗難、データ破損、または完全なホスト乗っ取りにつながる可能性があります。OWASPによると、インジェクションは最上位のリスクであり、現在ではクロスサイトスクリプティングもその分類に含まれています。
例: 注目すべき例の1つは、2023年のMOVEit Transfer侵害です。攻撃者はMOVEitファイル共有WebアプリのゼロデイSQLインジェクション（CVE-2023-34362）を悪用し、サーバー上でリモートコードを実行しました。Clopランサムウェアグループはこの脆弱性を利用して数百の組織からデータを盗み出し、単一のインジェクションバグが大規模な侵害にエスカレートする可能性を示しました。この事件は、SQLiが単なる「古い」問題ではなく、依然として非常に活発であり、壊滅的な被害をもたらす可能性があることを示しました。
影響: インジェクション攻撃が成功すると、壊滅的な被害をもたらす可能性があります。SQLインジェクションにより、ユーザーのパスワード、個人記録、またはビジネスデータが漏洩する可能性があります。OSコマンドインジェクションは、攻撃者にサーバーのシェルを与え、インフラストラクチャ全体の侵害につながる可能性があります。要するに、インジェクションの脆弱性は、深刻なデータ損失、アカウント侵害、またはリモートコード実行につながることが多く、攻撃者にとって格好の標的となっています。
対策： 信頼できない入力をコマンドと直接混在させないことが重要です。データベースアクセスには、パラメーター化クエリまたはプリペアドステートメントを使用します（これにより、SQLインタープリターが入力とコードを混同することはありません）。OSコマンドの場合、コマンド文字列の構築は避け、安全なAPIを使用するか、期待される値をホワイトリスト化します。入力検証と出力エンコーディングも重要な防御層です。AikidoのAIを活用したSAST（静的コード解析）は、デプロイ前にコード内の危険なインジェクションパターンを検出するのに役立ちます。例えば、Aikidoのコードスキャンは、ユーザー入力がサニタイズなしでSQLステートメントに連結されたり、システムコールに渡されたりする箇所を特定します。このようなスキャナーをCI/CDまたはIDEに統合することで、インジェクションの脆弱性を自動的に検出し、修正できます。Aikidoがあれば、攻撃者が悪用するずっと前に、その脆弱なSQLクエリを特定できていたでしょう。
2. Cross-Site Scripting (XSS)
概要： クロスサイトスクリプティングは、ユーザーのブラウザを標的とするインジェクションの一種です。XSS脆弱性により、攻撃者は悪意のあるクライアントサイドスクリプト（通常はJavaScript）を他のユーザーが閲覧するWebページに挿入できます。データベースを標的とするSQLiとは異なり、XSSは攻撃者がユーザーが見るコンテンツを操作することを可能にし、セッショントークンの窃取、UIの改ざん、マルウェアの配信などにつながる可能性があります。XSSには、反射型XSS（悪意のあるスクリプトがリクエストから来てレスポンスに反映される）、格納型XSS（スクリプトがサーバーに保存され、例えばデータベースのコメントフィールドに保存され、すべての閲覧者に提供される）、およびDOMベースXSS（脆弱性がページを変更するクライアントサイドコードにある）などの種類があります。
例: 最も有名なXSSインシデントの1つは、2018年のBritish Airwaysの情報漏洩でした。Magecartハッカーグループは、BAのウェブサイトで使用されていたサードパーティのJSライブラリ（Feedify）に悪意のあるスクリプトを注入しました。このスクリプトは、支払いページからクレジットカード情報をスキミングし、攻撃者が制御するサーバーにデータを送信しました。攻撃者は、情報漏洩が発覚するまでに約380,000件の取引から個人情報とクレジットカード情報を盗み出すことに成功しました。本質的に、サプライチェーンコンポーネントのXSS脆弱性が大規模なデータ窃取につながり、BAには高額な罰金が科されました。その他の実世界のXSSの例としては、数百万のアカウントが露呈する可能性があったFortniteのウェブページバグや、攻撃者が高価値の販売者アカウントを乗っ取るために悪用したeBayサイトのXSSなどがあります。
影響:XSSは主にユーザーを危険に晒しますが、間接的にアプリケーションのセキュリティ（そして確実に評判）にも影響を及ぼします。攻撃者はセッションクッキーを盗み（ユーザーになりすます）、被害者になりすまして操作を実行（CSRF対策が不十分な場合、資金移動やパスワード変更など）、あるいはフィッシングフォームを表示してユーザーを騙すことが可能です。管理者ユーザーのセッションがXSS経由で乗っ取られた場合、攻撃者はアプリケーションの完全な制御権を獲得する可能性があります。機密性のないサイトでもXSS対策は必須です。偽のログイン画面を表示したり、ユーザーをエクスプロイト へ誘導したりするサイトは誰も望みません。
防止: XSSに対する防御には、 出力エンコーディング およびコンテンツセキュリティポリシー。アプリケーションがユーザー提供データをウェブページに表示する際は常に、そのデータがコードとして解釈されないよう、コンテキスト（HTML、JavaScript、CSSなど）に合わせて適切にエスケープ/エンコードする必要があります。ほとんどのウェブフレームワークにはテンプレートまたはエンコードライブラリが備わっています。これらを一貫して使用し（生の文字列からHTMLを作成することは避けてください）、強力なContent Security Policy（CSP）を実装して、ページで実行できるスクリプトを制限してください（ただし、CSPは第二の防御線です）。 Aikidoのコードスキャンは、ユーザー入力が適切なサニタイズなしにページに挿入される領域を検出できます。 例えば、誤って使用した場合、 innerHTML あるいは文字列結合によってユーザーデータをDOMに注入する場合、Aikidoの静的アナライザーがそれを検出します。Aikidoは、設定スキャンを通じて、HTTP-onlyフラグの欠落やContent Security Policyヘッダーも特定できます。これらの問題を早期に発見することで、ユーザーに対する次のMagecartスタイルの攻撃を防ぎます。（ボーナス：Aikidoの統合された脆弱性ナレッジベースは、安全なコーディングプラクティス（例：～の使用）も提案できます。） textContent 概要 innerHTML DOM XSSを回避するため。）
3. 認証の不備
概要： Broken Authentication（認証の不備）とは、ユーザー認証情報、セッションID、パスワードリセット、アカウント回復など、サイトがログインおよびセッション管理を処理する方法における脆弱性を指します。実装の不備により、攻撃者がパスワード、キー、またはセッショントークンを容易に侵害できる場合、それは認証の不備です。一般的な落とし穴には、脆弱なパスワードポリシー（またはログイン時のレート制限がなく、ブルートフォース攻撃を可能にする）、パスワードを安全に保存しない（例：平文またはソルトなしハッシュでの保存）、予測可能または安全でないセッションIDの使用、ログアウト時のセッション無効化の欠如、および「記憶する」機能やパスワードリセットロジックの欠陥などがあります。攻撃者が他人のふりをする（認証情報やセッションを推測または盗むことによって）か、適切な認証情報なしでログインすることを可能にするあらゆる欠陥がこのカテゴリに分類されます。OWASPによると、これらの認証の失敗はアカウント乗っ取りや重大なデータ漏洩につながる可能性があります。
例: 例は枚挙にいとまがありません。侵害の大部分は、侵害された認証情報に起因しています。実際、2022年に発生したハッキング関連の侵害の81%は、脆弱なパスワードまたは盗まれたパスワードが原因でした。具体的な事例として、2023年初頭にUberは、請負業者のアカウントが以前の侵害で発見されたパスワードを再利用したために侵害されたことを開示しました。攻撃者はそのアカウントを使用してUberの内部システムに侵入しました。これは本質的に認証の失敗（パスワードの再利用とMFAの欠如）です。別の例として、2024年に金融サービス企業で発生した侵害では、多要素認証（MFA）がなかったため、攻撃者が漏洩したパスワードを使用してアカウントにアクセスし、数百万人に影響を与えました（これはSnowflakeの顧客データ事件の文脈で言及されました。Snowflakeのプラットフォームが直接ハッキングされたわけではありませんが、ユーザー側の認証の弱さが侵害につながりました）。これらの事例は、アプリケーションのコードが堅牢であっても、脆弱な認証慣行（ユーザーまたは開発者による）が広範な扉を開く可能性があることを示しています。
影響: 認証の不備は、一般顧客から管理者まで、システム内のあらゆるユーザーのアカウントが完全に侵害されることにつながる可能性があります。攻撃者がユーザー認証情報（ブルートフォース、漏洩したパスワードを使用したクレデンシャルスタッフィング、または認証ロジックの欠陥の悪用など）を入手した場合、そのユーザーになりすましてすべてのデータにアクセスできます。特に深刻なのは、管理者アカウントや特権アカウントが侵害された場合です。攻撃者はすべてのデータを盗んだり、設定を変更したり、さらに内部ネットワークに侵入したりする可能性があります。小規模であっても、侵害されたユーザーアカウントは詐欺、プライバシー侵害、ユーザーからの信頼喪失につながる可能性があります。
予防策: 堅牢な認証防御は必須です。強力なパスワード要件を強制し、保存されたパスワードには、ハッシュ化（bcryptやArgon2のような強力なアルゴリズムを使用）とソルト化を組み合わせて使用してください。生のパスワードを保存してはなりません。機密性の高いアカウントやアクションには多要素認証を実装してください。MFAは多くのパスワードベースの攻撃を阻止できます。安全なセッション管理を使用してください。セッションIDをランダムで推測不可能なものにし、有効期限を設定し、ログアウト時にセッションを無効にします。URLにセッションIDを公開することは避けてください（SecureおよびHttpOnlyフラグ付きのCookieを使用します）。ブルートフォース保護（複数回のログイン失敗後のロックアウトまたはCAPTCHA）を実装し、クレデンシャルスタッフィングを監視します。
Aikidoのプラットフォームは、コードと設定における一般的な認証の脆弱性を検出することで支援できます。例えば、Aikidoのスキャナーは、脆弱なパスワードハッシュ方式を使用している場合（またはさらに悪いことに、パスワードを平文で保存している場合）に警告します。また、セッションクッキーがSecure/HttpOnlyとしてマークされていない場合や、ウェブフレームワークのセキュリティ設定（DjangoやExpressなど）がセッション管理のために誤設定されている場合も検出できます。さらに、AikidoのSecrets Detectionは、APIキーやサービスアカウントのパスワードをコードに誤ってハードコードした場合にアラートを出し、それらのシークレットが攻撃者のバックドアログインになるのを防ぎます。これらの問題を早期に検出することで、最初からより強力な認証スキームを適用できます。
4. アクセス制御の不備（認可の欠陥およびIDOR）
概要： OWASPによると、アクセス制御の不備は現在、最も重大なWebアプリケーションのリスクの第1位です。これは、強制力の欠如を指します。 認可 — つまり、認証されたユーザーが何を行うことを許可されているかに関するルールです。ユーザーが本人であると主張し、認証が成功したとしても、アプリケーションは許可されたデータと機能のみにアクセスを制限する必要があります。一般的なアクセス制御の失敗には、特定のアクションに対するユーザーのロール/権限の確認不足、クライアントサイドの強制（攻撃者が回避可能）への信頼、または所有権を確認せずに内部オブジェクトへの参照を公開することなどが含まれます。非常に一般的なバリアントは IDOR（安全でない直接オブジェクト参照）、アプリがユーザー提供のID（口座番号、ドキュメントIDなど）を使用してデータを取得する場合 なしで 現在のユーザーが指定されたオブジェクトにアクセスすることを許可されていることを確認します。例えば、もし GET /api/orders/12345 これにアクセスした任意のユーザーに対して注文番号12345を返す場合、攻撃者はIDを12346に変更するだけで、別のユーザーの注文を取得できます。これは典型的なIDOR（不適切なオブジェクト参照）シナリオです。その他の例としては、「隠された」管理者エンドポイントでのアクセスチェックの欠落や、通常のユーザーがパラメーターやJWTトークンを調整することで管理者になれる権限昇格バグなどがあります。
例: 不適切なアクセス制御の蔓延は驚くべきもので、ある調査ではテストされたアプリケーションの94%に何らかのアクセス制御の不備が見つかりました。実際のインシデントとしては、Kia MotorsのAPI脆弱性（2024年）が挙げられます。研究者らは、車のVINまたはナンバープレート番号のみを提供することで、認証トークンなしで特定のKia/HyundaiのAPIエンドポイントを呼び出し、車両コマンド（ドアのロック解除など）をリモートで実行できることを発見しました。この重大な欠陥は、APIにおけるアクセス制御の失敗、つまりシステムがリクエストが認証された所有者からのものであることを確認していなかったことに起因します。別の例は、以前に言及したMOVEitの情報漏洩です。これは主にSQLiの問題でしたが、脆弱なエンドポイントに認証が欠如していたため、攻撃者が直接悪用できたことが指摘されました。また、ウェブアプリでは、あるユーザーが別のユーザーのデータを閲覧または変更できるIDORのバグが定期的に見られます。例えば、2021年に人気のあるソーシャルメディアプラットフォームのAPIで発見された脆弱性により、攻撃者はユーザープロファイルIDを列挙して、制限されるべきプライベートなプロファイル情報を取得することができました。要するに、不適切なアクセス制御は、垂直特権昇格（ユーザーが管理者になる）または水平昇格（ユーザーAがユーザーBとして行動できる）につながることがよくあります。
影響: アクセス制御が破綻すると、データ漏洩からシステム全体の乗っ取りまで、様々な結果を招きます。攻撃者は他のユーザーの機密データを読み取ったり（機密性の侵害）、不正なデータを変更したりする可能性があります（完全性の侵害）。重大なケースでは、アクセス制御の破綻により、外部の第三者が管理者権限を取得する可能性があり、これはアプリケーションにとって致命的です。例えば、ECサイトでのIDORにより、他の顧客の注文や個人情報が閲覧されたり、管理者チェックの欠如により、一般ユーザーが /admin/deleteUser エンドポイントからデータを消去します。これらの欠陥は直接的に機密性の侵害につながり、発見されると攻撃者にとってエクスプロイトが非常に容易であることがよくあります（高度なペイロードは不要で、URLやパラメータを変更するだけです）。
防止: ここでのマントラは「デフォルトで拒否」機密性の高い操作やデータレコードにアクセスするすべてのリクエストは、サーバーサイドのアクセス制御チェックの対象となるべきです。ロールや権限の適用を一元化するフレームワークやミドルウェアを使用してください。例えば、ユーザーロールがある場合、すべての管理者機能がサーバー上でユーザーのロールを検証するようにしてください（UIで管理者ボタンを非表示にするなどのクライアントサイドのチェックのみに依存しないでください）。オブジェクトレベルのアクセス（IDによるリソースの表示や編集など）については、所有権チェックを実装してください。例えば、その orderId リクエストされたものが、リクエストを行った認証済みユーザーに属していることを確認します。自動テストは、不正アクセスが適切にブロックされていることを検証するのに役立ちます。
Aikidoは、いくつかの方法で不適切なアクセス制御の検出を支援します。まず、AikidoのAutonomous Pentesting (Aikido Attack)は、実行中のアプリケーションを動的にプローブしてこれらの欠陥を検出できます。例えば、通常のユーザーアカウントを持つ攻撃者が管理者APIや他のユーザーのデータにアクセスしようとする状況をシミュレートし、権限のバイパスが成功した場合は報告します。コード側では、Aikidoの静的分析により、認証チェックが欠落しているルートやコントローラー（特に、ルートにロールがアノテーションされるべきフレームワークの場合）を特定できます。コードベースがアクセスポリシーにInfrastructure-as-Codeや設定（例えば、APIゲートウェイルールやクラウドIAM）を使用している場合、Aikidoのスキャナーはそれらも評価できます。Aikidoを使用して認証ロジックを継続的にテストすることで、攻撃者よりも早く「しまった、そのエンドポイントでログインを強制するのを忘れた」といったミスを検出できます。常に覚えておいてください。真に公開されているリソースを除き、すべてが適切な認証を必要とします。Aikidoは、この原則を遵守していることを確認するのに役立ちます。
5. セキュリティの誤設定
概要： 完璧にコーディングされたアプリケーションでも、安全でない設定によって台無しになる可能性があります。セキュリティ設定ミスは、インフラストラクチャまたはアプリケーションスタックにおけるあらゆる安全でない設定やセットアップを網羅する広範なカテゴリです。これには、サーバーにデフォルトの認証情報（例：admin/admin）をアクティブなままにしておくこと、デフォルトの設定ファイルやシークレットを使用すること、機密性の高いエンドポイント（データベース管理パネルやクラウドダッシュボードなど）を公開アクセス可能にしておくこと、Webサーバーでディレクトリリスティングを無効にしないこと、設定ミスのあるHTTPヘッダー（例：セキュリティヘッダーの欠落）を持つこと、またはクラウドストレージの適切な権限設定を忘れることなどが含まれます。設定ミスは、開発/テスト設定が本番用に強化されていない場合や、デプロイ時の単純な人為的ミスから生じることがよくあります。クラウド環境では、典型的な設定ミスとして、プライベートデータを含むS3バケットやAzure Blobストレージを公開読み取り可能にしておくことが挙げられます。要するに、設定の不注意により、システムが「攻撃者の皆さん、ドアは開いていますよ！」と言っているような状態です。
例: 残念ながら、設定ミスは多くの実際の情報漏洩を引き起こします。2024年の顕著なケースとして、単純なサーバーの設定ミスにより、130万件の患者記録が2週間にわたって公開サーバーに露出した事例があります。エクスプロイトは不要で、見落としのためにデータが実質的に世界に公開されたのです。別の例として、Prudential Financialでのインシデント（2024年）では、アクセス制御システムの単一の設定ミスにより、攻撃者が250万件の顧客記録に静かにアクセスできました。そして、Capital Oneの情報漏洩（2019年）を忘れることはできません。これはSSRFを攻撃メカニズムとして含んでいましたが、根本原因はAWS環境におけるウェブアプリケーションファイアウォールの設定ミスであり、これにより攻撃者は内部リソースに到達できました。Capital Oneのケースでは、WAFの設定ミスが悪用されると、機密データを含むAWS S3ストレージバケットにアクセスできるようになり、1億件以上の顧客記録が盗まれました。これらの例は、しばしば「小さな」設定ミス（開いているポート、忘れられた認証情報、無効化されたセキュリティ制御など）が甚大な結果をもたらす可能性があることを強調しています。
影響: 影響は、何が誤設定されたかによって異なります。軽微なケースでは、誤設定により重要ではない情報が「のみ」漏洩する可能性があります（例えば、ソフトウェアのバージョンを明らかにする詳細なエラーページは攻撃者には有用ですが、それ自体が侵害ではありません）。深刻なケースでは、誤設定が直接的な完全な侵害につながる可能性があります。開かれた管理インターフェースは攻撃者のログインを許し（特にデフォルトの認証情報が変更されていない場合）、開かれたクラウドストレージバケットは何百万ものレコードを公開し、無効化されたセキュリティ設定は容易なエクスプロイトを許す可能性があります。誤設定は、クラウドサービスにおけるデータ侵害の主要な原因の一つです。また、攻撃者によって容易にスキャンされます。オープンなElasticsearch/Kibanaダッシュボード、公開されたデータベースポート、公開バケットなどを継続的に探す検索エンジンやボットが存在します。要するに、注意を怠ると、誤設定によって安全なアプリケーションが「ハッカーの遊び場」と化してしまう可能性があります。
対策: 勤勉さと自動化が鍵となります。常にデフォルトのパスワードとキーを変更してください（「admin/admin」などのデフォルト設定で実行されるものはあってはなりません）。サーバーとフレームワークの設定を強化してください。例えば、本番環境ではデバッグモードとサンプルアプリをオフにし、ディレクトリブラウジングが無効になっていることを確認し、推奨されるセキュリティヘッダー（Content Security Policy、X-Frame-Optionsなど）を適用してください。クラウドリソースには最小権限の原則を適用してください。サービスやバケットがパブリックアクセスを必要としない場合は、ロックダウンし（パブリックである必要がある場合は、意図されたもののみを公開するようにしてください）。Infrastructure-as-Codeや環境設定をセキュリティベンチマークに対して定期的にレビューしてください。
AikidoのIaCスキャンと設定監査は、ここで非常に役立ちます。Terraform、CloudFormation、Kubernetes YAMLなどを使用している場合、Aikidoはそれらをスキャンして、安全でない設定（オープンなセキュリティグループ、公開S3バケット、暗号化設定の欠如など）を検出できます。また、実行中のクラウド環境の誤設定もチェックできます。ウェブサーバーやアプリケーションの場合、Aikidoのスキャナーは、セキュリティヘッダーの欠如や過度に詳細なエラーメッセージにフラグを立てます。さらに、Aikidoのランタイム保護機能は、誤設定をエクスプロイトしている可能性のある異常な使用状況を監視できます。重要なのは、設定チェックをパイプラインの一部にすることです。Aikidoはそれを自動化し、「うっかりバケットを公開してしまった」というミスをデプロイ前に検出できます。そして、常に新しいパッチとアップデートに注意してください。誤設定は、既知のデフォルトの脆弱性を持つ古いソフトウェアを実行していることに起因する場合もあります。
6. 機密データの露呈とシークレットの漏洩
概要： このカテゴリは、ユーザーデータとシークレットキーの両方を含む機密情報の適切な保護の失敗を扱います。「機密データ漏洩」（暗号化の失敗とも呼ばれる）とは、アプリケーションが転送中または保存中のデータを適切に保護していないことを意味します。例としては、機密通信にHTTPSを使用しないこと、保存データに弱い暗号化または暗号化を使用しないこと（パスワードのソルトなしハッシュや、データベースバックアップ内の平文の個人データなど）、またはデバッグやログを通じて誤ってデータを公開することなどが挙げられます。密接に関連しているのがシークレットの漏洩です。これは、開発者が注意を怠ると意図せずシークレットを公開してしまうことです。
予防策: 注意深さと自動化が鍵です。常にデフォルトのパスワードとキーを変更してください（「admin/admin」などのデフォルト設定で実行されるものがあってはなりません）。サーバーとフレームワークの構成を強化してください。例えば、本番環境ではデバッグモードとサンプルアプリをオフにし、ディレクトリブラウジングが無効になっていることを確認し、推奨されるセキュリティヘッダー（Content Security Policy、X-Frame-Optionsなど）を適用します。クラウドリソースには最小特権の原則を使用してください。サービスやバケットがパブリックアクセスを必要としない場合は、ロックダウンします（パブリックである必要があるものについては、意図されたもののみを公開するようにします）。インフラストラクチャ・アズ・コードまたは環境設定をセキュリティベンチマークに対して定期的にレビューしてください。
AikidoのIaCスキャンと設定監査は、ここで非常に役立ちます。Terraform、CloudFormation、Kubernetes YAMLなどを使用している場合、Aikidoはそれらをスキャンして、安全でない設定（オープンなセキュリティグループ、公開S3バケット、暗号化設定の欠如など）を検出できます。また、実行中のクラウド環境の誤設定もチェックできます。ウェブサーバーやアプリケーションの場合、Aikidoのスキャナーは、セキュリティヘッダーの欠如や過度に詳細なエラーメッセージにフラグを立てます。さらに、Aikidoのランタイム保護機能は、誤設定をエクスプロイトしている可能性のある異常な使用状況を監視できます。重要なのは、設定チェックをパイプラインの一部にすることです。Aikidoはそれを自動化し、「うっかりバケットを公開してしまった」というミスをデプロイ前に検出できます。そして、常に新しいパッチとアップデートに注意してください。誤設定は、既知のデフォルトの脆弱性を持つ古いソフトウェアを実行していることに起因する場合もあります。
6. 機密データの露呈とシークレットの漏洩
概要： このカテゴリは、ユーザーデータとシークレットキーの両方を含む機密情報の適切な保護の失敗を扱います。「機密データ漏洩」（暗号化の失敗とも呼ばれる）とは、アプリケーションが転送中または保存中のデータを適切に保護していないことを意味します。例としては、機密通信にHTTPSを使用しないこと、保存データに弱い暗号化または暗号化を使用しないこと（パスワードのソルトなしハッシュや、データベースバックアップ内の平文の個人データなど）、またはデバッグやログを通じて誤ってデータを公開することなどが挙げられます。密接に関連しているのがシークレットの漏洩です。これは、開発者がAPIキー、データベースパスワード、認証情報、トークンなどのシークレットを、コードにハードコーディングしたり、リポジトリにプッシュされた設定ファイルに残したり、クライアントサイドコードに保存したりすることで、意図せず公開してしまうことです。毎年、驚くべき量のシークレットが開発者によって漏洩しています（多くの場合、公開GitHub上で）。要するに、アプリケーションが暗号化すべきものを適切に暗号化しない場合、または機密情報やキーの扱いに不注意である場合、攻撃者がほとんど労力なくそのデータを取得するよう招いていることになります。
例: この問題の一側面は、暗号化されていないデータです。シンプルですが分かりやすい例として、何年も前には、ウェブサイトが平文のHTTP経由でログイン認証情報を受け入れることがありました。そのような時代はほとんど終わりましたが、現在でも設定ミスは発生します。2023年には、主要なAPI連携において、適切な暗号化なしで個人健康データが送信されていることが判明しました（TLS証明書チェーンの設定ミスが原因）。これにより、通信経路で個人情報が露呈しました。別の例として、データベースのバックアップファイルが安全でないクラウドバケットに保存されている場合（設定ミスに関連）、その中のすべての個人データが露呈する可能性があります。これは2022年に航空会社で発生し、バックアップが暗号化されておらず、アクセス制御もされていなかったため、数十万件の顧客記録が漏洩しました。
シークレットの側面では、この問題は固有のものです。2024年だけでも、研究者は公開GitHubコミットで約2380万件の新しいハードコードされたシークレットを検出しました。これは前年比25%の増加です。この「シークレットの拡散」は、実際の侵害につながっています。例えば、2023年には、攻撃者が漏洩した認証情報を悪用して、New York Timesのすべてのソースコードをプライベートリポジトリから漏洩させたと報じられました。別のケースでは、ビジネスインテリジェンス企業（Sisense）の内部認証情報が公開フォーラムに漏洩し、攻撃者がそれを使用して機密性の高い顧客データにアクセスしました。開発者にとって身近な話として、AWSのシークレットキーが誤ってGitHubにプッシュされ、数分以内にクリプトマイナーなどに悪用されたという話をどれほど頻繁に耳にするでしょうか？これらの例は、暗号化によるデータ保護の失敗とシークレットを秘密に保つことの失敗が、データ侵害や不正アクセスに直結することを示しています。
影響：機密性の高いユーザーデータ（個人情報、財務データ、健康記録など）が漏洩した場合、その影響は通常、ユーザー（プライバシー侵害、身元盗難リスク）と企業（規制当局による罰則、評判の毀損）の双方に及びます。 例えば、医療記録が漏洩するとHIPAA罰金や訴訟につながる可能性があります。パスワードやクレジットカード番号の漏洩は明らかに詐欺を招きます。一方、API シークレット 漏洩するとシークレット 攻撃者にとって黄金のチケットとなる可能性があります。例えば、データベースパスワードが漏洩すると攻撃者が接続してデータベース全体をダンプできる可能性があります。API 漏洩すると、攻撃者が（あなたの請求書で）サーバーを起動したり、機密のクラウドデータにアクセスしたりできる可能性があります。 たった1つの管理者認証情報が漏洩するだけで、アプリケーション全体、あるいはシステム群全体が危険に晒されることもあります。IBMのデータ侵害コストレポートが、認証情報の侵害や機密データ漏洩を伴う侵害事例が（金銭的損失と信頼喪失の両面で）最もコストが高いと一貫して指摘しているのも当然でしょう。
対策： ここには2つの側面があります。機密データを保護することと、シークレットを適切に管理することです。機密性の高いユーザー/ビジネスデータについては、常にHTTPSを使用します（すべてのトラフィックにTLSを強制し、最新のプロトコル/設定を使用します）。パスワードやトークンなどの機密情報を、内部通信であっても平文で送信しないでください。保存時には、重要なデータフィールドを暗号化します（多くのデータベースやクラウドストレージサービスは保存時の暗号化を提供しています。これを利用し、極めて機密性の高いフィールドにはアプリケーションレベルの暗号化も検討してください）。過剰なデータ露出を避けます。不要なデータを不必要に保存せず、不要になった機密データは削除してください。シークレット管理に関しては、コードやソース管理にコミットされる設定ファイルにシークレットをハードコードしないでください。環境変数、シークレット管理サービス（HashiCorp Vaultやクラウドのシークレットストアなど）を使用するか、少なくともリポジトリに含まれないセキュアな設定ファイルにシークレットを保存してください。 どうしても設定をコミットする必要がある場合は、プッシュする前にツールを使用してシークレットをスキャンしてください。定期的にキーをローテーションすることで、万が一漏洩した場合でも、有効期間を短くすることができます。
Aikidoのセキュリティプラットフォームは、両面で役立つ強力な機能を備えています。そのSecrets Detection機能は、APIキー、パスワード、プライベート証明書、その他の認証情報についてコードと設定をスキャンします。例えば、誰かが誤ってコミットされたファイルにAWSキーやデータベース接続文字列を残した場合、Aikidoはそれを即座にフラグ付けし、AWSアカウントの乗っ取りから保護する可能性があります。Aikidoは、リポジトリを継続的に監視し、リアルタイムでシークレットの漏洩を検出することも可能です。データ保護の側面では、Aikidoのスキャンは、脆弱な暗号化の使用（例：古いハッシュ関数や暗号化アルゴリズムの使用）を特定できます。また、インフラストラクチャ・アズ・コードやAPI定義をスキャンすることで、特定のコンプライアンスチェック（例：すべてのエンドポイントでTLSが有効になっていることの確認）を検証することもできます。Aikidoを統合することで、「これはAPIキーです。削除してください！」と本番環境に到達する前に警告する自動監視システムを手に入れることができます。そして、組織に多数のプライベートリポジトリや開発チームがある場合、毎年コード内で発見されるシークレットの数が増え続けていることからもわかるように、この種の自動シークレットスキャンは不可欠です。
7. 既知の脆弱性を持つコンポーネントの使用（サプライチェーンリスク）
概要： 現代のWebアプリケーションは、フレームワーク、ライブラリ、パッケージ、コンテナイメージ、サービスなど、数え切れないほどのサードパーティコンポーネントの上に構築されています。既知の脆弱性を持つコンポーネントの使用とは、アプリケーションが公開されているセキュリティ上の欠陥を持つ依存関係（またはサーバー上で実行されるもの）を含んでおり、それをパッチ適用または更新していない状態を指します。これは本質的に「サプライチェーン」の問題であり、使用しているライブラリの脆弱性が、自身のコードが完璧であってもアプリケーションを危険にさらす可能性があります。例は数多くあります。脆弱なバージョンのWebフレームワーク、古いOpenSSLライブラリ、情報漏洩するデバッグツールなどです。攻撃者は、特定の脆弱なバージョンのソフトウェアを使用しているアプリケーションを積極的にスキャンし、それらをエクスプロイトします。OWASP Top 10はこのリスクを強調しており（以前は「既知の脆弱性を持つコンポーネントの使用」としていましたが、2021年にはより広範なカテゴリに統合されました）、業界はLog4Shellのような、単一のライブラリの欠陥が世界中に波及効果をもたらした事件から厳しい教訓を学びました。
例: 典型的な例は、まさにLog4Shell (CVE-2021-44228)です。これは、広くJavaアプリケーションで使用されている人気のLog4jロギングライブラリにおける重大なRCE脆弱性でした。2021年12月に公開された際、特定のバージョンのLog4jが含まれている場合、数千ものアプリケーションが間接的に脆弱であったため、世界中で警鐘が鳴り響きました。攻撃者はすぐにこれを実際に悪用し始め、多くの企業でインシデントが発生しました。あるレポートが述べたように、「Log4jの脆弱性は、単一の広く使用されているコンポーネントが組織全体にリスクを露出させる方法を示した」のです。別の例として、Apache Struts 2には既知のRCEの欠陥（CVE-2017-5638）があり、これは2017年のEquifaxの情報漏洩につながったことで有名です。Equifaxがフレームワークを更新していなかったため、攻撃者はこれを悪用して1億4700万人分のデータを盗みました。さらに最近では、2022年から2023年にかけて、Log4Shellに似た（ただし深刻度は低い）Spring Frameworkの脆弱性であるSpring4Shell (CVE-2022-22965)や、それらのパッケージを使用している場合に攻撃者がコードを実行したりデータを盗んだりできる様々なnpm/PyPIパッケージの脆弱性が確認されました。フロントエンドライブラリも例外ではありません。例えば、2021年のDOMPurifyライブラリの脆弱性は、更新されていない場合、XSS保護を損なう可能性がありました。これらすべては、スタック内の既知のCVEが時限爆弾であることを示しています。
影響：影響脆弱性 完全に依存しますが、リモートコード実行、データ漏洩、認証バイパスなど、深刻な事態を引き起こす可能性があります。 問題は、こうした脆弱性が公知であり、エクスプロイト 容易に入手できる点です。攻撃者は自動スキャンでパッチ未適用のサーバーを特定できます。ワーム拡散可能な未修正コンポーネント1つが、大規模な侵害を引き起こす可能性があります（2021年のMS Exchange ProxyShell/ProxyLogon脆弱性のように——厳密には「Webアプリ」ではありませんが、既知の脆弱性が大量に悪用される概念は類似しています）。 脆弱なコンポーネントを使用している場合、攻撃者はあなたのコード内のバグを探す必要がなく、単にエクスプロイト 済みます。結果としてデータ漏洩やサーバー乗っ取りなど、他のカテゴリと同様の被害が生じる可能性がありますが、修正プログラムが存在していたにもかかわらず適用されなかったという点が特に苛立たしい点です。
防止: これはに帰結します。 依存関係の管理とパッチ適用規律。アプリケーションで使用されているすべてのコンポーネント（バージョンを含む）のインベントリを維持します。これはしばしばソフトウェア部品表（SBOM）と呼ばれます。脆弱性フィードを購読するか、自動ツールを使用して、使用しているライブラリに既知のCVEがある場合に通知を受け取ります。多くのパッケージマネージャーには監査コマンドがあります（例： npm audit, pip-audit)で、依存関係ツリー内の既知の脆弱性を特定します。依存関係を最新の状態に保ち、パッチが適用されたバージョンに速やかにアップグレードしてください。すぐにアップグレードできない場合は、可能な限りツールを使用して仮想パッチや回避策を適用してください。OS、Webサーバー、データベースサーバーなどのコンポーネントには、定期的にセキュリティアップデートを適用してください。また、～にも注意してください 悪意のあるパッケージ オープンソースエコシステムでは、攻撃者が侵害されたライブラリを公開したり（またはメンテナーアカウントを乗っ取ったり）することが時折あり、次回あなたが npm install、バックドアが仕込まれたアップデートを取り込んでいる可能性があります。信頼できるソースを使用し、依存関係のバージョンを固定すること（およびチェックサム/署名による整合性の検証）は、これを軽減するのに役立ちます。
Aikidoは、ソフトウェアコンポジション分析（SCA）と依存関係スキャン機能を通じて、このリスク管理をはるかに容易にします。 Aikidoの依存関係（SCA）スキャナーは、コードが使用しているオープンソースライブラリとバージョンを自動的に検出し、脆弱性データベースと照合し、既知のCVEについて警告します。例えば、プロジェクトがLog4j 2.14.0（Log4Shellに対して脆弱性がある）を使用している場合、AikidoはCVEの詳細とともにそれを検出し、アップグレードすべき修正バージョンを提案します。これは、IDEまたはCIパイプラインで直接実行できます。さらに、AikidoはAI AutoFixの提案を提供します。多くの場合、依存関係をより安全なバージョンに更新したり、必要なパッチを適用したりするためのプルリクエストを自動的に開くことができます。このプラットフォームは、古くなったコンポーネントがないかコンテナイメージをスキャンすることもできます（ベースイメージとOSパッケージが最新であることを保証します）。Aikidoを統合することで、CVEの追跡という面倒な作業を、決して休むことのない自動化されたシステムに実質的にアウトソースできます。これは、脆弱性が発表されてから数日または数時間後にエクスプロイトが広まることが多い状況において、迅速な修復が重要であることを意味します。要約すると、すべてを最新の状態に保ち、Aikido SCAのようなツールを使用して、コンポーネント面で攻撃者の一歩先を行きましょう。
8. クロスサイトリクエストフォージェリ (CSRF)
概要： Cross-Site Request Forgery（クロスサイトリクエストフォージェリ）は、悪意のあるウェブサイトがユーザーのブラウザを騙して、意図しないリクエストをウェブアプリケーションに送信させる攻撃です。ブラウザがリクエストに認証情報（セッションCookieなど）を自動的に含めるという事実を悪用します。ユーザーがサイトにログインしている状態で悪意のあるサイトを訪れると、その悪意のあるサイトは、例えば画像や隠しフォームを読み込み、ターゲットとなるサイトにリクエストを送信させることができます。この際、ブラウザはユーザーのセッションCookieを含めます。適切な防御がなければ、サーバーはユーザーが正当にそのリクエストを行ったと判断し、実行してしまいます。要するに、CSRFはユーザーの認証済みセッションを「乗っ取り」、ユーザーが意図しないアクションを実行させます。典型的な例として、ユーザーが銀行にログインしているとします。攻撃者のページを訪れると、そのページには銀行サイトへの資金移動リクエストを発行する隠しコードが含まれており、銀行は有効なセッションCookieを認識して送金を処理します。CSRFはデータを直接盗むのではなく、被害者のブラウザを騙して攻撃者の共犯者にします。多くのモダンなフレームワークにはCSRF保護機能が組み込まれており（通常はトークンを介して）、モダンなブラウザはCSRFを軽減するためにSameSite Cookie属性を追加しましたが、完全に根絶されたわけではありません。2025年において、CSRFは「死んでいないが、形を変えている」と言えます。特に、シングルページアプリケーションや、開発者が通常の保護を実装し忘れる可能性のあるCookieを認証に使用するAPIにおいて顕著です。
例: 実際の事例として、Reddit（2023年）の設定ページにはCSRF脆弱性があり、攻撃者がユーザーの環境設定を密かに変更したり、被害者のアカウントをスパムアカウントにリンクさせたりすることができました。通知設定の切り替えは送金ほど深刻ではありませんが、主要サイトの機能においてCSRFが依然として存在することを示しています。もう1つの注目すべき例は仮想通貨ウォレットアプリに関するもので、攻撃者はCSRFを利用してウォレットのウェブインターフェースを悪用し、デフォルトの支払いアドレスを変更したり、少額の取引を開始したりして、ユーザーが気づかないうちに資金を流出させました。歴史的には、さらに壊滅的なCSRF攻撃も存在します。2007年にはGmailにCSRFがあり、攻撃者がユーザーのメール転送アドレスを変更（メールを盗聴）することができました。また、2005年にはMySpaceで有名なSamy Wormが発生しました。これは実際には自己増殖型のCSRF（XSSと組み合わされたもの）で、Samy Kamkarのプロフィールに100万人の「友達」を増やしました。これらの例は、いたずらから重大な侵害まで多岐にわたりますが、すべてが次の考えを強調しています。CSRF保護がない場合、攻撃者はユーザーに意図しない行動を実行させることができます。
影響: CSRFの深刻度は、どの操作が脆弱であるかによって異なります。（Redditの例のように）軽微な設定変更しかできない場合、影響は限定的です（煩わしいですが壊滅的ではありません）。しかし、送金、パスワード変更、アカウント削除などの重要な操作が脆弱である場合、CSRFは大きな問題となります。ログイン中のユーザーのパスワードを攻撃者が知っているものに変更するCSRFを考えてみてください。これは完全なアカウント乗っ取りです。あるいは、ウェブベースのバンキングアプリで支払いを発行するCSRFは、直接的な金銭的窃盗です。企業環境では、アクセス制御設定の変更や悪意のあるデータの注入など、何らかの状態変更を引き起こすCSRFは、より深い侵害への足がかりとなる可能性があります。ユーザーのマシンにマルウェアがなく、即座に目に見える兆候がないというCSRFの静かな性質は、手遅れになるまでこのような攻撃が検出されない可能性があることを意味します。
予防策: 良いニュースは、CSRFが十分に理解されており、標準的な防御策が存在することです。
- CSRFトークン: 状態を変更するリクエストには、アンチCSRFトークンを実装します。サーバーはランダムなトークンを生成し、ユーザーのセッション（またはクッキーとして）に設定し、フォームやAPI（隠しフィールドまたはヘッダーとして）にも挿入します。リクエストが到着すると、サーバーはそのトークンを期待し、検証します。攻撃者による偽造されたリクエストは正しいトークンを持たないため、拒否されます。
- SameSite Cookie属性： セッションクッキーを以下で設定します
SameSite=Laxまたは厳格。これにより、ブラウザがクロスサイトリクエストでCookieを含めるのを防ぐことができます（ただし緩慢な一部のGETリクエストを依然として許可しています（理想的には副作用があってはなりません）。多くのフレームワークでは現在、セッションクッキーがデフォルトでSameSite=Lax。ただし、アプリが正当にクロスサイトリクエスト（例：サードパーティ統合）を必要とする場合は注意が必要です。その場合、例外が必要になるかもしれませんが、それらを分離してください。 - 状態を変更するアクションは適切なHTTP動詞を使用する（例：アクションにはGETではなくPOST/PUT/DELETEを使用する）ようにしてください。SameSiteがLaxまたはStrictの場合、ブラウザはクロスサイトPOSTで認証情報を送信せず、攻撃者がGETよりも隠れたPOSTを行うのはより困難です。
- Origin/Refererヘッダーの確認: 追加のレイヤーとして、リクエストが期待するドメインから発信されていることを検証することで、場合によってはクロスサイト攻撃を捕捉できます（ただし、完璧ではありません）。
- フレームワークセキュリティ: フレームワークに組み込まれているCSRF保護ミドルウェアを使用してください。ほとんどすべての最新フレームワークに搭載されています。
- 開発中に無効にしない (開発者はAPIテストのためにCSRFチェックを無効にし、その後再有効化を忘れることがあります)。
Aikidoは、アプリケーションが意図せずCSRFに対して脆弱にならないように支援します。 1つには、 Aikidoの動的スキャン（DAST） 外部コンテキストから状態変更アクションを実行しようとすることでCSRFをシミュレートし、成功するかどうかを確認できます。適切なCSRF保護が欠如しているアクションは報告されます。コード側では、Aikidoの静的解析（フレームワークの理解を伴う）は、データを変更するもののCSRFトークン検証が実施されていないルートを特定できます。（実際、Ghost Securityのような類似のAppSecツールは、「状態を変更するがCSRFトークンが欠如しているエンドポイント」の発見を特に宣伝しており、Aikidoも同等の機能を提供します。）Aikidoは、設定ミスも検出できます。 SameSite 応答のSet-Cookieヘッダーやセキュリティ設定を検査することで属性を特定します。Aikidoを使用してフォームやAPIエンドポイントをテストすることで、重要なパスにCSRF防御が欠けている場合にアラートを受け取ることができ、修正できます（通常は適切なトークンまたはヘッダーチェックを追加することで）。これらの対策により、CSRFを効果的に阻止し、アプリケーションが のみ 実際にサイトとユーザーから発せられたリクエストを尊重します。
9. サーバーサイドリクエストフォージェリ (SSRF)
概要： SSRFは、OWASP Top 10に新しく追加された項目であり（2021年版でトップ10入り）、それには正当な理由があります。 サーバーサイドリクエストフォージェリ アプリケーションが信頼できないソース（ユーザー入力など）からURLまたはリソースの場所を取得し、サーバーサイドのコードが 取得 適切な検証なしにそのURLを。基本的に、攻撃者はサーバーを騙して、そのサーバーに代わってリクエストを送信させます。これは、攻撃者が直接アクセスできない内部リソースや、サーバーの認証情報を持つ外部アドレスへのリクエストをサーバーに行わせるために悪用される可能性があります。典型的なシナリオとしては、「このURLのコンテンツを取得する」（プレビューやデータインポートのため）といった機能を備えたWebアプリケーションで、攻撃者が次のようなURLを提供するケースが挙げられます。 http://localhost/admin またはAWSメタデータURL (http://169.254.169.254）を介して、機密性の高い内部情報を取得します。SSRFは、サーバーを介した内部ネットワークのポートスキャン、あるいは内部サービスのエクスプロイトも可能にします。クラウド環境では、クラウドインスタンスが資格情報を生成するメタデータエンドポイントにアクセスできることが多いため、SSRFは特に危険です。2019年のCapital Oneの侵害は、実環境でSSRFが使用された（設定ミスと組み合わされた）典型的な例でした。
例: Capital Oneの情報漏洩: 元AWSエンジニアが、Capital Oneが運用していた設定ミスのあるWAF（Web Application Firewall）のSSRF脆弱性を悪用しました。外部からアクセス可能なウェブアプリからリクエストを作成することで、サーバーのAWSメタデータサービスにクエリを実行し、AWSアクセストークンを取得しました。そのトークンを使用して、機密データ（顧客情報を含むS3バケット）にアクセスし、1億件以上の記録が盗まれました。要するに、SSRFはサーバー自身の権限を悪用して外部ネットワークの障壁を迂回する最初の侵入経路でした。別の例として、2022年には、セキュリティ研究者が人気のあるDevOpsツールにSSRFを発見し、通常は公開されていない内部APIエンドポイントに到達できることを確認しました。これにより、管理者権限のアクションが可能になる可能性がありました。また、画像処理やPDF生成機能（サーバーが入力からURLをフェッチする）におけるSSRFのバグも確認されており、攻撃者はこれをポートスキャナーに変えたり、内部データベースの管理コンソールにアクセスするために使用したりしました。さらに別のケースでは、一部のクラウドサービスのウェブフックにSSRFがあり、攻撃者が内部HTTPエンドポイントへのリクエストをトリガーして、Redisや内部ダッシュボードなどにアクセスできるようになりました。
影響: 一見すると、SSRFはリクエストを行うことに関するものであり、限定的であるように聞こえるかもしれません。しかし、重大な影響をもたらす可能性があります。
- 内部ネットワークアクセス: サーバーが内部ホスト（例：同じVPCまたはデータセンター内）に到達できる場合、SSRFは公開されていない内部サービスと通信する可能性があります。これにより、機密データの読み取り（顧客情報を返す内部HTTP APIへのアクセスなど）につながる可能性や、内部管理インターフェースに認証が不足している場合（内部からの呼び出しのみが到達すると想定されているため）、特権コマンドの発行につながる可能性もあります。
- クラウドメタデータの漏洩: クラウドプロバイダー（AWS、GCP、Azure）では、SSRFはインスタンスメタデータサービスから認証情報を取得するためによく使用されます。これらの認証情報により、クラウド資産のさらなる侵害が可能になる可能性があります（Capital Oneの事例のように）。
- IPベースの制限のバイパス: ある機能を「localhost」からのリクエストや特定のIPに制限している場合、SSRFはローカルサーバー自体からリクエストを行うことでそれを回避する可能性があります。
- ワームの可能性：場合によっては、SSRFはさらなるエクスプロイトの起点となる可能性があります。例えば、既知のRCEを持つ内部サービスへのSSRFは、内部ネットワーク上での実際の遠隔コード実行につながる可能性があります。
OWASPの指摘にあるように、マイクロサービスとクラウドの複雑さにより、現代のアプリケーションではSSRFの問題が実際に増加しており、非常に深刻なものとなる可能性があります。
防止: SSRFの防止は主に以下のことを意味します ユーザーが提供するURLやリモートリソースリクエストの検証およびサニタイズ。アプリがユーザーから提供されたURL（またはアドレス）をフェッチする必要がある場合、厳格な許可リストを実装してください。例えば、信頼できるドメインからのURLのみを許可し（トリックを防ぐためにDNSルックアップなどで強制）、生のユーザー入力をサーバーサイドフェッチの宛先を直接制御させることは絶対に避けてください。また、ネットワークレベルの保護を実装することも可能です。例えば、サーバーが内部アドレスにアクセスする必要がない場合は、その機能を無効にします。一部のクラウドプロバイダーでは、メタデータサービスへのアクセスをオフにしたり制限したりできます（AWSには単純なGETリクエストを軽減するIMDSv2があります）。さらに、コードはURLスキームをチェックし、許可しないようにすべきです。 file:// URIまたはその他のローカルスキーム、そしてIPリテラルやリンクローカルアドレスを禁止する可能性があります。利用可能な場合は、SSRF保護を実行するライブラリまたはパッチを使用します（例えば、一部のHTTPクライアントライブラリは、接続可能なホストを制限できます）。基本的に、外部から提供されるURLは危険な入力として扱います。なぜなら、それらは危険だからです。
Aikidoのスキャンツールは、コード内のSSRFリスクを特定するのに役立ちます。 例えば、Aikidoの静的解析は、HTTPリクエストを行う関数やライブラリの使用を検出できます（例： requests.get() Pythonでは、 HttpClient Javaなど）で、URLがユーザー入力から派生している場合です。フィルタリングがない場合、それを潜在的なSSRFとしてフラグ付けできます。Aikidoは、コードが検証なしにURLからデータを取得しようとしている場合にもそれを検知し、許可リストチェックの追加を提案できます。動的な側面では、 AikidoのDASTおよびペンテストツール 一般的なSSRFペイロード（例えば、～を提供するなど）を試行できます。 http://169.254.169.254 （URLフェッチ機能への入力として）サーバーを騙して内部コンテンツで応答させることができるかどうかを確認するためです。SSRFベクターが発見された場合、Aikidoは証拠とともにそれを報告します。このフィードバックを受けて、適切な検証を実装したり、ネットワークアクセスを制限したりすることができます。Aikidoのクラウドスキャン機能は、インスタンスが過度に緩いネットワーク設定になっている場合（例えば、ウェブサーバーが本来アクセスすべきでないインターネットや内部ネットワークにエグレスできる場合など）にも警告を発することができます。コード分析とテストを組み合わせることで、攻撃者がアプリをプロキシとして使用する前に、SSRFの脆弱性を早期に発見できます。
10. 安全でないデシリアライゼーション
概要： 安全でないデシリアライゼーションは、より専門的な脆弱性ですが、存在すると非常に危険です。これは、アプリケーションが信頼できないソースからデータをデシリアライズする際に発生します。 適切な検証なしに — これは、クライアントからバイナリデータや構造化データ（オブジェクト、JSON/XML、バイナリブロブなど）を受け取り、メモリ内でオブジェクトを再構築することを意味します。特定のシリアライゼーション形式（特にJava、.NET、Python、PHPなどの言語）は、デシリアライゼーションプロセス中にコードを実行するために悪用される可能性があります。攻撃者は悪意のあるシリアライズされたオブジェクト（しばしば「ガジェットチェーン」と呼ばれる）を作成し、サーバーがそれをデシリアライズすると、攻撃者が選択したコマンドや動作がトリガーされます。これにより、通常のインジェクションの欠陥を必要とせずに、サーバー上でのリモートコード実行やロジック操作につながる可能性があります。安全でないデシリアライゼーションの脆弱性は、本質的にデータに隠されたロジック爆弾です。これらはOWASP Top 10 2017で強調され、2021年のTop 10では「ソフトウェアとデータの整合性の失敗」に拡大されましたが、依然として関連性があります。アプリケーションが何らかのシリアライズされたオブジェクト（Javaなど）を受け入れる場合 シリアライズ可能 オブジェクト、.NET ViewState、あるいはクラス型情報を含む特定のJSON）をユーザーから受け取る場合、リスクにさらされる可能性があります。
例： 最近話題になっている例は React Server ComponentsにおけるCVE-2025-55182 （2025年12月開示）。これは、React Server Componentsプロトコルにおける不安全なデシリアライゼーションによって引き起こされた重大なRCEでした。基本的に、攻撃者は不正なHTTPペイロードを送信し、Reactサーバー側がそれを誤ってデシリアライズすることで、任意のコード実行が可能になります。CVSSスコアは10であり、非常に多くのアプリケーション（Reactが広く普及しているため）に影響を与えました。これは、最先端のフレームワークでさえデシリアライゼーションの問題から免れないことを示しています。もう一つの典型的な例は、 2016年 Java Commons Collections エクスプロイト – 多くのJavaアプリケーションにおける安全でないデシリアライゼーション（ライブラリを介して）により、攻撃者はシリアライズされたオブジェクトを送信し、それがデシリアライズされるとサーバー上でコマンドを実行することが可能になりました。これはJenkins、WebLogicなどの製品で広くエクスプロイトされました。.NETでは、ViewStateデシリアライゼーションの脆弱性（CVE-2017-8759）や、ビューの状態における未サニタイズデータがRCEにつながる他の問題がありました。PHPアプリケーションでは、 unserialize() はユーザー入力時に呼び出されます。JavaScript (Node.js) でさえ、～に悪名高いものがありました。 serialize-javascript パッケージ。そのため、エンタープライズシステムから最新のフレームワークに至るまで、安全でないデシリアライゼーションは頻繁に発生し、多くの場合、深刻な結果を招きます。
影響:不安全なシリアライゼーションは、多くの場合リモートコード実行（RCE）への直接的な経路となります。これは最悪の事態とも言える深刻さです。攻撃者はサーバー上で任意のコードを実行でき、サーバーを完全に制御する可能性さえあります。 完全なRCEに至らなくても、デシリアライゼーションの欠陥はロジック操作（例：オブジェクトデータに対する権限を昇格させるためのデータ構造改ざん）に悪用される可能性があります。しかし通常、その影響は重大です：攻撃者がエクスプロイト できれば、ウェブシェルをドロップしたり、バックドアユーザーを作成したり、ネットワークの深部へ侵入したりすることが可能になります。 この危険性は、デシリアライゼーション攻撃が認証を必要としない場合が多い（認証前にデータをデシリアライズするアプリの場合）点と、単一リクエストで実行可能な点によって増幅されます。これはステルス性の高い侵入手段です——不審なSQLクエリやクロスサイトスクリプトではなく、一見無害なデータ塊が内部からアプリを破壊するのです。
予防策: 安全でないデシリアライゼーションを回避する最善の方法は、信頼できないデータをデシリアライズしないことです。ユーザーからシリアライズされたオブジェクトを絶対に受け入れる必要がない場合は、そうしないでください。より安全なデータ形式（例えば、任意のコンストラクタを呼び出す可能性のあるクラス型メタデータを含まないJSON）を使用してください。シリアライズ/デシリアライズする必要がある場合は、整合性チェックの実装を検討してください。例えば、シリアライズされたデータに署名するか、MACを含めることで、改ざんを検出できるようにします。一部のフレームワークでは、デシリアライズできるクラスを制限できます（クラスの許可リスト化）。これにより、任意のガジェットチェーンが機能するのを防ぐことができます。多くのデシリアライゼーションの欠陥は、オブジェクト構築中に実行されるコードを厳格化することで修正されるため、ライブラリを最新の状態に保ってください。OWASPはまた、デシリアライゼーションプロセスを分離することを推奨しています。おそらく低特権またはサンドボックス環境で実行することで、エクスプロイトがトリガーされた場合でも影響を最小限に抑えることができます。一般的に、シリアライズされたデータは潜在的に敵対的なものとして扱ってください。また、サービス間通信やキャッシュなどにおける隠れたシリアライゼーションにも注意してください。
Aikidoの脆弱性インテリジェンスとスキャンは、これらの問題を捕捉するのに役立ちます。 静的解析の側面では、Aikidoは危険な関数やパターンの使用を指摘できます。例えば、～の使用などです。 ObjectInputStream.readObject() Java、またはPHPの unserialize() ユーザーデータ、または悪用可能であることが知られている安全でないデシリアライゼーションライブラリに対して。「ここで何かをデシリアライズしていますが、それは安全ですか？」と警告します。Aikidoの依存関係スキャンも機能します。デシリアライゼーションの脆弱性があることが知られているライブラリバージョン（例えば、一般的なシリアライゼーションライブラリの古いバージョン）を使用している場合に警告できます。CVE-2025-55182（React関連のもの）のような主要なCVEが発生した場合、Aikidoの脅威インテリジェンスフィード（Aikido Intelなど）は、影響を受ける可能性のあるプロジェクトを特定し、パッチが必要であることを強調します。テストの観点からは、これは動的スキャナーにとってより困難な問題ですが、アプリケーションがデシリアライゼーションのバグで知られている一般的なフレームワークを使用している場合、Aikido Attackは既知のエクスプロイトペイロードを試行する可能性があります。最終的に、緩和策にはコード変更やライブラリの更新が必要となることが多く、Aikidoの役割はリスクを迅速に認識させることです。開発中またはスキャン中に安全でないデシリアライゼーションを検出することで、安全なデータ形式を使用するようにリファクタリングしたり、パッチが適用されたバージョンに更新したりできます。 前 時限爆弾をデプロイする。
セキュアなWebアプリケーションポスチャの構築
ご覧の通り、今日のウェブアプリケーションは多くの脆弱性に直面しています。データベースをダンプできるインジェクションの欠陥から、攻撃者が認証をすり抜けることを可能にするロジックの欠陥、そして私たちが依存するツールから生じるシークレットの漏洩や依存関係のリスクまで多岐にわたります。これは気が遠くなるように感じるかもしれませんが、共通のテーマは意識とプロアクティブな防御です。これらの主要な脆弱性を理解することで、それらを軽減するための対策において一歩先を行くことができます。
堅牢なウェブアプリケーションのセキュリティ体制を構築するためのいくつかの重要なポイント:
- セキュリティをシフトレフト: 開発の早い段階で問題を発見します。SAST/SCAツール（Aikidoなど）をCIパイプラインとIDEに統合することで、コードがマージされる前に脆弱性がフラグ付けされ、修正されます。不安全なSQLクエリを修正したり、コーディング中に認証チェックを追加したりする方が、侵害後に慌てて対応するよりもはるかに容易です。
- 多層防御: 複数のセキュリティ制御層を使用します。例えば、インジェクションやXSSを防ぐために、安全なコーディングプラクティスとセキュリティライブラリを組み合わせ、さらにWebアプリケーションファイアウォール（WAF）を実行して保護を強化します。認証にはMFAを強制し、監視を使用して疑わしいログインを検出します。多層防御とは、たとえ1つの層が機能しなくても、他の層が問題を捕捉することを意味します。
- 最新の状態を維持する：依存関係とサーバーを常にパッチ適用された状態に保ちます。可能な場合は、重要なコンポーネントの自動更新を有効にすることを検討してください。脆弱性フィードやプラットフォーム（Aikido、Dependabotなど）を活用して、スタックに脆弱なものが存在するかどうかを把握します。既知の問題を迅速にパッチ適用するほど、大規模なエクスプロイトキャンペーンに巻き込まれる可能性が低くなります。
- シークレット管理と最小権限: 認証情報は極めて重要なものとして扱います。シークレットにはボルトまたは環境設定を使用し、定期的にローテーションし、各サービスには必要最小限のアクセス権限を与えます。そうすることで、たとえ1つのキーが侵害されても、被害範囲を限定できます。
- Secure by design: 脅威モデリングとセキュア設計原則を初期段階から組み込みます。新機能については、悪用される可能性を考慮し、必要なチェックを組み込みます（例：新しいファイルアップロード機能がデシリアライゼーションやDoSの問題を防ぐためにファイルの種類とサイズを検証すること、新しいAPIエンドポイントがアクセス制御の欠陥を防ぐためにユーザーロールを確認することなど）。
- 教育と自動化: 開発チームに一般的な落とし穴（OWASP Top 10のような）について情報を提供し続けます。自動スキャナーとテストをセーフティネットとして使用するだけでなく、開発者がセキュリティへの影響を考慮する文化を育みます。少しの意識が、「テストのためだけに」CSRFトークンを無効にする誘惑や、セキュリティを考慮せずにStackOverflowからコードをコピー＆ペーストする行為を避ける上で大いに役立ちます。
これらの主要なプラクティスに注力することで、アプリケーションのリスクプロファイルを大幅に削減できます。多くの攻撃は、高度すぎるからではなく、基本的なセキュリティ衛生が見過ごされているために成功します。そのギャップを埋めれば、攻撃者はより簡単なターゲットへと移っていきます。
まとめ
今日の脅威に耐えうるWebアプリケーションを構築することは、開発チームにとって十分に可能です。特に適切なツールがあればなおさらです。私たちは、アプリケーションを悩ませる主要なWeb脆弱性を検証し、それらが実際のインシデントにどのように関連するかを見てきました。共通の分母は、認識と早期検出がすべてを左右するということです。サニタイズされていない入力、不足しているアクセスチェック、古いライブラリなど、何を探すべきかを知っていれば、事後対応ではなく、事前に対処することができます。
開発者またはDevSecOpsエンジニアとして、この問題に一人で取り組む必要はありません。Aikido Securityのような最新のAppSecソリューションは、ワークフローにシームレスに適合し、これらの問題を迅速に検出するように設計されています。すべてのコミットを自動化されたセキュリティエキスパートがレビューする状況を想像してみてください。巧妙なXSSバグを指摘し、AWSキーがラップトップから漏洩する前に捕捉し、重大なCVEを持つライブラリのバージョンを使用していることを指摘し、さらには修正を提案または適用します。これこそがAikidoが提供するものです。コード、依存関係、設定などに対するオールインワンスキャンであり、開発者のために構築されています。OWASP Top 10と最新のCVEデータベースがあなたの背後を見守り、作業を遅らせることなくサポートしてくれるようなものです。
次のステップ：監査や（さらに悪いことに）侵害が発生するまで、これらの脆弱性の発見を待つ必要はありません。まずはコードベースでセキュリティスキャンを実行し、現状を把握することから始められます。セキュリティのためのリンティングルールを設定し、依存関係チェックを追加し、あらゆる場所で2FAを有効にしてください。これらすべてを網羅し、さらに多くの機能を提供する開発者ファーストのプラットフォームにご興味があれば、Aikidoをお試しください。Aikidoは、コードスキャン、SAST、シークレット検出、IaCおよびコンテナスキャン、さらにAI支援による修正を1つの統合インターフェースで提供します。実際、AikidoはプロジェクトのステータスをOWASP Top 10カバレッジに対して自動的にマッピングし、ギャップを埋めるのに役立ちます。
最終的に、目標はセキュリティを開発の基盤に統合することです。これらの主要な脆弱性に焦点を当て、安全なコードを記述し、ツールを使用して重労働を自動化することで、ウェブアプリケーションのリスクを大幅に軽減できます。ユーザーのデータは安全に保たれ、アプリは稼働し続け、夜も少し安心して眠れるでしょう（先に述べた、コンテナとアプリのセキュリティについて心配で眠れないチームの42%も同様です！）。
こちらもおすすめです：
