华为Web应用安全开发规范(4)

DWR的请求和普通的Web请求一样，都可以通过过滤器来鉴权，对于DWR接口的鉴权直接沿用规则3.4.1的鉴权机制，具体实现参照规则3.4.1的实施指导。 规则3.9.4：必须对DWR提交的参数进行输入校验。 说明：具体输入校验部分请查看4.1输入校验。 4 Web编程安全规范 4.1 输入校验

规则4.1.1：必须对所有用户产生的输入进行校验，一旦数据不合法，应该告知用户输入非法并且建议用户纠正输入。 说明：用户产生的输入是指来自text、password、textareas或file表单域的数据；必须假定所有用户产生的输入都是不可信的，并对它们进行合法性校验。

规则4.1.2：必须对所有服务器产生的输入进行校验，一旦数据不合法，必须使会话失效，并记录告警日志。

说明：服务器产生的输入是指除用户产生的输入以外的输入，例如来自hidden fields、selection boxes、check boxes、radio buttons、cookies、HTTP headers、热点链接包含的URL参数的数据或客户端脚本等；必须假定所有服务器产生的输入都是被篡改过的、恶意的，并对它们进行合法性校验，如果不合法，说明有人恶意篡改数据。举例：假如用户资料填写表单中的“性别”为必填项，用radio button（‘男’和‘女’对应实际值分别为‘1’和‘0’）来限制用户的输入，如果应用程序收到的“性别”值为‘2’，那么可以断定有人恶意篡改数据。 规则4.1.3：禁止将HTTP标题头中的任何未加密信息作为安全决策依据。 说明：HTTP 标题头是在 HTTP 请求和 HTTP 响应的开始阶段发送的。Web 应用程序必须确保不以 HTTP 标题头中的任何未加密信息作为安全决策依据，因为攻击者要操作这一标题头是很容易的。例如，标题头中的 referer 字段包含来自请求源端的 Web 页面的 URL。不要根据 referer 字段的值做出任何安全决策（如检查请求是否来源于 Web 应用程序生成的页面），因为该字段是很容易被伪造的。

规则4.1.4：不能依赖于客户端校验，必须使用服务端代码对输入数据进行最终校验。

说明：客户端的校验只能作为辅助手段，减少客户端和服务端的信息交互次数。 规则4.1.5：对于在客户端已经做了输入校验，在服务器端再次以相同的规则进行校验时，一旦数据不合法，必须使会话失效，并记录告警日志。

说明：肯定存在攻击行为，攻击者绕过了客户端的输入校验，因此必须使会话失效，并记入告警日志。

规则4.1.6：如果输入为数字参数则必须进行数字型判断。 说明：这里的数字参数指的是完全由数字组成的数据。 实施指导：

String mobileno = request.getParameter(\

String characterPattern = \ //正则表达式表示是否全为数字 if (!mobileno.matches (characterPattern)) {

out.println (“Invalid Input”); }

规则4.1.7：如果输入只允许包含某些特定的字符或字符的组合，则使用白名单进行输入校验。

说明：对于一些有规则可循的输入，如email地址、日期、小数等，使用正则表达式进行白名单校验，这样比使用黑名单进行校验更有效。 实施指导：

email地址校验的方法：

String emailAddress = request.getParameter(\String characterPattern = \-zA-Z]{2,4}$\正则表达式

if (!emailAddress.matches(characterPattern)) {

out.println (“Invalid Email Address”); }

规则4.1.8：如果输入为字符串参数则必须进行字符型合法性判断。 说明：可定义一个合法字符集。 实施指导：

String text = request.getParameter(\

String characterPattern = \开发者自行定义字符规则(方括号内的字符集)

if (!text.matches (characterPattern)) {

out.println (“Invalid Input”); }

规则4.1.9：校验输入数据的长度。

说明：如果输入数据是字符串，必须校验字符串的长度是否符合要求，长度校验会加大攻击者实施攻击的难度。 规则4.1.10：校验输入数据的范围。

说明：如果输入数据是数值，必须校验数值的范围是否正确，如年龄应该为0～150之间的正整数。

规则4.1.11：禁止通过字符串串联直接使用用户输入构造可执行 SQL 语句。 说明：禁止通过字符串串联直接使用用户输入构造可执行 SQL 语句，如：string sql = \这样很容易被SQL注入攻击。

规则4.1.12：对于java/JSP语言，使用预编译语句PreparedStatement代替直接的语句执行Statement。

说明：使用预编译语句PreparedStatement，类型化 SQL 参数将检查输入的类型，确保输入值在数据库中当作字符串、数字、日期或boolean等值而不是可执行代码进行处理，从而防止SQL注入攻击。而且，由于 PreparedStatement 对象已预编译过，所以其执行速度要快于 Statement 对象。因此，多次执行的 SQL 语句经常创建为 PreparedStatement 对象，还可以提高效率。 实施指导： 参考如下代码：

String inssql = \PreparedStatement stmt = null;

stmt = conn.prepareStatement(inssql);

stmt.setString(1, empid); stmt.setString(2, name); stmt.setInt(3, age);

stmt.setDate(4, birthday); stmt.execute();

备注：使用like进行模糊查询时，如果直接用\like %?%\，程序会报错，必须采用如下方法

String express = \pstmt = con.prepareStatement(express); String c=\

pstmt.setString(1, \

//参数自动添加单引号，最后的SQL语句为：select * from table where comment like '%hello%' pstmt.execute();

规则4.1.13：禁止动态构建XPath语句。

说明：和动态构建SQL一样，动态构建XPath语句也会导致注入漏洞（XPath注入）。动态构建XPath语句的例子：public boolean doLogin(String loginID, String password){...... XPathExpression expr = xpath.compile(\and password/text()='\ ......}

规则4.1.14：在JavaBean中禁止使用property=\进行参数赋值。 说明：property=\这表明用户在可见的JSP页面中输入的，或是直接通过Query String提交的参数值，将存储到与参数名相匹配的bean属性中。例如，网上购物程序，一般，用户是这样提交请求的：http://www.somesite.com /addToBasket.jsp?newItem=ITEM0105342，如果用户提交：http://www.somesite.com

/addToBasket.jsp?newItem=ITEM0105342&balance=0，这样，balance=0的信息就被在存储到了JavaBean中了，而balance是整个会话中用来存储总费用的，当他们这时点击“chekout”结账的时候，费用就全免了。

规则4.1.15：用于重定向的输入参数不能包含回车和换行字符，以防止HTTP响应拆分攻击。 说明：注意，“回车”字符有多种表示方式（CR = = \\r ），“换行”字符有多种表示方式（LF = = \\n）。

规则4.1.16：如果服务端代码执行操作系统命令，禁止从客户端获取命令。 说明：如果服务端代码中使用Runtime.getRuntime().exec(cmd)或ProcessBuilder等执行操作系统命令，那么禁止从客户端获取命令；而且最好不要从客户端获取命令的参数，如果必须从客户获取命令的参数，那么必须采用正则表达式对命令参数进行严格的校验，以防止命令注入（因为，一旦从客户端获取命令或参数，通过;&|<>符号，非常容易构造命令注入，危害系统）。 4.2 输出编码

规则4.2.1：对于不可信的数据，输出到客户端前必须先进行HTML编码。

说明：不 …… 此处隐藏：3766字，全部文档内容请下载后查看。喜欢就下载吧 ……