华为Web应用安全开发规范

2. 如果是使用servlet处理提交的表单数据，那么只在doPost方法中处理，参考代码如下

public class ValidationServlet extends HttpServlet {

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {

//对提交的表单数据进行校验 } }

规则3.5.3.2：在客户端和服务器间传递明文的敏感数据时，必须使用带服务器端证书的SSL。

说明：如果在客户端和服务器间传递如帐号、口令等明文的敏感数据，必须使用带服务器端证书的SSL。由于SSL对服务端的CPU资源消耗很大，实施时必须考虑服务器的承受能力。

实施指导：

1. SSL的配置请参考《附件1 Tomcat配置SSL指导》。

2. Web应用中，从https切换到http过程中会丢失session，无法保持会话的连续。解决的办法就是用http-https-http过程代替https-http过程，保证会话的连续性。原因：当https请求转为http请求的时候，因为原先的session的secure属性值是true，无法再http协议中传输，因此，系统生成新的session，且新的session没有继承旧session的属性和值，因此，无法保持会话连续。而http-https-http这个过程，session始终不变，因此，可以保持会话连??? 规则3.5.3.3：禁止在URL中携带会话标识（如jsessionid）。

说明：由于浏览器会保存URL历史记录，如果URL中携带会话标识，则在多人共用的PC上会话标识容易被其他人看到，一旦该会话标识还在其生命有效期，则恶意用户可以冒充受害用户访问Web应用系统。 规则3.5.3.4：禁止将对用户保密的信息传送到客户端。

说明：这些信息一旦传送到客户端，那么用户也就可以获取到了。 3.6 安全审计

本节的安全审计是针对Web业务应用，不包括对操作系统、Web容器的安全审计。对于操作系统和Web容器的安全审计，可以参考对应的操作系统安全基线和Web安全配置规范。

规则3.6.1：应用服务器必须对安全事件及操作事件进行日志记录。

说明：安全事件包括登录、注销、添加、删除、修改用户、授权、取消权限、鉴权、修改用户口令等；操作事件包括对业务系统配置参数的修改，对重要业务数据的创建、删除、修改、查询等；对于上述事件的结果，不管是成功还是失败，都需要记录日志。 规则3.6.2：安全日志必须包括但不限于如下内容：事件发生的时间、事件类型、客户端IP、客户端机器名、当前用户的标识、受影响的个体（数据、资源）、成功或失败标识、启动该事件的进程标识以及对该事件的详细描述。 规则3.6.3：严格限制对安全日志的访问。

说明：只有Web应用程序的管理员才能查询数据库表形式或文件形式的安全日志；除数据库超级管理员外，只有应用程序连接数据库的帐号可以查询（select）及插入（insert）安全日志表；除操作系统超级管理员外，只有应用程序的运行帐户才能读、写文件形式的安全日志（但不允许删除）。确保日志的安全，限制对日志的访问，这加大了攻击者篡改日志文件以掩饰其攻击行为的难度。 规则3.6.4：对日志模块占用资源必须有相应的限制机制。 说明：限制日志模块占用的资源，以防止如自动的恶意登陆尝试导致的资源枯竭类DOS攻击；比如限制日志记录占用的磁盘空间。 规则3.6.5：禁止日志文件和操作系统存储在同一个分区中，同时，应使用转储、滚动、轮循机制，来防止存储日志的分区写满。

说明：所需空间和具体业务、局点容量、日志保存周期相关，要根据实际情况估算。

建议3.6.1：安全日志应该有备份及清理机制。 说明：备份及清理机制包括定期备份及清理安全日志和监控用于存放安全日志的磁盘空间的使用情况。可以配置定期备份及清理的时间，可以配置以用于存放安全日志的磁盘空间使用率达到多少时进行备份及清理。 建议3.6.2：通过网络形式保存安全日志。

说明：在生成安全日志时，即时将日志保存到网络上其他主机，而且生成安全日志的应用程序不能再访问存放在其他主机的日志。 3.7 Web Service

规则3.7.1：对Web Service接口的调用必须进行认证。

说明：认证就是确定谁在调用Web Service，并且证实调用者身份。 实施指导：

可以通过在消息头中增加用户名和口令，作为认证凭据；

对于安全性要求不高、只向同一信任域内其他主机开放的Web Service接口，可以通过简单的IP认证来实现接口的认证（只有服务器端指定IP地址的客户端才允许调用，IP地址可配置）。 规则3.7.2：如果调用者的权限各不相同，那么必须对Web Service接口的调用进行鉴权。

说明：鉴权就是判断调用者是否有权限调用该Web Service接口。 实施指导：

可以通过Axis的handler对调用进行鉴权。

规则3.7.3：通过Web Service接口传递敏感数据时，必须保障其机密性。 实施指导：

方案1：请参考《附件2 Web Service 安全接入开发指导》。 方案2：采用https安全协议。 规则3.7.4：通过Web Service接口传递重要的交易数据时，必须保障其完整性和不可抵赖性。 说明：重要的交易数据，如转账时涉及的“转入账号”、“转出账号”、“金额”等。 实施指导：

请参考《附件2 Web Service 安全接入开发指导》。

规则3.7.5：如果Web Service只对特定的IP开放，那么必须对调用Web Service接口的客户端IP进行鉴权，只有在IP地址白名单中的客户端才允许调用，IP地址白名单可配置。

实施指导：请参考《附件3客户端IP鉴权实施指导》。 规则3.7.6：对Web Service接口调用进行日志记录。

说明：日志内容包括但不限于如下内容：调用时间、操作类型、调用接口名称、详细的接口参数、客户端IP、客户端机器名、调用者的用户标识、受影响的个体（数据、资源）、成功或失败标识。

规则3.7.7：必须对Web Service提交的参数进行输入校验。 说明：具体输入校验部分请查看4.1输入校验。 3.8 RESTful Web Service RESTful Web Service（也称为 RESTful Web API）是一个使用HTTP并遵循REST原则的Web服务。

规则3.8.1：对RESTful Web Service的调用必须进行认证。

说明：认证就是确定谁在调用RESTful Web Service，并且证实调用者身份。 实施指导：

客户端发起的Restful请求需要在消息头带Authorization字段，内容填Basic Base64(user:pass)，服务端对user和passwd进行认证。

注意：user和pass必须加密保存在配置文件或数据库中，不能写死在代码中；传输时采用https安全协议。

对于安全性要求不高、只向同一信任域内其他主机开放的Web Service接口，可以通过简单的IP认证来实现接口的认证（只有服务器端指定IP地址的客户端才允许调用，IP地址可配置）。

规则3.8.2：如果调用者的权限各不相同，那么必须对RESTful Web Service的调用进行鉴权。

说明：鉴权就是判断调用者是否有权限调用该RESTful Web Service。

规则3.8.3：通过RESTful Web Service传递敏感数据时，必须保障其机密性。 实施指导：

采用https安全协议。

规则3.8.4：如果RESTful Web Service只对特定的IP开放，那么必须对调用RESTful Web Service的客户端IP进行鉴权，只有在IP地址白名单中的客户端才允许调用，IP地址白名单可配置。 实施指导：

请参考《附件3客户端IP鉴权实施指导》。

规则3.8.5：对RESTful Web Service调用进行日志记录。

说明：日志内容包括但不限于如下内容：调用时间、操作类型、调用接口名称、详细的接口参数、客户端IP、客户端机器名、调用者的用户标识、受影响的个体（数据、资源）、成功或失败标识。

规则3.8.6：必须对RESTful Web Service提交的参数进行输入校验。 说明：具体输入校验部分请查看4.1输入校验。 3.9 DWR

DWR（Direct Web Remoting）是一种Java 和JavaScript 相结合的开源框架，可以帮助开发人员更容易地完成应用Ajax 技术的Web 应用程序，让浏览器上的JavaScript 方法调用运行在Web 服务器上的Java 方法。 规则3.9.1：关闭DWR 调试功能。

说明：如果开启了DWR调试功能，那么攻击者可以轻易查看和调用系统提供的所有DWR接口，所以，版本发布时，一定要关闭DWR调试功能。 实施指导：

修改对应的web.xml文件中的debug参数值为false：

dwr-invoker

org.directwebremoting.servlet.DwrServlet

debug false ......

规则3.9.2：对DWR接口的调用必须进行认证。

说明：认证就是确定谁在调用DWR接口，并且证实调用者身份。 实施指导：

对于DWR接口的认证直接沿用3.2.2认证机制，不用单独再做认证。 规则3.9.3：对DWR接口的调用必须进行鉴权。

说明：鉴权就是判断调用者是否有权限调用该DWR接口。 实施指导：

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 其他

本文来源：https://www.bwwdw.com/article/kq13.html