华为WEB应用系统安全规范v1

《华为WEB应用系统安全规范v1》由会员分享，可在线阅读，更多相关《华为WEB应用系统安全规范v1（38页珍藏版）》请在金锄头文库上搜索。

1、. . . . . S. . . . . . DKBA 华为技术部技术规 DKBA 1606-XXXX.X Web 应用安全开发规 V1.5 2013 年 XX 月 XX 日发布 2013 年 XX 月 XX 日实施 华为技术 Huawei Technologies Co., Ltd. 所有 侵权必究 All rights reserved . . . . . S. . . . . . 修订声明修订声明 RevisionRevision declarationdeclaration 本规拟制与解释部门：本规拟制与解释部门： 网络安全能力中心 HttpSession newSession=req

2、uest.getSession(true); Cookie cookie = new Cookie(JSESSIONID,newSession.getId(); cookie.setMaxAge(-1); cookie.setSecure(false); cookie.setPath(request.getContextPath(); response.addCookie(cookie); 场景二：对于全程采用 HTTPS 协议，或者全程采用 HTTP 协议的，在用户名和密码认证通 过后增加以下行代码： request.getSession().invalidate(); request.ge

3、tSession(true); 建议建议 3.2.2.13.2.2.1：管理页面建议实施强身份认证。 说明：如双因素认证、SSL 双向证书认证、生物认证等；还可以通过应用程序限制只允许某 些特定的 IP 地址访问管理页面，并且这些特定的 IP 地址可配置。 建议建议 3.2.2.23.2.2.2：同一客户端在多次连续尝试登录失败后，服务端需要进行用户或者是客户端 所在机器的 IP 地址的锁定策略，且该锁定策略必须设置解锁时长，超时后自动解锁。 说明： 登录失败应该提示用户：如果重试多少次不成功系统将会锁定。在锁定期间不允许该 用户（或者客户端所在机器的 IP 地址）登录。 允许连续失败的次数（

4、指从最后一次成功以来失败次数的累计值）可配置，取值围为： . . . . . S. . . . . . 0-99 次，0 表示不执行锁定策略，建议默认：5 次。 锁定时长的取值围为：0-999 分钟，建议默认：30 分钟，当取值为 0 时，表示无限 期锁定，只能通过管理员手动解锁（需要提供管理员对服务器锁定其它用户/IP 进行解锁的 功能界面）。建议优先使用锁定策略。 注意：应用程序的超级用户不能被锁定，只能锁定操作的客户端所在的 IP，这是为了 防止系统不可用。特别说明：锁客户端 IP 策略存在缺陷，当用户使用 proxy 上网时，那么 锁定客户端 IP 会导致使用该 proxy 上网的所有

5、用户在 IP 锁定期间都不能使用该 Web 应用； 锁定用户的策略也存在缺陷，当攻击者不断尝试某的口令，就给该带来拒绝服务攻击，使 该不可用。 3.2.3验证码 规则规则 3.2.3.13.2.3.1：验证码必须是单一图片，且只能采用 JPEG、PNG 或 GIF 格式。 说明：验证码不能使用文本格式，不允许多图片组合（如用四个图片拼成的验证码）。 规则规则 3.2.3.23.2.3.2：验证码容不能与客户端提交的任何信息相关联。 说明：在使用验证码生成模块时不允许接收来自客户端的任何参数，例如：禁止通过 getcode.jsp?code=1234 的 URL 请求，将 1234 作为验证码随

6、机数。 规则规则 3.2.3.33.2.3.3：验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。 说明：在客户端网页上点击鼠标右键、选择“查看源文件”时，必须看不到验证码模块生 成的随机数。 规则规则 3.2.3.43.2.3.4：验证码字符串要随机生成，生成的随机数必须是安全的。 说明：对于 java 语言可以使用类 java.security.SecureRandom 来生成安全的随机数。 规则规则 3.2.3.53.2.3.5：验证码要求有背景干扰，背景干扰元素的颜色、位置、数量要求随机变化。 规则规则 3.2.3.63.2.3.6：验证码在一次使用后要求立即失效，新的

7、请求需要重新生成验证码。 说明：进行验证码校验后，立即将会话中的验证码信息清空，而不是等到生成新的验证码 时再去覆盖旧的验证码，防止验证码多次有效；注意：当客户端提交的验证码为空，验证 不通过。 说明： 以上规则可以通过使用电信软件与核心网网络安全工程部提供的验证码 CBB来实现。 . . . . . S. . . . . . 3.3会话管理 规则规则 3.3.13.3.1：使用会话 cookie 维持会话。 说明：目前主流的 Web 容器通过以下几种方式维持会话：隐藏域、URL 重写、持久性 cookie、会话 cookie，但通过隐藏域、URL 重写或持久性 cookie 方式维持的会话容

8、易被窃 取，所以要求使用会话 cookie 维持会话。如果条件限制必须通过持久性 cookie 维持会话 的话，那么 cookie 信息中的重要数据部分如身份信息、计费信息等都必须进行加密。 （cookie 有两种：会话 cookie 和持久性 cookie；会话 cookie，也就是非持久性 cookie， 不设置过期时间，其生命期为浏览器会话期间，只要关闭浏览器窗口，cookie 就消失了； 会话 cookie 一般不存储在硬盘上而是保存在存里。持久性 cookie，设置了过期时间，被浏 览器保存到硬盘上，关闭后再次打开浏览器，持久性 cookie 仍然有效直到超过设定的过期 时间。） 备

9、注：对于嵌入式系统的 Web，不适合本条规则，按“规则规则 3.3.93.3.9”实施。 规则规则 3.3.23.3.2：会话过程中不允许修改的信息，必须作为会话状态的一部分在服务器端存储和 维护。 说明：会话过程中不允许修改的信息，例如，当用户通过认证后，其用户标识在整个会话 过程中不能被篡改。禁止通过隐藏域或 URL 重写等不安全的方式存储和维护。对 JSP 语言， 就是应该通过 session 对象进行存储和维护。 规则规则 3.3.33.3.3：当 Web 应用跟踪到非法会话，则必须记录日志、清除会话并返回到认证界面。 说明： 非法会话的概念就是通过一系列的服务端合法性检测（包括访问未

10、授权资源，缺少 必要参数等情况），最终发现的不是正常请求产生的会话。 规则规则 3.3.43.3.4：禁止使用客户端提交的未经审核的信息来给会话信息赋值。 说明：防止会话信息被篡改，如恶意用户通过 URL 篡改手机等。 规则规则 3.3.53.3.5：当用户退出时，必须清除该用户的会话信息。 说明：防止遗留在存中的会话信息被窃取，减少存占用。 实施指导：对于 JSP 或 java 语言使用如下语句：request.getSession().invalidate(); 规则规则 3.3.63.3.6：必须设置会话超时机制，在超时过后必须要清除该会话信息。 说明：建议默认会话超时时间为 10 分钟

11、（备注：对于嵌入式系统中的 Web，建议默认超 . . . . . S. . . . . . 时时间为 5 分钟，以减少系统资源占用）。如果没有特殊需求，禁止使用自动发起请求的 机制来阻止 session 超时。 规则规则 3.3.73.3.7：在服务器端对业务流程进行必要的流程安全控制，保证流程衔接正确，防止关 键鉴别步骤被绕过、重复、乱序。 说明：客户端流程控制很容易被旁路（绕过），因此流程控制必须在服务器端实现。 实施指导：可以通过在 session 对象中创建一个表示流程当前状态的标识位，用 0、1、2、3、N 分别表示不同的处理步骤，标识位的初始值为 0，当接收到步骤 N 的 处理请

12、求时，判断该标识位是否为 N-1，如果不为 N-1，则表示步骤被绕过（或重复或乱序） ，拒绝受理，否则受理，受理完成后更改标识位为 N。 规则规则 3.3.83.3.8：所有登录后才能访问的页面都必须有明显的“注销（或退出）”的按钮或菜单， 如果该按钮或菜单被点击，则必须使对应的会话立即失效。 说明：这样做是为了让用户能够方便地、安全地注销或退出，减小会话劫持的风险。 规则规则 3.3.93.3.9：如果产品（如嵌入式系统）无法使用通用的 Web 容器，只能自己实现 Web 服务，那么必须自己实现会话管理，并满足以下要求： 采用会话 cookie 维持会话。 生成会话标识（session ID

13、）要保证足够的随机、离散，以便不能被猜测、枚举，要求 session ID 要至少要 32 字节，要支持字母和数字字符集。 服务端必须对客户端提交的 session ID 的有效性进行校验。 说明：在嵌入式系统中部署 Web 应用，由于软硬件资源所限，往往无法使用通用的 Web 容器及容器的会话管理功能，只能自己实现。另外，为了节省存，嵌入式 webserver 进程 往往是动态启动，为了使 session 更快的超时，建议增加心跳机制，对客户端浏览器是否关 闭进行探测，5s 一个心跳，30s 没有心跳则 session 超时，关闭该 session。 3.4权限管理 规则规则 3.4.13.

14、4.1：对于每一个需要授权访问的页面或 servlet 的请求都必须核实用户的会话标识 是否合法、用户是否被授权执行这个操作。 说明：防止用户通过直接输入 URL，越权请求并执行一些页面或 servlet；建议通过过滤器 实现。 实施指导： 请参考“附件 5 Web 权限管理设计规格说明书.docx”。 . . . . . S. . . . . . 规则规则 3.4.23.4.2：授权和用户角色数据必须存放在服务器端，不能存放在客户端，鉴权处理也必 须在服务器端完成。 说明：禁止将授权和角色数据存放在客户端中（比如 cookie 或隐藏域中），以防止被篡改。 规则规则 3.4.33.4.3：一个只能拥有必需的角色和必需的权限。一个组只能拥有必需的角色和必需的 权限。一个角色只能拥有必需的权限。 说明：做到权限最小化和职责分离（职责分离就是分清角色，系统管理只用于系统管理， 审计只用于审计，操作员只用于业务维护操作，普通用户只能使用业务。）这样即使被攻 击者盗取，也能把安全损失控制在最小的限度。 规则规则 3.4.43.4.4：对于运行应用程序的操作系统，不应使用“root”、“administrator”、 “supervisor”等特权或高级别权限，应该尽可能地使用低级别权限的操作系统。 规则规则 3.4.53.4.5：对于应用程序连