《WEB应用系统安全规范方案文档》由会员分享，可在线阅读，更多相关《WEB应用系统安全规范方案文档（15页珍藏版）》请在金锄头文库上搜索。
1、 完美WORD格式WEB应用系统安全规范目 录WEB应用系统安全规范11概述41.1目的41.2适用范围42范围43名词解释44WEB开发安全规范54.1Web应用程序体系结构和安全54.2Web安全编码规范74.2.1区分公共区域和受限区域74.2.2对身份验证 cookie 的内容进行加密74.2.3限制会话寿命74.2.4使用 SSL 保护会话身份验证 Cookie74.2.5确保用户没有绕过检查74.2.6验证从客户端发送的所有数据84.2.7不要向客户端泄漏信息84.2.8记录详细的错误信息84.2.9捕捉异常84.2.10不要信任 HTTP 头信息84.2.11不要使用 HTTP-
2、GET 协议传递敏感数据84.2.12不要在永久性 cookie 中存储敏感数据84.2.13对数据进行加密或确保通信通道的安全94.2.14SQL 语句的参数应以变量形式传入94.2.15页面中的非源代码内容应经过 URI 编码94.2.16页面中拼装的脚本应校验元素来源的合法性94.2.17页面请求处理应校验参数的最大长度94.2.18登录失败信息错误提示应一致104.2.19避免页面上传任意扩展名的文件104.2.20避免接受页面中的主机磁盘路径信息104.2.21第三方产品的合法性105系统部署安全规范105.1部署架构和安全105.1.1网络基础结构组件115.1.2部署拓扑结构12
3、5.2部署操作安全规范125.2.1确保管理界面的安全125.2.2确保配置存储的安全125.2.3单独分配管理特权125.2.4使用最少特权进程和服务帐户125.2.5尽量避免存储机密135.2.6不要在代码中存储机密135.2.7不要以纯文本形式存储数据库连接、密码或密钥135.2.8限制主机上 WEB 系统启动用户的权限135.2.9隐藏后台调试信息135.2.10密码加密存储135.2.11隐藏重要配置参数信息145.2.12隐藏日志文件145.2.13禁用 WebDAV，或者禁止不需要的 HTTP 方法145.2.14保证管理平台、测试账号口令强度145.2.15定期核查文件上传路径
4、、日志路径中是否存在木马145.2.16及时删除应用系统临时文件145.2.17重要系统隔离146安全审计156.1审核并记录跨应用层的访问156.2考虑标识流156.3记录关键事件156.4确保日志文件的安全156.5定期备份和分析日志文件167规范更新机制168规范的执行169参考资料171 概述1.1 目的为规范我司Java Web应用编码和部署的安全控制和管理，特制定本规范，并作为安全检查及考核的参考依据。1.2 适用范围本规范适用于我司所有在线Java业务系统、测试系统的WEB应用。本规范可作为其他非WEB应用的编码和部署安全办法参考。2 范围本规范中列出的是常见安全措施和高风险的漏
5、洞，在系统开发与系统部署的过程中，对本规范未能尽述的必要安全措施，仍应予以采用。本规范每年复审一次，其它时候也可以根据需要进行修订并发布。 本规范的解释权和修改权归属信息技术部。3 名词解释验证：通讯实体(例如，客户端和服务器)彼此验证，以经过访问授权的特定标识为依据。资源的访问控制：资源的交互仅限于某些用户或程序的集合，其目的是对完整性，保密性或可用性实施强制约束。 数据完整性：检验信息是否被第三方(非信息源的其它实体)修改。例如，处于开放网络环境中的数据接收方必须能够检测并丢弃那些在传递过程中被修改过的消息。 机密性或数据隐私：确保信息仅对经过访问授权的用户可用。 不可否认：对用户进行检验
6、，让他无法否认自己进行过的活动。 审核：捕获一个安全相关事件的防篡改记录，目的是评估安全策略和机制的有效性。 4 Web开发安全规范4.1 Web应用程序体系结构和安全HTTP 是无国界的，这意味着跟踪每位用户的会话状态将成为应用程序的责任。应用程序必须能够通过某种形式的身份验证来识别用户。由于所有后续授权决策都要基于用户的标识，因此，身份验证过程必须是安全的，同样必须很好地保护用于跟踪已验证用户的会话处理机制。设计安全的身份验证和会话管理机制仅仅是Web 应用程序设计人员和开发人员所面临的众多问题中的两个方面。由于输入和输出数据要在公共网络上进行传输，因此还会存在其他挑战。防止参数操作和敏感
7、数据泄漏也是另外一些重要问题。Web应用程序安全设计是根据应用程序漏洞类别进行组织的。实际经验表明，如果这些领域的设计存在薄弱环节，将会导致安全漏洞。下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。漏洞类别由于设计不当而引起的潜在问题输入验证嵌入到查询字符串、表单字段、cookie 和 HTTP 头中的恶意字符串的攻击。这些攻击包括命令执行、跨站点脚本(XSS)、SQL 注入和缓冲区溢出攻击。身份验证标识欺骗、密码破解、特权提升和未经授权的访问。授权访问保密数据或受限数据、篡改数据以及执行未经授权的操作。配置管理对管理界面进行未经授权的访问、具有更新配置数据的能力以
8、及对用户帐户和帐户配置文件进行未经授权的访问。敏感数据泄露保密信息以及篡改数据。会话管理捕捉会话标识符，从而导致会话劫持及标识欺骗。加密访问保密数据或帐户凭据，或二者均能访问。参数操作路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。异常管理拒绝服务和敏感的系统级详细信息的泄漏。审核和记录不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。针对上述漏洞的应用程序设计指南如下表：类别规范指南输入验证不要信任输入；应考虑集中式输入验证。不要依赖于客户端验证。注意标准化问题。限制、拒绝和净化输入。验证类型、长度、格式和范围。身份验证将站点分割为匿名区域、标识
9、区域和通过身份验证的区域。使用强密码。支持密码有效期和帐户禁用。不要存储凭据（应使用带有 salt 的单向哈希）。加密通信通道，以保护身份验证令牌。仅通过 HTTPS 连接传递表单身份验证 cookie。授权使用最少特权帐户。考虑授权粒度。实施分别授权。限制用户访问系统级资源。配置管理使用最少特权进程和服务帐户。不要以纯文本形式存储凭据。在管理界面上使用强身份验证和授权。不要使用 LSA。远程管理时要确保通信通道的安全。避免在 Web 空间中存储敏感数据。敏感数据避免存储机密。对网络上传输的敏感数据进行加密。确保通信通道的安全。对敏感数据存储提供强访问控制。不要在永久性 cookie 中存储敏
10、感数据。不要使用 HTTP-GET 协议传递敏感数据。会话管理限制会话寿命。确保通道的安全。对身份验证 cookie 的内容进行加密。保护会话状态，以防止未经授权的访问。加密不要自创加密算法。使用可靠并经过测试的平台功能。将未加密的数据存储在算法附近。使用正确的算法和密钥大小。避免密钥管理（使用 DPAPI）。定期回收密钥。在受限区域存储密钥。参数操作对敏感的 cookie 状态加密。不要信任客户端可以操作的字段（如查询字符串、表单字段、cookie 或 HTTP 头）。验证从客户端发送的所有数据。异常管理使用结构化的异常处理机制。不要泄漏敏感的应用程序实施细节。不要记录保密数据，如密码。考虑
11、使用集中式的异常管理框架。审核和记录识别怀有恶意的行为。了解好的数据流应该是什么样子。在所有应用层中审核和记录活动。确保日志文件访问的安全。定期备份和分析日志文件。4.2 Web安全编码规范4.2.1 区分公共区域和受限区域站点的公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。考虑一个典型的零售网站。您可以匿名浏览产品分类。当您向购物车中添加物品时，应用程序将使用会话标识符验证您的身份。最后，当您下订单时，即可执行安全的交易。这需要您进行登录，以便通过 SSL 验证交易。将站点分割为公共访问区域和受限访问区域，可以在该站点的不同区域使用不同的身
12、份验证和授权规则，从而限制对 SSL 的使用。使用 SSL 会导致性能下降，为了避免不必要的系统开销，在设计站点时，应该在要求验证访问的区域限制使用 SSL。4.2.2 对身份验证 cookie 的内容进行加密即使使用 SSL，也要对 cookie 内容进行加密。如果攻击者试图利用 XSS 攻击窃取 cookie，这种方法可以防止攻击者查看和修改该 cookie。在这种情况下，攻击者仍然可以使用 cookie 访问应用程序，但只有当 cookie 有效时，才能访问成功。4.2.3 限制会话寿命缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短，攻击者捕获会话 cookie 并利用它访问
13、应用程序的时间越有限。4.2.4 使用 SSL 保护会话身份验证 Cookie不要通过 HTTP 连接传递身份验证 cookie。在授权 cookie 内设置安全的 cookie 属性，以便指示浏览器只通过 HTTPS 连接向服务器传回 cookie。4.2.5 确保用户没有绕过检查确保用户没有通过操作参数而绕过检查。最终用户可以通过浏览器地址文本框操作 URL 参数。例如，URL 地址 http:/www./sessionId=10 包含一个值 10，通过将该值更改为其他随机数字，可以得到不同的输出。应确保在服务器端代码中执行上述检查，而不是在客户端的 JavaScript 中检查，因为可以
14、在浏览器中禁用 JavaScript。4.2.6 验证从客户端发送的所有数据限制可接受用户输入的字段，并对来自客户端的所有值进行修改和验证。如果表单字段中包含预定义值，用户可以更改这些值，并将其传回服务器，以得到不同的结果。只接受已知的有益数据。例如，如果输入字段面向一个州，那么只有与该州邮政编码匹配的输入才能被接受。4.2.7 不要向客户端泄漏信息发生故障时，不要暴露将会导致信息泄漏的消息。例如，不要暴露包括函数名以及调试内部版本时出问题的行数（该操作不应在生产服务器上进行）的堆栈跟踪详细信息。应向客户端返回一般性错误消息。4.2.8 记录详细的错误信息向错误日志发送详细的错误消息。应该向服
15、务或应用程序的客户发送最少量的信息，如一般性错误消息和自定义错误日志 ID，随后可以将这些信息映射到事件日志中的详细消息。确保没有记录密码或其他敏感数据。4.2.9 捕捉异常使用结构化异常处理机制，并捕捉异常现象。这样做可以避免将应用程序置于不协调的状态，这种状态可能会导致信息泄漏。它还有助于保护应用程序免受拒绝服务攻击。确定如何在应用程序内部广播异常现象，并着重考虑在应用程序的边界会发生什么事情。4.2.10 不要信任 HTTP 头信息HTTP 头在 HTTP 请求和响应开始时发送。应确保Web应用程序的任何安全决策都不是基于 HTTP 头中包含的信息，因为攻击者很容易操作 HTTP 头。例如，HTTP 头中的“referer”字段包含发出请求的网页的 URL。不要基
