1767068434
2025-12-29 15:21:00
Web アプリケーションのセキュリティの主な脆弱性とリスクのリストは、過去 10 年間ほとんど変わっておらず、攻撃ベクトルはセキュリティ専門家と開発者の両方によく知られています。しかし、解決策はすぐに入手でき、十分に文書化されているにもかかわらず、これらの問題は依然として存在します。
アプリケーションの開発および設計の責任者、セキュリティ管理者およびディレクターは、リスクが問題になるのを防ぐために、次の一般的な脆弱性のリストを参照する必要があります。 Web アプリのセキュリティ上の課題を特定し、それに対抗する方法について説明します。
アクセスと認証の問題
問題: Web アプリケーションはユーザーを認証し、セッションを確立して各ユーザーのリクエストを追跡します。認証資格情報、アクセス制御、および セッション識別子 アプリケーションが他の欠陥に対して脆弱なままになります。たとえば、攻撃者は盗んだ資格情報を使用してアクティブなセッションをハイジャックし、正規のユーザーの身元を偽ることができます。マルウェアまたはキーロギング ソフトウェアを導入する。またはデータへのアクセス、変更、削除。
解決: 行為 コードレビュー、認証、アクセス、セッション管理の問題を特定するための侵入テストと脆弱性スキャン。
強力な ID とアクセス管理を採用します (私は) 最小特権の原則の実装などのベスト プラクティスを含むプログラム (タコ)、ロールベースのアクセス制御を適用(RBAC)、MFA を要求し、ゼロトラスト セキュリティを採用します。強い体制を確立する パスワードポリシー、失敗したログイン試行を制限し、アクセス制御を監査し、 ユーザー権限を確認する 定期的に。
例: 安全でない直接オブジェクト参照 (IDOR)
IDOR は、アプリケーションまたは API がユーザー ID やファイル名などの参照を公開し、攻撃者が他のユーザー ID やファイル名を推測できるようにするときに発生します。たとえば、ユーザーのアカウント ID がページ URL (https://example.com/user/12345 など) に表示されている場合、攻撃者は別のユーザーの ID を推測し、他の正当なユーザーのデータにアクセスするリクエストを再送信しようとする可能性があります。 IDOR の脆弱性により、不正アクセス、権限昇格、データの盗難や操作が発生します。
IDOR を防ぐには、次の手順を実行します。
- ランダムで予測不可能な一意の識別子とファイル名とオブジェクト名を使用します。オブジェクトの実際の名前は決して公開しないでください。
- ユーザーがアクセスする各オブジェクトにアクセス制御チェックを実装します。
- セッション管理を使用して、ユーザーが自分自身を再認証するまでに自分のアカウントにアクセスできる時間を制限します。
インジェクション攻撃とコード実行攻撃
問題: インジェクション攻撃は、Web アプリケーションの脆弱性の中で最も一般的で、最も深刻なものの 1 つです。この問題は、攻撃者が慎重に作成したデータを使用してアプリケーションを騙し、意図しないコマンドを実行したり、不正なデータにアクセスしたりするときに発生します。
インジェクション攻撃の種類には、SQL インジェクション (SQLi)、OS インジェクション、電子メール インジェクション、LDAP インジェクション、プロンプト インジェクション、クロスサイト スクリプティング (XSS)。
解決: 脆弱性およびペネトテスト、脆弱性スキャナーおよびソース コード アナライザーを使用して、インジェクション脆弱性を検出します。
射出欠陥を防ぐには、次の手順を実行します。
- ユーザー入力を検証します。 ユーザーがフォーム、URL、Cookie、またはアプリケーションのデータベースを介して送信したデータはすべて信頼できないと想定します。厳密な検証関数を使用して、データが予想される形式と一致していることを確認します。
- HTML が必要な場合は、ユーザー入力をサニタイズします。 HTML サニタイザーを使用して、ブラウザーでレンダリングする前に、ユーザーが送信したデータから潜在的に悪意のあるコードをクリーンアップおよび解析します。
- ユーザー入力をエスケープします。 、”、& などの特定の文字を、コンテキスト認識エンコーディングを使用した安全なテキスト表現に置き換えて、コードとして解釈されたり実行されたりしないようにします。
- コンテンツセキュリティポリシーを実装します。 Web サイトへのロードを許可するスクリプトやスタイルなどの特定のリソース、およびそのソースと場所を定義します。
例: SQLi
SQLi 攻撃では、悪意のある攻撃者は、ユーザーが指定したデータが有効であるかどうかを最初にチェックせずに、それを使用して SQL クエリを利用します。したがって、攻撃者は悪意のある SQL クエリを送信し、コマンドを SQL データベースに直接渡すことができます。
上記の防止に関するアドバイスに加えて、ストアド プロシージャをトランザクションの実行に絶対に必要なものだけに制限してください。また、Cookie には HTTPOnly フラグを使用します。これにより、クライアント側のスクリプトが Cookie にアクセスできなくなり、XSS 攻撃の影響が軽減されます。
例: XSS
XSS 攻撃は 40 年近く前から存在しています。この攻撃では、悪意のある攻撃者がコード (通常は JavaScript などのクライアント側スクリプト) を Web アプリケーションの出力に挿入することにより、アプリケーションのユーザーをターゲットにします。ユーザーが侵害された出力または Web ページを表示すると、ブラウザが実行され、攻撃者がユーザー セッションをハイジャックできるようになります。ユーザーを悪意のあるサイトにリダイレクトします。ウェブサイトを改ざんする。ユーザーの Cookie、閲覧履歴、その他の機密データを盗みます。
XSS 攻撃は、同一生成元ポリシー (ある Web サイトで生成されたスクリプトが別のサイトのスクリプトと対話することを防ぐセキュリティ メカニズム) を回避します。
例: 即時注入
攻撃者が使用する プロンプトインジェクション攻撃 これには、直接プロンプト インジェクション、間接プロンプト インジェクション、ストアド プロンプト インジェクション、およびプロンプト リークが含まれます。AI ツールをだまして、通常は共有しない情報を開示させます。たとえば、攻撃者はダイレクト プロンプト インジェクション攻撃を使用して大規模な言語モデルをだます可能性があります (LLM) システムの API キーまたはシークレットを共有します。
プロンプト挿入の欠陥を防ぐには、プロンプトが AI および LLM の保護手段をバイパスまたはオーバーライドできないようにし、AI ツールと LLM に許可されるユーザー プロンプトの長さを制限します。
API とアーキテクチャの課題
問題: API は、データとサービスがどのように相互作用し、企業、そのパートナー、顧客の間で提供されるかの鍵となります。 API の実装が不適切であったり、セキュリティ対策が欠けていたりすると、攻撃やデータ損失が発生する可能性があります。
解決: に APIのセキュリティリスクを軽減する、次の操作を行います。
- API へのアクセスを制御します。 業界標準を使用して API トラフィックを認証し、POLP に従い、ゼロトラスト セキュリティ モデルを採用します。
- データを検証します。 入力を解析して検証することで、悪意のある入力を回避します。決して生データを受け入れないでください。
- API の文書化とテスト。 API レジストリを作成して、使用中のすべての API を文書化します。これも役立ちます シャドウ API を防止する。リスク評価を実施して既知の脆弱性を評価し、定期的なセキュリティ テストを実行して API の安全性を確保します。
- API キー管理のベスト プラクティスに従ってください。 API キーを慎重に管理および保護し、キーを定期的にローテーションします。
- データの漏洩を防ぎます。 データ損失防止ツールを使用して、データの過剰共有を監視および検出します。
例: 壊れたオブジェクトレベル認証 (BOLA)
BOLA は、アプリまたは API がオブジェクトに対するアクセス制御を適切に実施できず、攻撃者がアクセスすべきではないデータにアクセスしたり、データを変更したりできる場合に発生します。この脆弱性により、データ損失やデータ操作が発生する可能性があります。
BOLA 関連の攻撃を防ぐには、次の手順を実行します。
- オブジェクトレベルの認可、RBAC、POLP などの強力な認可と認証を実装します。
- ランダムで予測不可能な一意の識別子を使用します。
- フォローする 安全な API 設計のベスト プラクティス。
- BOLA の欠陥がないか API をテストします。
例: 不適切に構成されたクロスオリジン リソース共有 (CORS)
CORS は、Web アプリケーションが他のドメイン、プロトコル、ポートからリソースを安全に要求できるようにするメカニズムです。 CORS が不適切に構成されていると、クロスサイト リクエスト フォージェリ攻撃、データ漏洩、不正アクセスが発生する可能性があります。
CORS の構成ミスを防ぐには、次の手順を実行します。
- ホワイトリストを使用する 制限されたリソースにアクセスできるサーバーを制限します。
- カスタム ヘッダーを実装して、サーバー間の CORS リクエストのヘッダーの数と種類を制限します。
- CORS 構成を定期的にテストおよび監査します。
構成ミスとサプライチェーンのリスク
問題: Web アプリケーションをサポートするインフラストラクチャは、サーバー、ファイアウォール、データベース、OS、アプリケーション コンポーネントなど、さまざまなデバイスとソフトウェアで構成されます。このインフラストラクチャを保護することは非常に重要です。同様に重要なのは、組織のパートナーやサプライヤーを含むサードパーティのインフラストラクチャのセキュリティです。
ハードコードされたまたはデフォルトのシークレットおよび資格情報の使用、不要な機能の有効化、侵害されたコンポーネントまたは脆弱なコンポーネントの使用、サードパーティ ソフトウェアの脆弱性、Web アプリの誤解など、いくつかの構成ミスが Web アプリのセキュリティを妨げる可能性があります。 責任共有モデル、内部関係者の脅威など。
解決: 定期的に脆弱性テスト、侵入テスト、セキュリティ監査、依存関係スキャンを実行して、根本的な構成ミスを発見して修正します。
構成ミスを防ぐには、次の手順を実行します。
- 安全な開発のベスト プラクティスを採用します。
- 定期的に システムのアップデートとパッチ適用。
- ライブラリを定期的に監視します。
- 未使用の依存関係とコンポーネントを削除します。
- サードパーティのリスクを監視します。
- デフォルトの認証情報とパスワードを変更します。
- POLP や RBAC を含む強力な IAM を実装します。
- の作成と更新 企業ソフトウェア部品表 (SBOM) 使用中のすべてのソフトウェアとライブラリを文書化します。
例: 古くて脆弱な社内およびサードパーティのインフラストラクチャ
脆弱なまたは古いソフトウェア ライブラリ、フレームワーク、ソフトウェア (OS、API、ランタイム環境など) を使用すると、アプリケーションは、パフォーマンスや信頼性の問題だけでなく、データ侵害、データ損失、権限昇格、リモート コード実行、コンプライアンス違反、インシデント対応の遅れなどのリスクにさらされたままになります。
これは、企業によって導入されたソフトウェア (オープンソースおよび商用) だけでなく、企業のサードパーティによって導入されたソフトウェアにも当てはまります。
上記のアドバイスに加えて、すべてのオープンソース コードとサードパーティ コードを実装する前に、サンドボックス環境でテストしてください。また、サードパーティ ベンダー、インテグレーター、サービス プロバイダー、パートナー、コンサルタントからの SBOM も要求します。
データセキュリティの問題
問題: Web アプリケーションを悩ませる一般的なデータ セキュリティ問題には次のようなものがありますが、これらに限定されません。
- パスワードや機密データを平文で保存し、データベースのセキュリティが不十分であるなど、安全でないデータ ストレージ。
- 情報漏洩などのデータ漏洩、 ディレクトリトラバーサル URL 内の機密データ。
- 弱い暗号化、不十分なキー管理、安全でないデータ送信など、データ保護が不十分です。
解決: これらの問題を防ぐには、次のベスト プラクティスを考慮してください。
- 付着する 設計によるセキュリティの原則。
- 暗号化のベスト プラクティスに従ってください。
- 保存する前にパスワードをハッシュ化します。
- フォローする データベースセキュリティのベストプラクティス。
- データベースへのアクセスについては POLP に従ってください。
- 機密データを適切に分類して処理します。
- 強力な最新の暗号化アルゴリズムを使用します。
- 安全な鍵管理慣行に従ってください。
- HTTPS や TLS などの安全なデータ送信プロトコルを使用します。
Ravi Das は、IT サービス プロバイダーのテクニカル エンジニアリング ライターです。彼は個人事務所 ML Tech, Inc. のサイバーセキュリティ コンサルタントでもあり、ISC2 の Certified in Cybersecurity (CC) 認定を取得しています。
Sharon Shea は、Informa TechTarget の SearchSecurity サイトのエグゼクティブ エディターです。
#Web #アプリのセキュリティの主な脆弱性とその軽減方法