POL-Web应用程序安全标准

（XX组织）Web应用程序安全标准文档编号Org-Pol-xxx保密级别内部分发范围（XX组织）全范围修订历史生效日期版本号版本说明制作复审批准2007-12-01V1.0新建文员PMDM本文内容涉及（XXS织）商业秘密，受到有关知识产权法保护。任何个人、组织未经（XX组织）的书面授权许可，不得以任何方式披露、复制或引用本文件完整内容或任何片断。1.0目的建立Web应用程序的安全标准，提高Web应用程序的安全性。2.0范围适用于公司所有Web程序，包括自行开发、外包开发和购买的商业软件3.0职责.系统开发部：按照本标准开发Web应用程序。.信息安全部：按照本标准评审Web应用程序。4.0内容1.输入验证1）假定所有输入都是恶意的。开始输入验证时，首先假定所有输入都是恶意的，除非有证据表明它们并无恶意。无论输入是来自服务、共享文件、用户还是数据库，只要其来源不在可信任的范围之内，就应对输入进行验证。2）对输入验证采取集中式验证方法，例如，通过使用共享库中的公用验证和筛选代码。这可确保验证规则应用的一致性。止匕外，还能减少开发的工作量，且有助于以后的维护工作。3）不要依赖客户端做验证，应使用服务器端代码执行其自身的验证。4）对输入的数据进行标准化处理。标准化是指将数据转化为标准形式的过程。5）对输入的数据进行限制、拒绝和净化处理。限制是指定义一个筛选器，根据类型、长度、格式和范围来筛选输入的数据。拒绝是指拒绝已知的有害输入。净化是为了使有潜在危害的数据变得安全。如果所允许的输入范围不能保证输入数据的安全性，那么净化输入是非常有用的。净化包括从删除用户输入字符用后面的空格到去除值（以便按照文字格式处理该数据）等一切行为。2.身份验证1）区分公共区域和受限区域。公共区域允许任何用户进行匿名访问。受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。2）对用户帐户采用帐户锁定策略，可以禁用该帐户或将事件写入日志。3）支持密码有效期。4）能够禁用帐户。5）不要明文存储密码。6）要求使用强密码，并支持强密码的检查。7）不要在网络上以纯文本形式发送密码。8）保护身份验证cookie。身份验证cookie被窃取意味着登录被窃取。要求通过加密或安全的通信通道来保护验证cookieo另外，还应限制验证Cookie的有效期，以防止因重复攻击导致的欺骗威胁。9）身份验证要提供验证码保护机制。对于重要的业务功能，比如系统维护或电子商务功能，还要支持强身份认证，包括数字证书、动态令牌卡等。3.授权管理1）采用多重授权控制。利用网络、操作系统、WEEff台、Web应用等多重访问管理进行授权控制。2）限制用户对系统级资源的访问。3）考虑授权粒度。4.配置管理1）确保管理界面的安全。配置管理功能只能由经过授权的操作员和管理员访问，并在管理界面上实施强身份验证。如果有可能，限制或避免使用远程管理，并要求管理员在本地登录。如果需要支持远程管理，应使用加密通道，如SSL或VPN技术。2）确保配置数据的安全。基于文本的配置文件、注册表和数据库是存储应用程序配置数据的常用方法。如有可能，应避免在应用程序的Web空间使用配置文件，以防止可能出现的服务器配置漏洞导致配置文件被下载。无论使用哪种方法，都应确保配置数据访问的安全。还应避免以纯文本形式存储机密，如数据库连接字符串或帐户密码。通过加密确保这些机密数据的安全，然后限制对包含加密数据的注册表项、文件或表的访问权限。3）支持管理特权的分别授权，例如，负责更新站点静态内容的人员不必具有更改客户信息的权限。4）使用最少特权进程和服务帐户。应用程序配置的一个重要方面是用于运行Wet®务器进程的进程帐户，以及用于访问下游资源和系统的服务帐户。应确保为这些帐户设置最少特权，例如，不使用SA帐户连接数据库。5.敏感数据1）不要在代码和系统中存储机密。2）不要以纯文本形式存储数据库连接、密码或密钥。3）避免在微软LSA中存储机密。避免使用LSA,因为只有具有管理特权白应用程序才有能访问LSA而这一点违反了以最少特权运行的安全原则。4）使用数据保护API（DPAPI）对机密数据进行加密。5）根据需要检索敏感数据，而不是将其保留或高速缓存在内存中。6）如果在网络上向客户端发送敏感数据，应对数据进行加密或确保通信通道的安全。7）不要在永久性cookie中存储敏感数据。8）不要使用HTTP-GET协议传递敏感数据。6.会话管理1）使用SSL保护会话身份验证cookie。2）对身份验证cookie的内容进行加密。3）限制会话寿命。4）避免未经授权访问会话状态。7,加密管理1）不要自创加密方法，应使用应用平台提供的经过验证和测试的加密服务。2）向加密算法传递纯文本时，除非需要使用，否则不要获取该数据。3）使用正确的算法和密钥大小。数据加密标准（DES）64位密钥（8个字节）TripleDES128位密钥或192位密钥（16或24个字节）Rijndael128-256位密钥（16-32个字节）RSA384-16,384位密钥（48-2,048个字节）对于大量数据加密，应使用TripleDES对称加密算法。要减慢并加强对大量数据的加密，应使用Rijndael算法。要对将暂时存储的数据加密，可以考虑使用较快但较弱的算法，如DES。对于数字签名，应使用RSA或DSA算法。对于哈希，应使用SHA1.0算法。对于用户键入的哈希，应使用基于哈希的消息验证代码（HMACSHA1.0算法。4）确保加密密钥的安全。.参数操作利用参数操作攻击，攻击者能够修改在客户端与Web应用程序间发送的数据。此数据可能是使用查询字符用、表单字段、cookie或HTTP头发送的。以下做法有助于确保Web应用程序参数操作的安全：1）加密cookie中的敏感信息。Cookie中可能包含敏感数据，如会话标识符或用作服务器端授权进程一部分的数据。要保护该类型数据，应使用加密方法对cookie的内容加密。2）确保用户没有绕过检查。确保用户没有通过操作参数而绕过检查，避免最终用户通过浏览器地址框操作URL参数。例如，URL地址http://www.<YourSite>/<YourApp>/sessionId=6包含一个值6,通过将该值更改为其他随机数字，可以得到不同的输出。应确保在服务器端代码中执行上述检查，而不是在客户端的JavaScript中检查，因为可以在浏览器中禁用JavaScript。3）验证从客户端发送的所有数据。限制可接受用户输入的字段，并对来自客户端的所有数据进行验证。4）不要信任HTTP头信息。应确保Web应用程序的任何安全决策都不是基于HTTP头中包含的信息，因为攻击者很容易操作HTTP头。.异常管理1）不要向客户端泄漏信息发生故障时，不要暴露会导致信息泄漏的消息。例如，不要暴露包括函数名以及调试内部版本时出问题的行数（该操作不应在生产服务器上进行）的堆栈跟踪详细信息。应向客户端返回一般性错误消息。2）记录详细的错误信息在事件日志中记录详细的错误消息，但向服务或应用程序的客户发送的信息应当尽量少，如一般性错误消息和自定义错误的代号，这些信息可以映射到事件日志中的详细消息。另外，要确保错误信息中没有记录密码或其他敏感数据。3）捕捉异常应当采用统一的异常处理机制捕捉异常现象。.审核和记录1）审核并记录