Struts は、form-bean エントリを使用して HTML フォームをアクションにマップします。<action> タグの name 属性が form-bean の名前に対応していない場合、アクションをマッピングできず、不適切な定義または誤植を示します。

例 1: 次の設定は、bean2 のマッピングを含みません。

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

Struts は、form-bean の名前を使用して HTML フォームをアクションにマップします。form-bean に名前がないとアクションにマップできず、不適切な定義または誤って省略された Bean のいずれかを示します。
以下は適切な form-bean の例です。
例 1: 次の form-bean には空の name 属性があります。

<form-beans>
  <form-bean name="" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts は、form-bean エントリを使用して HTML フォームをアクションにマップします。form-bean にタイプがないと、アクションにマップできません。
例 1: 次の form-bean には空の type 属性があります。

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts では、<form-property> タグに type 属性を含める必要があります。Struts は、タイプなしで form-property を定義したフォームを処理すると、例外をスローします。

例 1: 次の設定は、name プロパティのタイプを省略しています。

<form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
  <form-property name="name" />
  <form-property name="password" type="java.lang.String" />
</form-bean>

<forward> タグには、name と path 属性が必要です。名前がないと、forward は使用されません。

例 1: 次の <forward> タグには空の name 属性があります。

    <forward name="" path="/results.jsp"/>

<forward> タグには、name と path 属性が必要です。パスを省略したり、空白のパスを指定するのは間違いです。また、すべてのパスは "/" 文字で始める必要があります。

例 1: 次の <forward> タグには path 属性がありません。

    <forward name="success" />

display_errors オプションが有効に設定されている場合、エラーが Web ブラウザに表示されるので、潜在的な脆弱性が攻撃者に明らかになる可能性があります。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージがシステムに関する間接的な手がかりを示すことがあります。

expose_php オプションが有効に設定されている場合、PHP インタプリタによって作成されるすべてのレスポンスには、ホストシステムにインストールされている PHP のバージョンが含まれます。リモート サーバーで実行されている PHP のバージョンを知り得た攻撃者は、システムに対する既知の悪用方法を列挙できるため、攻撃を成功させるのにかかる労力を大幅に削減できます。

クライアントを認証しないサービスでは、誰でもアクセスできます。

クライアントを認証しないサービスでは、誰でもアクセスできます。

Windows Communication Framework (WCF) サービスは、デバッグ情報を公開するように設定できます。デバッグ情報は、実運用環境では使用しないでください。<serviceDebug> タグは、WCF サービスに対してデバッグ情報機能を有効にするかどうかを定義します。



属性 includeExceptionDetailInFaults が true に設定されている場合、アプリケーションからの例外情報がクライアントに返されます。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

例: 次の設定ファイルには、<serviceDebug> タグが含まれています。

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>
...

WCF が監査ログに書き込めないときに例外をスローしないように設定されている場合、プログラムは失敗を通知されず、重大なセキュリティ イベントの監査が行われない可能性があります。

例 1: 次の WCF 設定ファイルの <behavior/> 要素は、WCF が監査ログへの書き込みに失敗したときにアプリケーションに通知を行わないよう WCF クライアントに命令しています。

<behaviors>
   <serviceBehaviors>
      <behavior name="NewBehavior">
         <serviceSecurityAudit auditLogLocation="Application"
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success"
             messageAuthenticationAuditLevel="Success" />
      </behavior>
   </serviceBehaviors>
</behaviors>

Windows Communication Foundation (WCF) は、認証の試行の成功または失敗をログに記録する機能を提供します。失敗した認証の試行をログに記録することで、ブルートフォース攻撃の可能性を管理者に報告できます。同様に、成功した認証イベントをログに記録することで、正当なアカウントが侵害された場合に役立つ監査証跡を実行できます。

WCF サービスの設定によっては、メタデータが公開される場合があります。メタデータは、詳細なサービスに関する説明情報が含まれており、実運用環境では公開してはいけません。ServiceMetaData クラスの HttpGetEnabled / HttpsGetEnabled プロパティは、サービスがメタデータを公開するかどうかを定義します。
例 1: 次のコードは、サービスのメタデータを公開するように WCF に命令しています。

    ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
    smb.HttpGetEnabled = true;
    smb.HttpGetUrl = new Uri(EndPointAddress);
    Host.Description.Behaviors.Add(smb);

別のプログラムにメッセージを配信するために使用される MSMQ キューへの接続に認証が使用されない場合、攻撃者が悪意のある匿名メッセージを送信する可能性があります。

例 1: 次の WCF 設定ファイルの <netMsmqBinding/> 要素は、メッセージを配信する MSMQ キューに接続するときに認証を無効にするよう WCF クライアントに命令しています。

    <bindings>
      <netMsmqBinding>
        <binding>
          <security>
            <transport msmqAuthenticationMode="None" />
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>

転送またはメッセージのセキュリティが設定されていないままメッセージを送信するプログラムでは、送信されるメッセージの完全性も機密性も保証されません。WCF セキュリティバインドが None に設定されている場合、転送セキュリティとメッセージセキュリティの両方が無効になります。

例 1: 次のコードは、偽の Widget サービスについて、WCF Basic HTTP Binding のセキュリティモードを None に設定しています。

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;

ServiceHost serviceHost = new ServiceHost(typeof(Widget), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Widget), binding, new URI("ExposureAddress"));

<serviceMetadata> タグはメタデータ発行機能を有効にします。サービスのメタデータには、一般アクセスを禁止する必要のある機密情報が含まれている可能性があります。

Windows Communication Foundation (WCF) は、サービス リクエストをスロットリングする機能を提供します。許可するクライアント リクエストが多すぎると、システムが許容レベルを超え、リソースの枯渇につながる可能性があります。一方、サービスに対して許容するリクエスト数を少なくしすぎると、正当なユーザーがサービスを使用できなくなる可能性があります。各サービスは、適切な量のリソースを許可するように個別に調整および設定する必要があります。

トランスポートセキュリティにより、機密性、完全性、および認証がトランスポートレイヤ機構 (HTTPS など) により提供されるようになります。HTTPS のようなトランスポートを使用している場合、このモードにはパフォーマンス効率上の利点があります。また、インターネットで広く利用されており、よく理解されています。このタイプのセキュリティは、コミュニケーション パスにおける各ホップで別々に適用されるため、コミュニケーションが「中間者（man in the middle）」攻撃を受ける可能性があります。WCFには、他にも 2 つの転送セキュリティモード、メッセージとメッセージ証明書付きトランスポートとがあり、どちらも推奨されます。メッセージセキュリティでは、WS-Security 仕様によって、機密性、完全性、および認証をメッセージレベルで確保します。ここではトランスポートメソッドでエンドツーエンドのセキュリティと柔軟性を実現しますが、パフォーマンスは劣ります。

最後の方法であるメッセージ資格情報を使用したトランスポートは、トランスポートとメソッドの混合です。メッセージ セキュリティはクライアントの認証に使用され、トランスポート セキュリティはサーバーの認証に使用され、機密性と整合性を提供します。これは純粋なトランスポート セキュリティとほぼ同じくらい効率的です。

クライアントが特定の WCF サービスをコールしている場合、WCF は、コーラーがサーバーでサービスメソッドを実行する許可があることを検証するさまざまな認証スキームを提供します。認証制御が、WCF サービスで有効になっていない場合、認証されたユーザーが権限を昇格する可能性があります。

例 1: 次のコードは、サービスを実行するときにクライアントの認証レベルをチェックしないように WCF に命令しています。

    ServiceHost myServiceHost = new ServiceHost(typeof(Calculator), baseUri);
    ServiceAuthorizationBehavior myServiceBehavior =
    myServiceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
    myServiceBehavior.PrincipalPermissionMode =
        PrincipalPermissionMode.None;