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