T_HMSJRXH 001-2023 哈密市法人银行业金融机构软件开发安全需求规范.docx

ICS 35.080L 67团体标准T / H M S J R X H 0012023哈密市法人银行业金融机构软件开发安全需求规范Hami City Legal Person Banking Financial Institutions SoftwareDevelopment Security Requirements Specification2023-11-20 发布2023-11-20 实施哈密市金融学会发布T/HMSJRXH 0012023目次前言. 引言. 1 范围. 12 规范性引用文件. 13 术语和定义. 14 概述. 55 适用范围. 66 安全需求. 6附  录  A （规范性） 安全威胁类型对应安全对策. 19IT/HMSJRXH 0012023前言本标准按照GB/T 1.1-2020标准化工作导则 第1部分:标准化文件的结构和起草规则起草。本标准由哈密市商业银行股份有限公司提出。本标准由中国人民银行哈密市分行归口。本标准起草单位：中国人民银行哈密市分行、哈密市商业银行股份有限公司。本标准主要起草人：张雷、徐伟峰、阿依萨代提·阿卜力孜、梁云鹏、朱磊、刘奎、李兵虎、何康旭、郑亚红、陈晨。IIT/HMSJRXH 0012023引言本标准是参考国家及行业标准，结合法人银行业金融机构实际情况，规范软件开发中安全建设而制定的标准性文档，制定该规范目的是为了明确软件开发中需要遵循的信息安全标准。依据该规范，软件开发人员在软件开发整个生命周期中,规范软件安全需求分析、安全设计、安全编码以及安全测试等工作，减少和控制软件安全漏洞和安全隐患，提高软件安全防护能力，进而开发符合法人银行业金融机构信息安全规范的高质量软件。IVT/HMSJRXH 0012023哈密市法人银行业金融机构软件开发安全需求规范1 范围本规范规定了软件开发人员在软件开发整个生命周期中,软件安全需求分析、安全设计、安全编码以及安全测试等工作要求。本规范适用于各类组织对项目经理、开发人员及安全管理人员的管理。2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本标准必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本标准；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本标准。GB/T 25070-2010信息安全技术 软件安全评测要求GB/T 22239-2008信息安全技术 防篡改技术要求GB/T 22240-2008信息安全技术 电子认证技术规范GB/T 22239.2-2008信息安全技术 防篡改技术评测指南GB/T 31113-2014信息安全技术 个人电脑安全要求ISO/IEC 27001:2013信息技术 - 信息安全管理体系 - 要求ISO/IEC 27034-1:2011信息技术 - 安全技术 - 应用安全 - 第1部分：概念和模型ISO/IEC 15408-1:2009信息技术 - 安全评估方法 - 第1部分：概述和模型ISO/IEC 27002:2013信息技术 - 安全技术 - 信息安全管理实践指南3 术语和定义下列术语和定义适用于本标准。3.1应用架构 application architecture软件的最上层是应用程序和API，以下是中间件层，最低的基础设施层包括底层基础设施的逻辑表现和物理表现层。应用可能运行DMZ（demilitarized zone）区域或者内部网的服务器上。3.2应用层 application layer1T/HMSJRXH 001-2023应用层是软件的特有功能实现的地方。软件可能是定制开发的，或者是第三方的系统。3.3应用程序接口 application programming interface一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无需关注服务的设计与实现。来源：JR/T 0185-2020，3.13.4中间件 middleware安全中间件是设计用于建立独立的安全服务功能，以便多应用调用的程序组件。3.5基础设施 infrastructure基础设施层是应用在上面运行的操作环境。它包括了环境平台、网络服务、硬件和加密设备等。3.6安全日志 security log这里所说的安全日志是指由软件记录的各种与信息安全相关的统计信息和异常事件，主要包括系统的启动与停止、系统的认证与授权、数据修改、删除以及数据传输等与信息安全相关的日志记录。不同与其它交易日志和防火墙或网络设备监控日志，在软件中我们把它单独抽取出来作为监控与分析软件，分析软件安全的依据。安全日志本身不能提供足够的信息来确定对安全事件的是否响应及怎样响应。安全日志再加上收集和查询及分析安全日志的其他安全审计工具与技术，才能组成一个完整的对软件安全监控和检测机制。3.7安全审计 Audit安全审计是通过对软件上发生的安全日志，并对日志进行统计分析，从而对资源使用情况进行事后分析的有效手段，也是发现和追踪事件的常用措施。在存储和使用安全建设中，审计的主要对象为用户、主机和节点，主要内容为访问的主体、客体、时间和成败情况等。安全审计应为确定发生的安全事件以及用户在安全事件中的责任提供准确的依据，是指软件能够检测、判断，或者使用工具和软件检测、判断发生了哪些安全事件，并采取相应的响应措施。审计内容用于检测、判断发生了哪些与安全相关的活动，以及这些活动应由哪个用户负责。2T/HMSJRXH 00120233.8用户ID - 口令 User ID - Password是软件和终端登录所采用的最基本的访问控制手段，对于口令管理的疏忽随时都可能导致对软件或终端系统的非法访问和破坏，因此从信息安全的角度，软件必须对于口令的设定、使用、更新和保护等各个环节进行规范提供足够技术支撑。3.9风险分析 risk analysis确定安全风险，决定风险等级，确立防护范围的过程。风险分析是风险管理的一部分。3.10安全策略 security policy规定机构如何管理、保护与分发敏感信息的法规与条例的集合。3.11安全需求 security requirements为使设备、信息、应用及设施符合安全策略的要求而需要采取的保护类型及保护等级。3.12安全测试 safety testing用于确定系统的安全特征按设计要求实现的过程。这一过程包括现场功能测试、渗透测试和验证。3.13保密性 confidential为秘密数据提供保护状态及保护等级的一种特性。3.14数据完整性 data integrity信息系统中的数据与在原文档中的相同，并未遭受偶然或恶意的修改或破坏时所具的性质。3T/HMSJRXH 001-20233.15数据可用性 data Availability当用户需要数据时，数据就以用户需要的形式存在于用户需要的地方的一种状态。3.16不可否认性 non-repudiation不可否认性是一种安全性概念，用来证明特定信息的传输过程。如果系统采用不可否认性技术，那么消息发送者就不能否认曾传送过该消息，而消息接收者也不能否认曾接收该消息。此外，如果消息包含合同信息，消息上的数字签名将能够验证合同信息并未遭到不当更改。3.17访问控制 access control限制已授权的用户、程序、进程或计算机网络中其他系统访问本系统资源的过程。用于处理所赋予用户的访问权限，以便他们执行系统上的某些功能。3.18访问控制机制 access control mechanism在信息系统中，为检测和防止未授权访问，以及为使授权访问正确进行所设计的硬件或软件功能、操作规程、管理规程和它们的各种组合。3.19访问管理 access management访问管理对访问信息进行管理，主要包含如下四项任务：帐户管理、维护、监控和撤销。3.20认证 authentication信息系统技术和非技术的安全特征及其他防护的综合评估，用以支持审批过程和确定特殊的设计和实际满足一系列预定的安全需求的程度。3.21身份验证 authentication4T/HMSJRXH 0012023用户利用此方法向系统证明他们是所宣称的身份。身份验证通常采用密码、智能卡、生物技术等方式。3.22信息隐藏 information hiding它是隐藏信息或其他数据存在的方法，其和密钥技术不同，它只隐藏信息内容，而不会隐藏信息本身。例如 “无字墨水”。3.23强口令 strong password强口令是设计使得个人或程序难得发现的一种口令。由于口令的目的在于保证只有授权用户才能访问资源，容易猜测的口令存在安全隐患。强口令的基本元素包括足够的长度以及多种字符类型的混合。当人们创建口令时，他们常常选择他们的名字、宠物的名字甚至“password”这个词，从而违背了口令的目的。3.24安全扫描 security scan利用安全扫描工具依照程序设定自动探测及发掘规则以探测系统缺陷和存在的漏洞。通过安全扫描查找安全漏洞，查杀病毒，木马，蠕虫等危害系统安全的恶意程序，检测主机当前可用的服务及其开放端口，查找可能被远程试图恶意访问者攻击的大量众所周知的漏洞，隐患及安全脆弱点。4 概述哈密市法人银行业金融机构软件开发安全需求规范（以下简称需求规范）是为规范软件开发中安全建设而制定的标准性文档，制定该规范目的是为了明确软件开发中需要遵循的信息安全标准。依据该规范，软件开发人员在软件开发整个生命周期中,规范软件安全需求分析、安全设计、安全编码以及安全测试等工作，减少和控制软件安全漏洞和安全隐患，提高软件安全防护能力，进而开发符合法人银行业金融机构信息安全规范的高质量软件。该规范制定过程中考虑了目前开发管理的实际情况并参照业界软件安全研究成果，从可操作性方面考虑，本版软件开发安全需求规范仅确定了软件开发中应遵循的最小安全规范集合，该规范中所涉及的内容是软件开发中必须执行的内容，也是软件验收环节安全测试的依据，安全测试将作为评判软件是否符合上线的指标之一。在软件开发过程中的安全需求必须涵盖但不限于本规范的要求，重要系统软件开发中要根据自身软件风险分析情况充实完善软件安全需求。5T/HMSJRXH 001-2023信息安全攻防技术是一个快速发展的领域，为应对新出现的软件安全漏洞和安全缺陷， 需求规范也将定期更新，新补充的软件安全需求内容将会在随后版本中得到整合体现。5 适用范围哈密市法人银行业金融机构软件开发安全需求规范中提到的软件包括在服务端、客户端运行以及单机上独立运行的软件，需求规范中所指的软件包括哈密市法人银行业金融机构独立开发的软件及与外单位合作开发的软件，也包括通过委托外包方式开发的软件。各项目经理、开发人员及安全管理人员是哈密市法人银行业金融机构软件开发安全需求规范的使用对象。项目经理及开发人员负责软件开发安全需求在软件开发过程的落实工作，负责软件安全测试工作；安全管理人员负责项目可研立项阶段、需求分析和软件设计阶段的安全审核工作以及软件上线、验收过程中的安全测试审核工作。6 安全需求软件开发安全需求包括六个方面，依次为软件访问控制、数据保护、编码安全、日志管理、部署准备和开发环境管理。访问控制部分说明软件自身在用户识别和授权方面的具体要求，明确软件访问控制应具备的基本要素。数据保护部分说明如何在对数据分类的基础上，选择适当的技术措施进行数据安全保护。编码安全强调何种编码行为是要严格遵守，何种编码方式具有高隐患应予禁止，进而说明如何建立一种安全的软件编码机制。日志管理部分主要从可审计角度来考虑，明确软件应记录的行为内容、记录格式以及对日志的管理办法。部署准备说明软件上线前要对编码进行梳理规范，清除不必要的调试编码等信息，避免信息泄露等隐患。开发环境管理说明如何处理软件本身与开发和运行主机之间的关系，以保持软件自身安全与运载环境安全的一致性。6.1 访问控制所有软件在可研阶段进行分析时，应当详尽分析所有用户在正常和异常情况下访问软件本身及相关数据时可能存在的影响，申明访问控制能够保护的途径，以及软件访问控制本身不能保护而需要其他系统、网络和硬件等层面保护的范围。软件需求中必须明确软件访问控制的安全要求。认证和授权是信息安全的第一关，综合考虑安全和开发效率的关系，今后凡是需要在全行范围内推广使用的软件，涉及到访问控制功能部分，必须优先考虑利用哈密市法人银行业金融机构已有的认证授权安全平台来完成。访问控制主要考虑用户管理、用户认证、授权和会话控制四部分。6.1.1 用户管理6.1.1.1 用户分类6T/HMSJRXH 0012023用户必须按类型和角色分类管理，至少分成系统维护人员、业务操作员以及软件服务对象三类。系统维护人员是指确保软件系统正常运行的维护人员（例如日常维护软件系统的数据备份人员、版本管理人员等）;业务操作员是指利用该软件为客户提供服务的业务人员(如银行柜面操作员、后台业务管理人员等);软件服务对象是指该软件最终服务的客户(如网上银行的客户、通过桌面设备、自助设备自行操作的客户，还包括通过业务操作员代为划卡等方式接触软件系统的用户等),帐户是其在软件系统中的身份标示。系统维护人员、业务操作员类别内也要至少分成具有用户管理权限的高级用户和仅仅从事一般业务的普通用户。6.1.1.2 用户身份管理根据业务上对用户身份管理要求，软件应提供相应的用户身份帐户管理机制，包括提供用户身份帐户的创建、注销、冻结/解冻、修改、查询等功能，同时还应该具备检测出长期不动用户，并自动将长期不动用户置成冻结状态的机制，并按生命周期进行全面管理。记录身份信息的变动历史，并能够监控帐户状态。普通用户的用户管理工作由同一用户类别内高级用户完成。6.1.2 用户认证对于所有用户的访问都必须通过认证。软件设计开发时，应仔细选择符合安全要求的认证方式。包括静态口令、动态口令、数字证书、生物特征等。谨慎考虑是否存在不通过认证直接访问资源的途径，并采取有效的技术和管理手段加以弥补。6.1.2.1 口令管理软件必须对用户的口令属性（口令长度、试探次数、口令生命期）有基本要求。原则上口令长度不得低于8位。最大连续试探次数不得超过5次。软件应该提供强制用户（不包含银行客户）定期更新口令机制，初始口令获取后首次使用时必须强制修改。口令最长有效期限：30/60/90 天，可根据系统重要性和用户权限采取不同的有效期；口令使用期限即将达到口令最长有效期限时，应具有提示用户修改口令的机制。对于口令仅由简单数字组成，如111111、123456等弱口令，软件应该提供弱口令供检测和警示机制。软件应具备口令保护机制。用户口令必须加密存储计算机系统中，严禁在网络上明文传输用户口令，在用户输入口令时，严禁在屏幕上显示口令明文，严禁输出口令明文（密码信封除外）。软件应该提供管理员重置用户口令的机制。6.1.2.2 认证限制根据业务需要，提供限制用户的登录时间和IP地址的机制，软件具有控制用户登录的能力（如IP7T/HMSJRXH 001-2023限制）。对于客户自行设定口令（如客户银行卡和定期密码），软件应该提供弱口令检测和警示机制，对于系统维护人员、业务操作员设定弱口令（如柜员密码），软件应该提供检测和拒绝机制。在连续登录失败次数超过5次的情况下，软件应提供警示和暂停用户登录的机制，避免非法用户恶意登录。在连续登录失败超过5次暂停用户后，软件依然显示与普通登录错误相同提示信息-用户名/口令密码错误，用于迷惑恶意攻击者，为跟踪黑客行为提供条件。软件可以提供锁定用户一定期限后自动解锁机制，也可以提供人工解锁用户机制。在用户成功登录后，在客户访问应用的程序或者页面上，软件需要结合业务要求，从以下几个方面，对用户进行告知：用户访问的是一个合法的系统；用户的隐私将得到保护；本系统可能使用到用户敏感的数据；本系统将对用户的行为进行审计。如果是非合法用户，则显示警示信息，提示该用户不是该软件的合法使用对象，同时拒绝非法用户登录。6.1.3 用户授权软件需求定义阶段，应遵循最小授权原则，根据业务逻辑，对用户和数据访问关系进行分析，软件需求定义阶段应定义用户访问数据授权关系，针对不同类型用户或角色分别建立最小数据访问列表，对用户访问何种数据进行明确定义和控制。所有权限鉴别过程需要通过单独的授权模块来实现。授权时可以根据用户的属性自动赋予权限，也可以由高级用户根据授权规则人工设置。软件具备对非法用户限制授权机制。没有经过认证的用户不可以分配权限（公开信息网站网页浏览用户除外）。6.1.4 会话控制软件应对有关用户管理、认证和授权数据的会话进行加密保护。互联网及外联平台应用开发中要对非内部用户使用的认证信息中用户信息和口令分不同数据包传递。软件可以利用时间戳等技术手段，建立合理的会话空闲中断提示功能和退出机制。对于会话残留信息，必须及时清理。软件必须提供会话数量控制手段，保证软件的高可用性。6.2 数据保护6.2.1 重点保护数据8T/HMSJRXH 0012023哈密市法人银行业金融机构信息系统数据坚持“分类保护，突出重点，实施分级”的保护原则。根据业务安全规定，重要数据要求特别保护，该类数据的传输、存取和存储，必需采取加密措施保护，仅能通过内置的软硬件加解密模块进行管制。需要加密保护的数据可根据数据的作用、传输的环境以及外泄可能性等方面进行考虑：从数据作用来看，需要保护用户身份、口令、认证和授权等访问控制数据；从传输环境看，现阶段尤其需要保护互联网和外联网上传输的数据；从存储安全来看，需要保护第三方维护时可能接触到的数据（如维护 ATM 等外部设备时）；其他根据业务安全要求需要特别保护的数据，如重要客户信息等。哈密市法人银行业金融机构其他普通数据也需要通过管理和技术手段进行保护。6.2.2 数据完整性对于互联网和外联环境，软件应考虑对传输的数据采用必要的技术来验证数据包是否被篡改。6.2.3 加密技术及服务各软件使用的加密服务应优先采用银行自有加密平台，各软件不应重复开发已有的加密算法。哈密市法人银行业金融机构提供的对称算法主要包括：DES、3DES、AES、SM1和SM4等算法，并且支持ECB、CBC等多种模式；使用的非对称算法主要包括：RSA、SM2和SM3算法，支持模长为1024/2048的运算。提供无键控Hash函数。软件如果需要采用特殊的加密技术和服务，需要说明采用的理由，并报请机构人员。需要重点加密保护的数据在应用层面进行传输时，应实现点到点的加密数据传输。用于两点之间信息传输加/解密的密钥，不应被非可信的第三方获悉。6.2.4 密钥管理数据保护密码服务应采用非对称密钥、对称密钥相结合的密钥管理体系。非对称密钥的管理以数字证书为基础。对称密钥基于非对称密钥协商产生（不支持非对称算法的应用环境除外）。非对称密钥主要用于对称密钥的管理、数字签名等，一般不用于数据、信息的传输加密。对称密钥用于数据、信息的加密/解密。密钥管理应具有通过配置的方式或动态协商的方式更换加密算法的功能。用于数据、信息传输加/解密的密钥，必须设定有效期，不应采用固定密钥。密钥采用强口令标准。对含有私钥信息的数字证书应存放在加密机、加密IC卡或者USBKey等硬件设备中，在能够保障主机系统安全的情况下，数字证书可以PKCS#12文件方式保存，并应有强口令保护。6.3 编码安全6.3.1 安全需求要求安全开发的第一步，是编写一个准确完整的软件安全需求，说明书应该覆盖访问控制、数据保护、编码安全、安全日志、部署准备和环境管理等内容。9T/HMSJRXH 001-2023安全需求应该从各种安全策略中选出适合应用需求的安全策略，并描述清楚软件应该如何执行，以便符合法人银行业金融机构安全策略的要求。安全策略确认后，软件开发安全需求分析应仔细例化访问控制等六个方面的具体安全要求，在设计阶段必须定义好用到的安全技术架构、安全控制和安全功能，对每个安全控制和安全功能的功能、接口、数据的输入输出进行详细的分析。一个准确完整的软件安全需求应能在软件的生命周期中尽早地发现应用的安全弱点和漏洞，并用最小的代价来预防和消除这些安全弱点和漏洞。在软件的生命周期内，应该根据业务需求、设计、开发和部署的变化及时调整更新软件安全需求。6.3.2 设计和编码要求6.3.2.1 统一的安全规范每个软件项目在设计阶段都应明确，在项目实施过程中项目组应该遵循的统一规范：具体包括命名规则、API引用、错误处理、避免使用全局变量等。6.3.2.2 模块划分软件应该按照安全性划分模块，审计和访问控制模块为安全可信模块，其它模块为不可信任模块。只有安全可信模块才可以执行安全控制功能，其它的模块不能访问安全可信模块的安全信息、功能或者权限。安全可信模块应该与其它模块分离，由经授权的哈密市法人银行业金融机构内部专人进行管理。只有安全可信模块，才能以高安全等级访问系统的敏感信息，对于其他模块限制其访问敏感信息。系统的敏感信息包括：用户身份信息；认证信息；授权信息；交易过程中的私密或隐私信息；其它的敏感信息。6.3.2.3 最小功能性根据“没有明确允许的就默认禁止”的原则，软件应只包含那些为达到某个目标而确实需要的功能，不应包含只是在将来某个时间需要但需求说明书中没有包括的功能。软件在最小化功能建设方面应遵循如下原则：只运行明确定义的功能；系统调用只在确实需要的时候；一次只执行一个任务；只有在上一个任务完成后才开始下一个任务；只有在确实需要的时候访问数据。10T/HMSJRXH 00120236.3.2.4 对多任务、多进程加以关注软件开发应尽量使用单任务的程序。如果软件需要使用多任务和多进程，应该认真分析研究多任务和多进程不会发生冲突，同步所有的进程和任务以避免冲突。同时作为结构化的编程，每个原子化组件都要保证一个入口和一个出口。6.3.2.5 界面输出最小化软件必须保持用户界面只提供必须的功能，没有旁路，确保用户不能通过用户界面直接访问数据或者直接访问被保护对象。6.3.2.6 使代码简单、最小化和易于修改开发时应尽量使代码简单、最小化和易于修改。使用结构化的编程语言，避免使用递归和Go to声明。使用简单的代码，清除不必要的功能，防止采用信息隐藏方式进行数据保护。6.3.2.7 避免高危的服务、协议软件应禁止使用FTP、SMTP等高危方式传输文件。6.3.2.8 数据和代码分离软件应该把数据与程序放置在不同的目录中，这里的数据包括远程下载文件等。6.3.2.9 重点数据传输保护软件在传输重点保护数据时，应该对重点保护数据进行加密后再传输，也可使用SSL/TLS等安全、可信任协议进行加密传输。同时可以应用Hash值等来确保数据完整性，使用数字签名来保证不可否认性。信息隐藏是不可靠、效率低的做法，软件应该使用正确的安全保护措施，不要依赖隐藏进行数据保护。6.3.2.10禁止赋予用户进程特权对于软件的普通用户进程，禁止赋予该类进程特权用户权限。特权用户类型包括：超级用户；直接操作数据库用户；安全管理用户。6.3.2.11使用适当的数据类型应该小心使用数据类型，特别是在程序接口部分。例如，在一些编程语言中signed和unsigned的数11T/HMSJRXH 001-2023据类型是视为不同的（如C或者C+语言）。6.3.2.12使用经过验证的安全代码使用经过验证的安全代码模块和外部源程序，防止潜在的安全风险。6.3.2.13使用应用中间件中间件作为一种应用层架构，软件设计应尽可能使用中间件，要在哈密市法人银行业金融机构选型的产品目录中选择所需的中间件。6.3.2.14设计错误、异常处理机制软件设计开发时应建立防止系统死锁的机制，异常情况的处理和恢复机制：具体包括错误和异常检测、交易回滚、安全错误通知、错误和异常记录、断点保护等。6.3.2.15提供备份机制为保证运行数据的完整性和可用性，软件开发必须设计有效的备份策略，根据业务和系统维护需要提供定期或不定期、自动或者手动方式的备份机制。6.3.3 保护机密性要求6.3.3.1 关注应用的对象重用对于底层系统的对象可重用性来说，应用软件需要提供对敏感的数据使用后马上覆盖的能力，这些敏感数据包括口令、安全密钥、会话密钥或者其它的高度敏感的数据。6.3.3.2 用户访问控制信息的机密性禁止在程序代码中直接写用户名和口令等用户访问控制信息。6.3.3.3 不要在客户端存放重点保护数据由于客户端是不可信任的，软件不要在客户端存放重点保护数据。特别注意在使用Cookie时不要把客户重要信息储存在客户端。6.3.3.4 避免内存溢出软件设计开发中，为防止内存溢出，应注意以下事项：在对缓存区填充数据时必须进行边界检查，判断是否超出分配的空间；12T/HMSJRXH 0012023对于数据库查询操作，如果查询返回的结果较多时，必须设计成分次提取；应保证系统资源及时释放和服务连接的及时关闭；软件程序必须检查每次内存分配是否失败；其他可能引起内存溢出的情况。6.3.3.5 输入保护在系统设计开发阶段，必须详细定义可接受的用户输入描述。软件必须对每次用户输入的信息长度进行检查，判断是否超出范围。软件必须检查用户输入的内容是一个有效的数据串，而不是其它类型的对象。检验输入数据串是否与预先定义的格式和语法一致，并完成适当的规范性检查。软件必须对输入信息中的特殊字符（如“>”、“<”等）进行检查、处理。软件应该采取措施保护会话，防止会话超时和会话劫持等漏洞。应该采取措施对 HTTP 报文头进行检查，防止浏览器到服务端被恶意修改。对输入的数据串进行检查，避免在输入中直接注入 SQL 语句。对 URL 和路径名称进行检查，确定当中没有包含指向恶意代码的内容，防止攻击者利用 URL 的扩展进行重定向，注入等攻击。6.3.3.6 输出保护软件应该限制返回给客户与业务办理无关的信息，防止把重点保护数据返回给不信任的用户，避免信息外泄。软件应有一套输出保护的方法。例如：检查输出是否含有非必要的信息；检查输出是否含有不符合业务管理规定的信息；其它需要检查的输出信息。软件还应该有错误信息保护机制，禁止将供软件维护人员使用的系统错误诊断信息提交给软件服务对象。6.3.3.7 可配置数据保护限制非应用软件用户访问可配置数据。6.4 安全日志6.4.1 安全日志的内容安全日志必须记录在独立的日志文件或日志数据库中。13T/HMSJRXH 001-20236.4.1.1 软件状态当软件运行的服务状态发生变化时应产生一个事件，并将这个发生的事件记录到安全日志中。这些事件包括：软件启动；软件停止；6.4.1.2 软件配置当软件所处的运行环境发生变化时，应将发生的事件记录到安全日志中，这些事件包括：软件配置参数发生改变；库文件的路径发生改变；6.4.1.3 访问控制信息当软件产生一个访问控制的事件时，应将事件记录到安全日志中。这些事件包括：由于超出尝试次数的限制而引起的拒绝登录；成功或失败的登录；用户权限的变更；用户密码的变更；授权用户执行了角色中没有明确授权的功能；用户试图执行角色中没有明确授权的功能。用户账户的创建；用户帐户的注销；用户账户的冻结；用户账户的解冻；6.4.1.4 用户对数据的异常操作当软件运行时发生用户对数据的异常操作事件，应将事件记录到安全日志中。这些事件至少包括：不成功的存取数据尝试；数据标志或标识被强制覆盖或修改；对只读数据的强制修改；来自非授权用户的数据操作；特别权限用户的活动；6.4.2 安全日志禁止记录的内容对于哈密市法人银行业金融机构的软件，下面列举的内容不应该记录在安全日志文件中：客户敏感信息（如密码、磁道信息等）14事件类型号事件描述