WEB应用系统安全规档

WEB应用系统安全规范目录TOC\o"1-3"\h\z\uHYPERLINK\l"_Toc335854975"WEB应用系统安全规范PAGEREF_Toc335854975\h1HYPERLINK\l"_Toc335854976"1概述PAGEREF_Toc335854976\h4HYPERLINK\l"_Toc335854977"1.1目的PAGEREF_Toc335854977\h4HYPERLINK\l"_Toc335854978"1.2适用范围PAGEREF_Toc335854978\h4HYPERLINK\l"_Toc335854979"2范围PAGEREF_Toc335854979\h4HYPERLINK\l"_Toc335854980"3名词解释PAGEREF_Toc335854980\h4HYPERLINK\l"_Toc335854981"4Web开发安全规范PAGEREF_Toc335854981\h5HYPERLINK\l"_Toc335854982"4.1Web应用程序体系结构和安全PAGEREF_Toc335854982\h5HYPERLINK\l"_Toc335854983"4.2Web安全编码规范PAGEREF_Toc335854983\h7HYPERLINK\l"_Toc335854984"4.2.1区分公共区域和受限区域PAGEREF_Toc335854984\h7HYPERLINK\l"_Toc335854985"4.2.2对身份验证cookie的内容进行加密PAGEREF_Toc335854985\h7HYPERLINK\l"_Toc335854986"4.2.3限制会话寿命PAGEREF_Toc335854986\h7HYPERLINK\l"_Toc335854987"4.2.4使用SSL保护会话身份验证CookiePAGEREF_Toc335854987\h7HYPERLINK\l"_Toc335854988"4.2.5确保用户没有绕过检查PAGEREF_Toc335854988\h7HYPERLINK\l"_Toc335854989"4.2.6验证从客户端发送的所有数据PAGEREF_Toc335854989\h8HYPERLINK\l"_Toc335854990"4.2.7不要向客户端泄漏信息PAGEREF_Toc335854990\h8HYPERLINK\l"_Toc335854991"4.2.8记录详细的错误信息PAGEREF_Toc335854991\h8HYPERLINK\l"_Toc335854992"4.2.9捕捉异常PAGEREF_Toc335854992\h8HYPERLINK\l"_Toc335854993"4.2.10不要信任HTTP头信息PAGEREF_Toc335854993\h8HYPERLINK\l"_Toc335854994"4.2.11不要使用HTTP-GET 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 传递敏感数据PAGEREF_Toc335854994\h8HYPERLINK\l"_Toc335854995"4.2.12不要在永久性cookie中存储敏感数据PAGEREF_Toc335854995\h8HYPERLINK\l"_Toc335854996"4.2.13对数据进行加密或确保通信通道的安全PAGEREF_Toc335854996\h9HYPERLINK\l"_Toc335854997"4.2.14SQL语句的参数应以变量形式传入PAGEREF_Toc335854997\h9HYPERLINK\l"_Toc335854998"4.2.15页面中的非源代码内容应经过URI编码PAGEREF_Toc335854998\h9HYPERLINK\l"_Toc335854999"4.2.16页面中拼装的脚本应校验元素来源的合法性PAGEREF_Toc335854999\h9HYPERLINK\l"_Toc335855000"4.2.17页面请求处理应校验参数的最大长度PAGEREF_Toc335855000\h9HYPERLINK\l"_Toc335855001"4.2.18登录失败信息错误提示应一致PAGEREF_Toc335855001\h10HYPERLINK\l"_Toc335855002"4.2.19避免页面上传任意扩展名的文件PAGEREF_Toc335855002\h10HYPERLINK\l"_Toc335855003"4.2.20避免接受页面中的主机磁盘路径信息PAGEREF_Toc335855003\h10HYPERLINK\l"_Toc335855004"4.2.21第三方产品的合法性PAGEREF_Toc335855004\h10HYPERLINK\l"_Toc335855005"5系统部署安全规范PAGEREF_Toc335855005\h10HYPERLINK\l"_Toc335855006"5.1部署架构和安全PAGEREF_Toc335855006\h10HYPERLINK\l"_Toc335855007"5.1.1网络基础结构组件PAGEREF_Toc335855007\h11HYPERLINK\l"_Toc335855008"5.1.2部署拓扑结构PAGEREF_Toc335855008\h12HYPERLINK\l"_Toc335855009"5.2部署操作安全规范PAGEREF_Toc335855009\h12HYPERLINK\l"_Toc335855010"5.2.1确保管理界面的安全PAGEREF_Toc335855010\h12HYPERLINK\l"_Toc335855011"5.2.2确保配置存储的安全PAGEREF_Toc335855011\h12HYPERLINK\l"_Toc335855012"5.2.3单独分配管理特权PAGEREF_Toc335855012\h12HYPERLINK\l"_Toc335855013"5.2.4使用最少特权进程和服务帐户PAGEREF_Toc335855013\h12HYPERLINK\l"_Toc335855014"5.2.5尽量避免存储机密PAGEREF_Toc335855014\h13HYPERLINK\l"_Toc335855015"5.2.6不要在代码中存储机密PAGEREF_Toc335855015\h13HYPERLINK\l"_Toc335855016"5.2.7不要以纯文本形式存储数据库连接、密码或密钥PAGEREF_Toc335855016\h13HYPERLINK\l"_Toc335855017"5.2.8限制主机上WEB系统启动用户的权限PAGEREF_Toc335855017\h13HYPERLINK\l"_Toc335855018"5.2.9隐藏后台调试信息PAGEREF_Toc335855018\h13HYPERLINK\l"_Toc335855019"5.2.10密码加密存储PAGEREF_Toc335855019\h13HYPERLINK\l"_Toc335855020"5.2.11隐藏重要配置参数信息PAGEREF_Toc335855020\h14HYPERLINK\l"_Toc335855021"5.2.12隐藏日志文件PAGEREF_Toc335855021\h14HYPERLINK\l"_Toc335855022"5.2.13禁用WebDAV，或者禁止不需要的HTTP方法PAGEREF_Toc335855022\h14HYPERLINK\l"_Toc335855023"5.2.14保证管理平台、测试账号口令强度PAGEREF_Toc335855023\h14HYPERLINK\l"_Toc335855024"5.2.15定期核查文件上传路径、日志路径中是否存在木马PAGEREF_Toc335855024\h14HYPERLINK\l"_Toc335855025"5.2.16及时删除应用系统临时文件PAGEREF_Toc335855025\h14HYPERLINK\l"_Toc335855026"5.2.17重要系统隔离PAGEREF_Toc335855026\h14HYPERLINK\l"_Toc335855027"6安全审计PAGEREF_Toc335855027\h15HYPERLINK\l"_Toc335855028"6.1审核并记录跨应用层的访问PAGEREF_Toc335855028\h15HYPERLINK\l"_Toc335855029"6.2考虑标识流PAGEREF_Toc335855029\h15HYPERLINK\l"_Toc335855030"6.3记录关键事件PAGEREF_Toc335855030\h15HYPERLINK\l"_Toc335855031"6.4确保日志文件的安全PAGEREF_Toc335855031\h15HYPERLINK\l"_Toc335855032"6.5定期备份和分析日志文件PAGEREF_Toc335855032\h16HYPERLINK\l"_Toc335855033"7规范更新机制PAGEREF_Toc335855033\h16HYPERLINK\l"_Toc335855034"8规范的执行PAGEREF_Toc335855034\h16HYPERLINK\l"_Toc335855035"9参考资料PAGEREF_Toc335855035\h17概述目的为规范我司JavaWeb应用编码和部署的安全控制和管理，特制定本规范，并作为安全检查及考核的参考依据。适用范围本规范适用于我司所有在线Java业务系统、测试系统的WEB应用。本规范可作为其他非WEB应用的编码和部署安全办法参考。范围本规范中列出的是常见安全措施和高风险的漏洞，在系统开发与系统部署的过程中，对本规范未能尽述的必要安全措施，仍应予以采用。本规范每年复审一次，其它时候也可以根据需要进行修订并发布。本规范的解释权和修改权归属信息技术部。名词解释验证：通讯实体(例如，客户端和服务器)彼此验证，以经过访问授权的特定标识为依据。资源的访问控制：资源的交互仅限于某些用户或程序的集合，其目的是对完整性，保密性或可用性实施强制约束。数据完整性：检验信息是否被第三方(非信息源的其它实体)修改。例如，处于开放网络环境中的数据接收方必须能够检测并丢弃那些在传递过程中被修改过的消息。机密性或数据隐私：确保信息仅对经过访问授权的用户可用。不可否认：对用户进行检验，让他无法否认自己进行过的活动。审核：捕获一个安全相关事件的防篡改记录，目的是评估安全策略和机制的有效性。Web开发安全规范Web应用程序体系结构和安全HTTP是无国界的，这意味着跟踪每位用户的会话状态将成为应用程序的责任。应用程序必须能够通过某种形式的身份验证来识别用户。由于所有后续授权决策都要基于用户的标识，因此，身份验证过程必须是安全的，同样必须很好地保护用于跟踪已验证用户的会话处理机制。 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 安全的身份验证和会话管理机制仅仅是Web应用程序设计人员和开发人员所面临的众多问题中的两个方面。由于输入和输出数据要在公共网络上进行传输，因此还会存在其他挑战。防止参数操作和敏感数据泄漏也是另外一些重要问题。Web应用程序安全设计是根据应用程序漏洞类别进行组织的。实际经验表明，如果这些领域的设计存在薄弱环节，将会导致安全漏洞。下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。漏洞类别由于设计不当而引起的潜在问题输入验证嵌入到查询字符串、表单字段、cookie和HTTP头中的恶意字符串的攻击。这些攻击包括命令执行、跨站点脚本(XSS)、SQL注入和缓冲区溢出攻击。身份验证标识欺骗、密码破解、特权提升和未经授权的访问。授权访问保密数据或受限数据、篡改数据以及执行未经授权的操作。配置管理对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户帐户和帐户配置文件进行未经授权的访问。敏感数据泄露保密信息以及篡改数据。会话管理捕捉会话标识符，从而导致会话劫持及标识欺骗。加密访问保密数据或帐户凭据，或二者均能访问。参数操作路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。异常管理拒绝服务和敏感的系统级详细信息的泄漏。审核和记录不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。针对上述漏洞的应用程序设计指南如下表：类别规范指南输入验证不要信任输入；应考虑集中式输入验证。不要依赖于客户端验证。注意标准化问题。限制、拒绝和净化输入。验证类型、长度、格式和范围。身份验证将站点分割为匿名区域、标识区域和通过身份验证的区域。使用强密码。支持密码有效期和帐户禁用。不要存储凭据（应使用带有salt的单向哈希）。加密通信通道，以保护身份验证令牌。仅通过HTTPS连接传递表单身份验证cookie。授权使用最少特权帐户。考虑授权粒度。实施分别授权。限制用户访问系统级资源。配置管理使用最少特权进程和服务帐户。不要以纯文本形式存储凭据。在管理界面上使用强身份验证和授权。不要使用LSA。远程管理时要确保通信通道的安全。避免在Web空间中存储敏感数据。敏感数据避免存储机密。对网络上传输的敏感数据进行加密。确保通信通道的安全。对敏感数据存储提供强访问控制。不要在永久性cookie中存储敏感数据。不要使用HTTP-GET协议传递敏感数据。会话管理限制会话寿命。确保通道的安全。对身份验证cookie的内容进行加密。保护会话状态，以防止未经授权的访问。加密不要自创加密算法。使用可靠并经过测试的平台功能。将未加密的数据存储在算法附近。使用正确的算法和密钥大小。避免密钥管理（使用DPAPI）。定期回收密钥。在受限区域存储密钥。参数操作对敏感的cookie状态加密。不要信任客户端可以操作的字段（如查询字符串、表单字段、cookie或HTTP头）。验证从客户端发送的所有数据。异常管理使用结构化的异常处理机制。不要泄漏敏感的应用程序实施细节。不要记录保密数据，如密码。考虑使用集中式的异常管理框架。审核和记录识别怀有恶意的行为。了解好的数据流应该是什么样子。在所有应用层中审核和记录活动。确保日志文件访问的安全。定期备份和分析日志文件。Web安全编码规范区分公共区域和受限区域站点的公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。考虑一个典型的零售网站。您可以匿名浏览产品分类。当您向购物车中添加物品时，应用程序将使用会话标识符验证您的身份。最后，当您下订单时，即可执行安全的交易。这需要您进行登录，以便通过SSL验证交易。将站点分割为公共访问区域和受限访问区域，可以在该站点的不同区域使用不同的身份验证和授权规则，从而限制对SSL的使用。使用SSL会导致性能下降，为了避免不必要的系统开销，在设计站点时，应该在要求验证访问的区域限制使用SSL。对身份验证cookie的内容进行加密即使使用SSL，也要对cookie内容进行加密。如果攻击者试图利用XSS攻击窃取cookie，这种方法可以防止攻击者查看和修改该cookie。在这种情况下，攻击者仍然可以使用cookie访问应用程序，但只有当cookie有效时，才能访问成功。限制会话寿命缩短会话寿命可以降低会话劫持和重复攻击的风险。会话寿命越短，攻击者捕获会话cookie并利用它访问应用程序的时间越有限。使用SSL保护会话身份验证Cookie不要通过HTTP连接传递身份验证cookie。在授权cookie内设置安全的cookie属性，以便指示浏览器只通过HTTPS连接向服务器传回cookie。确保用户没有绕过检查确保用户没有通过操作参数而绕过检查。最终用户可以通过浏览器地址文本框操作URL参数。例如，URL地址http://www.//sessionId=10包含一个值10，通过将该值更改为其他随机数字，可以得到不同的输出。应确保在服务器端代码中执行上述检查，而不是在客户端的JavaScript中检查，因为可以在浏览器中禁用JavaScript。验证从客户端发送的所有数据限制可接受用户输入的字段，并对来自客户端的所有值进行修改和验证。如果表单字段中包含预定义值，用户可以更改这些值，并将其传回服务器，以得到不同的结果。只接受已知的有益数据。例如，如果输入字段面向一个州，那么只有与该州邮政编码匹配的输入才能被接受。不要向客户端泄漏信息发生故障时，不要暴露将会导致信息泄漏的消息。例如，不要暴露包括函数名以及调试内部版本时出问题的行数（该操作不应在生产服务器上进行）的堆栈跟踪详细信息。应向客户端返回一般性错误消息。记录详细的错误信息向错误日志发送详细的错误消息。应该向服务或应用程序的客户发送最少量的信息，如一般性错误消息和自定义错误日志ID，随后可以将这些信息映射到事件日志中的详细消息。确保没有记录密码或其他敏感数据。捕捉异常使用结构化异常处理机制，并捕捉异常现象。这样做可以避免将应用程序置于不协调的状态，这种状态可能会导致信息泄漏。它还有助于保护应用程序免受拒绝服务攻击。确定如何在应用程序内部广播异常现象，并着重考虑在应用程序的边界会发生什么事情。不要信任HTTP头信息HTTP头在HTTP请求和响应开始时发送。应确保Web应用程序的任何安全决策都不是基于HTTP头中包含的信息，因为攻击者很容易操作HTTP头。例如，HTTP头中的“referer”字段包含发出请求的网页的URL。不要基于“referer”字段值作出任何安全决策，以检查发出请求的页面是否由该Web应用程序生成，因为该字段很容易伪造。不要使用HTTP-GET协议传递敏感数据应避免使用HTTP-GET协议存储敏感数据，因为该协议使用查询字符串传递数据。使用查询字符串不能确保敏感数据的安全性，因为查询字符串经常被服务器记录下来。不要在永久性cookie中存储敏感数据避免在永久性cookie中存储敏感数据。如果存储的是纯文本数据，最终用户能够看到并修改该数据。如果对其加密，必须考虑密钥管理。例如，如果用于加密cookie中的数据的密钥已过期且已被回收，则新密钥不能对客户端通过浏览器传递的永久性cookie进行解密。对数据进行加密或确保通信通道的安全如果在网络上向客户端发送敏感数据，应对数据进行加密或确保通信通道的安全。通常的做法是在客户端与Web服务器之间使用SSL。服务器间的通信通常使用IPSec。要确保通过多重中间件传输的敏感数据的安全性，如Web服务简单对象访问协议(SOAP)消息，应使用消息级加密。SQL语句的参数应以变量形式传入（一）在对数据库进行查询与各类操作时，SQL语句中的参数应以变量形式传输给服务器，不应直接将参数的值拼接到SQL语句的文本中。（二）参数的类型包括所有数据类型，而不仅是字符串类型。（三）参数值的来源包括但不限于：用户输入的数据、从数据库中读出的数据、从配置文件中读出的数据、从外部系统中获得的数据、其它程序逻辑计算得出的数据，等等。（四）SQL语句的执行位置包括但不限于：代码中的SQL语句，数据库的存储过程、触发器、定时器等。（五）应用程序在处理用户非法URL请求，触发后台应用程序的SQL错误时，应返回处理后的错误页面提示，禁止直接抛出数据库SQL错误，如出现ORA-xxx等等。页面中的非源代码内容应经过URI编码（一）页面中的非源代码内容，应该以URI编码后的字符出现，避免特殊字符直接出现在页面中。（二）内容的来源包括但不限于：在服务器端由程序生成的页面内容、在浏览器端由脚本生成的页面内容（如：javascript中的document.write函数）。（三）页面中的隐藏内容、页面格式控制等，也应受本条约束。页面中拼装的脚本应校验元素来源的合法性（一）在浏览器端拼装并运行（如：利用javascript的eval函数执行）的脚本，应校验拼装元素的来源合法性，确定其中没有危害性的内容。（二）校验的范围包括但不限于：变量名元素应符合标识符的规则、整型元素只包含数字、元素中不包含特殊字符。页面请求处理应校验参数的最大长度（一）WEB服务器在接受页面请求时，应校验参数的最大长度，截断超出最大长度的范围。登录失败信息错误提示应一致（一）WEB服务器在接受用户登录请求时，不应区分登录失败的提示信息（如：用户名不存在、密码错误、密码已过期等），应采用统一的失败提示信息（如：错误的用户名或密码）。避免页面上传任意扩展名的文件（一）WEB服务器在接受页面上传文件时，应对文件名进行过滤，仅接受指定范围的文件（如：图片,.zip文件等），同时，要修改上传后的文件名，不应接受可能存在危险的文件（如：.jsp,.sh,.war,.jar文件等）。（二）如果出于业务的需要（如：网盘等）必须接受任意扩展名的文件，则应自动修改上传文件的扩展名，并注意采用统一的无风险的扩展名命名规则。避免接受页面中的主机磁盘路径信息（一）WEB服务器接受的页面请求中的任何内容，不得作为主机磁盘路径（包括相对路径）处理，尤其不得在程序中提取磁盘上的目录、文件的内容传送到页面。第三方产品的合法性（一）应选择合法的第三方产品，在使用第三方产品前，需要进行安全的评估和版本筛选。系统部署安全规范部署架构和安全下图显示了需在程序设计阶段考虑的几个程序部署问题。在应用程序设计阶段，应考虑我司安全策略和程序，以及部署应用程序的基础结构。通常，目标环境是固定不变的，应用程序的设计必须要反映这些限制条件。有时需要折衷考虑设计 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ，例如，由于存在协议和端口限制，或是特定部署拓扑结构的要求。要在设计初期确定存在哪些限制条件，以避免日后在开发过程中出现意外；另外，应邀请网络和基础结构工作组的成员参与此过程。网络基础结构组件确保您了解目标环境提供的网络结构，并了解网络的基本安全要求，如筛选规则、端口限制、支持的协议等等。确定防火墙和防火墙策略可能会如何影响应用程序的设计和部署。在面向Internet的应用程序和内部网络之间可能存在防火墙将其隔开。也许还存在用于保护数据库的其他防火墙。这些防火墙影响了可用的通信端口，因此会影响Web服务器到远程应用程序和数据库服务器的身份验证选项。例如，Windows身份验证需要附加端口。在设计阶段，需要考虑允许哪些协议、端口和服务从外围网络中的Web服务器访问内部资源。还应确定应用程序设计所需的协议和端口，并分析打开新端口或使用新协议会带来哪些潜在威胁。交流并记录所有有关网络和应用层安全的设想，以及哪些组件将处理哪些问题。这样，当开发人员和网络管理人员都认为对方会解决安全问题时，可以防止安全控制失败。注意网络为应用程序提供的安全防范措施。设想如果更改网络设置，可能会带来哪些安全隐患。如果实现特定的网络结构更改，将会出现多少安全漏洞？部署拓扑结构应用程序的部署拓扑结构和是否具有远程应用层是设计阶段必须考虑的关键问题。如果具有远程应用层，需要考虑怎样保护服务器之间的网络以减少网络窃听威胁，以及怎样保护敏感数据的保密性和完整性。此外，还要考虑标识符流，并确定在应用程序连接到远程服务器时将用于网络身份验证的帐户。一种常见方法是使用最小特权进程帐户，并在远程服务器上创建一个具有相同密码的帐户副本（镜像）。另一种方法是使用域进程帐户，此类帐户管理方便，但会带来更大的安全问题，因为很难限制该帐户在网络上的使用。未建立信任关系的介入防火墙和单独域使应用本地帐户成为唯一的选择。部署操作安全规范确保管理界面的安全配置管理功能只能由经过授权的操作员和管理员访问，这一点是非常重要的。关键一点是要在管理界面上实施强身份验证，如使用证书。如果有可能，限制或避免使用远程管理，并要求管理员在本地登录。如果需要支持远程管理，应使用加密通道，如SSL或VPN技术，因为通过管理界面传递的数据是敏感数据。此外，还要考虑使用IPSec策略限制对内部网络计算机的远程管理，以进一步降低风险。确保配置存储的安全基于文本的配置文件、注册表和数据库是存储应用程序配置数据的常用方法。如有可能，应避免在应用程序的Web空间使用配置文件，以防止可能出现的服务器配置漏洞导致配置文件被下载。无论使用哪种方法，都应确保配置存储访问的安全，如使用WindowsACL或数据库权限。还应避免以纯文本形式存储机密，如数据库连接字符串或帐户凭据。通过加密确保这些项目的安全，然后限制对包含加密数据的注册表项、文件或表的访问权限。单独分配管理特权如果应用程序的配置管理功能所支持的功能性基于管理员角色而变化，则应考虑使用基于角色的授权策略分别为每个角色授权。例如，负责更新站点静态内容的人员不必具有更改客户信贷限额的权限。使用最少特权进程和服务帐户应用程序配置的一个重要方面是用于运行Web服务器进程的进程帐户，以及用于访问下游资源和系统的服务帐户。应确保为这些帐户设置最少特权。如果攻击者设法控制一个进程，则该进程标识对文件系统和其他系统资源应该具有极有限的访问权限，以减少可能造成的危害。尽量避免存储机密在软件中以完全安全的方式存储机密是不可能的。可以接触到服务器的系统管理员可以访问这些数据。例如，当您所要做的仅仅是验证用户是否知道某个机密时，则没有必要存储该机密。在这种情况下，可以存储代表机密的哈希值，然后使用用户提供的值计算哈希值，以验证该用户是否知道该机密。不要在代码中存储机密不要在代码中对机密进行硬编码。即使不将源代码暴露在Web服务器上，但从编译过的可执行文件中仍然可以提取字符串常量。配置漏洞可能会允许攻击者检索可执行文件。不要以纯文本形式存储数据库连接、密码或密钥避免以纯文本形式存储诸如数据库连接字符串、密码和密钥之类的机密。使用加密，并存储经过加密的字符串。限制主机上WEB系统启动用户的权限（一）应将WEB系统的启动用户的权限限制在最小范围内，禁止该用户访问其它不必要的路径（如：/etc/、/root）。隐藏后台调试信息（一）WEB系统、数据库等 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 的异常信息、调试信息不应该出现在页面上。密码加密存储（一）WEB系统中存储的密码应采用一定的加密算法，以密文形式存放。此处所指的密码包括但不限于：1．配置文件中的主机、网络、数据库、邮箱的密码；2．数据库中的用户资料密码；（二）加密算法的选择应根据实际需要，首选不对称加密算法，次选破解难度高的对称加密算法。隐藏重要配置参数信息（一）对于重要的配置参数信息，应采用必要的隐藏措施，具体技术请遵循《我司敏感参数保护规范》（二）此处所指的配置参数包括但不限于：1.重要的用户名、密码；2.重要设备的内网地址（如：数据库、存储设备）；隐藏日志文件（一）不应将日志文件的路径设置在页面可达的位置，用户通过页面应该无法访问到系统产生的日志文件。禁用WebDAV，或者禁止不需要的HTTP方法（一）在无特定的需求情况下，应只开放GET,HEAD,POST等安全的HTTP方法，禁用PUT,DELETE,OPTIONS等具有操作性质的HTTP方法。保证管理平台、测试账号口令强度（一）WEB系统的管理平台、测试账号的口令应具有足够的强度。具体要求请遵循《我司公司系统帐号口令管理办法》。定期核查文件上传路径、日志路径中是否存在木马（一）应定期对不可能出现代码的路径进行检查，及时发现与排除可能存在的木马。（二）需要检查的路径包括但不限于：用户文件上传路径、日志文件路径。及时删除应用系统临时文件（一）WEB系统中不应该含有不必要的文件。包括但不限于：.CVS文件夹、.svn文件夹、临时备份文件等等。（二）对于WEB页面备份文件，不要以.bak文件存放（如index.jsp.bak等）重要系统隔离（一）在部署WEB系统时，应根据实际情况，尽量使重要系统之间互相隔离、重要系统与其它系统之间隔离。（二）隔离措施包括但不限于：主机分离、数据库分离、网段隔离。安全审计应该审核和记录跨应用层的活动。使用日志，可以检测到踪迹可疑的活动。这通常能较早地发现成熟攻击的迹象，日志还有助于解决抵赖问题，即用户拒绝承认其行为的问题。在证明个人错误行为的法律程序中，可能需要使用日志文件作为证据。通常情况下，如果审核的生成时间恰好是资源访问的时间，并且使用相同的资源访问例程，则审核是最具权威性的。以下做法可以提高Web应用程序的安全性：审核并记录跨应用层的访问考虑标识流记录关键事件确保日志文件的安全定期备份和分析日志文件审核并记录跨应用层的访问审核并记录跨应用层的访问，以便用于认可。可以结合使用应用程序级记录和平台审核功能，如操作系统、Web服务器和数据库审核。考虑标识流考虑应用程序如何在多重应用层间传送调用方标识。有两个基本选择。可以使用Kerberos协议委派，在操作系统级传送调用方标识。这允许您使用操作系统级审核。这种方法的缺点在于它影响了可伸缩性，因为它意味着在中间层可能没有有效的数据库连接池。另外，还可以在应用程序级传送调用方标识，并使用受信任标识访问后端资源。使用此方法时，必须信任中间层，因此存在着潜在的抵赖风险。应在中间层生成审核跟踪，使之能与后端审核跟踪相关联。因此，必须确保服务器时钟是同步的，虽然MicrosoftWindows2000和ActiveDirectory提供了此项功能。记录关键事件应记录的事件类型包括成功和失败的登录尝试、数据修改、数据检索、网络通信和管理功能，如启用或禁用日志记录。日志应包括事件发生的时间、地点（包括主机名）、当前用户的标识、启动该事件的进程标识以及对该事件的详细描述。确保日志文件的安全应使用操作系统访问控制（ACL）确保日志文件的安全，并限制对日志文件的访问。这加大了攻击者篡改日志文件以掩饰其攻击行为的难度。应将有权操作日志文件的个人数量减到最小。只为高度信任的帐户（如管理员）授予访问权限。定期备份和分析日志文件如果从不对日志文件进行分析，则记录活动没有任何意义。应定期删除生产服务器上的日志文件。删除频率取决于应用程序的活动级别。设计程序时，应考虑检索日志文件和将其移到脱机服务器进行分析的方式。必须安全地锁定Web服务器上为此目的打开的所有其他协议和端口。规范更新机制操作步骤具体任务准备回顾材料组织会议更新规范发布规范规范的执行本规范的执行遵从现有的项目管理办法，在项目管理办法中补充如下表中内容：阶段步骤任务与本规范相关的内容规划阶段需求分析规划说明审批阶段招投标实施阶段系统设计系统开发 总结 初级经济法重点总结下载党员个人总结TXt高中句型全总结.doc高中句型全总结.doc理论力学知识点总结pdf 阶段项目总结参考资料