Action Fields に、対応する検証定義がありません。各フィールドには、ActionClass-validation.xml で参照される明示的な検証ルーチンが必要です。

開発者は、アクションフォームマッピングの削除または名前の変更を実行した際に検証ロジックの更新を忘れることがあります。検証ロジックが適切に保守されていないことを示すものの 1 つが、検証機能の欠落です。

検証ロジックの保守と保存は、アプリケーションのその他の部分と同期していることが非常に重要です。今日最も被害が大きく最も一般的なソフトウェアのセキュリティ問題の根本原因が入力の未検証です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性は、いずれも入力検証が不完全だったり、行われなかったりしたことが原因となっています。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

ActionClass-validation.xml に同じ名前のフィールド バリデーター定義が複数存在します。同じ名前の検証定義が重複していると、予期しない動作が発生する可能性があります。

例 1: 次のエントリは、2 つの重複するフィールド バリデーター定義を示しています。

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

この Struts2 Action 定義に対して、2 つ以上の ActionClass-validation.xml ファイルが検出されました。ActionClass の形式で定義されている各 Struts2 Action について、Struts2 は検証に必要な制限事項を確認するために、対応する ActionClass-validation.xml を検索します。配置に含まれている 1 つの Action に複数の検証定義がある場合、予期せぬ動作の原因となる可能性があります。

同じ名前の検証フォームが 2 つある場合、Struts Validator は任意でいずれかのフォームを選択して入力の検証に使用し、もう一方は破棄します。この判断がプログラマの予想と一致しないことがあります。また、これは検証ロジックが保守されていないことを示し、さらに他の非常に小さな検証エラーが存在することも示している可能性があります。

検証ロジックの保守と保存は、アプリケーションのその他の部分と同期していることが非常に重要です。今日最も被害が大きく最も一般的なソフトウェアのセキュリティ問題の根本原因が入力の未検証です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性は、いずれも入力検証が不完全だったり、行われなかったりしたことが原因となっています。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

複数のバリデーター定義が validators.xml で発見されました。同じ名前の検証定義が複数あると、予期しない動作が発生する可能性があります。

2 つの検証クラスが同じ名前で定義されている場合、Struts バリデーターは、入力検証に使用するためにどちらかの形式を任意に選択し、もう 1 つを破棄します。この決定が、プログラマの想定と合っていない可能性があります。さらに、検証ロジックが保守されていないことを示し、他のよりわかりにくい検証エラーが存在する可能性もあります。

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

Struts2 では、カスタム バリデーターを、アクション バリデーター定義で使用する前に validators.xml で定義する必要があります。バリデーター定義がない場合、検証が最新ではないことを意味します。

例 1: 次のアクション バリデーターは、validators.xml で定義されていません。

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

J2EE アプリケーションの脆弱性の主な原因は、未検証の入力です。Cross-Site Scripting、Process Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

そのような攻撃を防止するため、Struts Validation フレームワークを使用してすべてのプログラム入力を確認してからアプリケーションに処理させます。Fortify Static Code Analyzer を使用すると、Struts Validator の設定の不備な点を確実になくすことができます。

Validator を使用すると、次のような点をチェックできます。

- 電話番号フィールドには、電話番号で有効な文字だけが含まれる。

- ブール値は「T」と「F」のいずれかだけである。

- 自由入力の文字列は適切な長さと形式にする。

Struts2 検証ファイルが、対応する Struts2 アクションなしで検出されました。各 ActionClass について、Struts2 は対応する ActionClass-validation.xml を検索し、必要な検証の制約を探します。この場合、ActionClass-validation.xml という形式の検証ファイルが見つかりましたが、ActionClass が Struts2 設定ファイルで定義されたアクションと一致しません。

開発者は、アクション フォーム マッピングを削除または名前変更するときに、検証ロジックの更新を忘れがちです。検証ロジックが適切に保守されていないことを示す兆候の 1 つは、未使用の検証フォームが存在することです。

Struts2 バリデーターの定義が、存在しないアクション フィールドを参照しています。

開発者は、アクション フォーム マッピングを削除または名前変更するときに、検証ロジックの更新を忘れがちです。検証ロジックが適切に管理されていないことを示す 1 つの兆候は、孤立したバリデーター定義の存在です。

form-bean の名前の重複には意味がありません。複数の <form-bean> タグで同じ名前が使用されていても、最後のエントリのみが登録されるためです。

例 1: 次の設定には、同じ名前の form-bean エントリが 2 つあります。

<form-beans>
  <form-bean name="loginForm" 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-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts は path 属性を使用して、リクエストの処理に必要なリソースを見つけます。パスはモジュールと関連する場所であるため、"/" 文字で始まらない場合はエラーになります。

例 1: 次の設定には、空のパスが含まれています。

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

例 2: 次の設定は、"/" 文字で始まらないパスを使用しています。

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

名前付きアクションから検証エラーが返される場合は、Struts の仕様により input 属性が求められます [2]。input 属性は、検証エラーが発生した場合のエラー メッセージの表示に使用するページを指定します。
例 1: 次の設定は、名前付き検証アクションを定義していますが、input 属性は指定していません。

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

<exception> タグには、例外タイプを定義する必要があります。type 属性がない、または空の場合は、不適切な例外ハンドラーか、誤って削除したことを意味します。開発者が、例外を処理するつもりだったものの例外タイプの定義を忘れた場合、アプリケーションからシステムに関する機密情報が漏洩する可能性があります。
例 1: 次の設定は、<exception> タグからタイプを省略しています。

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

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" />

2 つの検証フォームの名前が同じである場合、Struts Validator は、入力検証に使用するフォームの 1 つを任意に選択し、もう 1 つを破棄します。この決定が、プログラマの想定と合っていない可能性があります。さらに、検証ロジックが保守されていないことを示し、他のよりわかりにくい検証エラーが存在する可能性もあります。

例 1: 同じ名前の 2 つの検証フォーム。

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

Struts Validator はフォームの validate() メソッドを使用して、関連する検証フォームで指定される制約に対して form プロパティのコンテンツをチェックします。つまり、以下のクラスは検証フレームワークの一部である validate() メソッドを持つことを意味します。

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

これらのクラスのいずれかを拡張するクラスを作成し、そのクラスが validate() メソッドを上書きしてカスタム検証ロジックを実装する場合、validate() 実装の super.validate() をコールする必要があります。これを行わないと、検証フレームワークはフォームのコンテンツを検証フォームに対してチェックできません。つまり、検証フレームワークは特定のフォームでは無効となります。

フォームに対して検証フレームワークが無効になると、アプリケーションを様々なタイプの攻撃にさらすことになります。Cross-Site Scripting、Process Control や SQL Injection のような脆弱性の根本的な原因は入力の未検証です。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。