华为WEB应用系统安全规范v5.docx

DKBA华为技术内部技术规范DKBA 1606-XXXX.XWeb应用平安开发规范V1.5HUAWI2013年XX月XX日发布 2013年XX月XX日实施华为技术Huawei Technologies Co, Ltd.版权所有侵权必究All rights reserved编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第1。页共39页实施指导：对此规那么或建议的实施进行相应的指导2常见Web平安漏洞Web应用的平安漏洞有很多，无法穷举。针对众多的Web漏洞，0WASP的专家们结合各 自在各领域的应用平安工作经验及智慧，提出了十大Web应用程序平安漏洞，帮助人们关注 最严重的漏洞。（0WASP即开放Web应用平安工程，是一个旨在帮助人们理解和提高Web应 用及服务平安性的工程组织。）表2十大Web应用程序平安漏洞列表序号漏洞名称漏洞描述1注入注入攻击漏洞，例如SQL、OS命令以及LDAP注入。这些攻击发生在当不 可信的数据作为命令或者查询语句的一局部，被发送给解和器的时候。攻击者 发送的恶意数据可以欺骗解释器，以执行计划外的命令或者访问未被授权的数 据。2跨站脚本当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下， 就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（简称XSS）。XSS 允许攻击者在受害者的浏览器上执行脚本，从而劫持用户会话、危害网站、或 者将用户转向至恶意网站。3失效的身份认证和会话管理与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，这就导致/攻击者破坏密码、密匙、会话令牌或攻击其他的漏洞去冒充其他用户的身份。4不平安的直接对象引用当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数 据库密匙，就会产生一个不平安的直接对象引用。在没有访问控制检测或其他 保护时，攻击者会操控这些引用去访问未授权数据。5跨站请求伪造一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的 请求，包括该 用户的会话cookie和其他认证信息，发送到一个存在漏洞的Web应用程序。 这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求，而这些请 求会被应用程序认为是用户的合法请求。6平安配置错误好的平安需要对应用程序、框架、应用程序服务器、Web版务器、数据库服第10页共39页编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第11页共39页务器和平台，定义和执行平安配置。由于许多设置的默认位并不是平安的，因 此，必须定义、实施和维护所有这些设置。这包括了对所有的软件保护及时地 更新，包括所有应用程序的库文件。7失败的URL访问权限限制许多Web应用程序在显示受保护的链接和按钮之前会检测URL访问权限。但是，当这些页面被访问时，应用程序也需要执行类似的访问控制检测，否那么 攻击者将可以伪装这些URL去访问隐藏的网页。8未经验证的重定向和前转Web应用程序经常将用户重定向和前转到其他网页和网站，并且利用不可信 的数据去判定目的页面。如果没有得到适当验证，攻击者可以将受害用户重定 向到钓鱼网站或恶意网站，或者使用前转去访问未经授权的网页。9不平安的加密存储许多Web应用程序并没有使用恰当的加密措施或Hash算法保护敏感数据， 比方信用广、社会平安号码（SSN）、认证凭据等。攻击者可能利用这种弱 保护数据实行身份盗窃、信用卡欺骗或或其他犯罪。10传输层保护缺乏应用程序时常没有身份认证、加密措施，甚至没有保护敏感网络数据的保密性 和完整性。而当进行保护时，应用程序有时采用弱算法、使用过期或无效的证 书，或不正确地使用这些技术。3 Web设计平安规范3.1 Web部署要求规那么：如果Web应用对Internet开放,Web服务器应当置于DMZ区，在Web服务 器与Internet之间，Web服务器与内网之间应当有防火墙隔离，并设置合理的策略。规那么3.12 如果Web应用对Internet开放，Web服务器应该部署在其专用的服务器上，应防止将数据库服务器或其他核心应用与Web服务器部署在同一台主机上。说明：Web服务器比拟容易被攻击，如果数据库或核心应用与Web服务器部署在同一台主 机，一旦Web服务器被攻陷，那么数据库和核心应用也就被攻击者掌控了。规那么： Web站点的根目录必须安装在非系统卷中。说明：Web站点根目录安装在非系统卷，如单独创立一个目录/home/Web作为Web站点根 目录，能够防止攻击者使用目录遍历攻击访问系统工具和可执行文件。建议： Web服务器与应用服务器需物理别离（即安装在不同的主机上），以提高应用第11页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第12页共39页的平安性。建议：如果Web应用系统存在不同的访问等级（如个人帐号使用、客户服务、管理）， 那么应该通过不同的Web服务器来处理来自不同访问等级的请求，而且Web应用应该鉴别 请求是否来自正确的Web服务器。说明：这样便F通过防火墙的访问控制策略和Web应用来控制不同访问等级的访问，比方 通过防火墙策略控制，只允许内网访问管理Portal。建议：对于“客户服务”和“管理”类的访问，除了普通的认证，还应该增加额外的 访问限制。说明：额外的访问限制，可以限制请求来自企业内网，可以建立VPN,或采用双向认证的 SSL：或采用更简单的方法，通过IP地址白名单对客户端的IP地址进行过滤判断，实施参 考附件3客户端1P鉴权实施指导。3.2 身份验证口令关于Web应用及容器涉及到的口令，请遵循产品网络平安红线的口令平安要求（详 细内容请见：附件4 口令平安要求.xlsx）。3.2.1 认证规那么：对用户的最终认证处理过程必须放到应用服务器进行。说明：不允许仅仅通过脚本或其他形式在客户端进行验证，必须在应用服务器进行最终认证 处理（如果采用集中认证，那么对用户的最终认证就是放在集中认证服务器进行）。规那么：网页上的登录/认证表单必须加入验证码。说明：使用验证码的目的是为了阻止攻击者使用自动登录工具连续尝试登录，从而降低被暴 力破解的可能。如果觉得验证码影响用户体验,那么可以在前3次登录尝试中不使用验证码, 3次登录失败后必须使用验证码。验证码在设计上必须要考虑到一些平安因素，以免能被轻 易地破解。具体实现细节请查看验证码。如图：第12页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第13页共39页客户登录图2验证码实施指导：建议使用电信软件与核心网网络平安工程部提供的验证码CBB“备注：对于嵌入式系统，如果实现验证码比拟困难，可以通过屡次认证失败锁定客户端IP 的方式来防止暴力破解。规那么用户名、密码和验证码必须在同一个请求中提交给服务器，必须先判断验证码 是否正确，只有当验证码检验通过后才进行用户名和密码的检验，否那么直接提示验证码错误。 说明：如果验证码和用户名、密码分开提交，攻击者就可以绕过验证码校验（如：先手工提 交正确的验证码，再通过程序暴力破解），验证码就形同虚设，攻击者依然可以暴力破解用 户名及口令。规那么：所有登录页面的认证处理模块必须统一。说明：可以存在多个登录页面，但是不允许存在多个可用于处理登录认证请求的模块，防止 不一致的认证方式。规那么：所有针对其他第三方开放接口的认证处理模块必须统一。规那么3.226：认证处理模块必须对提交的参数进行合法性检查。说明：具体输入校验局部请查看4.1输入校验。规那么3.227：认证失败后，不能提示给用户详细以及明确的错误原因，只能给出一般性的提 /Ko说明：可以提示：“用户名或者口令错误，登录失败”；不能提示：“用户名不存在”、“口 令必须是6位”等等。规那么322.8：最终用户portal和管理portal别离。说明：最终用户portal和管理portal别离，防止相互影响，防止来自用户面的攻击影响管理 面。实施指导：第13页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第14页共39页将最终用户portal和管理portal分别部署在不同的物理服务器；如果为了解决本钱合设(部 署在同一台物理服务器上)，那么，必须做到端口别离(通过不同的端口提供Web服务)， 一般的Web容器(如tomcat)支持为不同的Web应用创立不同的端口。规那么：禁止在系统中预留任何的后门帐号或特殊的访问机制。规那么322.1()：对手重要的管理事务或重要的交易事务要进行重新认证，以防范会话劫持和 跨站请求伪造给用户带来损失。说明：重要的管理事务，比方重新启动业务模块；重要的交易事务，比方转账、余额转移、 充值等。重新认证，比方让用户重新输入口令。规那么3.2211：用户名和密码认证通过后，必须更换会话标识，以防止会话固定(session fixation)漏洞。实施指导：场景一：对于从 转到 S再转到 (也就是仅在认证过程采用 S,认证 成功后又转到 )的，在用户名和密码认证通过后增加以下行代码：request.getSession().invalidate(); Session ncwSession=rcqucst.getSession(true);Cookie cookie = new Cookie(JSESSIONID,newSession.getId();cookic.sctMaxAgc(-1);cookie.setSecure( false);cookic.setPath(rcqucst.gctContcxtPath();response.addCookie(cookie);场景二：对于全程采用 S协议，或者全程采用 协议的，在用户名和密码认证通 过后增加以下行代码：rcqucst.gctScssion().invalidatc();request.getSession(true);建议3.221：管理页面建议实施强身份认证。说明：如双因素认证、SSL双向证书认证、生物认证等；还可以通过应用程序限制只允许某 些特定的IP地址访问管理页面，并且这些特定的IP地址可配置。建议3.222：同一客户端在屡次连续尝试登录失败后，服务端需要进行用户帐号或者是客户 端所在机器的IP地址的锁定策略，且该锁定策略必须设置解锁时长，超时后自动解锁。 说明：登录失败应该提示用户：如果重试多少次不成功系统将会锁定。在锁定期间不允许该用户帐号(或者客户端所在机器的IP地址)登录。第14页共39页编号：时间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第15页共39页允许连续失败的次数（指从最后一次成功以来失败次数的累计值）可配置，取值范围为： 0-99次，0表示不执行锁定策略，建议默认：5次。锁定时长的取值范围为：0-999分钟，建议默认：30分钟，当取值为0时，表示无限 期锁定，只能通过管理员手动解锁（需要提供管理员对服务器锁定其它用户帐号/IP进行解 锁的功能界面）。建议优先使用帐号锁定策略.注意：应用程序的超级用户帐号不能被锁定，只能锁定操作的客户端所在的IP,这是 为了防止系统不可用。特别说明：锁客户端IP策略存在缺陷，当用户使用proxy上网时， 那么锁定客户端IP会导致使用该proxy上网的所有用户在IP锁定期间都不能使用该Web 应用；锁定用户帐户的策略也存在缺陷，当攻击者不断尝试某帐户的口令，就给该帐户带来 拒绝服务攻击，使该帐户不可用。3.2.2 验证码规贝：验证码必须是单一图片，且只能采用JPEG、PNG或GIF格式。说明：验证码不能使用文本格式，不允许多图片组合（如用四个图片拼成的验证码）。规那么323.2：验证码内容不能与客户端提交的任何信息相关联。说明：在使用验证码生成模块时不允许接收来自客户端的任何参数，例如：禁止通过 getcode.jsp?code=1234的URL请求，将1234作为验证码随机数。规那么3.233：验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。 说明：在客户端网页上点击鼠标右键、选择“查看源文件”时，必须看不到验证码模块生成 的随机数。规那么：验证码字符串要求是随机生成，生成的随机数必须是平安的。说明：对于java语言可以使用类来生成平安的随机数。规那么3.235：验证码要求有背景干扰，背景干扰元素的颜色、位置、数最要求随机变化。规那么3.236：验证码在一次使用后要求立即失效，新的请求需要重新生成验证码。说明：进行验证码校验后，立即将会话中的验证码信息清空，而不是等到生成新的验证码时 再去覆盖旧的验证码，防止验证码屡次有效；注意：当客户端提交的验证码为空，验证不通 过。说明:第15页共39页编号：时间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第16页共39页以上规那么可以通过使用刈信软件与核心网网络平安工程部提供的验证码CBB来实现。3.3 会话管理规那么：使用会话cookie维持会话。说明：目前主流的Web容器通过以下几种方式维持会话:隐藏域、URL重写、持久性cookie、 会话cookie,但通过隐藏域、URL重写或持久性cookie方式维持的会话容易被窃取，所以 要求使用会话cookie维持会话。如果条件限制必须通过持久性cookie维持会话的话，那么 cookie信息中的重要数据局部如身份信息、计费信息等都必须进行加密。（cookie有两种: 会话cookie和持久性cookie；会话cookie,也就是非持久性cookie,不设置过期时间，其生 命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了；会话cookie一般不存储 在硬盘上而是保存在内存里。持久性cookie,设置了过期时间，被浏览器保存到硬盘上，关 闭后再次翻开浏览器，持久性cookie仍然有效直到超过设定的过期时间。）备注：对于嵌入式系统的Web,不适合本条规那么，按“规那么3.3.9”实施。规那么：会话过程中不允许修改的信息，必须作为会话状态的一局部在服务器端存储和 维护。说明：会话过程中不允许修改的信息，例如，当用户通过认证后，其用户标识在整个会话过 程中不能被篡改。禁止通过隐藏域或URL重写等不平安的方式存储和维护。对JSP语言， 就是应该通过session对象进行存储和维护。规那么：当Web应用跟踪到非法会话，那么必须记录日志、清除会话并返回到认证界面。 说明：非法会话的概念就是通过一系列的服务端合法性检测（包括访问未授权资源，缺少 必要参数等情况），最终发现的不是正常请求产生的会话。规那么：禁止使用客户端提交的未经审核的信息来给会话信息赋值。说明：防止会话信息被篡改，如恶意用户通过URL篡改手机号码等。规那么：当用户退出时，必须清除该用户的会话信息。说明：防止遗留在内存中的会话信息被窃取，减少内存占用。实施指导：对于JSP或java语言使用如下语句：requesi.getSession（）.invalidaie（）;规那么：必须设置会话超时机制，在超时过后必须要清除该会话信息。说明：建议默认会话超时时间为10分钟（备注：对于嵌入式系统中的Web,建议默认超时第16页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第17页共39页时间为5分钟，以减少系统资源占用）。如果没有特殊需求，禁止使用自动发起请求的机制 来阻止session超时。规那么：在服务器端对业务流程进行必要的流程平安控制，保证流程衔接正确，防止关 键鉴别步骤被绕过、重复、乱序。说明：客户端流程控制很容易被旁路（绕过），因此流程控制必须在服务器端实现。实施指导:可以通过在session对象中创立一个表示流程当前状态的标识位，用0、I、2、3、N分别表示不同的处理步骤，标识位的初始值为0,当接收到步骤N的处理请求时，判断该 标识位是否为N-1,如果不为N-1,那么表示步骤被绕过（或重复或乱序），拒绝受理，否那么 受理，受理完成后更改标识位为N。规那么：所有登录后才能访问的页面都必须有明显的“注销（或退出）”的按钮或菜单， 如果该按钮或菜单被点击，那么必须使对应的会话立即失效。说明：这样做是为了让用户能够方便地、平安地注销或退出，减小会话劫持的风险。规那么：如果产品（如嵌入式系统）无法使用通用的Web容器，只能自己实现Web服务， 那么必须自己实现会话管理，并满足以下要求： 采用会话cookie维持会话。 生成会话标识（session ID）要保证足够的随机、离散，以便不能被猜想、枚举，要求 session ID要至少要32字节，要支持字母和数字字符集。 服务端必须对客户端提交的session ID的有效性进行校验。说明：在嵌入式系统中部署Web应用，由于软硬件资源所限，往往无法使用通用的Web容 器及容器的会话管理功能，只能自己实现。另外，为了节省内存，嵌入式webserver进程往 往是动态启动，为了使session更快的超时，建议增加心跳机制，对客户端浏览器是否关闭 进行探测，5s 一个心跳，30s没有心跳那么session超时，关闭该sessiono3.4 权限管理规那么：对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是 否合法、用户是否被授权执行这个操作。说明：防止用户通过直接输入URL,越权请求并执行一些页面或servlet；建议通过过滤器 实现。实施指导：请参考“附件5 Web权限管理设计规格说明书docx” .第0页共39页编号：日寸间；2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第18页共39页规那么342：授权和用户角色数据必须存放在服务器端，不能存放在客户端，鉴权处理也必 须在服务器端完成。说明：禁止将授权和角色数据存放在客户端中（比方cookie或隐藏域中），以防止被篡改。规那么： 一个帐号只能拥有必需的角色和必需的权限。一个组只能拥有必需的角色和必 需的权限。一个角色只能拥有必需的权限。说明：做到权限最小化和职责别离（职责别离就是分清帐号角色，系统管理帐号只用于系统 管理,审计帐号只用于审计，操作员帐号只用于业务维护操作，普通用户帐号只能使用业务。） 这样即使帐号被攻击者盗取，也能把平安损失控制在最小的限度。规那么：对于运行应用程序的操作系统帐号，不应使用“root”、“administrator、“supervisor” 等特权帐号或高级别权限帐号，应该尽可能地使用低级别权限的操作系统帐号。规那么：对于应用程序连接数据库服务器的数据库帐号，在满足业务需求的前提下，必 须使用最低级别权限的数据库帐号。说明：根据业务系统要求，创立相应的数据库帐号，并授予必需的数据库权限。不能使用“sa”、 “sysman”等管理帐号或高级别权限帐号。3.5 敏感数据保护敏感数据定义敏感数据包括但不限于：口令、密钥、证书、会话标识、License,隐私数据（如短消 息的内容）、授权凭据、个人数据（如姓名、住址、 等）等，在程序文件、配置文件、 日志文件、备份文件及数据库中都有可能包含敏感数据。3.5.1 敏感数据存储规那么352.1：禁止在代码中存储敏感数据。说明：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致 泄密。用于加密密钥的密钥可以硬编码在代码中。规那么：禁止密钥或帐号的口令以明文形式存储在数据库或者文件中。说明：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以 明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规那么，将该配置文件的属第18页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第19页共39页性改为只有属主可读写。规那么3：禁止在cookie中以明文形式存储敏感数据。说明：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据：如果条件限制必须使 用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。规那么3.524：禁止在隐藏域,中存放明文形式的敏感数据。规那么3.525：禁止用自己开发的加密算法，必须使用公开、平安的标准加密算法。实施指导：场景I：后台服务端保存数据库的登录口令后台服务器登录数据库需要使用登录数据库的明文口令，此时后台服务器加密保 存该口令后，下次登录时需要还原成明文，因此，在这种情况下，不可用不可逆的加密 算法，而需要使用对称加密算法或者非对称加密算法，一般也不建议采用非对称加密算 法。推荐的对称加密算法：AES128、AES192. AES256。场景2：后台服务端保存用户的登录口令在该场景下，一般情况是：客户端提交用户名及用户口令，后台服务端对用户名 及用户口令进行验证，然后返回验证的结果。此时，在后台服务端，用户口令可以不需 要还原，因此建议使用不可逆的加密算法，对“用户名+口令”字符串进行加密。推荐的不可逆加密算法：SHA256、SHA384、SHA5I2, HMAC-SHA256、HMAC-SHA384、 HMAC-SHA5I2。规那么3.526：禁止在日志中记录明文的敏感数据。说明：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等），防止敏感信 息泄漏。规那么：禁止带有敏感数据的Web页面缓存。说明：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器 上网的用户数据互窜问题。实施指导：在HTML页面的vHEAD标签内加入如下代码：第19页共39页修订声明 Revision declaration本规范拟制与解释部门：网络平安能力中心&电信软件与核心网网络平安工程部本规范的相关系列规范或文件：C&C+语言平安编程规范Java语言平安编程规范相关国际规范或文件一致性：无替代或作废的其它规范或文件：无相关规范或文件的相互关系：产品网络平安红线和电信软件与核心网业务部平安能力基线中的Web平安要 求引用了本规范的内容，如果存在冲突，以本规范为准。规范号主要起草部门专家主要评审部门专家修订情况DKBA 1606-2007.4平安解决方案：赵武42873,杨光磊57125.万振华55108软件公司设计管理 部：刘茂征11000, 刘高峰63564,何伟祥 33428平安解决方案：刘海军 12014,吴宇翔 18167, 吴海翔57182接入网：彭东红27279无线:胡涛46634核心网:吴桂彬41508, 甘嘉栋33229,马进 32897,谢秀洪 33194, 张毅27651,张永锋 40582业软：包宜强56737, T 小龙63583,董鹏越 60793,傅鉴杏 36918, 傅用成30333,龚连阳 18753,胡海 60017320, 胡海华52463,李诚 37517,李大锋 54630, 李战杰21615,刘创文 65632,刘飞 46266,刘 剑 51690,栾阳 62227, 罗仁钧65560,罗湘武 06277,马亮 60009259,V1.0编号：时间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第20页共39页在JSP页面的最前面加入如下代码：注意：以上代码对于采用强制缓存策略的代理服务器不生效(代理服务器默认是不缓存的)， 要防止代理服务器缓存页面，可以在链接后加入一个随机数pageid,此时链接变成： :/localhost:8080/query.do?a=2&pageid=2245562,其中 2245562 数字是随机生成的，每次 请求此页面时，随机数都不同，IE始终认为此为一个新请求，并重新解析，生成新的响应 页面。3.5.2 敏感数据传输规贝：带有敏感数据的表单必须使用 -POST方法提交。说明：禁止使用 -GET方法提交带有敏感数据的表单(form),因为该方法使用查询 字符串传递表单数据，易被查看、篡改。如果是使用servlet处理提交的表单数据，那么不 在doGct方法中处理，只在doPost方法处理。实施指导：1 .对于JSP页面，将表单的属性me【hod赋值为posl，如下2 .如果是使用servlet处理提交的表单数据，那么只在doPost方法中处理，参考代码如下 public class ValidationServlet extends Servlet第20页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第21页共39页public void doPost(HtlpServle(Request request, HtipServletResponse response) throws lOException, ServletException对提交的表单数据进行校验)I规那么：在客户端和服务器间传递明文的敏感数据时，必须使用带服务器端证书的SSLo 说明：如果在客户端和服务器间传递如帐号、口令等明文的敏感数据，必须使用带服务器端 证书的SSL。由于SSL对服务端的CPU资源消耗很大，实施时必须考虑服务器的承受能力。 实施指导：1. SSL的配置请参考附件1 Tomcat配置SSL指导。2. Web应用中，从 s切换到hup过程中会丧失session,无法保持会话的连续。解决的办 法就是用 -ht(ps-h(tp过程代替htips- 过程，保证会话的连续性。原因：当 s请求转 为 请求的时候，因为原先的session的secure属性值是true,无法再 协议中传输， 因此，系统生成新的session,且新的session没有继承旧session的属性和值，因此，无法保 持会话连续。而 - s 这个过程，session始终不变，因此，可以保持会话连续。 规那么：禁止在URL中携带会话标识(如jscssionid)。说明：由于浏览器会保存URL历史记录，如果URL中携带会话标识，那么在多人共用的PC 上会话标识容易被其他人看到，一旦该会话标识还在其生命有效期，那么恶意用户可以冒充受 害用户访问Web应用系统。规那么3：禁止将对用户保密的信息传送到客户端。说明：这些信息一旦传送到客户端，那么用户也就可以获取到J2.6 平安审计本节的平安审计是针对Web业务应用，不包括对操作系统、Web容器的平安审计。对 于操作系统和Web容器的平安审计，可以参考对应的操作系统平安基线和Web平安配置规 范。规那么：应用服务器必须对平安事件及操作事件进行口志记录。说明：平安事件包括登录、注销、添加、删除、修改用户、授权、取消权限、鉴权、修改用第21页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟页码：第22页共39页户口令等；操作事件包括对业务系统配置参数的修改，对重要业务数据的创立、删除、修改、 查询等；对于上述事件的结果，不管是成功还是失败，都需要记录FI志。规那么362：平安口志必须包括但不限于如下内容：事件发生的时间、事件类型、客户端1P、 客户端机器名、当前用户的标识、受影响的个体(数据、资源)、成功或失败标识、启动该 事件的进程标识以及对该事件的详细描述。规那么363：严格限制对平安日志的访问。说明：只有Web应用程序的管理员才能查询数据库表形式或文件形式的平安日志；除数据 库超级管理员外，只有应用程序连接数据库的帐号可以查询(select)及插入(insert)平安 日志表；除操作系统超级管理员外，只有应用程序的运行帐户才能读、写文件形式的平安日 志(但不允许删除)。确保口志的平安，限制对日志的访问，这加大了攻击者篡改口志文件 以掩饰其攻击行为的难度。规那么：对日志模块占用资源必须有相应的限制机制。说明：限制日志模块占用的资源，以防止如自动的恶意登陆尝试导致的资源枯竭类DOS攻 击；比方限制日志记录占用的磁盘空间。规那么365：禁止日志文件和操作系统存储在同一个分区中，同时，应使用转储、滚动、轮 循机制，来防止存储日志的分区写满。说明：所需空间和具体业务、局点容量、口志保存周期相关，要根据实际情况估算。建议361：平安日忐应该有备份及清理机制。说明：备份及清理机制包括定期备份及清理平安日志和监控用于存放平安日志的磁盘空间的 使用情况。可以配置定期备份及清理的时间，可以配置以用于存放平安日志的磁盘空间使用 率到达多少时进行备份及清理。建议：通过网络形式保存平安日志。说明：在生成平安日志时，即时将日志保存到网络上其他主机，而且生成平安日志的应用程 序不能再访问存放在其他主机的口志。2.7 Web Service规那么：对Web Service接口的调用必须进行认证。说明：认证就是确定谁在调用Web Service,并且证实调用者身份。实施指导：第22页共39页编号：日寸间：2021年X月X日书山有路勤为径，学海无涯苦作舟 页码：第23页共39页可以通过在消息头中增加用户名和口令，作为认证凭据；对于平安性要求不高、只向同信任域内其他主机开放的Web Service接口，可以通过简 单的IP认证来实现接口的认证（只有服务器端指定IP地址的客户端才允许调用，IP地址 可配置）。规贝！I ：如果调用者的权限各不相同，那么必须对Web Service接口的调用进行鉴权。 说明：鉴权就是判断调用者是否有权限调用该Web Service接口。实施指导：可以通过Axis的handler对调用进行鉴权。规那么：通过Web Service接口传递敏感数据时，必须保障其机密性。实施指导：方案I：请参考附件2 Web Service平安接入开发指导。方案2：采用 s平安协议。规那么：通过Web Service接口传递重要的交易数据时，必须保隙其完整性和不可抵赖性。说明：重要的交易数据，如转账时涉及的“转入账号”、“转出账号”、“金额”等。实施指导：请参考附件2 Web Service平安接入开发指导。规那么：如果Web Service只对特定的IP开放，那么必须对调用Web Service接U的客户 端IP进行鉴权，只有在IP地址白名单中的客户端才允许调用，IP地址白名单可配置。实施指导：请参考附件3客户端IP鉴权实施指导。规那么：对Web Service接口调用进行日志记录。说明：日志内容包括但不限于如下内容：调用时间、操作类型、调用接口名称、详细的接口 参数、客户端IP、客户端机器名、调用者的用户标识、受影响的个体（数据、资源）、成 功或失败标识。规那么：必须对Web Service提交的参数进行输入校验。说明：具体输入校验局部请杳看4.1输入校验。2.8 RESTful Web ServiceRESTful Web Service （也称为 RESTful Web API）是一个使用 并遵循 REST 原那么的Web服务。第23页共39页编号：时间：2021年X月X日 书山有路勤为径，学海无涯苦作舟 页码：第24页共39页规那么：对RESTful Web Service的调用必须进行认证。说明：认证就是确定谁在调用RESTful Web Service,并且证实调用者身份。实施指导：客户端发起的Restful请求需要在消息头带Authorization字段，内容填Basic Base64(user:pass),服务端对 user 和 passwd 进行认证。注意：usei和pass必须加密保存在配置文件或数据库中，不能写死在代码中；传输时采用 s平安协议。对于平安性要求不高、只向同一信任域内其他主机开放的Web Service接口，可以通过简 单的IP认证来实现接口的认证(只有服务器端指定IP地址的客户端才允许调用，IP地址 可配置)。规那么：如果调用者的权限各不相同，那么必须对RESTful Web Service的调用进行鉴权。 说明：鉴权就是判断调用者是否有权限调用该RESTful Web Service(,规那么383：通过RESTful Web Service传递敏感数据时，必须保障其机密性。实施指导：采用 s平安协议。规那么：如果RESTful Web Service只对特定的IP开放，那么必须对调用RESTful Web Service的客户端IP进行鉴权，只有在1P地址白名单中的客户端才允许调用，1P地址白名 单可配置。实施指导：请参考附件3客户端IP鉴权实施指导。规那么：对RESTful Web Service调用进行日志记录。说明：日志内容包括但不限于如下内容：调用时间、操作类型、调用接口名称、详细的接口 参数、客户端IP、客户端机器名、调用者的用户标识、受影响的个体(数据、资源)、成 功或失败标识。规那么：必须对RESTful Web Service提交的参数进行输入校验。说明：具体输入校验局部请杳看4.1输入校验。2.9 DWRDWR (Direct Web Rernoting)是一种Java和JavaScript相结合的开源框架，可以帮助第24页共39页编号：时间：2021年X月X日 书山有路勤为径，学海无涯苦作舟 页码：第25页共39页开发人员更容易地完成应用Ajax技术的Web应用程序，让浏览器上的JavaScript方法调用运行在Web服务器上的Java方法。规那么：关闭DWR调试功能。说明：如果开启了 DWR调试功能，那么攻击者可以轻易杳看和调用系统提供的所有DWR接口，所以，版本发布时，一定要关闭DWR调试功能。实施指导：修改对应的web.xml文件中的debug参数值为false：se