华为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编码。

说明：不可信的数据（也就是其他业务系统生成的未经本应用程序验证的表数据或文件数据），通过对输出到客户端的数据进行编码，可以防止浏览器将 HTML 视为可执行脚本，从而防止跨站脚本攻击。 实施指导：

JSP语言可以通过替换输出数据的特殊字符【&<>”’ ( )%+-】为其他表示形式后再输出给客户端，例如： <%

String OutStr = \OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\OutStr = OutStr.replaceAll(\out.println(OutStr); %>

ASP.NET语言可以通过HtmlEncode方法对 HTML 的输出进行编码。

PHP语言可以通过htmlentities或htmlspecialchars方法对HTML输出进行编码。 4.3 上传下载

规则4.3.1：必须在服务器端采用白名单方式对上传或下载的文件类型、大小进行严格的限制。

规则4.3.2：禁止以用户提交的数据作为读/写/上传/下载文件的路径或文件名，以防止目录跨越和不安全直接对象引用攻击。 说明：建议对写/上传文件的路径或文件名采用随机方式生成，或将写/上传文件放置在有适当访问许可的专门目录。对读/下载文件采用映射表（例如，用户提交的读文件参数为1，则读取file1，参数为2，则读取file2）。防止恶意用户构造路径和文件名，实施目录跨越和不安全直接对象引用攻击。

规则4.3.3：禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放在Web内容目录下。

说明：Web内容目录指的是：通过Web可以直接浏览、访问的目录，存放在Web内容目录下的文件容易被攻击者直接下载。 4.4 异常处理

规则4.4.1：应用程序出现异常时，禁止向客户端暴露不必要的信息，只能向客户端返回一般性的错误提示消息。

说明：应用程序出现异常时，禁止将数据库版本、数据库结构、操作系统版本、堆栈跟踪、文件名和路径信息、SQL 查询字符串等对攻击者有用的信息返回给客户端。建议重定向到一个统一、默认的错误提示页面，进行信息过滤。 规则4.4.2：应用程序捕获异常，并在日志中记录详细的错误信息。 说明：记录详细的错误消息，可供入侵检测及问题定位。 4.5 代码注释

规则4.5.1：在注释信息中禁止包含物理路径信息。 规则4.5.2：在注释信息中禁止包含数据库连接信息。 规则4.5.3：在注释信息中禁止包含SQL语句信息。

规则4.5.4：对于静态页面，在注释信息中禁止包含源代码信息。 规则4.5.5：对于动态页面不使用普通注释，只使用隐藏注释。

说明：动态页面包括ASP、PHP、JSP、CGI等由动态语言生成的页面。通过浏览器查看源码的功能，能够查看动态页面中的普通注释信息，但看不到隐藏注释（隐藏注释不会发送给客户端）。因此，为了减少信息泄漏，建议只使用隐藏注释。 实施指导：

<%

//隐藏注释2

java.lang.String str=(String)request.getParameter(\/*隐藏注释3*/

str = str.replaceAll(\out.println(str); %>

4.6 归档要求

规则4.6.1：版本归档时，必须删除开发过程（包括现场定制）中的临时文件、备份文件、无用目录等。

说明：恶意用户可以通过URL请求诸如.bak之类的文件，Web服务器会将这些文件以文本方式呈现给恶意用户，造成代码的泄漏，严重威胁Web应用的安全。 实施指导：

在web应用的根目录下执行以下命令：

find ./ -name \-o -name \-o -name \-o -name \-o -name \\\\

分析查找到的文件是否临时文件、备份文件、无用文件，如果是则删除。 规则4.6.2：归档的页面程序文件的扩展名必须使用小写字母。

说明：很多Web server对大小写是敏感的，但对后缀的大小写映像并没有做正确的处理。攻击者只要在URL中将JSP文件后缀从小写变成大写，Web服务器就不能正确处理这个文件后缀，而将其当作纯文本显示。攻击者可以通过查看源码获得这些程序的源代码。因此，归档的页面程序文件的扩展名必须使用小写字母，如jsp、html、htm、asp等页面程序文件的扩展名分别为jsp、html、htm、asp。

规则4.6.3：归档的程序文件中禁止保留调试用的代码。

说明：这里的“调试用的代码”是指开发过程中进行临时调试所用的、在Web应用运行过程中不需要使用到的Web页面代码或servlet代码。例如：在代码开发过程中为了测试一个添加帐号的功能，开发人员临时编写了一个JSP页面进行测试，那么在归档时，该JSP页面必须删除，以免被攻击者利用。 4.7 其他

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说教育文库华为Web应用安全开发规范(4)在线全文阅读。