あなたは、最新のウェブアプリケーションがあらゆる攻撃に対して本質的に脆弱であることを知っています。また、アプリケーションのセキュリティが完璧であることはあり得ないが、昨日よりも明日、より良くすることは可能であることもご存知でしょう。
問題は、エンタープライズ・グレードの（つまり高価で複雑な）セキュリティ・ツールを使っているにせよ、オープンソースのプロジェクトをCI/CDパイプラインやGitコミット・フックに寄せ集めてベストを尽くしているにせよ、ツールキットでは何も見えてこないということだ：
- あなたのアプリは、あまり理想的でないプログラミングプラクティスや、安全でない依存関係などによって、どのように 脆弱になる可能性があるのか。
- どこで 脆弱性が潜んでいる可能性は高い。
package.jsonファイル。 - 特定の脆弱性をすぐに修正すべき理由と 、他の脆弱性の優先順位が低い理由。
Aikido 、適切な セキュリティ修正を迅速に適用し、コードの出荷に戻る必要がある開発者にとって、アプリのセキュリティを適切かつ効率的にするために存在します。私たちが開発者中心のセキュリティ・プラットフォームで行っているように、一般的な脆弱性にまつわるノイズを減らし、3つの重要な詳細に焦点を当てます：
- TL;DRは、あなたが恐れるに足るだけのことを教えてくれる...そして、あなたの教育的検索を続けるための正しいキーワード。
- これは私に影響しますか」という質問に対する簡潔な答えで、イエスかノー（✅かᑕ）かを明確にし、簡潔に説明すること。
- 高価なツールや高価なリファクターを必要としない「どうすれば直りますか？
#1位：SQLインジェクションとNoSQLインジェクション
TL;DR: この古典的な脆弱性は、未サニタイズ、未認証のユーザー入力によって実現され、攻撃者はあなたのデータベースに対して直接クエリを実行することができます。攻撃者はそこからデータを抽出したり、レコードを変更したり、削除したりすることができます。
これは私に影響しますか？
- アプリが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：パス・トラバーサル
TL;DR： このセキュリティ上の欠陥により、攻撃者は、ウェブサーバ上のファイルやディレクトリにアクセスする際に ../ シーケンスや絶対パスでさえも。ダブルエンコーディングのような卑劣な手口を使い、攻撃者はフレームワーク特有のフォルダ・ファイル階層や一般的なファイル名を使って貴重な情報を見つけることができる。
これは私に影響しますか？
- ✅.あなたのアプリはウェブサーバー上で実行され、ファイルシステムへの参照を含んでいます。
どうすれば直りますか？ 最初のステップは、ウェブサーバのルートディレクトリから、環境変数やシークレットを含むような機密性の高いファイルを削除することです。
環境変数や秘密を含むような機密性の高いファイルは、決してウェブサーバのルートディレクトリに保存しないようにしてください。また、これらのファイルを /静的 そして /パブリック フォルダー Next.jsプロジェクト.最後に ../ パス区切り文字とそのエンコードされた変種をユーザー入力から取得する。
ランタイムはパストラバーサルでも素晴らしい働きをする。
#5位：XML eXternal Entity (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の基礎となるシェルに直接ユーザ入力を渡すため、攻撃者は任意のコマンドを実行したり、ファイルシステムをトラバースしたりすることができます。
これは私に影響しますか？
- アプリがファイルシステムやシェルと直接やりとりする場合。
猫. - 🙅 既にフレームワークのAPIやメソッドを使って、実行する必要のあるコマンドに引数を安全に渡したり、SSGのようにファイルシステム/シェルとやりとりする必要がない場合。
どうすれば直りますか？ ユーザー入力を直接コマンドに取り込んだり、直接コマンドを呼び出したりするのは避けましょう。代わりに、以下のようなフレームワークのAPI/メソッドを使います。 child_process.execFile() Node.jsでは、文字列のリストで引数を渡すことができます。このような保護があったとしても、攻撃者がウェブ・サーバを「エスケープ」して、次のようなアクセスをしてくるのを防ぐため、必要なビジネス・ロジックに必要な最小限の権限でアプリを実行するようにしてください。 ルート-フォルダとファイルのみ。
そうそう、もう1つ親切な注意喚起を追加するために戻ってきた。 ランタイム を1つのコマンド (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) を使って、一般的なシェル/コマンドインジェクション攻撃からアプリを即座に保護することができます。
#8位：ローカル・ファイル・インクルージョン（LFI）
TL;DR： LFI攻撃は、あなたのアプリを騙して、Webサーバーを実行しているシステム上のファイルを公開させたり、実行させたりします。パストラバーサル攻撃は攻撃者にファイルを読ませるだけですが、LFI攻撃はアプリ内でそれらのファイルを実行するため、リモートコード実行（RCE）のようなアプリセキュリティの脆弱性の羅列にさらされることになります。
これは私に影響しますか？
- アプリがユーザー入力としてファイルへのパスを使用する場合、 ✅。
- アプリがアクションを完了するためにユーザーがパスを提供する必要がない場合は、🙅。
どうすれば直りますか？ 常にユーザー入力をサニタイズして、上で説明したパストラバーサル手法を防いでください。ローカルファイルシステム上のファイルを、通常 "安全な" /パブリック または /静的 フォルダで、アプリが読み取りと実行を許可されるファイル名と場所を allowlist で指定する。
#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=true&redirectURL=https://example.phishing.com 攻撃者は、リダイレクトを他の脆弱性と連鎖させることができます。さらに、攻撃者はリダイレクトを他の脆弱性と連鎖させることで、より大きな影響を与え、アカウントの乗っ取りなどにつなげることができます。
これは私に影響しますか？
- アプリがアクションを完了した後、ユーザーを別のページ/ビューにリダイレクトする場合。
example.app/ダッシュボード認証成功後 - もしあなたがまだ静的に生成された人生を生きているのなら、🙅。
どうすれば解決できますか？ まず、アプリからパラメータベースのリダイレクトを削除し、ユーザーが特定のアクションを行った後にリダイレクトできる、信頼できるドメインとパスの許可リストに基づいた固定リダイレクトに置き換えます。これは、ユーザーエクスペリエンスを若干低下させるかもしれませんが、より良いアプリのセキュリティのための有意義な妥協であり、クレジットカードの明細に記載された奇妙な出費をあなたのせいにするようなものではありません。
アプリのセキュリティの次は？
もしあなたが、攻撃の範囲やそれらから守るために必要なすべての作業に圧倒されていると感じているのなら、あなたは一人ではないことを知っておいてほしい。
これらのセキュリティ上の問題や脆弱性の可能性をすべて自分で解決できるとは誰も期待していない。SQLインジェクション攻撃だけでも何十年も前から存在し、洗練されたアプリやフレームワーク、ライブラリにあるCVEを、人々は今でも常に見つけている。だからといって、これらのセキュリティ問題を大目に見るべきだというわけではありません。もしあなたのプロジェクトが、これらのアプリのセキュリティ問題トップ10のいずれかに✅当てはまったら、対策を始めるべきです。
まず、 Aikido登録し、アプリのセキュリティに対する真の脅威に焦点を当てましょう。2分で、しかも無料で、リポジトリをスキャンし、アプリの特定のアーキテクチャや、実装した機能、関数、ヘルパーライブラリに基づいて、関連する詳細と、最も重要な脆弱性のためのガイド付き対策を得ることができます。Aikido使えば、重要な範囲に絞り込んでスマートな修正を迅速に実装し、最新のコミットで導入された新しいセキュリティ問題を即座に知ることができます。
次に、オープンソースの組み込みセキュリティエンジンであるRuntimeをNode.jsアプリに追加します。Runtimeは、様々なインジェクション、プロトタイプ汚染、パストラバーサル攻撃をサーバレベルでブロックすることにより、即座に自律的にアプリを保護しますが、Webアプリケーションファイアウォールやエージェントベースのアプリケーションセキュリティ管理プラットフォームのようなコストや複雑さは必要ありません。Runtimeは、アプリとユーザがこれらの一般的なセキュリティ問題から安全であることを確信させるだけでなく、リアルタイムデータをAikido フィードバックして、現在の攻撃ベクトルを可視化し、修正の優先順位付けに役立てることができます。
これで、あなたは正しいスタートを切ることができた：
- あなたのアプリは、 あなたがかつて考えていたよりも多くの点で脆弱である。
- 最も重要な問題を最初に解決するために、時間と注意をどこに 集中させるべきか。
- なぜアプリの セキュリティと脆弱性スキャンは一度だけの取り組みではなく、継続的なプロセスなのか？ Aikido.
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
