サービス拒否
サービス拒否は、メッセージを処理できなくしたり、メッセージ処理を大幅に遅延させたりするなど、システムに過大な負荷が生じた場合に発生します。
過度のメモリ消費
一意のローカル名、名前空間、またはプレフィックスを大量に含んだ XML ドキュメントを読み込むと、問題が発生する場合があります。 XmlReader から派生したクラスを使用している場合、LocalName、Prefix、または NamespaceURI のいずれかのプロパティが項目ごとに呼び出され、それによって返された文字列が NameTable に追加されます。 NameTable が保持するコレクションのサイズは決して減ることがありません。その結果、文字列ハンドルの実質的な "メモリ リーク" が発生する場合があります。
回避事項を次に示します。
NameTable からの派生クラスを作成し、最大サイズのクォータを指定します (NameTable の使用を回避したり、サイズが上限に達したときに NameTable を切り替えたりすることはできません)。
可能であれば、前述のプロパティを使用せずに、MoveToAttribute メソッドと IsStartElement メソッドを使用します。これらのメソッドでは、文字列が返されないため、NameTable コレクションがあふれてしまう問題を回避できます。
悪質なクライアントにより過度のライセンス要求がサービスに送信される
悪質なクライアントが過度のライセンス要求を実行してサービスを攻撃する場合、サーバーは過度のメモリを使用することになります。
軽減策: LocalServiceSecuritySettings クラスの次のプロパティを使用します。
MaxCachedCookies :
SecurityContextToken
またはSPNego
ネゴシエーションの後にサーバーがキャッシュする、期限付きのSSL
の最大数を制御します。IssuedCookieLifetime :
SecurityContextTokens
またはSPNego
ネゴシエーションに続いてサーバーが発行するSSL
の有効期限を制御します。 サーバーは、この期間のSecurityContextToken
をキャッシュします。MaxPendingSessions: サーバーで確立されているが、そのアプリケーション メッセージが処理されていない、セキュリティで保護されたメッセージ交換の最大数を制御します。 このクォータは、クライアントが、セキュリティで保護されたメッセージ交換をサービスで確立しないようにします。それによって、サービスはクライアントごとの状態を保持できますが、それらの状態を使用することはありません。
InactivityTimeout: サービスが、セキュリティで保護されたメッセージ交換でクライアントからのアプリケーション メッセージを受信しなくても、そのメッセージ交換を確立したままにする最長時間を制御します。 このクォータは、クライアントが、セキュリティで保護されたメッセージ交換をサービスで確立しないようにします。それによって、サービスはクライアントごとの状態を保持できますが、それらの状態を使用することはありません。
WSDualHttpBinding または二重カスタム バインディングにクライアント認証が必要になる
既定では、WSDualHttpBinding のセキュリティは有効になっています。 ただし、ClientCredentialType プロパティを None に設定してクライアント認証を無効にすると、第 3 のサービスで悪質なユーザーからサービス拒否攻撃を受ける可能性があります。 これは、悪質なクライアントが、メッセージ ストリームを第 3 のサービスに送信するようサービスに指示できるためです。
これを防ぐには、このプロパティを None
に設定しないようにします。 二重メッセージ パターンを持つカスタム バインドを作成する場合もこの可能性があることに注意してください。
監査イベント ログがいっぱいになる可能性がある
悪意のあるユーザーに監査が有効になっていることを知られると、その攻撃者に監査エントリの書き込みにつながる無効なメッセージを送信される可能性があります。 このような方法で監査ログに書き込みが行われると、監査システムに障害が発生します。
これを防ぐには、SuppressAuditFailure プロパティを true
に設定し、イベント ビューアーのプロパティを使用して監査動作を制御します。 イベント ビューアーを使用してイベント ログを表示および管理する方法については、「イベント ビューアー」を参照してください。 詳細については、「監査」を参照してください。
IAuthorizationPolicy の無効な実装によりサービスが応答しなくなる可能性がある
欠陥のある IAuthorizationPolicy インターフェイスの実装で Evaluate メソッドを呼び出すと、サービスが応答しなくなる可能性があります。
回避方法 : 信頼されたコードのみを使用します。 つまり、ユーザーが記述しテストしたコード、または信頼されたプロバイダーが提供するコードのみを使用します。 十分な検討を行わずに、IAuthorizationPolicy の信頼されない拡張をユーザーのコードに接続することを許可しないでください。 これは、サービスの実装で使用されるすべての拡張に当てはまります。 WCF では、アプリケーション コードと、拡張ポイントを使用して接続される外部コードは区別されません。
Kerberos の最大トークン サイズの変更が必要になる場合がある
クライアントが多数のグループ (実際の数はグループにより異なるが、約 900) に属している場合、メッセージ ヘッダーのブロックが 64 KB を超えると問題が発生する場合があります。 その場合は、Kerberos トークンの最大サイズを増やすことができます。 WCF メッセージの最大サイズを Kerberos トークンの増加に合わせて増加させることが必要な場合もあります。
自動登録によってコンピューターに同一サブジェクト名の証明書が複数発生する
"自動登録" は、証明書用のユーザーとコンピューターを自動で登録する Windows Server 2003 の機能です。 この機能が有効になっているドメイン上にコンピューターがある場合、新しいコンピューターがネットワークに参加するたびに、クライアント認証を目的とする X.509 証明書が自動的に作成されローカル コンピューターの個人用証明書のストアに自動で挿入されます。 ただし、自動登録では、キャッシュに作成されたすべての証明書に同じサブジェクト名が使用されます。
この影響で、WCF サービスを自動登録のドメインで開始できない場合があります。 コンピューターの完全修飾ドメイン ネーム システム (DNS) 名を持つ証明書が複数あるため、既定サービスの X.509 資格情報検索の条件が不明確になり、このような問題が発生します。 この場合、1 つは自動登録で作成された証明書、もう 1 つは自己発行された証明書です。
これを防ぐには、<serviceCredentials> のより厳密な検索条件を使用して、使用する証明書を正確に参照します。 たとえば、FindByThumbprint オプションを使用し、一意の拇印 (ハッシュ) により証明書を指定します。
自動登録機能の詳細については、「Windows Server 2003 での証明書の自動登録」を参照してください。
複数の代替サブジェクト名の最後が承認に使用される
まれなケースとして X.509 証明書に複数の代替サブジェクト名が含まれる場合、その代替サブジェクト名を使用して承認を行うと、承認は失敗する場合があります。
ACL を使用して構成ファイルを保護する
CardSpace で発行されたトークンについては、必須およびオプションのクレームをコードと構成ファイルに指定できます。 これにより、対応する要素が、セキュリティ トークン サービスに送信される RequestSecurityToken
メッセージに送出されます。 攻撃者は、コードまたは構成を変更して必須またはオプションのクレームを削除でき、対象サービスへのアクセスが許可されていないトークンをセキュリティ トークン サービスに発行させることができます。
これを防ぐには、コンピューターにアクセスして構成ファイルを変更する必要があります。 アクセス制御リスト (ACL: Access Control List) を使用して構成ファイルをセキュリティで保護します。 WCF では、コードが構成から読み込まれる前に、そのコードをアプリケーション ディレクトリまたはグローバル アセンブリ キャッシュに格納する必要があります。 ディレクトリの ACL を使用してディレクトリをセキュリティで保護します。
1 つのサービスに対して、セキュリティで保護されたセッションが最大数に達する
クライアントがサービスにより正常に認証され、セキュリティで保護されたセッションがサービスと共に確立されると、クライアントがセッションをキャンセルするか、セッションの期限が切れるまで、サービスはそのセッションを追跡します。 セッションが確立されるたびに、1 つのサービスで同時にアクティブにできるセッションは上限に近づいていきます。 この上限に達した場合、1 つ以上のアクティブなセッションが期限切れになるかまたはクライアントによりキャンセルされるまで、そのサービスで新しいセッションの作成を試みるクライアントは拒否されます。 クライアントは 1 つのサービスで複数のセッションを保持できますが、その各セッションは上限に反映されます。
Note
ステートフルなセッションを使用する場合、前の段落は適用されません。 ステートフルなセッションの詳細については、「方法: セキュリティで保護されたセッションに対しセキュリティ コンテキスト トークンを作成する」を参照してください。
これを防ぐには、SecurityBindingElement クラスの SecurityBindingElement プロパティを設定して、アクティブなセッションの最大数とセッションの最長有効期間の制限を設定します。