华为技术有限公司内部技术规范模板.doc

DKBA华为技术内部技术规范DKBA 1606-XXXX.XWeb应用安全开发规范 V1.5XX月XX日公布 XX月XX日实施华为技术Huawei Technologies Co., Ltd.版权全部 侵权必究All rights reserved修订申明Revision declaration本规范拟制和解释部门：网络安全能力中心&电信软件和关键网网络安全工程部本规范相关系列规范或文件：C&C+语言安全编程规范Java语言安全编程规范相关国际规范或文件一致性：无替换或作废其它规范或文件：无相关规范或文件相互关系：产品网络安全红线和电信软件和关键网业务部安全能力基线中Web安全要求引用了本规范内容，假如存在冲突，以本规范为准。规范号关键起草部门教授关键评审部门教授修订情况DKBA 1606-.4安全处理方案：赵武42873，杨光磊57125，万振华55108软件企业设计管理部：刘茂征11000，刘高峰63564，何伟祥33428安全处理方案：刘海军1，吴宇翔18167，吴海翔57182接入网：彭东红27279无线：胡涛46634关键网：吴桂彬 41508，甘嘉栋 33229，马进 32897，谢秀洪 33194，张毅 27651，张永锋 40582业软：包宜强56737，丁小龙63583，董鹏越60793，傅鉴杏36918，傅用成30333，龚连阳18753，胡海60017320，胡海华52463，李诚37517，李大锋54630，李战杰21615，刘创文65632，刘飞46266，刘剑51690，栾阳62227，罗仁钧65560，罗湘武06277，马亮60009259，孟咏喜22499，潘海涛27360，孙林46580，王福40317，王锦亮36430，王美玲60011866，王谟磊65558，王玉龙24387，杨娟60019875，张锋43381，张健60005645，张轶57143，邹韬51591V1.0何伟祥33428刘高峰 63564，龚连阳 00129383，许汝波 62966，吴宇翔 00120395，王欢 00104062，吕晓雨 56987V1.2增加了Web Service、Ajax和上传和下载相关安全规范。何伟祥00162822V1.3增加了预防会话固定和预防跨站请求伪造安全规范。何伟祥00162822V1.4增加了“规则3.4.1”实施指导；删除了“提议3.4.1”；修改了“6 配套CBB介绍”内容和获取方法。增加了“3.9 DWR”何伟祥 00162822吴淑荣 00197720魏建雄 00222906谢和坤 00197709李田 00042091孙波 00175839朱双红 00051429王伟 00207440陈伟 00141500V1.5增加“规则3.3.9、规则3.6.5、规则4.7.1、提议4.7.2、4.8 PHP”增加“3.8 RESTful Web Service”修改“规则3.2.2.8、规则3.2.2.3、规则3.4.1、规则4.6.1”删除“3.2.1口令策略”和“规则3.1.3、规则3.2.3.8、规则4.7.1”附件文档作为对象直接插入主文档目 录 Table of Contents1概述71.1背景介绍71.2技术框架81.3使用对象91.4适用范围91.5用词约定92常见WEB安全漏洞103WEB设计安全规范113.1Web布署要求113.2身份验证123.2.1口令123.2.2认证123.2.3验证码153.3会话管理163.4权限管理173.5敏感数据保护183.5.1敏感数据定义183.5.2敏感数据存放183.5.3敏感数据传输203.6安全审计213.7Web Service223.8RESTful Web Service233.9DWR244WEB编程安全规范254.1输入校验254.2输出编码304.3上传下载304.4异常处理314.5代码注释314.6归档要求324.7其它334.8PHP345WEB安全配置规范366配套CBB介绍376.1WAF CBB376.2验证码CBB387附件387.1附件1 Tomcat配置SSL指导387.2附件2 Web Service 安全接入开发指导387.3附件3 用户端IP鉴权实施指导387.4附件4 口令安全要求387.5附件5 Web权限管理设计规格说明书39Web应用安全开发规范 V1.51 概述1.1 背景介绍在Internet大众化及Web技术飞速演变今天，Web安全所面临挑战日益严峻。黑客攻击技术越来越成熟和大众化，针对Web攻击和破坏不停增加，Web安全风险达成了前所未有高度。很多程序员不知道怎样开发安全应用程序，开发出来Web应用存在较多安全漏洞，这些安全漏洞一旦被黑客利用将造成严重甚至是灾难性后果。这并非危言耸听，类似网上事故举不胜举，企业Web产品也曾数次遭黑客攻击，甚至有黑客利用企业Web产品漏洞敲诈运行商，造成极其恶劣影响。本规范就是提供一套完善、系统化、实用Web安全开发方法供Web研发人员使用，以期达成提升Web安全目标。本规范关键包含三大内容：Web设计安全、Web编程安全、Web配置安全，配套CBB，多管齐下，实现Web应用整体安全性；本规范关键以JSP/Java编程语言为例。1.2 技术框架图1 经典Web安全技术框架图1 显示了经典Web安全技术框架和安全技术点，这些安全技术点，贯穿整个Web设计开发过程。上图各个区域中存在任何一点微弱步骤，全部轻易造成安全漏洞。因为HTTP开放性，Web应用程序必需能够经过某种形式身份验证来识别用户，并确保身份验证过程是安全，一样必需很好地保护用于跟踪已验证用户会话处理机制。为了预防部分恶意输入，还要对输入数据和参数进行校验。另外还要考虑Web系统安全配置，敏感数据保护和用户权限管理，和全部操作安全审计。当然还要考虑代码安全，和其它方面威胁。表 1 列出了部分Web缺点类别，并针对每类缺点列出了因为设计不妥可能会造成潜在问题。针对这些潜在问题，本规范中有对应处理方法。表1 Web 应用程序缺点和因为不良设计可能造成问题缺点类别因为不良设计可能造成问题身份验证身份伪造、口令破解、权限提升和未授权访问。会话管理经过捕捉造成会话劫持和会话伪造。权限管理访问机密或受限数据、篡改和实施未授权操作。配置管理未授权访问管理界面、更新配置数据、访问用户帐户和帐户配置文件。敏感数据机密信息泄漏和数据篡改。加密技术未授权访问机密数据或帐户信息。安全审计未能识别入侵征兆、无法证实用户操作，和在问题诊疗中存在困难。输入检验经过嵌入查询字符串、窗体字段、Cookie 和 HTTP 标头中恶意字符串所实施攻击。包含命令实施、跨站点脚本编写 (XSS)、SQL 注入和缓冲区溢出攻击等。参数操作路径遍历攻击、命令实施、另外还有跳过访问控制机制、造成信息泄露、权限提升和拒绝服务。异常管理拒绝服务和敏感系统级具体信息泄露。1.3 使用对象本规范读者及使用对象关键为Web相关需求分析人员、设计人员、开发人员、测试人员等。1.4 适用范围本规范制订考虑了企业多种Web应用开发共性，适合于企业绝大部分Web产品，要求Web产品开发必需遵照。对于嵌入式系统（如ADSL Modem、硬件防火墙）中Web应用，因为其特殊性（CPU、内存、磁盘容量有限，没有成熟Web容器），不强制遵照本规范全部内容，只需遵照以下章节规则要求：3.2身份验证3.3会话管理3.5敏感数据保护4.1输入校验4.2输出编码4.3上传下载4.5代码注释4.6归档要求1.5 用词约定 规则：强制必需遵守标准 提议：需要加以考虑标准 说明：对此规则或提议进行对应解释 实施指导：对此规则或提议实施进行对应指导2 常见Web安全漏洞Web应用安全漏洞有很多，无法穷举。针对众多Web漏洞，OWASP教授们结合各自在各领域应用安全工作经验及智慧，提出了十大Web应用程序安全漏洞，帮助大家关注最严重漏洞。（OWASP即开放Web应用安全项目，是一个意在帮助大家了解和提升Web应用及服务安全性项目组织。）表2 十大Web应用程序安全漏洞列表序号漏洞名称漏洞描述1注入注入攻击漏洞，比如SQL、OS命令和LDAP注入。这些攻击发生在当不可信数据作为命令或查询语句一部分，被发送给解释器时候。攻击者发送恶意数据能够欺骗解释器，以实施计划外命令或访问未被授权数据。2跨站脚本当应用程序收到含有不可信数据，在没有进行合适验证和转义情况下，就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（简称XSS）。XSS许可攻击者在受害者浏览器上实施脚本，从而劫持用户会话、危害网站、或将用户转向至恶意网站。3失效身份认证和会话管理和身份认证和会话管理相关应用程序功效往往得不到正确实现，这就造成了攻击者破坏密码、密匙、会话令牌或攻击其它漏洞去冒充其它用户身份。4不安全直接对象引用当开发人员暴露一个对内部实现对象引用时，比如，一个文件、目录或数据库密匙，就会产生一个不安全直接对象引用。在没有访问控制检测或其它保护时，攻击者会操控这些引用去访问未授权数据。5跨站请求伪造一个跨站请求伪造攻击迫使登录用户浏览器将伪造HTTP请求，包含该用户会话cookie和其它认证信息，发送到一个存在漏洞Web应用程序。这就许可了攻击者迫使用户浏览器向存在漏洞应用程序发送请求，而这些请求会被应用程序认为是用户正当请求。6安全配置错误好安全需要对应用程序、框架、应用程序服务器、Web服务器、数据库服务器和平台，定义和实施安全配置。因为很多设置默认值并不是安全，所以，必需定义、实施和维护全部这些设置。这包含了对全部软件保护立即地更新，包含全部应用程序库文件。7失败URL访问权限限制很多Web应用程序在显示受保护链接和按钮之前会检测URL访问权限。不过，当这些页面被访问时，应用程序也需要实施类似访问控制检测，不然攻击者将能够伪装这些URL去访问隐藏网页。8未经验证重定向和前转Web应用程序常常将用户重定向和前转到其它网页和网站，而且利用不可信数据去判定目标页面。假如没有得到合适验证，攻击者能够将受害用户重定向到钓鱼网站或恶意网站，或使用前转去访问未经授权网页。9不安全加密存放很多Web应用程序并没有使用合适加密方法或Hash算法保护敏感数据，比如信用卡、社会安全号码（SSN）、认证凭据等。攻击者可能利用这种弱保护数据实施身份偷窃、信用卡欺骗或或其它犯罪。10传输层保护不足应用程序时常没有身份认证、加密方法，甚至没有保护敏感网络数据保密性和完整性。而当进行保护时，应用程序有时采取弱算法、使用过期或无效证书，或不正确地使用这些技术。3 Web设计安全规范3.1 Web布署要求规则3.1.1：假如 Web 应用对 Internet 开放，Web服务器应该置于DMZ区，在Web服务器和Internet之间，Web服务器和内网之间应该有防火墙隔离，并设置合理策略。规则3.1.2：假如 Web 应用对 Internet 开放，Web服务器应该布署在其专用服务器上，应避免将数据库服务器或其它关键应用和Web服务器布署在同一台主机上。说明：Web服务器比较轻易被攻击，假如数据库或关键应用和Web服务器布署在同一台主机，一旦Web服务器被攻陷，那么数据库和关键应用也就被攻击者掌控了。规则3.1.3：Web站点根目录必需安装在非系统卷中。说明：Web站点根目录安装在非系统卷，如单独创建一个目录/home/Web作为Web站点根目录，能够预防攻击者使用目录遍历攻击访问系统工具和可实施文件。提议3.1.1：Web服务器和应用服务器需物理分离（即安装在不一样主机上），以提升应用安全性。提议3.1.2：假如Web应用系统存在不一样访问等级（如个人帐号使用、用户服务、管理），那么应该经过不一样Web服务器来处理来自不一样访问等级请求，而且Web应用应该判别请求是否来自正确Web服务器。说明：这么便于经过防火墙访问控制策略和Web应用来控制不一样访问等级访问，比如经过防火墙策略控制，只许可内网访问管理Portal。提议3.1.3：对于“用户服务”和“管理”类访问，除了一般认证，还应该增加额外访问限制。说明：额外访问限制，能够限制请求来自企业内网，能够建立VPN，或采取双向认证SSL；或采取更简单措施，经过IP地址白名单对用户端IP地址进行过滤判定，实施参考附件3用户端IP鉴权实施指导。3.2 身份验证3.2.1 口令相关Web应用及容器包含到口令，请遵照产品网络安全红线口令安全要求（具体内容请见：附件4 口令安全要求.xlsx）。3.2.2 认证规则3.2.2.1：对用户最终认证处理过程必需放到应用服务器进行。说明：不许可仅仅经过脚本或其它形式在用户端进行验证，必需在应用服务器进行最终认证处理（假如采取集中认证，那么对用户最终认证就是放在集中认证服务器进行）。规则3.2.2.2：网页上登录/认证表单必需加入验证码。说明：使用验证码目标是为了阻止攻击者使用自动登录工具连续尝试登录，从而降低被暴力破解可能。假如认为验证码影响用户体验，那么能够在前3次登录尝试中不使用验证码，3次登录失败后必需使用验证码。验证码在设计上必需要考虑到部分安全原因，以免能被轻易地破解。具体实现细节请查看Error! Reference source not found.Error! Reference source not found.。图：图2 验证码实施指导：提议使用电信软件和关键网网络安全工程部提供验证码CBB。备注：对于嵌入式系统，假如实现验证码比较困难，能够经过数次认证失败锁定用户端IP方法来预防暴力破解。规则3.2.2.3：用户名、密码和验证码必需在同一个请求中提交给服务器，必需先判定验证码是否正确，只有当验证码检验经过后才进行用户名和密码检验，不然直接提醒验证码错误。说明：假如验证码和用户名、密码分开提交，攻击者就能够绕过验证码校验（如：先手工提交正确验证码，再经过程序暴力破解），验证码就形同虚设，攻击者仍然能够暴力破解用户名及口令。规则3.2.2.4：全部登录页面认证处理模块必需统一。说明：能够存在多个登录页面，不过不许可存在多个可用于处理登录认证请求模块，预防不一致认证方法。规则3.2.2.5：全部针对其它第三方开放接口认证处理模块必需统一。规则3.2.2.6：认证处理模块必需对提交参数进行正当性检验。说明：具体输入校验部分请查看4.1输入校验。规则3.2.2.7：认证失败后，不能提醒给用户具体和明确错误原因，只能给出通常性提醒。说明：能够提醒：“用户名或口令错误，登录失败”；不能提醒：“用户名不存在”、“口令必需是 6 位”等等。规则3.2.2.8：最终用户portal和管理portal分离。说明：最终用户portal和管理portal分离，预防相互影响，预防来自用户面攻击影响管理面。实施指导：将最终用户portal和管理portal分别布署在不一样物理服务器；假如为了处理成本合设（布署在同一台物理服务器上），那么，必需做到端口分离（经过不一样端口提供Web服务），通常Web容器（如tomcat）支持为不一样Web应用创建不一样端口。规则3.2.2.9：严禁在系统中预留任何后门帐号或特殊访问机制。规则3.2.2.10：对于关键管理事务或关键交易事务要进行重新认证，以防范会话劫持和跨站请求伪造给用户带来损失。说明：关键管理事务，比如重新开启业务模块；关键交易事务，比如转账、余额转移、充值等。重新认证，比如让用户重新输入口令。规则3.2.2.11：用户名和密码认证经过后，必需更换会话标识，以预防会话固定（session fixation）漏洞。实施指导：场景一：对于从HTTP转到HTTPS再转到HTTP（也就是仅在认证过程采取HTTPS，认证成功后又转到HTTP），在用户名和密码认证经过后增加以下行代码：request.getSession().invalidate();HttpSession newSession=request.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.getSession(true);提议3.2.2.1：管理页面提议实施强身份认证。说明：如双原因认证、SSL双向证书认证、生物认证等；还能够经过应用程序限制只许可一些特定IP地址访问管理页面，而且这些特定IP地址可配置。提议3.2.2.2：同一用户端在数次连续尝试登录失败后，服务端需要进行用户帐号或是用户端所在机器 IP 地址锁定策略，且该锁定策略必需设置解锁时长，超时后自动解锁。说明：登录失败应该提醒用户：假如重试多少次不成功系统将会锁定。在锁定时间不许可该用户帐号（或用户端所在机器 IP 地址）登录。许可连续失败次数（指从最终一次成功以来失败次数累计值）可配置，取值范围为：0-99 次，0表示不实施锁定策略，提议默认：5 次。锁定时长取值范围为：0-999 分钟，提议默认：30 分钟，当取值为 0 时，表示无限期锁定，只能经过管理员手动解锁（需要提供管理员对服务器锁定其它用户帐号/IP进行解锁功效界面）。提议优先使用帐号锁定策略。注意：应用程序超级用户帐号不能被锁定，只能锁定操作用户端所在 IP，这是为了预防系统不可用。尤其说明：锁用户端IP策略存在缺点，当用户使用proxy上网时，那么锁定用户端IP会造成使用该proxy上网全部用户在IP锁定时间全部不能使用该Web应用；锁定用户帐户策略也存在缺点，当攻击者不停尝试某帐户口令，就给该帐户带来拒绝服务攻击，使该帐户不可用。3.2.3 验证码规则3.2.3.1：验证码必需是单一图片，且只能采取 JPEG、PNG或GIF格式。说明：验证码不能使用文本格式，不允很多图片组合（如用四个图片拼成验证码）。规则3.2.3.2：验证码内容不能和用户端提交任何信息相关联。说明：在使用验证码生成模块时不许可接收来自用户端任何参数，比如：严禁经过getcode.jsp?code=1234URL请求，将1234作为验证码随机数。规则3.2.3.3：验证码模块生成随机数不能在用户端静态页面中网页源代码里出现。说明：在用户端网页上点击鼠标右键、选择“查看源文件”时，必需看不到验证码模块生成随机数。规则3.2.3.4：验证码字符串要求是随机生成，生成随机数必需是安全。说明：对于java语言能够使用类 java.security.SecureRandom来生成安全随机数。规则3.2.3.5：验证码要求有背景干扰，背景干扰元素颜色、位置、数量要求随机改变。规则3.2.3.6：验证码在一次使用后要求立即失效，新请求需要重新生成验证码。说明：进行验证码校验后，立即将会话中验证码信息清空，而不是等到生成新验证码时再去覆盖旧验证码，预防验证码数次有效；注意：当用户端提交验证码为空，验证不经过。说明：以上规则能够经过使用电信软件和关键网网络安全工程部提供验证码CBB来实现。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：对于运行应用程序操作系统帐号，不应使用“root”、“administrator”、“supervisor”等特权帐号或高等级权限帐号，应该尽可能地使用低等级权限操作系统帐号。规则3.4.5：对于应用程序连接数据库服务器数据库帐号，在满足业务需求前提下，必需使用最低等级权限数据库帐号。说明：依据业务系统要求，创建对应数据库帐号，并授予必需数据库权限。不能使用“sa”、“sysman”等管理帐号或高等级权限帐号。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页面最前面加入以下代码：注意：以上代码对于采取强制缓存策略代理服务器不生效（代理服务器默认是不缓存），要预防代理服务器缓存页面，能够在链接后加入一个随机数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赋值为post，以下2. 假如是使用servlet处理提交表单数据，那么只在doPost方法中处理，参考代码以下public class ValidationServlet extends HttpServletpublic 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请求时候，因为原先sessionsecure属性值是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，而且证实调用者身份。实施指导：能够经过在消息头中增加用户名