Web アプリケーションの中核となる防御メカニズムは何ですか?

#悪意のある入力を防ぐために、アプリケーションは多数のセキュリティ メカニズムを実装しています。これらのセキュリティ メカニズムは概念的には似ています。

これらのセキュリティ メカニズムは次の側面で構成されます:

1. Web アプリケーションのデータおよび機能へのユーザー アクセスの処理 (不正アクセスの防止)

# 2. Web アプリケーション機能にユーザーが入力したデータの処理 (悪意のあるデータの構築の防止)

3. 攻撃への対応 (予期しないエラー報告の処理、明らかな攻撃の自動ブロック、管理者へのアラートの自動送信、メンテナンス)プログラム アクセス ログ)

4. アプリケーションの管理とメンテナンス

処理アクセス

通常、アプリケーションには、一般ユーザーなど、さまざまなタイプのユーザーが存在します。ログインしてユーザーと管理者を確認します。ユーザー Web アプリケーションごとに異なる権限が与えられるため、異なるデータと機能のみにアクセスできます。

Web アプリケーションは、相互に関連する 3 つのセキュリティ メカニズムを通じてユーザー アクセスを処理します:

1. 認証

2. セッション管理 (セッション管理)

3 . アクセス制御

これら 3 つのメカニズムは、アプリケーションへのユーザー アクセスを処理し、3 つの攻撃対象領域でもあります。)、これら 3 つは相互に依存しており、不可欠です。どこに問題があっても、不正アクセスは発生します。が発生します（バレル原理）。

認証

認証はユーザー アクセスを処理する最初のメカニズムです。Web サイトにユーザーが 1 人しかいない場合を除き、認証を使用する必要があります。

今日のほとんどの Web アプリケーションは、従来の認証モデル、つまりユーザー名とパスワードを使用しています。

銀行業務などのより高いセキュリティ要件があるアプリケーションでは、このモデルを強化するために他の証明書、2 要素認証などが使用されます。より高いセキュリティ要件があるアプリケーションでは、クライアント証明書、スマート カード、またはクエリが使用される場合があります。必須 - 応答メカニズムとその他の認証モデル。

認証メカニズムでは、多くの場合、登録、パスワードの忘れ、パスワードの変更など、他の一連のサポート機能が必要になります。

認証メカニズムには、ユーザー名のトラバーサル、脆弱なパスワード、ログインを回避する論理的欠陥、ソーシャル エンジニアリング データベース クエリなどの一般的な脆弱性がいくつかあります。

セッション管理

検証に合格したら、ユーザーのセッションを管理します。アクセス制御を実装するには、アプリケーションはさまざまなユーザーによって送信されたさまざまなリクエストを識別する必要があります。これを行うには、アプリケーションは各ユーザーのセッションを確立し、セッションを表すトークン、つまりセッション トークンをユーザーに送信する必要があります。ユーザー。セッション自体は、ユーザーとアプリケーション間の対話状態を追跡する、サーバーに保存される一連のデータ構造です。

セッション トークンは通常、Cookie で渡され、非表示のフォーム フィールドまたは URL クエリ文字列に表示されることもあります。セッション トークンは、リクエストを停止してから一定期間内に期限切れになります。

一部のアプリケーションでは、セッションの識別にセッション トークンを使用せず、代わりにユーザー証明書を繰り返し送信することでセッションを識別します (これは http の組み込み認証メカニズムの場合であり、base64 で暗号化されたアカウント パスワードを繰り返し送信することでセッションを識別します) ）。セッション情報はサーバーではなくクライアントに保存される場合があり、ユーザーによる変更を防ぐために、通常は暗号化されます。

セッション管理の攻撃面はセッショントークンそのものであり、セッショントークンの生成ルールを推測したり、他のユーザーのセッショントークンを傍受したりすることで、他人になりすまして不正な機能やデータにアクセスすることができます。

アクセス制御

以前の認証とセッション管理が正常に実行されている場合、アプリケーションは各リクエストのセッション トークンを通じて各ユーザーの ID と対話ステータスを確認できるため、ユーザーのリクエストに同意するため。

一般的なアクセス制御の要件は比較的複雑であるため、各役割には異なる権限があり、各ユーザーはアプリケーション内のデータと機能の一部にしかアクセスできません。このメカニズムには抜け穴があり、将来の承認されたアクセスを引き起こす可能性があります。

入力の処理

すべてのユーザー入力は信頼できません。Web アプリケーションに対するほとんどの攻撃は、攻撃者によって特別に構築された入力に関連しています。したがって、ユーザー入力を安全に処理することが、アプリケーションのセキュリティを確保する鍵となります。キープログラムのセキュリティに。

入力の多様性

Web アプリケーションは、長さ制限、文字制限など、一部の特殊な入力に対して非常に厳密なチェックを実行する場合があり、場合によっては、ユーザーが送信した入力を受け入れる必要がある場合があります。 ; ただし、非表示のフォーム フィールドと Cookie はサーバー上で生成されてクライアントに送信され、ユーザーのリクエストによってサーバーに送信されるため、このプロセス中に攻撃者はそれらを表示および変更できます。

入力処理方法

状況に応じて異なる処理方法を使用したり、組み合わせて使用​​したりできます。

1. ブラックリスト

ブラックリストには、攻撃に使用される文字列またはパターンのセットが含まれており、ブラックリストに一致するすべてのデータがブロックされます。

ブラックリストは、入力確認の最も効果の低い方法です。理由は 2 つあります:

1) ユーザー入力は、同じ効果を持つ一部の文字の欠落など、さまざまなエンコーディングや他の形式の表現によってバイパスされる可能性があります。たとえば、alert('xss') がブロックされている場合、prompt('xss') を使用することもできます。たとえば、Web アプリケーション ファイアウォールはヌル バイト (null) 攻撃の対象となることがよくあります。これは、マネージド ファイアウォールでは文字列が異なる方法で処理されるためです。そして管理不能な状況。

2) テクノロジーの急速な発展により、脆弱性を悪用する新しい方法がいくつか生まれました。

2. ホワイトリスト

ホワイトリストには、無害な文字列、パターン、または標準のセットが含まれています。ホワイトリストに一致しないデータはすべてブロックされます。

ホワイトリストを指定すると安全な文字列のみが残され、攻撃者が入力を構築できないため、ホワイトリストは入力確認に最も効果的な方法です。

ただし、ホワイトリストには制限があります。多くの場合、Web アプリケーションでは、セキュリティ標準を満たさない一部の文字を受け入れる必要があります。たとえば、アプリケーションではユーザーが実名で登録する必要がありますが、名前にはデータベースへの攻撃を引き起こす可能性のあるハイフン、アポストロフィ、その他の文字が含まれています。 。したがって、ホワイトリストには制限があり、安全でない入力に対する普遍的な解決策ではありません。

3. 浄化

このメソッドは、ホワイト リストでは処理できない問題を解決します。セキュリティを保証できない一部のデータ入力は受け入れますが、削除、エスケープ、エンコーディング、および暗号化などのデータ入力を浄化します。その他

浄化は一般的な方法として使用できますが、入力項目が複数の可能性のある悪意のあるデータに対応する必要がある場合、効果的に進化させることができることに注意してください。この場合には境界確認が必要となります。

4. 安全なデータ処理

ユーザーが送信したデータを安全でない方法で処理することが、多くの Web アプリケーションの脆弱性の根本原因です。

安全なデータ処理方法では、ユーザー入力データの確認を気にする必要がなく、処理プロセスの絶対的な安全性が保証されます。たとえば、SQL インジェクションを防ぐためのパラメータ化されたクエリ。

ただし、この方法は、Web アプリケーションが実行する必要があるすべてのタスクに適用できるわけではありません。該当する場合は、悪意のある入力を処理するための一般的な方法です。

5. ロジックチェック

一部の脆弱性では、攻撃者の入力と通常のユーザーの入力はまったく同じですが、動機が異なります。この場合、上記のメカニズムはほぼ完全に当てはまります。効果がない。たとえば、他のユーザー アカウントにアクセスするために、非表示のフォーム フィールドを変更して送信されたアカウントを攻撃します。現時点では、どれだけ入力を確認しても、攻撃者のデータと通常のユーザーのデータを区別することはできません。不正アクセスを防ぐために、アプリケーションは、送信されたアカウントが以前にアカウントを送信したユーザーに属していることを確認する必要があります。

境界確認

核心的なセキュリティ問題の性質 (すべてのユーザー入力が信頼できない) を考慮すると、インターネット (信頼できない) とサーバー アプリケーション (信頼できる) の間の境界を境界として使用できます。次に境界でインターネットからのすべての入力をサニタイズし、サニタイズされたデータをサーバー アプリケーションに渡します。以上は簡易的な境界確認ですが、実際の脆弱性を解析すると、この単純な入力確認だけでは十分ではないことが分かりました。

アプリケーション実行機能の広範さと使用されるテクノロジーの多様性に基づいて、一般的なアプリケーションは、多数のさまざまな入力攻撃から防御する必要があり、それぞれがまったく異なる特殊な設計データを使用する可能性があるため、すべての攻撃を防御するための単純なメカニズムを外部境界に確立することは困難です。

多くのアプリケーション機能は、一連の異なるプロセスを組み合わせるように設計されており、1 つのユーザー入力により多くのコンポーネントで多くの操作が実行され、前の操作の出力が次の操作で使用されます。データは変換され、元の入力とはまったく異なります。ただし、経験豊富な攻撃者はこの違いを利用して、重要なステップで悪意のあるデータを生成し、データを受け取るコンポーネントを攻撃する可能性があります。したがって、すべての攻撃を防御するための単純なメカニズムを外部境界に確立することは困難です。

境界確認はより効果的なモデルです。ここでの境界は、インターネットと Web アプリケーションの境界に限定されるものではなく、Web アプリケーションの各コンポーネントや機能単位にも境界があります。このようにして、各コンポーネントは、受信する特別に設計された特定の種類の入力に対して自身を防御できます。データが異なるコンポーネントを通過する場合、以前に生成されたデータに対して検証チェックを実行できます。また、異なる検証チェックが処理の異なる段階で実行されるため、それらの間で競合が発生する可能性はありません。

例:次の図:

複数ステップの確認と標準化

確認チェックプロセスで、必要な場合ユーザーが入力を行う場合、入力メカニズムで頻繁に発生する問題が発生します。この問題は、アプリケーションが特定の文字を削除またはエンコードしてユーザー入力をサニタイズしようとすると発生します。この問題に慎重に対処しないと、攻撃者が特殊な入力を構築して悪意のあるデータが確認メカニズムを回避できる可能性があります。たとえば、二重書き込みバイパスやステップ実行順序バイパスなどです。

データの正規化により、別の問題が発生します。 http 経由で一部の一般的ではない文字やバイナリデータを送信する場合、通常はエンコードによって正規化されますが、フィルタリングを実装した後にデコードを行うと、攻撃者はエンコードによる確認の仕組みを回避できます。

Web アプリケーションで使用される標準のエンコード スキームに加えて、アプリケーションのコンポーネントがある文字セットから別の文字セットにデータを変換する場合にも、正規化の問題が発生する可能性があります。たとえば、Ÿ と Â は Y と A に変換されます。攻撃者は、ブロックされた文字やキーワードを送信するためにこの方法をよく使用します。

複数段階の確認と標準化によって引き起こされる問題を回避することが難しい場合があり、そのような問題に対する単一の解決策はありません。一般に、不正な入力のサニタイズを回避し、代わりにそのような入力を完全に拒否するにはどうすればよいでしょうか。

攻撃への対応

攻撃者の侵入を防ぐために最善を尽くしてきましたが、完全に安全なシステムは存在しません。セキュリティ インシデントが発生した場合、Web アプリケーションは攻撃にどのように対応すべきでしょうか?対処方法は何ですか? 一般的には次のとおりです:

1. 予期せぬエラー報告を処理する

2. 明らかな攻撃を自動的にブロックする

3. 自動的に送信する管理者への警告

4. プログラム アクセス ログの維持

##エラーの処理##アプリケーションの重要なメカニズムは、予期しないエラーを処理する方法です。 。一般に、運用環境では、アプリケーションはシステム生成情報やその他のデバッグ情報をユーザーに返すべきではありません。この情報は、攻撃者に次の攻撃のための適切な参考情報を提供します。また、予期しないエラーは、プログラムの防御メカニズムに何らかの欠陥があることを示していることがよくあります。エラー処理メカニズムは、多くの場合、ログ メカニズムと統合されています。

攻撃への対応

多くの攻撃では、一般的な悪意のある文字が大量に送信されるため、アプリケーションは攻撃者が検出できないように自動応答対策を講じる必要があります。たとえば、セッションの終了、再ログインの要求、IP の禁止などです。

メンテナンス ログ

ログには侵入状況が記録され、侵入プロセスは次のようなことができます。侵入後も復元可能です。

重要なアプリケーション ログにはすべてのリクエストが記録される必要があります。一般に、少なくとも次の項目を含める必要があります:

1. ログインの成功または失敗、パスワード変更などのすべての認証関連イベント

2. 主要な操作など転送など

3. アクセス制御によってブロックされたリクエスト

4. 既知の攻撃文字列を含む

ログには、時間、IP、ユーザー アカウントが記録されます。ログは不正な読み取りから厳重に保護する必要があります。

#ログの書き込み、変更なども攻撃対象になります。たとえば、許可なくアクセスできるログは、セッション トークンやリクエスト パラメーターなどの機密情報を攻撃者に提供します。

管理者への警告

中心的な問題は誤検知と誤検知です。警告メカニズムと確認メカニズムやその他の制御方法を組み合わせることで、いくつかの改善を達成できます。

一般的に、監視される異常イベントには次のものが含まれます:

1. IP

2 からの大量のリクエストの受信など、アプリケーションの異常。銀行口座の送金金額が異常であるなど、トランザクションが異常である

3. 既知の攻撃文字列が含まれている

4. リクエスト内のデータが表示できない一般ユーザーによる変更

管理アプリケーション

管理アプリケーションは、管理者がユーザー アカウントとロールを管理し、監視および監査機能を適用し、診断タスクを実行し、さまざまなアプリケーション機能を構成するのに役立ちます。

管理メカニズムはアプリケーションの主な攻撃対象領域の 1 つであり、多くの場合、管理メカニズムには非常に高い権限が与えられます。管理メカニズムの制御を取得することは、アプリケーションの制御を取得することと同じです。さらに、管理メカニズムには明らかな抜け穴や機密機能が存在することがよくあります。管理者権限を取得する脆弱性は、通常、不正アクセスや脆弱なパスワードなどのユーザー アクセス メカニズムで発生します。管理バックグラウンドが一般ユーザーから送信されたリクエストを処理できる場合は、バックグラウンドで XSS 脆弱性を盲目的に入力してみることができます。

以上がWeb アプリケーションの中核となる防御メカニズムは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。