ここに来た目的は何ですか？
アプリケーションがあらゆる種類の攻撃に対して脆弱であることをご存じでしょう。全体として、Cybersecurity Venturesによると、サイバー犯罪は2025年には9.5兆ドルの損害をもたらすと予測されており、これは2015年から3倍の増加です。そして昨年、Webアプリケーション攻撃は全データ侵害の12%を占め、前年の9%から増加しました。この着実な増加と、Webアプリケーションのセキュリティを確保できないことが多数の規制に違反する可能性があるという事実が相まって、開発者は自身に最も影響を与える脅威をよりよく理解しようと熱心になっています。
一般的な脆弱性に関するノイズを削減し、3つの重要な詳細に焦点を当てます。
- TL;DR（要するに）、これにより攻撃の種類についてよりよく理解できます。
- 「これは私に影響しますか？」という質問に対する、明確な「はい」または「いいえ」（✅ または 🙅）と簡単な説明付きの簡潔な回答。
- 「どうすれば修正できますか？」という質問に対する、高価なツールや費用のかかるリファクタリングを伴わない迅速なヒント。
1. SQLインジェクションとNoSQLインジェクション
TL;DR: この典型的な脆弱性は、サニタイズおよび検証されていないユーザー入力によって引き起こされ、攻撃者がデータベースに対して直接クエリを実行することを可能にします。そこから、攻撃者はデータを抽出したり、レコードを変更したり、自由に削除したりすることができます。
これは影響しますか？
✅ アプリが何らかの形でSQLまたはNoSQLデータベースと連携する場合。インジェクション攻撃は何十年も前から存在しており、自動化された攻撃は、一般的なエクスプロイトを使用してエンドポイントを直ちにプローブし始めます。
🙅 データベースレコードに基づいた動的コンテンツがない場合。これは、完全にクライアントサイドである、静的サイトジェネレーター（SSG）を使用している、またはデータベースでサーバーサイドレンダリングを行っているが、ユーザーからの入力を一切受け付けていないためです。
どうすれば修正できますか？まず第一に、不要な文字や文字列を排除するために、すべてのユーザー入力をサニタイズし、検証してください。パラメーター化クエリを可能にするオープンソースライブラリやフレームワークを活用し、ユーザー入力をデータベースクエリに連結しないでください。Node.jsを使用している場合は、SQL/NoSQLインジェクション攻撃などから自律的に保護する当社のオープンソースセキュリティエンジン Runtimeをご検討ください。
2. クロスサイトスクリプティング (XSS)
TL;DR: XSSは別のインジェクション攻撃であり、攻撃者が悪意のあるスクリプトを別のユーザーに送信することを可能にし、認証情報や機密データを収集する可能性があります。
これは影響しますか？
✅ アプリがユーザー入力を受け入れ、それを動的コンテンツとして別の場所に出力する場合。
🙅 ユーザー入力を一切受け付けない場合。
どうすれば直りますか？ SQL/NoSQLインジェクション攻撃と同様に、ユーザー入力を の中に含める際には検証が必要です。 href アンカータグの属性で、プロトコルが でないことを確認するために。 javascript。JavaScriptメソッド（ のような）を使用する際には注意が必要です。 innerHTML またはReactの dangerouslySetInnerHTML。これらは出力時に文字列に埋め込まれた任意のコードを恣意的に実行する可能性があります。どのようなアプローチを取るにしても、オープンソースのサニタイザーを使用してHTML出力をサニタイズしてください。 DOMPurify ユーザーにクリーンで実行不可能なHTMLのみを送信するため。
3. サーバーサイドリクエストフォージェリ (SSRF)
要約: SSRF攻撃は、悪意のある攻撃者がアプリケーションを悪用し、その基盤となるネットワークとやり取りすることで発生します。攻撃者はアプリケーションをプロキシのように動作させ、潜在的により脆弱な、または金銭的価値のあるサービスへアクセスします。
これは影響しますか？
✅ アプリがユーザーデータに対して特定の操作を行う別のサービスやAPIと連携している場合、既知の信頼されたエンドポイント間のみにトラフィックを制限する許可リストを使用している場合でも。🙅 真に静的である場合。
修正方法: IPアドレスやホスト名を検証するための正規表現は良い出発点ですが、通常、8進数エンコーディングのようなバイパス手法に対して脆弱です。より信頼性の高い2つの解決策は、許可リストとプラットフォームのネイティブURLパーサーを使用して、入力を安全で既知のホストのみに制限すること、およびフェッチリクエストでのリダイレクトを無効にすることです。フレームワークによっては、Node.js向けのssrf-req-filterのようなオープンソースプロジェクトを自由に活用し、内部ホストへのリクエストを適切に拒否することも可能です。
4. パストラバーサル
TL;DR: このセキュリティ上の欠陥により、攻撃者は「../」シーケンスや絶対パスを使用してファイルを参照することで、Webサーバー上のファイルやディレクトリにアクセスできます。ダブルエンコーディングのような巧妙な手口を使い、攻撃者はフレームワーク固有のフォルダー・ファイル階層や一般的なファイル名を利用して、貴重な情報を見つけ出すことができます。
これは影響しますか？
✅ アプリケーションがWebサーバー上で動作し、ファイルシステムへの参照が含まれている場合、これは避けられません。
修正方法: 最初のステップは、環境変数やシークレットを含む機密ファイルなどをWebサーバーのルートディレクトリから削除し、さらなるミスを防ぐためのプロセスを確立することです。
環境変数やシークレットを含む機密ファイルをウェブサーバーのルートディレクトリに保存しないことです。また、これらのファイルを公開アクセス可能なフォルダ（例：）に保存しないでください。 /static そして /public のフォルダー Next.jsプロジェクト最後に、ユーザー入力から「../」パスセパレーターとそのエンコードされたバリアントを削除します。
Runtimeもパストラバーサル対策に非常に効果的です…念のため。
5. XML外部エンティティ (XXE) インジェクション
要約: XXE攻撃は、XMLパーサーの脆弱性を悪用し、文書型定義 (DTD) によって参照される外部エンティティが、検証やサニタイズなしにフェッチおよび処理されることを可能にします。攻撃の種類と深刻度は、主に攻撃者のスキルと、インフラプロバイダーからのOSレベルのセキュリティ/権限によって制限されます。
これは影響しますか？
✅ SAMLを使用したシングルサインオン認証フローを含め、何らかの理由でXMLをパースする場合。
🙅 アプリケーションでXMLを扱う必要がない場合！
修正方法: XMLパーサーで外部DTDの解決を無効にします。一部のXMLペイロードにDTDが含まれるのは一般的なため、DTDを完全に拒否することはできないでしょう。XMLパーサーにそれらを処理させないようにするだけです。
6. デシリアライゼーション
要約: 攻撃者は、アプリに組み込まれたデシリアライゼーション関数（例： unserialize() node-serialize）を介して悪意のあるデータを送信し、リモートでコードを実行したり、サービス拒否攻撃を実行したり、さらにはリバースシェルを作成したりする可能性があります。
これは影響しますか？
✅ アプリがユーザーとのインタラクションから直接、またはクッキー、HTMLフォーム、サードパーティAPI、キャッシングなどのバックグラウンド関数/サービスを介してデータをデシリアライズする場合。
🙅 上記のいずれも含まない完全な静的アプリを実行している場合。
修正方法：一般的に、ユーザー入力（信頼できないデータ）のデシリアライズは避けてください。やむを得ない場合は、信頼できる署名、証明書、およびIDプロバイダーに基づいて、認証され認可されたユーザーからのデータのみを受け入れてください。
7. シェルインジェクション／コマンドインジェクション
要約：アプリがユーザー入力を、ウェブサーバーとアプリが実行されるOSの基盤となるシェルに直接渡すため、攻撃者は任意のコマンドを実行したり、ファイルシステムを横断したりすることが可能になります。多くの場合、データを抽出したり、別のシステムにピボットしたりするのに十分な権限を持っています。
これは影響しますか？
✅ アプリケーションがファイルシステムまたはシェルと直接やり取りする場合、例えばcatのようなUNIXコマンドを使用する場合です。
🙅 実行する必要があるコマンドに引数を安全に渡すために、すでにフレームワークのAPIまたはメソッドを使用している場合、またはSSGのようにファイルシステム/シェルとやり取りする必要がない場合。
どうすれば直りますか？ ユーザー入力をコマンドに直接受け入れたり、直接呼び出したりすることは避けてください。代わりに、フレームワークのAPI/メソッドを使用してください。 child_process.execFile() Node.jsの）のように、文字列のリストとして引数を渡すことができます。そのような保護があっても、攻撃者がウェブサーバーから「エスケープ」して rootroot-onlyのフォルダーやファイルにアクセスするのを防ぐため、必要なビジネスロジックに必要な最小限の権限でアプリを実行するようにしてください。
そして、もう一度、念押しとして Runtime を任意のNode.jsプロジェクトに1つのコマンド（npm add @aikidosec/runtime || yarn install @aikidosec/runtime）で追加し、一般的なシェル／コマンドインジェクション攻撃からアプリを即座に保護してください。
8. ローカルファイルインクルージョン (LFI)
TL;DR: LFI攻撃は、Webサーバーを実行しているシステム上のファイルをアプリケーションに公開または実行させることで、攻撃者が情報を抽出したり、リモートでコードを実行したりすることを可能にします。パストラバーサルは攻撃者がファイルを読み取ることを許可するだけですが、LFI攻撃はアプリケーション内でそれらのファイルを実行するため、リモートコード実行（RCE）のような多数の脆弱性にさらされることになります。
これは影響しますか？
✅ アプリがファイルのパスをユーザー入力として使用する場合。
🙅 アプリが何らかのアクションを完了するためにユーザーがパスを提供する必要がない場合。
どうすれば直りますか？ 上記で説明したパストラバーサル手法を防ぐため、常にユーザー入力をサニタイズしてください。ローカルファイルシステムに、通常「安全な」 /public または /static フォルダーの場合、アプリケーションが読み取りおよび実行を許可されているファイル名と場所に対して、許可リストを使用します。
9. プロトタイプ汚染
要約: これは JavaScriptに特化した脆弱性 攻撃者がアプリのグローバルオブジェクトを操作できるようにします。 __proto__その結果、新しいオブジェクトがアプリ全体に継承され、機密データへのアクセスや権限昇格につながる可能性があります。
これは影響しますか？
✅ JavaScriptを使用している場合。
🙅♀️ JavaScript以外を使用している場合！
どうすれば直りますか？ まず、ユーザー入力からのキーを許可リストまたはオープンソースのヘルパーライブラリを使用してサニタイズすることから始めます。保護を強化するには、 Object.freeze() プロトタイプへの変更を防ぐために使用するか、あるいは --disable-proto=delete Node.jsで提供されるフラグを使用することもできます。
10. オープンリダイレクト
要約: この一般的なフィッシング攻撃ベクトルでは、攻撃者は次のようなカスタムURLを作成し、 https://www.example.com/abc/def?&success=false&redirectURL=https://example.phishing.com アプリが不注意なユーザーを悪意のあるウェブサイトにリダイレクトするように仕向けます。さらに、攻撃者は他の脆弱性とリダイレクトを連鎖させることで、アカウント乗っ取りなど、より大きな影響を与える可能性があります。
これは私に影響しますか？
✅ アプリが、アクション完了後にユーザーを別のページ/ビューにリダイレクトする場合。例えば、 example.app/dashboard 認証成功後にリダイレクトする場合など。
🙅♀️ 静的生成されたサイトを運用している場合。
どのように修正すればよいでしょうか？まず、アプリケーションからパラメータベースのリダイレクトを削除し、ユーザーが特定のアクションを実行した後にリダイレクトできる信頼できるドメインとパスの許可リストに基づいた固定リダイレクトに置き換えてください。これによりユーザーエクスペリエンスがわずかに低下する可能性がありますが、クレジットカードの明細書に身に覚えのない請求が記載されてユーザーから非難されるような事態を避けるためにも、安全なエクスペリエンスを提供するための重要な妥協点となります。
次は何ですか？
攻撃の範囲やそれらから保護するために必要な作業の多さに圧倒されていると感じるかもしれませんが、それはあなた一人ではありません。
これらのセキュリティ問題や潜在的な脆弱性をすべて自分で解決することを誰も期待していません。SQLインジェクション攻撃だけでも何十年も前から存在しており、洗練されたアプリケーション、フレームワーク、ライブラリで常にCVEが発見され続けています。だからといって、これらのセキュリティ問題を軽視すべきではありません。もしアプリケーションがこれらトップ10のセキュリティ問題のいずれかに該当する（✅）場合は、すぐに対策を講じるべきです。
おそらく、エンタープライズグレードの（つまり、高価で複雑な）セキュリティツールを使用しているか、あるいは、いくつかのオープンソースプロジェクトをCI/CDパイプラインやGitコミットフックに寄せ集めて、最善を願っているかのどちらかでしょう。これにより、以下のようなセキュリティギャップが生じる可能性があります。
- 理想的とは言えないプログラミングプラクティス、安全でない依存関係などにより、アプリがどのように脆弱になる可能性があるか。
- 脆弱性がどこに 潜んでいる可能性が高いか、単一のLOCや
package.jsonファイル内のエントリに至るまで。 - なぜ特定の脆弱性を直ちに修正すべきなのか、そして他の脆弱性の優先度が低いのはなぜか。
Aikido Securityは、2つの簡単なステップでこれらのギャップを埋めるのに役立ちます。
1. Aikidoでコードをスキャンします
サインアップ（無料、2分で完了）してリポジトリをスキャンしてください。アプリケーションの実際のアーキテクチャと使用状況に基づいて、重要な脆弱性の絞り込まれたリストを取得します。何が重要かを正確に把握し、ガイド付きの修正を受け、最新のコミットでの新しい問題に対するアラートを受け取ります。
2. RuntimeでNode.jsアプリを保護します
オープンソースのRuntimeを追加することで、WAFやエージェントのオーバーヘッドなしに、サーバーレベルでインジェクション、プロトタイプ汚染、パス横断攻撃をブロックできます。Runtimeはリアルタイムの攻撃データをAikidoに送信するため、何が標的になっているかを確認し、修正の優先順位を付けることができます。
これで、あなたは正しいスタートを切り、以下の点についてより明確な全体像を把握できたでしょう。
- アプリケーションが、かつて考えていた以上に多くの方法で脆弱であるか。
- 最も重要な問題を最初に修正するために、時間と注意をどこに集中すべきか。
- セキュリティおよび脆弱性スキャンが一度限りの取り組みではなく、継続的なプロセスである理由
