应用安全技术规范

应用安全技术规范一、总则与适用范围本规范旨在为应用系统的全生命周期提供标准化的安全技术指引，确保应用在设计、开发、测试、部署及运维阶段具备抵御各类网络攻击的能力，保障业务数据的机密性、完整性和可用性。本规范适用于公司内部所有基于Web、移动端及API接口的业务系统，包括但不限于对外服务的互联网应用、对内管理的办公系统以及涉及核心数据处理的后台服务。所有研发、测试、运维及安全相关人员必须严格遵循本规范，将安全作为系统交付的必要条件。安全建设应遵循“安全左移”原则，在需求分析与设计阶段即介入安全考量，通过技术手段与管理流程的结合，构建纵深防御体系，有效防范SQL注入、跨站脚本攻击（XSS）、远程代码执行（RCE）等常见Web漏洞，以及业务逻辑层面的越权、数据泄露等风险。二、安全架构设计原则应用系统的架构设计必须建立在安全的基础之上，严禁为了追求性能或开发便利而牺牲安全性。架构设计需遵循最小权限原则、纵深防御原则及默认安全原则。2.1分层防御与边界控制系统应采用清晰的分层架构，在不同层级之间实施严格的访问控制策略。对外服务的入口必须部署Web应用防火墙（WAF），对HTTP/HTTPS流量进行实时清洗，拦截恶意攻击请求。内部服务之间调用应通过微服务网关进行统一鉴权与路由，禁止直接暴露内部服务接口。对于核心数据区域，必须通过网络隔离技术（如VPC、子网划分）限制访问源，仅允许指定的应用服务器IP地址连接数据库或中间件的特定端口。2.2零信任访问模型在身份认证方面，应摒弃传统的基于网络边界的信任模型，转向零信任架构。即无论访问请求来自内部网络还是外部网络，均需经过严格的身份验证和授权。系统应支持基于风险的动态访问控制，根据用户的行为特征、设备环境、地理位置等因素动态调整认证强度。例如，当检测到异地登录或异常设备时，应强制要求多因素认证（MFA）或直接阻断访问。2.3资源配额与抗拒绝服务为防范拒绝服务攻击，系统架构必须具备流量清洗与资源限流能力。在网关层及应用层应配置合理的连接数限制、请求速率限制（RateLimiting）及并发数限制。针对关键接口，应实施基于令牌桶或漏桶算法的限流策略，防止因突发流量或恶意高频请求导致系统资源耗尽。同时，需做好服务器资源的监控，在CPU、内存或带宽使用率超过阈值时自动触发报警或扩容机制。三、身份认证与访问控制身份认证是应用安全的第一道防线，必须确保用户身份的真实性，并严格控制其权限范围。3.1身份认证机制系统必须采用强密码策略，禁止弱口令存在。用户密码在传输过程中必须使用TLS1.2及以上版本加密，严禁明文传输。密码存储必须使用不可逆的哈希算法（如Argon2、bcrypt或PBKDF2），并配合随机盐值（Salt）进行存储，严禁直接存储明文密码或使用MD5、SHA1等已被证明不安全的哈希算法。对于高敏感操作或特权账号，必须强制实施多因素认证（MFA）。MFA应支持短信验证码、动态令牌（TOTP）、生物识别等多种方式，且验证码本身必须具备随机性、时效性（通常不超过5分钟）和一次性使用限制。3.2会话管理应用系统必须严格管理用户会话。会话标识（SessionID）应由服务端随机生成，长度不得小于128位，且具备足够的熵值，避免可预测性。SessionID不得通过URL参数传递，防止通过Referer泄露。必须设置安全的Cookie属性，包括：Secure：确保Cookie仅通过HTTPS协议传输。HttpOnly：禁止JavaScript脚本访问Cookie，防范XSS攻击窃取会话。SameSite：设置为Strict或Lax，防范跨站请求伪造（CSRF）。会话必须具有合理的超时机制，用户在一段时间内无操作（建议为15-30分钟）后应自动登出。在用户点击“退出登录”时，服务端必须立即销毁对应的会话状态。3.3权限控制模型系统应实施基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC）。权限控制检查必须在服务端执行，严禁仅依赖前端隐藏按钮或链接来进行权限限制。每一个API接口或功能点在执行前，都必须校验当前用户是否具备相应的操作权限。对于涉及对象数据的访问，必须实施细粒度的数据级权限控制。例如，普通用户查询订单接口，必须在SQL查询条件中强制加入当前用户ID的过滤条件，防止通过修改参数ID越权查看其他用户的订单数据（水平越权）。同时，严禁普通用户通过接口访问管理员功能（垂直越权）。四、通信与传输安全为防止数据在网络传输过程中被窃听、篡改或劫持，必须保障全链路的通信安全。4.1HTTPS强制实施所有生产环境的应用系统必须强制使用HTTPS协议，禁止使用HTTP协议。服务器必须配置有效的SSL/TLS证书，严禁使用自签名证书或已过期的证书。服务器应配置HSTS（HTTPStrictTransportSecurity），强制浏览器仅通过HTTPS访问站点，并设置合理的IncludeSubDomains和Max-Age参数。4.2TLS配置规范服务器与客户端之间的TLS连接配置应遵循以下安全标准，禁用不安全的加密套件和协议版本。推荐的TLS配置参数如下表所示：配置项推荐值/策略说明TLS协议版本TLS1.2,TLS1.3禁用SSLv2,SSLv3,TLS1.0,TLS1.1加密套件优先选择AES-GCM,ChaCha20-Poly1305禁用RC4,DES,3DES,AES-CBC(无SIV)等弱加密算法前向保密强制要求(EphemeralDH/ECDH)确保即使服务器私钥泄露，历史会话数据也无法解密证书签名使用SHA-256及以上哈希算法禁用SHA-1签名的证书OCSP装订启用提高证书状态验证效率，减少握手延迟4.3API接口安全对于前后端分离或第三方集成的API接口，必须实施严格的身份认证和签名机制。建议使用OAuth2.0或OpenIDConnect等标准协议进行授权。对于高安全要求的接口，应对请求参数进行签名验证，确保请求在传输过程中未被篡改。API接口应返回适当的HTTP状态码，例如401表示未认证，403表示无权限，500表示服务器内部错误，严禁在错误响应中暴露堆栈信息、服务器路径或数据库表结构等敏感信息。五、输入验证与输出编码绝大多数的Web攻击（如SQL注入、XSS、命令执行）都源于对用户输入的信任。因此，必须建立严格的输入验证和输出编码机制。5.1输入验证所有来自用户的数据输入，包括URL参数、表单数据、Cookie、HTTPHeader等，都必须被视为不可信的。验证应采用“白名单”机制，仅允许符合预期格式、类型和长度的数据通过。例如，年龄字段应为整数且在合理范围内，姓名字段应仅包含特定字符且长度受限。数据类型验证策略示例拒绝字符/模式示例整数正则表达式`^\d{1,10}$`任何非数字字符，超大数值邮箱符合RFC5322标准格式包含脚本标签`<script>`，SQL注入字符`'`日期ISO8601格式(YYYY-MM-DD)任意字符串，逻辑不存在的日期富文本使用HTMLsanitizer库(如DOMPurify)`<script>`,`javascript:`,`onerror=`5.2SQL注入防护严禁使用字符串拼接的方式构造SQL语句。所有数据库访问必须使用参数化查询（PreparedStatements）或使用成熟的ORM框架。在特殊场景下必须使用动态SQL时，必须对所有输入变量进行严格的转义处理。数据库账号应遵循最小权限原则，应用账号禁止拥有DROPTABLE、TRUNCATE、GRANT等管理权限。5.3输出编码与XSS防护为了防范跨站脚本攻击（XSS），系统在将数据输出到HTML页面、JavaScript代码块或URL参数时，必须进行上下文相关的HTML实体编码。例如，输出到HTMLBody时，将`<`转义为`<`，`>`转义为`>`。输出到JavaScript变量时，需要进行Unicode转义。此外，应启用内容安全策略（CSP），通过HTTPHeader限制浏览器加载外部资源的来源，有效缓解XSS攻击的危害。5.4命令注入防护应用系统应尽量避免调用系统命令执行函数（如Java中的Runtime.exec，PHP中的system、exec）。如果必须调用，严禁将用户输入直接作为命令参数。必须对参数进行严格的白名单过滤，或者使用编程语言提供的带参数转义的命令执行函数。六、数据安全与加密数据是企业的核心资产，必须从数据的产生、存储、传输、使用到销毁的全生命周期进行保护。6.1敏感数据识别与分类系统应根据数据的重要性和敏感程度进行分类分级。常见的敏感数据包括：个人身份信息（身份证号、手机号）、银行卡号、密码、密钥、生物识别信息等。对于敏感数据，必须在数据库设计时进行明确标识，并在代码层面实施特殊处理。6.2存储加密敏感数据在数据库中存储时必须进行加密。建议采用透明的数据加密（TDE）技术对数据库文件级进行加密，或者应用层使用国密算法（如SM4）或AES-256算法对字段级进行加密。加密密钥的管理必须与数据存储分离，使用专业的密钥管理服务（KMS）或硬件安全模块（HSM）进行密钥的生成、存储和轮换，严禁将密钥硬编码在代码中或存放在配置文件中。6.3数据脱敏在前端展示、日志记录、导出报表等场景中，必须对敏感数据进行脱敏处理。例如，手机号中间四位显示为星号（138****5678），身份证号遮挡出生日期部分。日志系统严禁记录用户的明文密码、银行卡号等原始敏感信息。在前端展示、日志记录、导出报表等场景中，必须对敏感数据进行脱敏处理。例如，手机号中间四位显示为星号（138****5678），身份证号遮挡出生日期部分。日志系统严禁记录用户的明文密码、银行卡号等原始敏感信息。6.4备份与恢复安全数据备份是应对勒索病毒和数据丢失的最后一道防线。必须建立定期的自动化备份机制，并对备份数据进行加密存储。备份数据应存储在异地或物理隔离的环境中。应定期（至少每季度）进行数据恢复演练，验证备份的有效性和完整性。同时，严格限制对备份介质的访问权限，防止备份数据泄露。七、软件供应链安全随着开源组件和第三方库的广泛使用，软件供应链安全成为应用安全的重要组成部分。7.1第三方组件管理系统引入的第三方库、框架、中间件必须经过安全评估。严禁使用存在已知高危漏洞（CVSS评分>=7.0）的组件。应建立软件物料清单（SBOM），详细记录项目中使用的所有组件及其版本信息。使用自动化工具（如OWASPDependency-Check、Snyk）定期扫描依赖项，及时发现并修复漏洞。7.2开源组件合规性在使用开源软件时，必须严格遵守其开源许可证（LGPL,GPL,MIT等）的要求，避免侵犯知识产权或引发商业法律风险。对于Copyleft类型的许可证，需特别注意其对代码开源的传染性要求。7.3开发环境安全开发人员的代码仓库、构建服务器、包管理仓库必须配置严格的访问控制。禁止在代码中硬编码凭证，应使用环境变量或密钥管理工具注入敏感信息。CI/CD流水线应集成代码安全扫描（SAST）和依赖扫描，确保不安全的代码无法被构建和部署到生产环境。八、运行安全与监控安全是一个持续的过程，不仅需要构建安全的系统，还需要在运行阶段保持持续的监控和响应能力。8.1安全日志与审计系统必须记录关键的安全事件日志，包括但不限于：用户登录/登出、权限变更、敏感数据访问、失败的操作尝试（如连续登录失败）。日志内容应包含时间、来源IP、操作人、操作类型、操作结果等关键要素。日志格式建议采用JSON等结构化格式，便于后续分析。日志应发送至集中的日志服务器（如ELKStack或Splunk）进行长期存储，保存时间至少6个月，满足合规审计要求。8.2异常行为监控应部署应用性能监控（APM）和安全信息事件管理（SIEM）系统，对系统的运行状态进行实时监控。建立基于基线的异常检测规则，例如：单个用户在短时间内请求大量接口（可能在进行爬虫或撞库）。单个用户在短时间内请求大量接口（可能在进行爬虫或撞库）。某个接口的响应时间突然飙升（可能遭受慢速攻击或资源耗尽）。某个接口的响应时间突然飙升（可能遭受慢速攻击或资源耗尽）。数据库出现大量的全表扫描或异常连接数。数据库出现大量的全表扫描或异常连接数。一旦触发告警规则，应立即通过邮件、短信或即时通讯工具通知安全运维人员。一旦触发告警规则，应立即通过邮件、短信或即时通讯工具通知安全运维人员。8.3漏洞管理与补丁应建立定期的漏洞扫描和渗透测试机制。在系统上线前、重大变更后，必须进行人工渗透测试。对于自动化扫描工具发现的漏洞，需进行验证并修复。服务器操作系统、数据库、Web服务器（Nginx/Apache）、运行时环境（Java/Python/Node.js）必须定期安装最新的安全补丁，修复操作系统层面的漏洞。九、应急响应计划尽管采取了多种防护措施，但仍无法完全杜绝安全事件的发生。因此，必须制定完善的应急响应预案（IRP），确保在安全事件发生时能够快速、有效地进行处置，将损失降到最低。9.1事件分级与响应流程根据安全事件的影响范围和严重程度，将其分为一般、较大、重大、特别重大四个等级。针对不同等级的事件，制定明确的响应流程，包括事件发现、上报、研判、处置、恢复、总结等阶段。9.2常见攻击处置指南针对常见的攻击类型，制定具体的处置手册：网页篡改：立即切断对外网络连接，开启维护模式，查找被篡改文件，从备份中恢复干净版本，修复上传漏洞。勒索病毒：立即断网，防止横向扩散，评估感染范围，联系专业安全厂商协助解密或使用备份数据恢复。数据泄露：立即封堵泄露源头（如关闭API接口），评估泄露数据量，通知法务部门，根据法律法规要求上报监管机构并通知受影响用户。9.3攻击溯源在处置安全事件后，应利用日志留存、流量回溯分析等技术手段进行攻击溯源，分析攻击者的入侵路径、攻击手法和攻击目的，并针对性地加固系统防护策略，防止同类攻击再次发生。十、移动应用安全专项对于移动端应用（App、小程序），除遵循上述通用规范外，还需满足以下专项安全要求。10.1客户端安全加固移动应用客户端在发布前必须进行加固处理，防止被反编译、篡改或注入恶意代码。应启用代码混淆、资源加密、反调试、反Hook等保护技术。严禁在客户端本地存储明文的用户密码或会话Token，应使用操作系统提供的安全存储机制（如iOS的Keychain，Android的Keystore）。10.2通信安全移动应用与服务端的通信必须使用双向SSL认证或高强度的API签名机制，防止中间人攻击（MITM）或通过模拟器/抓包工具进行重放攻击。应对API请求的时间戳进行校验，请求的有效期应控制在合理范围内（如60秒内），防止重放攻击。10.