<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 攻撃を実行できる可能性があります。

Struts Validator を使用するには、フォームで次のいずれかを拡張する必要があります。

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

Struts Validator は、これらのクラスの validate() メソッドを実装することでアプリケーションと連動するため、これらのクラスのいずれかを拡張する必要があります。

次のクラスから派生したフォームは、Struts Validator を使用できません。

ActionForm
DynaActionForm

フォームの検証フレームワークをバイパスすると、アプリケーションがさまざまな種類の攻撃にさらされます。入力の未検証は、Cross-Site Scripting、Process Control、SQL Injection などの脆弱性の根本的な原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

単一の入力フィールドでも検証を省略すると、攻撃者に自由裁量の余地を与える可能性があります。

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

一部のアプリケーションでは、複数の用途に同じ ActionForm を使用しています。このような場合、一部のアクションマッピングの下で未使用のままとなるフィールドもあります。未使用のフィールドも検証することが重要です。できれば、未使用フィールドは空か未定義にしかならないように制限してください。未使用フィールドが検証されなかった場合、アクションでの共有ビジネスロジックにより、攻撃者はフォームの他の用途のために実行される検証チェックを回避できる可能性があります。

入力の未検証は、J2EE アプリケーションの脆弱性の主な原因です。入力の未検証は、Cross-Site Scripting、Process Control、SQL Injection など、さまざまな脆弱性の原因となる可能性があります。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

このような攻撃を防ぐには、Struts Validator を使用して、アプリケーションで処理される前にすべてのプログラム入力をチェックします。Fortify Static Code Analyzer を使用して、Struts Validator の設定に欠陥がないことを確認します。

このバリデーターの使用例として、次の内容を確認するためのチェックがあります。

- 電話番号フィールドには、電話番号に有効な文字のみが含まれている。

- ブール値は T または F のみである。

- 自由形式の文字列が適度な長さと設定になっている。

Struts は、form-bean エントリを使用して HTML フォームをアクションにマップします。Struts 設定ファイルの <action-mappings> 要素に、<form-bean> タグを介して定義された関連するアクション フォームに対応するエントリがない場合、アプリケーション ロジックが最新でない可能性があります。

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

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean1" />
  <form-bean name="bean2" type="coreservlets.UserFormBean2" />
</form-beans>

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

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

Struts Action Form Mapping でフォームを指定する場合は、Struts Validator で定義された検証フォームが必要です。アクション フォーム マッピングに検証フォームが定義されていないと、入力の未検証を利用するさまざまな攻撃に対して脆弱になる可能性があります。

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

アクションやフォームは他の方法で検証できますが、Struts Validator は、すべての入力が少なくとも基本レベルのチェックを受けていることを確認する優れた方法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

アクション フォーム マッピングで検証を無効にしない必要があります。検証を無効にすると、Struts Validator と、フォームによって実行されるカスタム検証ロジックが無効になります。

例 1: 検証を無効にするアクション フォーム マッピング。

<action path="/download"
type="com.website.d2.action.DownloadAction"
name="downloadForm"
scope="request"
input=".download"
validate="false">
</action>

検証を無効にすると、このアクションがさまざまな種類の攻撃にさらされます。入力の未検証は、Cross-Site Scripting、Process Control、SQL Injection などの脆弱性の根本的な原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

開発者は、ActionForm クラスに変更を加えるときに、検証ロジックの更新を忘れがちです。検証ロジックが適切に保守されていないことを示す兆候の 1 つは、アクション フォームと検証フォームの間の不整合です。

例 1.a: 2 つのフィールドを持つアクション フォーム。

    public class DateRangeForm extends ValidatorForm {
    String startDate, endDate;
    public void setStartDate(String startDate) {
        this.startDate = startDate;
    }
    public void setEndDate(String endDate) {
        this.endDate = endDate;
    }
}

例 1.a は、2 つのフィールド、startDate および endDate を持つアクション フォームを示しています。

例 1.b: 3 番目のフィールドを持つ検証フォーム。

<form name="DateRangeForm">
    <field property="startDate" depends="date">
        <arg0 key="start.date"/>
    </field>
    <field property="endDate" depends="date">
         <arg0 key="end.date"/>
    </field>
    <field property="scale" depends="integer">
         <arg0 key="range.scale"/>
    </field>
</form>

例 1.b は、アクション フォームの検証フォームを示しています。検証フォームには、3 番目のフィールドがリストされています。scale。3 番目のフィールドの存在は、検証を考慮せずに DateRangeForm を変更したことを表しています。

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

ABAP システム フィールドは常に ABAP プログラムで使用できます。実行環境で、プログラムを起動し、画面を送信し、内部モードを変更した後に、コンテキストに従って自動的に入力されます。これらのフィールドはシステムのステータスを照会するためにプログラムで使用できます。システム フィールドは変数ですが、常に定数のように扱い、読み取り専用にする必要があります。これらの値を変更すると、プログラムのフローに必要な、重要な情報が失われる可能性があります。制限された一部の情報のみが顧客の ABAP プログラム内で変更されます。


実行時に ABAP プログラムに固有の情報との通信を行うシステムフィールドの値を変更すると、ABAP プログラムが停止したり、予期せぬ動作をしたりする可能性があります。

情報漏れが発生するのは、システム データやデバッグ情報が出力ストリームやロギング機能を通じてプログラムから出ていく場合です。

例 1: 以下のコードは例外を標準エラーストリームに書き込みます。

try {
    ...
} catch (Exception e) {
    e.printStackTrace();
}

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびリモートユーザーへの開示が可能です。たとえば、スクリプト メカニズムを使用すると、「標準エラー」または「標準出力」から出力情報をファイルまたは他のプログラムへ容易にリダイレクトできます。または、プログラムが実行されるシステムに、リモート デバイスへログを送信する「syslog」サーバーなどのリモート ロギング メカニズムを設定できます。開発中、この情報が最終的にどこで表示されることになるかを知る方法はありません。

場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

情報漏洩は、モバイル コンピューティング環境でも懸念事項です。モバイル プラットフォームでは、あちこちのソースからアプリケーションがダウンロードされ、同じデバイス上で一緒に実行されます。このため、たとえばバンキング アプリケーションのすぐそばでマルウェアを実行するなどの可能性が高くなるので、アプリケーションの開発者は、同じデバイスで実行されている他のアプリケーションに送信するメッセージにどの情報を含めるかについて十分注意する必要があります。

例 2: 次のコードでは、キャッチされた例外のスタックトレースをすべての登録済み Android 受信者に開示します。

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

これは、モバイル環境に特有の別のシナリオです。現在、大半のモバイルデバイスは NFC (Near-Field Communication) プロトコルを実装しており、無線通信を使用するデバイス間で迅速に情報を共有します。NFC は、デバイスを相互に近づけるかまたは接触させることで機能します。NFC の通信範囲は数センチメートルに限定されますが、NFC 自体ではセキュリティをともなう通信を確立できないので、盗聴、データ改変など各種の攻撃が可能です。

例 3: Android プラットフォームでは NFCがサポートされます。次のコードは、通信範囲内にある他のデバイスにプッシュされるメッセージを作成します。

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

NDEF (NFC Data Exchange Format) メッセージには、入力済みデータ、URI、またはカスタムのアプリケーション ペイロードが含まれます。メッセージにアプリケーションについての情報、たとえば名前、MIME タイプ、デバイスソフトウェアのバージョンなどが含まれていると、その情報が盗聴者に漏れる可能性があります。

情報漏れが発生するのは、システム データやデバッグ情報が出力ストリームやロギング機能を通じてプログラムから出ていく場合です。

true に設定すると、axis.enableListQuery により、Web Service Deployment Descriptor (WSDD) の一覧表示が有効になります。この機能は、adminservice パスワードなどの機密情報を含む現在のシステム構成を公開します。