私たちは、Aikido ユーザが直面する、重大なウェブアプリケーションのセキュリティ脆弱性のトップ 3 を特定しました。このガイドでは、これらの脆弱性が何であるか、なぜ一般的であるか、そしてどのように修正するかについて概説します。
早期に効果的に対処することで、ウェブアプリケーションをサイバー犯罪に対して安全に保つための戦いにおいて、すでに先手を打つことができるだろう。
1.最も一般的で重大なコードの脆弱性（SAST）
静的アプリケーション・セキュリティテスト（SAST）は、開発サイクルの早い段階で、ソースコードに脆弱性がない かスキャンするテスト手法です。アプリケーションの動作がテスト者に知られているため、ホワイトボックス手法と呼ばれています。
NoSQLインジェクション攻撃（コードの脆弱性：SAST）
NoSQL インジェクションは、データの漏えい、データベースの破損、さらにはシステムの完全な侵害につながる可能性があります。悲しいことに、これは重大なウェブ・アプリケーション・セキュリティの脆弱性であり、私たちは多くのAikido ユーザー・アカウントがこの脆弱性にさらされているのを見てきました。
NoSQLインジェクションとは？
NoSQLインジェクションは、ハッカーが悪意のあるコードを使用してNoSQLデータベースを操作したり、不正にアクセスしたりする攻撃の一種です。SQLデータベースを標的とするSQLインジェクションとは異なり、NoSQLインジェクションはMongoDBのようなNoSQLデータベースの脆弱性を悪用します。データ漏洩、破損、あるいはデータベースの完全な制御を引き起こす可能性がある。
なぜこのような脆弱性が多発するのか？
NoSQLデータベース、特にMongoDBの人気が高まっていることもあり、NoSQLインジェクションが一般的になっている。これらのデータベースはパフォーマンス上の利点がありますが、セキュリティ上のユニークな課題があります。
その上、NoSQLデータベースはXMLやJSONのような様々なフォーマットを受け入れるという点で柔軟性がある。この柔軟性は素晴らしいものですが、標準的なセキュリティチェックではこれらの形式に合わせた悪意のある入力を検出できない可能性があるため、ウェブアプリケーションのセキュリティ脆弱性につながる可能性があります。
また、膨大な数のNoSQLデータベースがあり、それぞれが独自の構文と構造を持つため、普遍的な安全策を作ることも難しくなっている。セキュリティ専門家は、各データベースの具体的な詳細を理解する必要があり、それが防止プロセスに複雑さを加えている。
さらに悪いことに、従来のSQLインジェクションとは異なり、NoSQLインジェクションはアプリケーションのさまざまな部分で発生する可能性があります。そのため、検出はさらに難しくなります。
どうすればこの脆弱性を簡単に修正できるのか？
入力検証とパラメータ化されたクエリを使用する。入力バリデーションは、ユーザの入力が期待される型やフォーマットと一致することを保証し、安全でない値を拒否します。パラメータ化されたクエリは、検証されていない入力の埋め込みを防ぎます。
一般的に、認証や暗号化などのデータベース・セキュリティ機能を常に実装すること。常に最新のパッチを適用すること。そして、コードや設定の定期的な監査を実施し、この脆弱性やその他の脆弱性を特定して修正するようにしてください。
次点コード内に危険なデバッグ関数を残す（コードの脆弱性：SAST）
公開されたデバッグ関数は、攻撃者がシステムを悪用するための偵察を可能にする。
危険なデバッグ関数とは？
phpinfo() のようなデバッグ関数は、サーバーや環境に関する機密情報を公開する可能性があります。これには、PHP のバージョンや OS の詳細、サーバーの情報、 そして秘密鍵を含む環境変数までが含まれます (そもそも、秘密鍵をそこに置くことはお勧めしませんが!)。
その結果、これらのデバッグ関数を使用してファイルシステムの構造を検出すると、 サイトが脆弱な場合にハッカーがディレクトリトラバーサル攻撃を行う可能性があります。phpinfo() を単独で公開することは、必ずしもリスクが高いわけではありませんが、 攻撃者にとっては若干容易になります。原則は明確で、ハッカーがあなたのシステムに関する具体的な情報を持っていないほうがよいということです。
なぜこのような脆弱性が多発するのか？
このウェブ・アプリケーション・セキュリティの脆弱性は、開発者がこれらの関数をデバッグのために使い、時には、トラブル シューティングのために、本番環境にも適用してしまうために、しばしば発生します。急ぎのリリース、コードレビューの不足、リスクの過小評価、これらすべてが、これらの関数を露出したままにする一因です。
どうすればこの脆弱性を簡単に修正できるのか？
- コードレビュー：本番環境にデプロイする前に、定期的にコードをチェックし、デバッグ関数を特定して削除する。
- 自動脆弱性スキャンツール：危険なデバッグ関数を検出できるAikidoようなツールを使う。
- 環境固有の設定：本番環境ではデバッグ機能を無効にしてください。
2.最も一般的で重要な DAST の脆弱性
動的アプリケーション・セキュリティテスト（DAST）は、実行中のアプリケーションの脆弱性を特定するテスト技 術です。観察可能な動作だけに焦点を当てるので、ブラックボックス手法と呼ばれます。DAST は、攻撃者にとって、システムがどのように見えるかを示します。
主要なセキュリティヘッダを忘れる：HSTSとCSP（クラウドの脆弱性：DAST）
HSTSとCSPが適切に実装されていないため、ウェブアプリケーションはXSSや情報漏えいといった主要な攻撃に対して脆弱なままとなる。
CSPとは？
コンテンツ・セキュリティ・ポリシー（CSP）は、クロスサイト・スクリプティングやクリックジャッキングのような、様々なブラウザベースの攻撃を打ち負かすのに役立つセキュリティ・メカニズムである。インラインJavaScriptや安全でないeval()関数など、ウェブページにおける危険な動作を制限することでこれを実現します。CSPは、コンテンツの完全性と機密性を維持するために、より安全なデフォルトを強制します。主な利点は、スクリプトの悪意のあるインジェクションから保護することです。
このDASTの脆弱性はなぜ一般的なのか？
HSTSとCSP、特にCSPを軽視することはよくあることで、開発者はこれらのヘッダーよりも機能を優先することが多い。
CSPは開発の早い段階で計画すべきだが、見過ごされることが多い。そして、開発者が後からCSPを実装したり、後付けしようとすると、コンフリクトを引き起こすため、CSPを完全にスキップして他の作業に取り掛かる。このため、アプリは無防備なまま放置され、さまざまなウェブ・アプリケーション・セキュリティの脆弱性にさらされることになる。
DASTの脆弱性を簡単に修正するには？
- HSTSを導入してHTTPSのみの接続を強制する。設定ファイルまたはWAFを使用してサーバー上で有効にする。
- インライン・スクリプトのような安全でないプラクティスを制限することで、アプリに合わせた厳格なCSPを定義し、適用する。互換性を慎重にテストする。
- アプリの進化に合わせてヘッダーを継続的に監視・更新し、保護を維持する。
3.最も一般的で重要なクラウドの脆弱性（CSPM）
クラウド・セキュリティ・ポスチャ管理（CSPM）ツールは、クラウド・ベースの環境を継続的に監視し、セキュリティ標準とベスト・プラクティスへの準拠を保証する。CSPMツールは、セキュリティの設定ミスを探し、リスクを軽減することを目的としている。
EC2のIAMロールがSSRF攻撃に脆弱なままになっている（クラウド：CSPM）
オープンなEC2のIAMロールは、攻撃者がクラウド環境を横方向に移動し、不正にアクセスすることを頻繁に可能にする。この種の攻撃の潜在的な影響は壊滅的なものになる可能性がある。
EC2 IAMロールとは？
Amazon Web Services（AWS）のEC2 IAM（Identity and Access Management）ロールは、特定のリソースに対して許可されるアクションを決定する権限を委譲する。これにより、EC2インスタンスは、インスタンス自体に認証情報を直接保存することなく、他のAWSサービスと安全にやり取りできるようになる。
SSRF攻撃とは？
サーバー・サイド・リクエスト・フォージェリ（SSRF）攻撃とは、攻撃者がサーバーに、あたかもサーバー自身が要求しているかのように、内部リソースへのリクエストを行わせるものです。攻撃者は、この方法で権限のないシステムにアクセスしたり、制御をバイパスしたり、コマンドを実行したりする可能性があります。単純なメール送信フォームからSSRF攻撃がスタートアップのクラウドを乗っ取った恐ろしい例をご覧ください。
なぜこのCSPMの脆弱性が一般的なのか？
EC2 IAMロールは通常、セキュリティの設定ミスや過度に寛容なロールのために、SSRF攻撃に対して脆弱なままになっている。複雑なクラウドのパーミッションを調整するのは難しく、開発者の中にはリスクを十分に理解していない人もいるだろう。その上、サービスを円滑に連携させたいがために、本当に必要なアクセス権よりも多くのアクセス権を付与してしまうこともある。
どうすればこのCSPMの脆弱性を簡単に修正できるのか？
EC2のロールに取り組み、SSRFのウェブ・アプリケーション・セキュリティの脆弱性を軽減するための確実な方法がいくつかある。まず第一に、最小特権の原則に忠実であること - 絶対に必要なアクセスだけを許可し、それ以上は許可しないこと。過度に寛容なロールはトラブルの元だ。
次に、セキュリティグループやネットワークACLのようなAWSのビルトインツールを利用して、トラフィックをロックダウンし、SSRF攻撃の潜在的な隙を減らす。アクセスを制限できればできるほど良い。
また、定期的にロールを見直し、監査することで、時間の経過とともに変化する不要なアクセスを発見することも重要です。常に把握しておくこと。
そして最後に、SSRF 攻撃が被害をもたらす前に検知し防止することに特化した AWS セキュリティツールを導入する。保護のレイヤーが多ければ多いほど、安全性は高まります。
次点：時代遅れのクラウド・ラムダ・ランタイム（クラウド：CSPM）
これらの実行環境が古くなると、ラムダ関数が攻撃者にさらされる可能性がある。
時代遅れのラムダ・ランタイムとは？
時代遅れのラムダ・ランタイムとは、サーバーレス関数（ラムダ）で古いバージョンのプログラミング言語や環境を使用することを指す。これらの古いランタイムは、最新のセキュリティパッチや機能アップデートが適用されていない可能性があり、アプリケーションを既知のWebアプリケーションセキュリティの脆弱性にさらす可能性があります。
なぜこのCSPMの脆弱性が一般的なのか？
この脆弱性は、しばしば「セット・アンド・フェザー（セットして忘れる）」という考え方から生じる。開発者は、特定のランタイムでラムダをデプロイし、新しいバージョンがリリースされたときにそれらをアップデートすることを怠るかもしれない。また、クラウド・プロバイダーがすべてのメンテナンスを行ってくれると思い込んでしまうこともある。AWSやGoogle Cloud Functionsは、OSのマイナーパッチでランタイムをメンテナンスしてくれるが、主要な言語のアップグレードはしてくれない。その上、複数のラムダを管理する複雑さから、古くなったランタイムが抜け落ちやすくなり、余計なリスクが発生する。
どうすればこのCSPMの脆弱性を簡単に修正できるのか？
3つのシンプルなルールに従うことで、リスクを軽減することができる：
- 使用されているランタイムを定期的に確認し、アップデートがないかチェックする。
- セキュリティパッチが適用された最新のサポートバージョンにアップグレードする。
- 可能であれば、自動化ツールを使用してランタイムを管理・更新する。
Webアプリケーション・セキュリティの脆弱性とベストプラクティス
これらのウェブ・アプリケーション・セキュリティの脆弱性を理解することは、システム・セキュリティのために不可欠ですが、ベスト・セキュリティ・プラクティスに従うことを忘れないでください。最新の状態を維持し、適切な修正プログラムを適用し、定期的な監視を行うことで、安全でセキュアな環境を維持しましょう。
今すぐAikido あなたの環境をスキャンして、これらの脆弱性にさらされていないか調べてみましょう。
Aikido「2024 SaaS CTOセキュリティ・チェックリスト」で、人材、プロセス、コード、インフラなど、セキュリティ向上のための40以上の方法について簡潔なアドバイスをご覧ください。
.jpg)
.avif)
