ブログへようこそ

アプリのセキュリティ問題トップ10とその対策
あなたは、最新のウェブアプリケーションがあらゆる攻撃に対して本質的に脆弱であることを知っています。また、アプリケーションのセキュリティが完璧であることはあり得ないが、昨日よりも明日、より良くすることは可能であることもご存知でしょう。
問題は、エンタープライズ・グレードの(つまり高価で複雑な)セキュリティ・ツールを使っているにせよ、オープンソースのプロジェクトを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.

シリーズAで1700万ドルを調達した
TL;DR 私たちは多くの資金を調達し、大きく羽ばたく準備ができた。
私たちは、開発者に "BSなし "のセキュリティを提供するために1,700万ドルを調達しました。Singular.vcの Henri Tilloy氏を取締役に迎え、Notion Capitalと Connect Venturesが加わりました。このラウンドは、シード資金として530万ドルを調達してからわずか6ヶ月後のことです。早いですね。
私たちがAikido 設立したのは、開発者が問題を抱えているからです。セキュリティとコンプライアンスの要件は、もはや大企業だけのものではなく、あらゆる規模の企業、特に顧客を獲得し、規模を拡大しようとしている中小企業にとって、必要性が高まっています。SOC2、ISO 27001、CIS、HIPAA、そして今後予定されている欧州のNIS 2指令のようなコンプライアンス基準は、ソフトウェア企業、特にヘルステックやフィンテックのような企業への販売や機密データを扱う企業にとって基本的な要件になりつつあります。
しかし、この増大するコンプライアンスの負担は、セキュリティの専門家としての機能を期待されている開発者の肩にかかることが多い。Aikido 、必要なコードとクラウドセキュリティスキャナを1つのシンプルで使いやすいインターフェイスにまとめ、最高のオープンソースを活用したオールインワンプラットフォームです。私たちはフリーミアムで、セルフサービスで、フードの下に何があるのか、いくらかかるのかをオープンにしています。
私たちは、業界のベテランが率いる米国やイスラエルの企業が長い間支配してきた、確立された緊密なセキュリティ業界におけるアウトサイダーの挑戦者です。確かに、30年前からセキュリティ・ツールはありましたが、私たちは全く異なる立場から出発しています。私たちは、購入者がユーザーであるセキュリティ・プラットフォームを構築しています。よくあることだが、CISOが買い手であるにもかかわらず、どこかの貧弱な開発者がユーザーになっている。
私たちは、以前、そのような貧しい開発者になったことがある。私たちは、時間とお金を浪費する不格好なレガシー・セキュリティ・ツールで作業することのフラストレーションを感じてきました。私たち自身もCTOとして、無関係なセキュリティ・アラートに何百時間も浪費しました。私たちは、これらのツールがF-16のコックピット内部のように見えることを知っています。複雑で誤ったアラートに振り回され、チェックするのをやめてしまう。私たちは、開発者がただ問題を修正し、楽しい機能の構築に進みたいと考えていることを理解しています。
アンリとSingularと一緒に仕事ができることに興奮しています。彼は、私たちが実際に製品を理解していると感じた最初の投資家の一人で、私たちを単なる表計算ソフトとして見ていませんでした。彼は、私たちが「 シンプルで、オープンソースを活用し、セットアップと使用が簡単でありながら、Aikido 企業のコンプライアンスとセキュリティ要件を一度に満たしてくれる 」という「セキュリティに対する信じられないほどユニークなアプローチ」を持っていると信じています。(私たちは、彼の素敵な引用と賛辞も気に入っています)。
立ち上げから1年足らずで、すでに3,000以上の組織と6,000人以上の個人開発者に利用されています。Vismaが、175社以上のポートフォリオをすべて確保するために当社を選択したことは重要であり、当社が正しい道を歩んでいることを確認しました(疑っていたわけではありません ;)。私たちの顧客の30%は米国におり、開発者や中小企業がセキュリティを確保できるよう、さらなる国際的な拡大を目指しています。
この新たな1,700万ドルのシリーズA資金調達により、我々はプラットフォームをさらに深化させ、Aikido グローバルなステージに押し上げ、中小企業にとってセキュリティをシンプルなものにし、開発者にとって業界の専門用語やお役所仕事、そして率直に言ってBSなしに実行可能なものにすることができる。

2025年の開発者向けベストRASPツール
サイバー脅威が高度化する中、アプリケーション・セキュリティは重要な意味を持っています。開発者は、機密データを脅かし、業務を妨害する脆弱性や攻撃からアプリケーションを保護しなければなりません。
従来のセキュリティ対策は、進化する脅威に遅れをとることが多い。これらの対策は、ゼロデイ・エクスプロイトやアプリケーションのランタイム環境を標的とする複雑な攻撃ベクトルから保護できない可能性があります。
ランタイム・アプリケーション・セルフプロテクション(RASP)ツールは、このような課題に対処します。RASPツールは、挙動を監視し、リアルタイムで攻撃をブロックすることで、アプリケーションをプロアクティブに保護します。
RASP(ランタイム・アプリケーション・セルフ・プロテクション)を理解する
RASP テクノロジーは、ランタイム中の動作を継続的に監視することで、アプリケーションを保護します。従来の境界ベースのセキュリティ・ソリューションとは異なり、RASPツールはアプリケーションのランタイム環境に直接統合し、内部からの防御レイヤーを提供します。
アプリケーションにセキュリティ制御を組み込むことで、RASP は様々な脆弱性や脅威をリアルタイムで検出し、防止します。これには、SQLインジェクション、クロスサイト・スクリプティング(XSS)、リモート・コード実行などの一般的な攻撃や、他のセキュリティ対策をバイパスする高度なエクスプロイトが含まれます。
RASPは、アプリケーションコードを大幅に変更することなく、継続的な攻撃防御を提供する点で際立っている。RASPツールは、事前に定義されたセキュリティ・ポリシーと機械学習に基づいて、悪意のあるリクエストや動作を自動的に識別し、ブロックする。これにより、RASPがシームレスにセキュリティを処理する間、開発者は機能の構築に集中することができます。
2025年に開発者がRASPツールを必要とする理由
2025年のサイバーセキュリティの状況は、ユニークな課題を提示している。脅威が急速に進化する中、従来のセキュリティ対策では、新たな脆弱性に対処するための俊敏性に欠けることが多い。このギャップは、リアルタイムの保護を提供できるダイナミックなソリューションを求めています。RASPツールは、アプリケーションに直接セキュリティ制御を組み込むことで、悪意のあるアクションを即座に検出し、阻止することを可能にします。
これらのツールは、ランタイム中の能動的な脅威モニタリングを通じて、アプリケーションを保護する上で重要な役割を果たします。アプリケーションの動作を分析し、潜在的な脅威を特定することで、RASPツールはセキュリティフレームワークを強化し、開発者がコンプライアンス要件を満たすのを支援します。データ保護規制が厳しい分野では、RASPツールはデータ漏洩や不正アクセスに関連するリスクを軽減するために極めて重要です。
RASP ツールを開発ライフサイクルに組み込むことで、開発者はセキュリティを損なうことなく技術革新を行うことができます。これらのツールは既存の開発環境とスムーズに統合されるため、セキュリティ強化によってワークフローが中断されることはありません。その結果、開発チームは、セキュリティのニーズが管理・維持されていることを確信しながら、高度なアプリケーションの作成に専念することができる。
2025年のトップRASPツール
1.Aikido セキュリティ・プラットフォーム
AikidoRASPソリューション「Zen」は、高度なAI技術を利用してアプリケーションの防御を強化し、脅威を即座に特定して緩和することで、強固なセキュリティを確保します。このツールは、潜在的な脆弱性や攻撃ベクトルを深く可視化し、開発者が効果的にセキュリティ対策を強化できるようにします。一般的な開発環境との統合もスムーズで、開発者は開発プロセスを中断することなくセキュリティ機能を強化できる。
2.コントラストプロテクト
Contrast Protectは、幅広いプログラミング言語とフレームワークをサポートする汎用性の高いRASPソリューションです。高度な機械学習技術を使用して新たな脅威を検出し、防御を調整することで、誤警告を低減します。このプラットフォームは、包括的な分析とレポートを提供し、開発者が脆弱性に迅速に対処し、アプリケーションの堅牢性を向上させるための情報を提供します。
3.Imperva RASP
Imperva RASPはクラウドベースのインフラストラクチャ上で動作し、OWASPによって特定された脆弱性を含むさまざまな脆弱性に対する広範な保護を提供します。有害なトラフィックをリアルタイムで効率的に検出してブロックし、パフォーマンスを犠牲にすることなくアプリケーションを確実に保護します。このツールは既存のセキュリティ・セットアップと容易に統合でき、高度なサイバー脅威に対するアプリケーション防御の強化プロセスを簡素化します。
アプリケーションに適したRASPツールの選択
理想的な RASP ツールを選択するには、開発環境の技術的および運用上のニーズを理解する必要があります。まず、アプリケーションが使用しているプログラミング言語とフレームワークを評価する。RASP ツールによって互換性のレベルはさまざまであり、自社の技術スタックに合ったものを選択することで、統合を合理化し、効率的な運用を実現できる。最も一般的に使用されている言語とフレームワークをサポートする RASP ソリューションを選択することで、包括的なアプリケーション保護を実現できます。
RASPツールが、複雑さを増すことなく、開発ワークフローをどのように強化するかを検討する。ツールは、既存のプロセスに自然に適合し、チームの方法論を補完するものでなければならない。効果的な RASP ツールは、主要なセキュリティタスクを自動化し、CI/CD システムと統合することで、効率を高め、開発の勢いを維持する。
RASP ツールが一般的な脆弱性や攻撃ベクトルに対して提供する保護レベルは極めて重要です。バッファ・オーバーフロー、特権の昇格、高度なエクスプロイトなどの脅威を処理するツールの能力を調べます。高度な分析と適応学習を備えたツールは、新しい脅威に的確に対応し、包括的な防御を提供します。さらに、継続的な改善に役立つ詳細な洞察やレポートを提供するツールの能力も考慮してください。
導入と管理のしやすさも見逃せない。わかりやすい RASP ツールであれば、開発チームの学習曲線が短縮され、運用の負担も最小限に抑えられる。文書、顧客サービス、コミュニティ・リソースなど、ベンダーのサポート内容を評価する。ベンダーの強力なサポートは、特に複雑なセキュリティ上の課題を克服する場合や、統合フェーズにおいて極めて重要である。
開発プロセスにRASPを導入するためのベストプラクティス
RASP をセキュリティ戦略に組み込む場合は、アプリケーションのアーキテクチャに組み込んで保護を強化します。RASP をコアに統合することで、継続的な監視と迅速な脅威検出が可能になります。このプロアクティブなアプローチにより、アプリケーションと共に進化する適応性のあるセキュリティ対策が可能になり、開発を遅らせることなく堅牢な防御を提供します。
セキュリティを強化するには、RASPとリアルタイムの脅威インテリジェンス・サービスを同時に導入します。この組み合わせにより、セキュリティの枠組みが強化され、新たな脅威に対する洞察が得られ、先手を打った対応が可能になります。リアルタイム・インテリジェンスは、潜在的な脆弱性に関する外部の視点を提供することでRASPを補完し、包括的なセキュリティ・アプローチを実現します。
RASPの設定を定期的に更新し、有効性を維持する。設定とパフォーマンス指標の徹底的な監査を実施し、運用を改善し、ギャップに対処する。RASP ツールを最新の脅威データとセキュリティ・プロトコルに対応させることで、脅威を効果的に遮断し、高いアプリケーション・セキュリティ基準を維持することができます。
最後に、セキュリティ重視の環境を育成する。RASP を効果的に使用するための知識をチームに与え、より広範なセキュリティ環境における RASP の役割を強調する。継続的な学習と新しいセキュリティ動向への適応を奨励し、チームが常に情報を入手し、進化するサイバーセキュリティの課題に備えるようにする。
RASPツールを採用し、開発プロセスに組み込むことで、進化する脅威に対してアプリケーションを強化することができます。2025年に向けてアプリケーション・セキュリティの課題に取り組む際には、潜在的な脆弱性の一歩先を行くために、事前の対策と継続的な適応が不可欠であることを忘れないでください。アプリケーション・セキュリティを強化する準備が整いましたら、 Aikido無料サービスをご利用ください。

Webhookセキュリティ・チェックリスト:安全なウェブフックを構築する方法
なぜここに?
時間を無駄にしないようにしましょう。あなたがここにいるのは、アプリにウェブフック機能を構築しているからです。残念ながら、セキュリティの観点からうまくいかないことがたくさんあります。この記事の目的は、Webhookを構築している間によく知られている間違いを犯さないようにすることです。
ウェブフックはどのように機能するのか?
簡単におさらいすると、webhookとは、あなたのアプリで起こったことをサードパーティに通知するためのHTTP(S)リクエストです。例えば、請求書を作成するアプリケーションを提供している場合、新しい請求書が作成されたときにトリガーされるWebhook機能を設定する機会を顧客に提供することができます。つまり、請求書が作成されると、アプリケーションはHTTP(S)リクエストをユーザーが決めた場所に送信します。ユーザーはこれを利用して、リマインダーメールのスケジューリングやSlackでのメッセージ送信など、Webhookをトリガーとした独自のカスタムワークフローを設定することができます。
チェックリスト:ウェブフックの実装を保護する
1.SSRF型攻撃への対処
このタイプの攻撃では、攻撃者はWebhook機能を悪用して情報(クラウド上のインスタンス・メタデータなど)を取得しようとする。これに対抗するには、以下の対策を講じる必要がある。
✅ ユーザー入力を検証する
- Basic:簡単なURL検証を行う。
- より良い:URLが "https://"で始まることを確認し、"file://"やその他の非HTTPSスキームを許可しない。
✅ ローカルアドレスを制限する
- 典型的なローカルIPをブロック:127.0.x、192.168.x、172.x。
- "localhost "と "http://"の禁止
限界ログ曝露量
- ユーザー向けログにHTTPステータスコードのみを表示する。
- ヘッダーや本文の表示は避ける。
✅ 高度な:URL検証の強化
- POSTリクエストに対して、顧客固有のレスポンスヘッダを要求する。
- DNSの変更に対処するため、初期設定後もこの検証を継続する。

2.ユーザーがデータの信頼性を確認できるようにする
Webhookコンシューマーは、データが本当にあなたのアプリから来たものであることを知る方法を持たなければなりません。以下のいずれかの方法を使用できます。
テスト・メッセージの 検証
まず、セキュリティー・メカニズムをテストするために、ユーザーがテスト・メッセージをトリガーできるようにする。
✅ HMAC検証ハッシュ
ウェブフック機能に対する最も効果的なセキュリティ・メカニズムの一つは、データの完全性と真正性のためにHMACを実装することである。
基本的なプロセスは以下のようにまとめられる:
- SHA-256と秘密鍵を使ってペイロードのハッシュを生成する。
- HMACをペイロードと一緒に送信する。
- 受信者はハッシュを再作成し、ペイロードの真正性と完全性を検証する。
タイムスタンプ・インクルージョン
これは、より高度なセキュリティ緩和策である。リプレイ攻撃を防ぐために、ペイロードにタイムスタンプを追加する。メッセージが再利用されたり改ざんされたりしないようにする。
クライアント側 TLS 証明書
クライアント側のTLS証明書でHTTPコールを認証する。これは特に企業レベルの消費者にとって魅力的です。
3.レートの制限とデータの過剰露出の回避
ウェブフックのセキュリティーについては、送信するデータが少なすぎる方が、多すぎるよりも安全である。ウェブフックのコールバックはHTTPSを使って暗号化されるべきだが、数年後に誰がドメイン名を管理しているかは分からない。
✅ データ露出の最小化
- 個人を特定できる情報(PII)や機密性の高いデータの送信は避けてください。
- 複数のデータ(contact_id、email、nameなど)を送信する代わりに、contact_idだけを送信します。必要であれば、ユーザーにパブリックAPIから追加データを取得させましょう。
再試行 ポリシー通信
- リトライポリシーとレート制限をユーザーに明確に伝える。
- リトライのため、メッセージが順番通りに届かない可能性があることを伝える。
- 2xx応答はすべて成功であると定義する。
✅ 配送にキューシステムを使う
Webhookの配信を管理し、出力を調整するためにキューシステムを実装します。このアプローチは、大規模なCSVインポートが過剰なWebhookコールと再試行を引き起こすようなエッジケースにおいて、誤ってユーザーのサーバーを圧迫することを防ぐのに役立ちます。
4.ボーナス:異常アラート
これはセキュリティというより開発者の利便性のためだが、それでも実装しておくに越したことはない。
- 4xxおよび5xxレスポンスが発生した場合、ユーザーに警告を発する。
- ユーザーに障害を知らせる通知を送る
この追加により、Webhookシステムの透明性と応答性が向上します。
結論
これで完成だ!Webhookを機能的にするだけでなく、安全でユーザーフレンドリーにするためのいくつかのステップを紹介しました。これらのステップを実装することで、アプリを保護し、全体的なユーザーエクスペリエンスを向上させることができます。それでは、よいコーディングを!🚀🔒👨💻
Aikido Securityは、開発者中心のソフトウェアセキュリティプラットフォームです。私たちは、あなたがコードを書くことに集中できるように、あなたの製品を安全に保つお手伝いをします。 GitHub、GitLab、Bitbucket、またはAzure DevOpsのアカウントに接続するだけで、無料でリポジトリスキャンを開始できます。

セキュリティ・アラート疲労症候群への対処法
ほとんどのセキュリティ・ツールは開発者の時間を浪費している。我々はこれを解決する使命を担っている。
アプリケーション開発者は、セキュリティを気にするために給料をもらっているわけではない。彼らのパフォーマンスは、新機能や機能強化を通じてビジネスに付加価値を与えるスピードによって評価される。
そのため、従来のセキュリティ・ツールは開発者のために作られていないため、邪魔な存在になっている。セキュリティ・アラートの膨大なリストを表示するだけで、あとは開発者が考えるしかないのだ。

Aikido使命は、アプリケーションのセキュリティをできるだけ迅速かつ容易にすることであり、そのための最も重要な方法の1つは、開発者の時間を浪費し、セキュリティ修正プログラムの出荷を遅らせる原因となるノイズや偽陽性を減らすことです。
この記事では、アラート疲労症候群に苦しむ開発者にAikido どのような治療を提供しているかを紹介する。
ノイズを減らす
ケニー・ロジャースの有名な歌『ギャンブラー』は、それをうまく表現している:
"生き残る秘訣は、何を捨て、何を残すかを知っていることだ"
S/N比に最も大きな影響を与えることができるのは、開発者が行動を起こすべきCVEとセキュリティ警告だけを表示し、それ以外は無視することです。
ここでは、Aikido 無関係なセキュリティ警告やCVEをインテリジェントに無視する方法を紹介する:
開発のみの依存関係
デフォルトでは、Aikido は開発環境にのみインストールするようマークされた依存関係については、ステージング環境や本番環境には存在しないはずなので、脆弱性を報告しません。
無効なCVEまたは修正のないCVE
修正のないCVEを表示することは、単なる目くらましです。そのため、Aikido 、ダッシュボードに表示する前に、修正プログラムが利用可能になるまで、これらの問題を一時的に無視される問題のリストに移動します。

到達不能コード
Aikidoコード・インテリジェンスと到達可能性エンジンは、コード・ベースに脆弱な関数が呼び出されていなければ、CVEを無視する。

これにより、特にTensorFlowのような依存関係の多い大規模なライブラリのノイズが減少する。
期限切れまたは失効した秘密
Aikido 、期限切れや失効が確認された秘密、あるいは変数と思われる秘密を無視します。Aikido 、機密データを生成しない認可を必要とするAPIエンドポイントにリクエストを送ることで、既知のシークレットタイプの妥当性を安全に検証します。

マニュアル無視ルール
特定の条件下で脆弱性を無視するようにAikido 設定することができます。例えば、リポジトリ内の特定のパスの報告を無視することができます。

重複除去
ほとんどの企業は、複数の異なるソースからセキュリティ・インフラを組み合わせているため、複数のシステムで同じアラートやCVEが表示されることはよくあることです。さらに、従来のツールでは、1つのリポジトリ内で同じCVEが複数回表示されることもよくあります。ノイズについて話そう!
Aikido 、すべてのセキュリティ問題を単一のガラスペインで提供するオールインワン・プラットフォームであるため、各脆弱性の場所を一覧表示するサブ問題を含む各リポジトリの単一のCVEアラートのみが表示されます。

文脈に応じた感度調整でシグナルを高める
機密データを扱うリポジトリで発見されたセキュリティ問題は、データをまったく保存しない内部だけのリポジトリとは異なる方法で採点されるべきである。

Aikido 、各リポジトリに対して様々なコンテキスト指標を提供し、より多くのセキュリティリスクを発見し、問題の最終的な重大度スコアに適切な重み付けを行うことを支援する。
例えば、ドメイン名を追加することで、Aikido 、SSLの脆弱性、クッキーの誤設定、CSPが適用されている場合、クロスサイト・スクリプティング(XSS)攻撃などの問題を対象としたスキャンを実行することができる。
その他の文脈的な例としては、アプリケーションがインターネットにアクセスできるかどうかや、アプリケーションがどのような環境で展開されているかなどがある。
搾取リスクのシグナルを高める
Aikido 、リアルタイム指標を使用して、悪用の確認事例、悪用の実行方法を文書化した公開コード、特に脆弱となる可能性のある顧客固有のクラウドインフラストラクチャの懸念事項など、CVEが悪用される可能性を追跡する。
例えば、IMDS APIバージョン1を使用しているAWSインスタンスは、Aikido 認証情報を公開するSSRFエクスプロイトに対してより脆弱です。
概要
従来のセキュリティツールは、開発者の生産性を気にしない。偽陽性の山にリポジトリを埋没させ、実際にセキュリティ問題を解決するために費やすことができたはずの開発者の時間を浪費させることに満足しているのだ。
Aikido 他と違うのは、開発者の生産性とセキュリティの関連性に着目している点です。無関係なアラートやCVEを削除することで、本物の脅威がより注目されるようになり、その結果、修正がより迅速に適用されるようになります。
開発者とセキュリティの双方にメリットがあるこの方法こそ、私たちが目指しているものであり、お客様のセキュリティ・アラート疲労症候群を治療する方法なのです。
実際に使ってみませんか?サインアップして最初のレポをスキャンし、2分以内に最初の結果を得ましょう。

NIS2:誰が影響を受けるのか?
これはお客様からよくいただく質問です。NIS2指令の文言は必ずしも明確ではありません。NIS2は各国が実施する必要のある枠組みです。これは指令であって規則ではないため、EU各国は独自の解釈のもとでこれを展開する自治権を持っています。
NIS2の文言は幅広く、特に各国が具体的な内容を公表するまでは、その内容を理解するのは難しい。しかし、NIS2が現在どの企業に影響を及ぼしているのか、できる限り明確にお答えします。
AikidoのクイックNIS2セルフチェックで、スコープ内かどうかを確認する。
私たちは、現実的でわかりやすいことが好きです。そこで、NIS2の適用範囲内かどうかを確認するための簡単な5ステップのセルフチェックをご紹介します:
- 御社は「不可欠な」あるいは「重要な」産業に従事していますか?
- サブ・インダストリーに属しているかどうかをチェックする。
- サイズ要件に該当しますか?
- 1、2、3に「ノー」の場合は、自分が例外でないことを再確認する(プロからのアドバイス:念のため弁護士に相談する必要があるかもしれない)。
- そして、上記のすべてに「いいえ」の場合は、あなたの顧客が範囲内か、範囲外かを確認する。
NIS2は誰に適用されるのか?
NIS2が自社に影響を与えるかどうかを確認するために、2つの重要なパラメータがある:
- 業界必須」または「重要」な業界に属している場合。
- 規模:あなたの会社の規模が、従業員数がX人以上、売上高がXユーロ以上、貸借対照表がXユーロ以上など、特定の「必須」または「重要」の閾値を満たしている場合。
両者をさらに詳しく見てみよう。
NIS2はどのセクターに適用されるのか?
すべてはここから始まるNIS2は、必要不可欠で重要な産業の安全を確保するためのものである。NIS2は、最初のNIS指令の焦点であった産業の数を拡大している。NIS2は、必須と重要を区別しているが、どちらのカテゴリーもその範囲に含まれている。
基幹産業: エネルギー、飲料水、下水、輸送、銀行、金融市場、ICTサービス管理、行政、医療、宇宙。
重要産業:郵便・宅配便、廃棄物管理、化学、食品、製造業(医療機器、コンピューター・電子機器、機械・設備、自動車、トレーラー・セミトレーラー・その他輸送機器など)、デジタルプロバイダー(オンラインマーケットプレイスなど)、研究機関。
何があろうと即座にスコープに入るセクターもある。例えば、ドメイン名レジストラ、信託サービスプロバイダー、DNSサービスプロバイダー、TLD名レジストリ、電気通信プロバイダーなどです。
それ以上に、各国当局は、必要不可欠な部門や重要な部門に分類されない個々の企業を指定する権限を持つ。これは、その企業が唯一無二のサービスを提供し、大きな影響力を持ち、社会にとって不可欠であると判断された場合に可能となる。
NIS2の企業規模基準
NIS2にはサイズキャップ規定がある。つまり、一定の閾値を超えると指令に準拠する必要がある。
規模基準にとって不可欠で重要な企業とは?
- 必須企業: 従業員250名以上 OR 年間売上高5,000万ユーロ以上 OR 貸借対照表4,300万ユーロ以上
注:必須企業規模基準(上記)を満たさないが、重要企業規模基準(下記)を満たす企業は、重要企業とみなされる。従って、まだ適用範囲内である。 - 重要な企業 従業員50人以上 OR 年間売上高1000万ユーロ以上 OR 貸借対照表1000万ユーロ以上
つまり、表面的には、NIS2は中企業と大企業に適用され、中小企業や零細企業は除外されている。そして、中小企業や零細企業は除外されている。しかし、例外もある。例えば、ある企業が規模基準を満たさない場合、国家機関はセクター基準と同様に指定特権を行使することができる。
どの国が私のビジネスを管轄しているのか、どうすれば分かりますか?
欧州委員会は、『原則として、不可欠かつ重要な事業体は、その事業体が設立された加盟国の管轄下にあるとみなされる。事業体が複数の加盟国に設立されている場合は、各加盟国の管轄下に入るべきである』としている。
例外もある。場合によっては、その企業がどこでサービスを提供しているかを考慮する必要がある(例:DNSサービスプロバイダー)。他のケースでは、主要な事業所がどこにあるかが鍵となる(クラウド・コンピューティング・サービス・プロバイダーなど)。
ルールに他の例外はありますか?
もちろん、業種や規模の規定に関連するものもある。その上、各国がこの指令を実施し、地域ごとのルールが発効する(すべて2024年10月17日まで)ため、国ごとに注意すべき違いが出てくる。
例えば、規模要件は満たしていないが、加盟国の社会活動や経済活動にとって重要なサービスを提供する唯一のプロバイダーである場合も、NIS2を導入する必要があるかもしれない。
注:金融業界で活躍されている方であれば、デジタル・オペレーショナル・レジリエンス法(DORA)をすでにご存知でしょう。DORAは法律であり、NIS2のような指令ではないため、NIS2よりも優先される。まずはDORAに注力することをお勧めしますが、NIS2がEU加盟国によって国内法に移管された際には必ずご確認ください。
サイバーレジリエンス法(CRA)もお忘れなく。CRAは、EU市場に投入されるさまざまなハードウェアおよびソフトウェア製品に対するサイバーセキュリティ要件を定めている。これには、スマートスピーカー、ゲーム、OSなどが含まれる。
もう少し詳細をお聞きになりたいですか?
サイバーセキュリティ・ベルギーセンターが作成した、対象者の概要を紹介しよう:

NIS2が適用される顧客は、NIS2の影響を受ける可能性が高い。
NIS2にはサードパーティノックオン効果が含まれていることをご存知ですか?つまり、あなたが直接の適用範囲でなくても、あなたの顧客が適用範囲であれば、NIS2に準拠する必要がある可能性が高いということです。
NIS2を導入しなければならない企業は、「第三者プロバイダー」に関連する「リスクを管理・評価」する必要がある。これには、例えば、定期的なセキュリティ評価の実施、適切なサイバーセキュリティ対策の確保、NIS2要件への準拠を求める契約/合意の実施などが含まれる。
ですから、もしあなたがB2B企業で、業種や規模から対象外だと思っていたとしても、あなたの顧客がNIS2の対象になっているのであれば、準備を始めるべきです!
Aikido NIS2レポートを提供
Aikido セキュリティは、アプリで利用可能なNIS2レポート機能を作成しました。このレポートは、指令に準拠する必要がある企業を支援するために設計されています。

NIS2 の影響を受けそうですか?
NIS2 に関するあなたのアプリケーションの立ち位置を確認してください。
私たちのレポートは網羅的ではありませんが(技術的なセットアップのみを対象としています)、これを読めば正しい道を歩み始めることができます。
Aikido 登録すると、NIS2レポートを無料で入手できます!