华为Web应用安全开发规范

3.3 会话管理

规则3.3.1：使用会话cookie维持会话。 说明：目前主流的Web容器通过以下几种方式维持会话：隐藏域、URL重写、持久性cookie、会话cookie，但通过隐藏域、URL重写或持久性cookie方式维持的会话容易被窃取，所以要求使用会话cookie维持会话。如果条件限制必须通过持久性cookie维持会话的话，那么cookie信息中的重要数据部分如身份信息、计费信息等都必须进行加密。（cookie有两种：会话cookie和持久性cookie；会话cookie，也就是非持久性cookie，不设置过期时间，其生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了；会话cookie一般不存储在硬盘上而是保存在内存里。持久性cookie，设置了过期时间，被浏览器保存到硬盘上，关闭后再次打开浏览器，持久性cookie仍然有效直到超过设定的过期时间。） 备注：对于嵌入式系统的Web，不适合本条规则，按\规则3.3.9\实施。

规则3.3.2：会话过程中不允许修改的信息，必须作为会话状态的一部分在服务器端存储和维护。

说明：会话过程中不允许修改的信息，例如，当用户通过认证后，其用户标识在整个会话过程中不能被篡改。禁止通过隐藏域或URL重写等不安全的方式存储和维护。对JSP语言，就是应该通过session对象进行存储和维护。

规则3.3.3：当Web应用跟踪到非法会话，则必须记录日志、清除会话并返回到认证界面。 说明：非法会话的概念就是通过一系列的服务端合法性检测（包括访问未授权资源，缺少必要参数等情况），最终发现的不是正常请求产生的会话。

规则3.3.4：禁止使用客户端提交的未经审核的信息来给会话信息赋值。 说明：防止会话信息被篡改，如恶意用户通过URL篡改手机号码等。 规则3.3.5：当用户退出时，必须清除该用户的会话信息。 说明：防止遗留在内存中的会话信息被窃取，减少内存占用。

实施指导：对于JSP或java语言使用如下语句：request.getSession().invalidate(); 规则3.3.6：必须设置会话超时机制，在超时过后必须要清除该会话信息。

说明：建议默认会话超时时间为10分钟（备注：对于嵌入式系统中的Web，建议默认超时时间为5分钟，以减少系统资源占用）。如果没有特殊需求，禁止使用自动发起请求的机制来阻止session超时。

规则3.3.7：在服务器端对业务流程进行必要的流程安全控制，保证流程衔接正确，防止关键鉴别步骤被绕过、重复、乱序。

说明：客户端流程控制很容易被旁路（绕过），因此流程控制必须在服务器端实现。 实施指导：可以通过在session对象中创建一个表示流程当前状态的标识位，用0、1、2、3、...、N分别表示不同的处理步骤，标识位的初始值为0，当接收到步骤N的处理请求时，判断该标识位是否为N-1，如果不为N-1，则表示步骤被绕过（或重复或乱序），拒绝受理，否则受理，受理完成后更改标识位为N。

规则3.3.8：所有登录后才能访问的页面都必须有明显的\注销（或退出）\的按钮或菜单，如果该按钮或菜单被点击，则必须使对应的会话立即失效。

说明：这样做是为了让用户能够方便地、安全地注销或退出，减小会话劫持的风险。 规则3.3.9：如果产品（如嵌入式系统）无法使用通用的Web容器，只能自己实现Web服务，那么必须自己实现会话管理，并满足以下要求： ? 采用会话cookie维持会话。

? 生成会话标识（session ID）要保证足够的随机、离散，以便不能被猜测、枚举，要求session ID要至少要32字节，要支持字母和数字字符集。

? 服务端必须对客户端提交的session ID的有效性进行校验。

说明：在嵌入式系统中部署Web应用，由于软硬件资源所限，往往无法使用通用的Web容器及容器的会话管理功能，只能自己实现。另外，为了节省内存，嵌入式webserver进程往往是动态启动，为了使session更快的超时，建议增加心跳机制，对客户端浏览器是否关闭进行探测，5s一个心跳，30s没有心跳则session超时，关闭该session。 3.4 权限管理

规则3.4.1：对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是否合法、用户是否被授权执行这个操作。

说明：防止用户通过直接输入URL，越权请求并执行一些页面或servlet；建议通过过滤器实现。

实施指导：请参考\附件5 Web权限管理设计规格说明书.docx\。

规则3.4.2：授权和用户角色数据必须存放在服务器端，不能存放在客户端，鉴权处理也必须在服务器端完成。

说明：禁止将授权和角色数据存放在客户端中（比如cookie或隐藏域中），以防止被篡改。 规则3.4.3：一个帐号只能拥有必需的角色和必需的权限。一个组只能拥有必需的角色和必需的权限。一个角色只能拥有必需的权限。

说明：做到权限最小化和职责分离（职责分离就是分清帐号角色，系统管理帐号只用于系统管理，审计帐号只用于审计，操作员帐号只用于业务维护操作，普通用户帐号只能使用业务。）这样即使帐号被攻击者盗取，也能把安全损失控制在最小的限度。 规则3.4.4：对于运行应用程序的操作系统帐号，不应使用\、\、\等特权帐号或高级别权限帐号，应该尽可能地使用低级别权限的操作系统帐号。

规则3.4.5：对于应用程序连接数据库服务器的数据库帐号，在满足业务需求的前提下，必须使用最低级别权限的数据库帐号。 说明：根据业务系统要求，创建相应的数据库帐号，并授予必需的数据库权限。不能使用\、\等管理帐号或高级别权限帐号。 3.5 敏感数据保护 3.5.1 敏感数据定义

敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短消息的内容）、授权凭据、个人数据（如姓名、住址、电话等）等，在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。 3.5.2 敏感数据存储

规则3.5.2.1：禁止在代码中存储敏感数据。

说明：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。

规则3.5.2.2：禁止密钥或帐号的口令以明文形式存储在数据库或者文件中。

说明：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。

规则3.5.2.3：禁止在 cookie 中以明文形式存储敏感数据。

说明：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。 规则3.5.2.4：禁止在隐藏域中存放明文形式的敏感数据。

规则3.5.2.5：禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。 实施指导：

场景 1：后台服务端保存数据库的登录口令

后台服务器登录数据库需要使用登录数据库的明文口令，此时后台服务器加密保存该口令后，下次登录时需要还原成明文，因此，在这种情况下，不可用不可逆的加密算法，而需要使用对称加密算法或者非对称加密算法，一般也不建议采用非对称加密算法。 推荐的对称加密算法：AES128、AES192、AES256。 场景 2：后台服务端保存用户的登录口令

在该场景下，一般情况是：客户端提交用户名及用户口令，后台服务端对用户名及用户口令进行验证，然后返回验证的结果。此时，在后台服务端，用户口令可以不需要还原，因此建议使用不可逆的加密算法，对\用户名+口令\字符串进行加密。

推荐的不可逆加密算法： SHA256、SHA384、SHA512，HMAC-SHA256、HMAC-SHA384、HMAC-SHA512。

规则3.5.2.6：禁止在日志中记录明文的敏感数据。

说明：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等），防止敏感信息泄漏。

规则3.5.2.7：禁止带有敏感数据的Web页面缓存。

说明：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。 实施指导：

在HTML页面的标签内加入如下代码：

在JSP页面的最前面加入如下代码： <%

response.setHeader(\ response.setHeader(\ response.setDateHeader(\ %>

注意：以上代码对于采用强制缓存策略的代理服务器不生效（代理服务器默认是不缓存的），要防止代理服务器缓存页面，可以在链接后加入一个随机数pageid,此时链接变成：http://localhost:8080/query.do?a=2&pageid=2245562, 其中2245562数字是随机生成的，每次请求此页面时，随机数都不同，IE始终认为此为一个新请求，并重新解析，生成新的响应页面。 3.5.3 敏感数据传输

规则3.5.3.1：带有敏感数据的表单必须使用 HTTP-POST 方法提交。 说明：禁止使用 HTTP-GET 方法提交带有敏感数据的表单（form），因为该方法使用查询字符串传递表单数据，易被查看、篡改。如果是使用servlet处理提交的表单数据，那么不在doGet方法中处理，只在doPost方法处理。 实施指导：

1. 对于JSP页面，将表单的属性method赋值为\，如下