SQL injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。



2. 该数据用于动态地构造一个 HQL 查询。

示例 1：以下代码动态地构造并执行一个 HQL 查询，用于搜索与指定名称相匹配的项。该查询仅会显示条目所有者与被授予权限的当前用户一致的条目。

    ...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String query = "FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	List items = sess.createQuery(query).list();
	...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于Example 1.中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL injection 攻击。

防范 SQL injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SQL injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。再次重申，存储过程可以阻止某些类型的盗取行为，但是它们并不能保护您的应用程序免受 SQL Injection 攻击。

SQL Injection 错误会在以下情况下出现：

1.数据从一个不可信数据源进入程序。

2.数据用于动态地构造 SQL 查询。



使用 iBatis Data Map 可以在 SQL 语句中指定动态参数，而 Batis Data Map 通常使用 # 字符来定义，如下所示：

    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName#
    </select>

变量名称两侧的 # 字符表示 iBatis 将创建含 userName 变量的参数化查询。但是，iBatis 也允许使用 $ 字符将变量直接连接到 SQL 语句，因而为发动 SQL Injection 攻击敞开了大门。

示例 1：下列代码可动态地构建并执行一个 SQL 查询，用来搜索与指定名称相匹配的条目。该查询仅会显示条目所有者与当前经过身份验证的用户的名称一致的条目。

    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName# AND itemname = '$itemName$'
    </select>

但是，由于该查询是动态构造的，由一个常数基本查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，该查询才能正常运行。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，则该查询会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

如果添加条件 OR 'a'='a'，where 子句的值将始终为 true，这样该查询在逻辑上就等同于一个更为简单的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

包括 Microsoft(R) SQL Server 2000 在内的很多数据库服务器都可以一次性执行多条用分号分隔的 SQL 语句。在不允许批量执行用分号分隔的语句的 Oracle 和其他数据库服务器上，此攻击字符串只会导致错误；但是在支持批量执行的数据库上，此类型攻击可以使攻击者针对数据库执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于 Example 1 中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

阻止 SQL Injection 攻击的一种传统方法是将其作为一种输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列表中的潜在恶意值（拒绝列表）。检查允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的拒绝列表实现方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将未引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 SQL 查询输入中的字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

防范 SQL Injection 攻击的另外一种常用解决方法是使用存储过程。虽然存储过程可以阻止某些类型的 SQL Injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL Injection 攻击的常用方式是限制可传入存储过程参数的语句类型。但是，有许多方法都可以绕过这一限制，许多危险的语句仍可以传入存储过程。所以再次强调，存储过程在某些情况下可以避免一些漏洞，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

SQL injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态地构造一个 SQL 或 JDOQL 查询。

例 1：以下代码动态地构造并执行了一个 SQL 查询，该查询可以搜索与指定名称相匹配的项。该查询仅会显示条目所有者与被授予权限的当前用户一致的条目。

...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String sql = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	Query query = pm.newQuery(Query.SQL, sql);
	query.setClass(Person.class);
	List people = (List)query.execute();
	...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于Example 1.中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL injection 攻击。

防范 SQL injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SQL injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。再次重申，存储过程可以阻止某些类型的盗取行为，但是它们并不能保护您的应用程序免受 SQL Injection 攻击。

与 LINQ 相关的 injection 错误在以下情况下出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据用于动态地构造一个查询。
示例 1：以下代码动态地构造并执行了一个 LINQ 查询，用于搜索与指定名称相匹配的项。该查询仅会显示条目 owner 与被授予权限的当前用户一致的条目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

var items = dataContext.ExecuteCommand<Item>(query);
...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'); DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于Example 1.中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 LINQ injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 LINQ 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 LINQ Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 LINQ 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 LINQ injection 攻击。

防范 LINQ injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 LINQ injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 LINQ injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。所以再次强调，存储过程可以避免部分情况，但是并不能完全保护您的应用系统抵御 LINQ injection 的攻击。

SQL Injection 错误会在以下情况下出现：

1.数据从一个不可信数据源进入程序。

2.数据用于动态地构造 SQL 查询。



使用 MyBatis Mapper XML 文件可在 SQL 语句中指定动态参数，而这些文件通常使用 # 字符来定义，如下所示：

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
    </select>

使用 # 字符并在变量名称两侧添加大括号表示 MyBatis 将创建含 userName 变量的参数化查询。但是，MyBatis 也允许使用 $ 字符将变量直接连接到 SQL 语句，因而为发动 SQL Injection 攻击敞开了大门。

示例 1：下列代码可动态地构建并执行一个 SQL 查询，用来搜索与指定名称相匹配的条目。该查询仅会显示条目所有者与当前经过身份验证的用户的名称一致的条目。

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
        AND itemname = ${itemName}
    </select>

但是，由于该查询是动态构造的，由一个常数基本查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，该查询才能正常运行。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，则该查询会变成：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name' OR 'a'='a';

如果添加条件 OR 'a'='a'，WHERE 子句的值将始终为 true，这样该查询在逻辑上就等同于一个更为简单的查询：

    SELECT * FROM items;

通常，查询应仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    --'

包括 Microsoft(R) SQL Server 2000 在内的很多数据库服务器都可以一次性执行多条用分号分隔的 SQL 语句。在不允许批量执行用分号分隔的语句的 Oracle 和其他数据库服务器上，此攻击字符串只会导致错误；但是在支持批量执行的数据库上，此类型攻击可以使攻击者针对数据库执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于 Example 1 中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    SELECT * FROM items WHERE 'a'='a';

阻止 SQL Injection 攻击的一种传统方法是将其作为一种输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列表中的潜在恶意值（拒绝列表）。检查允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的拒绝列表实现方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将未引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 SQL 查询输入中的字符有一定的帮助，但是并不能保证完全保护您的应用程序免受 SQL Injection 攻击。

防范 SQL Injection 攻击的另外一种常用解决方法是使用存储过程。虽然存储过程可以阻止某些类型的 SQL Injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL Injection 攻击的常用方式是限制可传入存储过程参数的语句类型。但是，有许多方法都可以绕过这一限制，许多危险的语句仍可以传入存储过程。所以再次强调，存储过程在某些情况下可以避免一些漏洞，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

SQL injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据用于动态地构造一个 SQL 查询。
示例 1：以下代码动态地构造并执行了一个 SQL 查询，该查询可以搜索与指定名称相匹配的项。该查询仅会显示条目 owner 与被授予权限的当前用户一致的条目。

...
	string userName = ctx.GetAuthenticatedUserName();
	string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 ItemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 ItemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 ItemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于Example 1.中所用的技巧进行攻击。如果攻击者输入字符串“name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL injection 攻击。

防范 SQL injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SQL injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。再次重申，存储过程可以阻止某些类型的盗取行为，但是它们并不能保护您的应用程序免受 SQL Injection 攻击。

在以下情况下会发生 SQL Injection: PartiQL 问题：

1.数据从一个不可信数据源进入程序。

2.数据用于动态地构造 PartiQL 查询。
示例 1：以下代码可动态地构造并执行 PartiQL 查询，以便搜索与指定名称相匹配的条目。该查询仅会显示条目的owner与当前经过身份验证的用户的名称一致的条目。

...
String userName = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于该查询是动态构造的，由一个常数基本查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，该查询才能正常运行。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，则该查询会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

如果添加条件 OR 'a'='a'，where 子句的值将始终为 true，这样该查询在逻辑上就等同于一个更为简单的查询：
阻止 SQL Injection 攻击的一种传统方法是将其作为一种输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列表中的潜在恶意值（拒绝列表）。检查允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的拒绝列表实现方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将未引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 PartiQL 查询输入中的字符有一定的帮助，但是并不能完全保护您的应用程序免受 PartiQL Injection 攻击。

SQL injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

在这种情况下，Fortify Static Code Analyzer（Fortify 静态代码分析器）无法确定数据源是否可信赖。

2. 数据用于动态地构造一个 SQL 查询。

例 1：以下代码动态地构造并执行了一个 SQL 查询，该查询可以搜索与指定名称相匹配的项。该查询仅会显示条目所有者与被授予权限的当前用户一致的条目。

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

查询计划执行以下代码：

        SELECT * FROM items
        WHERE owner = <userName>
        AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

        SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'; DELETE FROM items; --”，则该查询就会变为以下两个查询：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        --'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。对于不允许以这种方式使用注释的数据库，攻击者通常仍可使用类似于Example 1 中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        SELECT * FROM items WHERE 'a'='a';

有些人认为在移动世界中，典型的 Web 应用程序漏洞（如 SQL injection）是无意义的 -- 为什么用户要攻击自己？但是，谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高，它们会强制扩展移动应用程序的攻击面（包括跨进程通信）。

示例 3：以下代码会调整Example 1 以适应 Android 平台。

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL injection 攻击。

防范 SQL injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SQL injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。所以再次强调，存储过程在某些情况下可以避免这种攻击，但是并不能完全保护您的应用系统抵御 SQL injection 的攻击。

使用 mysql_real_escape_string() 等编码函数可避免一部分 SQL Injection 漏洞，但不能完全避免。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 SQL Injection 攻击，并且可能允许攻击者修改语句的含义或者执行任意 SQL 命令。由于在动态解释代码的给定部分中不可能总是静态确定输入显示的位置，因此 Fortify 安全编码规则包可能会将经过验证的动态 SQL 数据显示为“SQL Injection: Poor Validation”问题，即使验证可能足以防止在该上下文中出现 SQL Injection 攻击时也是如此。

SQL Injection 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。



2. 数据用于动态地构造 SQL 查询。

示例 1： 以下示例演示数据库配置如何影响 mysqli_real_escape_string() 的行为。 将 SQL 模式设置为“NO_BACKSLASH_ESCAPES” 时，反斜杠字符会被视为正常字符，而不是转移字符[5]。 由于 mysqli_real_escape_string() 将此情况考虑在内，因此鉴于数据库配置，当 " 不再转义为 \" 时，以下查询易受到 SQL Injection 的攻击。

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

如果攻击者将 password 字段留空并为 userName 输入 " OR 1=1;-- ，则不对引号进行转义，最后的查询如下所示：

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

由于 OR 1=1 会导致 where 子句的值始终为 true 且双连字符会导致剩余语句被视为注释，因此该查询在逻辑上就等同于一个更为简单的查询：

  SELECT * FROM users;

避免 SQL injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SQL 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SQL Injection 攻击。例如，攻击者可以：

- 将没有被黑名单引用的字段作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动转义 SQL 查询输入中的字符有一定的帮助，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

防范 SQL Injection 攻击的另外一种常用解决方法是使用存储过程。 虽然存储过程可以阻止某些类型的 SQL Injection 攻击，但是对于绝大多数攻击仍无能为力。 存储过程有助于避免 SQL Injection 攻击的常用方式是限制可传入存储过程参数的语句类型。 但是，有许多方法都可以绕过这一限制，许多危险的语句仍可以传入存储过程。 所以再次强调，存储过程在某些情况下可以避免一些漏洞，但是并不能完全保护您的应用程序免受 SQL Injection 攻击。

与 SubSonic 相关的 SQL injection 错误在以下情况下出现：

1. 数据从一个不可信赖的数据源进入程序。

2. 数据用于动态地构造一个查询。
示例 1：以下代码动态地构造并执行了一个 SubSonic 查询，该查询可以搜索与指定名称相匹配的项。该查询仅会显示条目 owner 与被授予权限的当前用户一致的条目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

查询计划执行以下代码：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于这个查询是动态构造的，由一个不变的基查询字符串和一个用户输入字符串连接而成，因此只有在 itemName 不包含单引号字符时，才会正确执行这一查询。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name' OR 'a'='a”，那么查询就会变成：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加条件 OR 'a'='a' 会使 where 从句永远评估为 true，因此该查询在逻辑上将等同于一个更为简化的查询：

	SELECT * FROM items;

通常，查询必须仅返回已通过身份验证的用户所拥有的条目，而通过以这种方式简化查询，攻击者就可以规避这一要求。现在，查询会返回存储在 items 表中的所有条目，而不论其指定所有者是谁。

示例 2：此示例说明了将不同的恶意值传递给Example 1.中构造和执行的查询所带来的影响。如果一个用户名为 wiley 的攻击者为 itemName 输入字符串“name'); DELETE FROM items; --”，则该查询就会变为以下两个查询：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

众多数据库服务器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性执行多条用分号分隔的 SQL 指令。对于那些不允许运行用分号分隔的批量指令的数据库服务器，比如 Oracle 和其他数据库服务器，攻击者输入的这个字符串只会导致错误；但是在那些支持这种操作的数据库服务器上，攻击者可能会通过执行多条指令而在数据库上执行任意命令。

注意末尾的一对连字符 (--)；这在大多数数据库服务器上都表示该语句剩余部分将视为注释，不会加以执行 [4]。在这种情况下，可通过注释字符删除修改后的查询遗留的末尾单引号。而在不允许通过这种方式使用注释的数据库上，攻击者通常仍可使用类似于Example 1.中所用的技巧进行攻击。如果攻击者输入字符串“name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a”，将创建以下三个有效语句：

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SubSonic injection 攻击的传统方法之一是，作为一个输入验证问题来处理，只接受列在安全值允许列表中的字符，或者识别并避免列在潜在恶意值列表（拒绝列表）中的字符。检验允许列表是一种非常有效的方法，它可以强制执行严格的输入验证规则，但是参数化的 SubSonic 语句所需的维护工作更少，而且能提供更好的安全保障。而对于通常采用的执行拒绝列表方式，由于总是存在一些小漏洞，所以并不能有效地防止 SubSonic SQL Injection 攻击。例如，攻击者可以：

— 把没有被黑名单引用的值作为目标
- 寻找方法以绕过某些需要转义的元字符
- 使用存储过程隐藏注入的元字符

手动去除 SubSonic SQL 查询中的元字符有一定的帮助，但是并不能完全保护您的应用程序免受 SubSonic SQL injection 攻击。

防范 SubSonic Injection 攻击的另外一种常用方式是使用存储过程。虽然存储过程可以阻止某些类型的 SubSonic injection 攻击，但是对于绝大多数攻击仍无能为力。存储过程有助于避免 SubSonic SQL injection 的常用方式是限制可作为参数传入的指令类型。但是，有许多方法都可以绕过这一限制，许多危险的表达式仍可以传入存储过程。所以再次强调，存储过程可以避免部分情况，但是并不能完全保护您的应用系统抵御 SubSonic injection 的攻击。

string termination error 在以下情况下出现：

1.数据通过某一函数进入程序，而该函数不会以“null”结束输出。

2.数据被传递到某个函数，而该函数的输入需要以“null”结尾。
示例 1：以下代码会从 cfgfile 进行读取，并使用 strcpy() 将输入复制到 inputbuf 中。但是，该代码会错误的假定 inputbuf 始终包含 null 终止符。

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

如果从 cfgfile 中读取的数据在磁盘上按预期以“null”结尾，则Example 1 中的代码可正常运行。但是，如果攻击者能够篡改此输入，使其不包含所需的 null 字符，则对 strcpy() 的调用将连续从内存进行复制，直到遇到任意 null 字符为止。因此，可能会溢出目标缓冲区，更有甚者，如果攻击者能够控制紧随 inputbuf 之后的内存内容，那么就会使应用程序遭受 Buffer Overflow 攻击。

示例 2：在以下代码中，readlink() 对存储在缓冲区 path 上的某个符号链接名进行了扩展，以使缓冲区 buf 包含可通过该符号链接而引用的文件的绝对路径。而最终的长度值将通过 strlen() 来计算。

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

由于通过 readlink() 读入 buf 的值不会以“null”结尾，Example 2 中的代码将无法正确运行。在测试过程中，类似于这样的漏洞可能不会被捕捉到，因为 buf 中未使用的内容或紧随其后的内存可能都为 null，因此会显示 strlen()，而这看上去似乎运行正常一样。然而，在默认情况下，strlen() 将持续遍历内存，直到在堆栈中遇到任意 null 字符为止，这会导致 length 的值远远大于 buf 的大小，从而在随后使用该值的操作中可能会造成缓冲区溢出。

示例 3：以下代码使用 snprintf() 复制用户输入字符串并将其放置在多个输出字符串中。尽管与 sprintf() 相比，snprintf() 函数提供了额外的保护机制，特别是指定了最大输出大小，但当指定的输出大小大于预期输入时，该函数仍然容易发生字符串终止错误。字符串终止错误可能导致下游问题，例如内存泄漏或缓冲区溢出。

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

Example 3 中的代码演示了内存泄漏。当 output_2 填充有 no_null_term 时，snprintf() 必须从 no_null_term 位置读取值，直到遇到 null 字符或达到指定的大小限制。因为 no_null_term 没有终止，snprintf 继续读入 output_1 数据，最终到达第一次调用 snprintf() 提供的 null 终止字符。output_2 的 printf() 演示了内存泄漏，其中包含 no_null_term 字符序列两次。

一般来说，字符串表示为一个内存区域，其中的数据以 null 字符结尾。先前的字符串处理方法往往会通过此 null 字符来确定字符串的长度。如果某个不包含 null 终止符的缓冲区被传递给其中一个函数，那么该函数就会读取到该缓冲区末尾之后的内容。

恶意用户通常会通过对应用程序注入意外大小的数据或内容，从而达到利用这类漏洞的目的。为了达到这个目的，他们可能会直接向程序提供恶意输入，或者间接地修改应用程序的资源，如配置文件等。如果攻击者能够使应用程序读取超出缓冲区边界的信息，那么他就可以利用 buffer overflow 漏洞在系统中注入或是执行任意代码。

一个或多个 Action 字段没有对应的验证定义。每个字段均应具有一个 ActionClass-validation.xml 中引用的明确验证例程。

当开发人员删除或者重命名 action form 映射后，很容易忘记更新验证逻辑。如果缺少验证器定义，就表明验证逻辑没有得到适当维护。

验证逻辑的维护至关重要，验证逻辑必须与应用程序的其余部分保持同步。未经检验的输入是导致当今一些最糟糕、最常见的软件安全问题的根源。Cross-site scripting、SQL injection 和 process control 漏洞是由于缺少输入验证或者输入验证不完整造成的。虽然 J2EE 应用程序通常情况下不容易受到内存损坏的影响，但是如果 J2EE 应用程序连接到未执行数组边界检查的本地代码，攻击者就可能会利用 J2EE 应用程序中一个输入校验错误发起 buffer overflow 攻击。

ActionClass-validation.xml 中存在多个同名字段验证器定义。重复同名验证定义可能引发意外行为。

示例 1：以下条目显示了两个重复字段验证器定义。

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

发现此 Struts2 Action 定义存在多个 ActionClass-validation.xml 文件。对以 ActionClass 形式定义的每个 Struts2 Action，Struts2 都会搜索对应的 ActionClass-validation.xml，以获取必要的验证限制。如果部署中的某一 Action（操作）存在多个验证定义，则会导致异常。

如果两个 validation form 具有相同的名称，Struts Validator 会任意选择一个来进行输入验证，而放弃另外一个。这一决策可能不是程序员所期望的。而且，它也暗示着验证逻辑没有得到维护，并暗示着存在其他更难察觉的验证错误。

验证逻辑的维护至关重要，验证逻辑必须与应用程序的其余部分保持同步。未经检验的输入是导致当今一些最糟糕、最常见的软件安全问题的根源。Cross-site scripting、SQL injection 和 process control 漏洞是由于缺少输入验证或者输入验证不完整造成的。虽然 J2EE 应用程序通常情况下不容易受到内存损坏的影响，但是如果 J2EE 应用程序连接到未执行数组边界检查的本地代码，攻击者就可能会利用 J2EE 应用程序中一个输入校验错误发起 buffer overflow 攻击。

在 validators.xml 中发现多个验证器定义。多个同名验证定义可能引发意外行为。

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

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

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

在 J2EE 应用程序中，未经检验的输入是导致漏洞发生的首要原因。未经校验的输入会导致出现各种漏洞，包括 Cross-Site Scripting、Process Control 和 SQL Injection。虽然 J2EE 应用程序通常情况下不容易受到 Memory Corruption 攻击的影响，但是如果 J2EE 应用程序连接到未执行数组边界检查的本地代码，攻击者就可能会利用 J2EE 应用程序中的某个输入校验错误发起 Buffer Overflow 攻击。

为了防止此类攻击，我们应在应用程序处理输入之前，使用 Struts Validation 框架来检验所有的程序输入。使用 Fortify Static Code Analyzer（Fortify 静态代码分析器）来确保您的 Struts Validator 配置中不存在任何漏洞。

验证器在例子中的用法包括检查并确保以下内容：

- 在电话号码字段中只包含有效字符

- 布尔值仅为“T”或者“F”

- 未限定格式的字符串必须具有合理的长度，并且由有效的字符组成

发现 Struts2 验证文件不具备匹配的 Struts2 操作。对于每个 ActionClass，Struts2 会搜索相应的 ActionClass-validation.xml 以施加必要的验证限制。在这种情况下，发现 ActionClass-validation.xml 形式的验证文件，但 ActionClass 与 Struts2 配置文件中定义的操作不匹配。

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

Struts2 验证器定义指向不存在的操作字段。

开发人员在删除或重命名操作表单映射时，很容易忘记更新验证逻辑。存在孤立的验证器定义是验证逻辑未得到妥善维护的一个迹象。

如果两个验证表单具有相同的名称，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 攻击。