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

如果两个验证表单具有相同的名称，Struts 验证器会任意选择其中一个表单用于输入验证，并放弃另一个表单。这样选择可能不符合程序员的期望。此外，它表明验证逻辑没有得到维护，并且可以表明存在其他更严重的验证错误。

示例 1：两个验证表单具有相同的名称。

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

维护验证逻辑并与应用程序的其余部分保持同步非常重要。未经检查的输入是当今一些最严重和最常见的软件安全问题的根本原因。Cross-Site Scripting、SQL Injection 和 Process Control 漏洞全是由于输入验证不完整或者缺少输入验证造成的。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

Struts Validator 使用表单的 validate() 方法，对照那些在相关校验表单中定义的约束条件来检测表单属性的内容。这就意味着以下这些类具有一个 validate() 方法，该方法是校验框架的一部分：

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

如果要建立一个继承上述类的类，并且您的这个类覆盖 validate() 函数，强行实现自定义校验逻辑，则您必须在 validate() 的实现方法中调用 super.validate()。如果不这么做，校验框架就无法对照校验表单来校验表单中的内容。换言之，针对某个特定的表单，会禁用校验框架。

对表单来说，禁用校验框架会使应用程序完全暴露在各种攻击之下。未经校验的输入是导致各种漏洞的根源，如 cross-site scripting、process control 和 SQL injection。虽然 J2EE 应用程序通常情况下不容易受到内存损坏的影响，但是如果 J2EE 应用程序连接到未执行数组边界检查的本地代码，攻击者就可能会利用 J2EE 应用程序中一个输入校验错误发起 buffer overflow 攻击。

要使用 Struts 验证器，表单必须扩展以下其中类之一：

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

您必须扩展这些类之一，因为 Struts 验证器通过实现这些类中的 validate() 方法与应用程序关联。

从以下类派生的表单不能使用 Struts 验证器：

ActionForm
DynaActionForm

绕过表单的验证框架会使应用程序面临多种类型的攻击。未经检查的输入是导致 Cross-Site Scripting、Process Control 和 SQL Injection 等漏洞的根本原因。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

即使忽略对单个输入字段的验证也会为攻击者提供攻击机会。

未经检查的输入是当今一些最严重和最常见的软件安全问题的根本原因。Cross-Site Scripting、SQL Injection 和 Process Control 漏洞全是由于输入验证不完整或者缺少输入验证造成的。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

一些应用程序会使用同一个 ActionForm 来实现多个用途。在此类情况下，一些字段可能会在部分操作映射中处于未使用状态。对未使用的字段进行验证也是十分重要的。最好对未使用的字段进行严格控制，使其只能处于空或未定义状态。如果未使用的字段没有经过验证，则操作中的共享业务逻辑就可能会使攻击者绕过对该表单的其他用途执行的验证检查。

未经检查的输入是导致 J2EE 应用程序漏洞的主要原因。未经检查的输入会导致许多漏洞，包括 Cross-Site Scripting、Process Control 和 SQL Injection。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

为防止此类攻击，请在应用程序处理所有程序输入之前使用 Struts 验证器检查所有程序输入。使用 Fortify Static Code Analyzer 确保 Struts 验证器的配置中没有漏洞。

验证器的示例用途包括进行检查以确保：

- 电话号码字段仅包含电话号码中的有效字符

- 布尔值仅为“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>

开发人员在删除或重命名操作表单映射时，很容易忘记更新验证逻辑。存在未使用的验证表单也可以表明验证逻辑未得到正确维护。

如果 Struts 操作表单映射指定了一个表单，则该表单必须有一个在 Struts 验证器下定义的验证表单。如果操作表单映射没有定义的验证表单，它可能容易受到依赖于未经检查的输入的许多攻击。

未经检查的输入是当今一些最严重和最常见的软件安全问题的根本原因。Cross-Site Scripting、SQL Injection 和 Process Control 漏洞全是由于输入验证不完整或者缺少输入验证造成的。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

操作或表单可能会以其他方式执行验证，但 Struts 验证器提供了一种极好的方法来验证所有输入至少接受了基本级别的检查。如果没有这种方法，将很难且通常不可能以高度可信的方式确定所有输入都经过验证。

操作表单映射不应该禁用验证。禁用验证会禁用 Struts 验证器以及表单执行的任何自定义验证逻辑。

示例 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 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

当开发人员更改 ActionForm 类时，很容易忘记更新验证逻辑。操作表单和验证表单之间的不一致也可以表明验证逻辑没有得到正确维护。

示例 1.a：具有两个字段的操作表单。

    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 显示了一个具有两个字段的操作表单，startDate 和 endDate。

示例 1.b：具有第三个字段的验证表单。

<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 列出了操作表单相应的验证表单。验证表单列出了第三个字段：scale。第三个字段的存在表明在未考虑验证的情况下对 DateRangeForm 进行了修改。

维护验证逻辑并与应用程序的其余部分保持同步非常重要。未经检查的输入是当今一些最严重和最常见的软件安全问题的根本原因。Cross-Site Scripting、SQL Injection 和 Process Control 漏洞全是由于输入验证不完整或者缺少输入验证造成的。尽管 J2EE 应用程序通常不会受到内存腐败攻击的影响，但如果 J2EE 应用程序与不执行数组边界检查的本机代码交互，攻击者可能会利用 J2EE 应用程序中的输入验证错误来发起 Buffer Overflow 攻击。

ABAP 系统字段在 ABAP 程序中始终可用。运行时系统会在启动程序后、发送屏幕后和更改内部模式后，根据上下文填充这些字段。然后，这些字段可在程序中用于查询系统状态。系统字段为变量，但应始终将其作为常量和只读字段处理。更改这些字段的值会导致程序运行所需的重要信息丢失。因此，在客户 ABAP 程序中只能更改其中有限的字段。


对向 ABAP 程序传送运行时特定信息的系统字段值进行更改，会导致服务中断或 ABAP 程序行为异常。

当系统数据或调试信息通过输出流或者日志功能流出程序时，就会发生信息泄漏。

示例 1：以下代码会将一个异常写入标准错误流：

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

根据系统配置，该信息可能会转储到控制台、写入日志文件或公开给远程用户。例如，凭借脚本机制，可以轻松将输出信息从“标准错误”或“标准输出”重定向至文件或其他程序。或者，运行程序的系统可能具有将日志发送至远程设备的远程日志记录系统，例如“syslog”服务器。在开发过程中，您无法知道此信息最终可能显示的位置。

在某些情况下，该错误消息会告诉攻击者该系统易遭受的确切攻击类型。例如，数据库错误消息可以揭示应用程序容易受到 SQL Injection 攻击。其他错误消息可以揭示有关该系统的更多间接线索。在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) 协议，以便使用无线电通信在设备之间快速共享信息。它在设备极为贴近或互相接触时有效。即使 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);
...

NFC 数据交换格式 (NDEF) 消息包含类型化数据、URI 或自定义应用程序有效负载。如果该消息包含与应用程序有关的信息（如其名称、MIME 类型或设备软件版本），则此信息可能会泄露给窃听者。

当系统数据或调试信息通过输出流或者日志功能流出程序时，就会发生信息泄漏。



当设置为 true 时，axis.enableListQuery 启用 Web Service Deployment Descriptor (WSDD) 列表。此功能会暴露当前系统配置，其中包含 adminservice 密码等敏感信息。