最新のウェブアプリケーションがあらゆる種類の攻撃に対して本質的に脆弱であることをご存知でしょう。また、アプリセキュリティは決して完璧ではないことも理解していますが、昨日よりも今日、今日よりも明日と改善していくことは可能です。
問題は、エンタープライズグレード（高価で複雑な）セキュリティツールを使用しているか、あるいは、いくつかのオープンソースプロジェクトをCI/CDパイプラインやGitコミットフックに寄せ集めて、最善を願っているかに関わらず、お使いのツールキットでは、以下を確認できないことです：
- 理想的とは言えないプログラミングプラクティス、安全でない依存関係などにより、アプリがどのように脆弱になる可能性があるか。
- 脆弱性がどこに 潜んでいる可能性が高いか、単一のLOCや
package.jsonファイル内のエントリに至るまで。 - なぜ特定の脆弱性を直ちに修正すべきなのか、そして他の脆弱性の優先度が低いのはなぜか。
Aikidoは、適切なセキュリティ修正を迅速に適用し、コードの出荷に戻る必要がある開発者にとって、アプリケーションセキュリティを関連性があり効率的なものにするために存在します。開発者中心のセキュリティプラットフォームで行っているように、一般的な脆弱性に関するノイズを減らし、3つの重要な詳細に焦点を当てます。
- The 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: パストラバーサル
要約: このセキュリティ上の欠陥は、攻撃者がウェブサーバー上のファイルやディレクトリにアクセスすることを可能にします。 ../ シーケンスや絶対パスを使用することで。二重エンコーディングのような巧妙な手口を使い、攻撃者はフレームワーク固有のフォルダーとファイルの階層や一般的なファイル名を利用して、価値のある情報を見つけ出すことができます。
これは私に影響しますか？
- ✅. アプリケーションがウェブサーバー上で動作し、ファイルシステムへの参照を含んでいる場合—これは避けられません。
修正方法: 最初のステップは、環境変数やシークレットを含む機密ファイルなどを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の基盤となるシェルに直接渡すため、攻撃者は任意のコマンドを実行したり、ファイルシステムを横断したりすることが可能になります。多くの場合、データを抽出したり、別のシステムにピボットしたりするのに十分な権限を持っています。
これは私に影響しますか？
- ✅ アプリがファイルシステムやシェルと直接やり取りする場合（例えばUNIXコマンドの
cat. - 🙅 実行する必要があるコマンドに引数を安全に渡すために、すでにフレームワークのAPIまたはメソッドを使用している場合、またはSSGのようにファイルシステム/シェルとやり取りする必要がない場合。
どうすれば直りますか？ ユーザー入力をコマンドに直接受け入れたり、直接呼び出したりすることは避けてください。代わりに、フレームワークのAPI/メソッドを使用してください。 child_process.execFile() Node.jsの）のように、文字列のリストとして引数を渡すことができます。そのような保護があっても、攻撃者がウェブサーバーから「エスケープ」して rootroot-onlyのフォルダーやファイルにアクセスするのを防ぐため、必要なビジネスロジックに必要な最小限の権限でアプリを実行するようにしてください。
そして、もう一度、念押しとして Runtime を任意のNode.jsプロジェクトに1つのコマンド（npm add @aikidosec/runtime || yarn install @aikidosec/runtime）で追加し、一般的なシェル／コマンドインジェクション攻撃からアプリを即座に保護してください。
#8: ローカルファイルインクルージョン（LFI）
要約：LFI攻撃は、ウェブサーバーが動作しているシステム上のファイルをアプリに公開または実行させることで行われます。これにより、攻撃者は情報を抽出したり、リモートでコードを実行したりできます。パストラバーサルは攻撃者がファイルを読み取ることを可能にするだけですが、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=true&redirectURL=https://example.phishing.com アプリが不注意なユーザーを悪意のあるウェブサイトにリダイレクトするように仕向けます。さらに、攻撃者は他の脆弱性とリダイレクトを連鎖させることで、アカウント乗っ取りなど、より大きな影響を与える可能性があります。
これは私に影響しますか？
- ✅ アプリが、アクション完了後にユーザーを別のページ/ビューにリダイレクトする場合。例えば、
example.app/dashboard認証成功後にリダイレクトする場合など。 - 🙅♀️ 静的生成されたサイトを運用している場合。
修正方法：まず、アプリからパラメータベースのリダイレクトを削除し、ユーザーが特定のアクションを実行した後にリダイレクトできる信頼できるドメインとパスの許可リストに基づいた固定リダイレクトに置き換えます。これはユーザーエクスペリエンスをわずかに低下させるかもしれませんが、アプリのセキュリティを向上させるための意味のある妥協であり、ユーザーがクレジットカードの明細書にある見慣れない請求についてあなたを責めるような事態にはなりません。
アプリのセキュリティの次なるステップは？
攻撃の範囲とそれらから保護するために必要なすべての作業に圧倒されていると感じても、あなたは一人ではありません。
これらのセキュリティ問題や潜在的な脆弱性のすべてを自分で解決することを誰も期待していません。SQLインジェクション攻撃だけでも何十年も前から存在しており、高度なアプリ、フレームワーク、ライブラリで常にCVEが発見されています。だからといって、これらのセキュリティ問題を軽視すべきではありません。もしあなたのプロジェクトが、これらトップ10のアプリセキュリティ問題のいずれかで✅に該当する場合、すぐに対策を講じるべきです。
まず、Aikidoにサインアップして、アプリケーションセキュリティに対する真の脅威に焦点を当て始めましょう。2分で無料でリポジトリをスキャンし、アプリケーションの特定のアーキテクチャ、および実装されている機能、関数、ヘルパーライブラリに基づいて、最も重要な脆弱性に関する関連性の高い詳細情報とガイダンス付きの修正を得ることができます。Aikidoを使用すると、重要なものに範囲を絞り込み、スマートな修正をより迅速に実装し、最新のコミットで導入された新たなセキュリティ問題について即座に通知を受け取ることができます。
次に、Node.jsアプリに、当社のオープンソース組み込みセキュリティエンジンであるRuntimeを追加します。Runtimeは、Webアプリケーションファイアウォールやエージェントベースのアプリケーションセキュリティ管理プラットフォームのようなコストや複雑さなしに、サーバーレベルでブロックすることで、様々なインジェクション、プロトタイプ汚染、パストラバーサル攻撃からアプリを即座に自律的に保護します。Runtimeは、アプリとユーザーがこれらの一般的なセキュリティ問題から安全であるという確信を与えますが、リアルタイムデータをAikidoにフィードバックして、現在の攻撃ベクトルを可視化し、修正の優先順位付けを支援することもできます。
これで、あなたは正しいスタートを切り、以下の点についてより明確な全体像を把握できたでしょう。
- アプリが、かつて考えていた以上に多くの方法で脆弱になる可能性があること。
- 最も重要な問題を最初に修正するために、どこに時間と注意を集中すべきか。
- アプリケーションセキュリティと脆弱性スキャンが一度限りの取り組みではなく、Aikidoによって大幅に簡素化される継続的なプロセスである理由。
