OWASP-安全编码规范参考指南

一个与技术无关的通用软件安全编码规范。它提供了一种综合的清单模式,可以融合到应用程序开发周期之中。2012年8月序言本项与技术无关的文档以清单列表的形式,定义了一套可以集成到软件开发生命周期中的道用软件安全编码规范。釆用这些规范将减少最为常见的软件灀泂一般来说,开发安全的软件要比在软件包完成以后纠正安全问题的成本低很多,且还没涉及到因为安全问题而造成的损失。保护关键软件资源的安全性,比以往任何时候都更为重要,因为攻击者的重点已逐步转向了应用层。2009年SANS的一项研究1表明,针对web应用稈序的攻击已占据了在互联网上观察到攻击总数的60%以上。在使月本指南时,开发团队应该从评估他们的安全软件开发生命周期成熟度和开发人员知识水平着手。由于本指南不涉及如何实现每个编码规范的具体细节,因此,开发人员需要了解相关知识,或者有足够可用资源来提供必要的指导。通过本指南,开发人员可在无需深入了解安全漏洞和攻击的情况下,将编规范转换成编码要求,当然,开发团队的其他成员应该有责任,通过提供适当的培训、工具和资源,以验证整个系统的设计和开发是安全的。本文档中使用的重要术语,包括部分标题和文字,都以斜体字标注,并列举在附录B的术语列表中关于安全软件开发框架的指南不属于本文讨论的范闱。但是,我们推荐以下额外的常用规范和资源·明确定义角色和职责为开发团队提供足够的软件安全培训采用一个安全软件开发生命周期OWASP CLASP项目建立安全编码标准。O OWASP开发指南项目建立一个可重用的对象库文件OWASP Enterprise Security API(ESAPD)项且·验证安仝控制的有效性。o OWASP Application Security Verification Standard(ASVS)JE建立外包开发安仝规范,包括在建议书(RF)和合同中定义安全需求和验证方法。OWASP Legal项且中文版ⅴ ersion1.02012年8月软件安全与风险原则概览开发安全的软件需要对妄全原则有基本的了解。虽然对于安全原则的全面评估超出了本指南的范围,但是我们还是提供了一个快速的概览软件安全的目标是要维护信息资源的保密,完整性,和可用丝,以确保业务的成功运作。该目标通过实施安全矬籝来实现。本指南重点介绍具体的技术控制,以解常见软件漏的发生。虽然主要的关注点是Wcb应用程序及其配套的基础设施,但是本指南的大部分内容可应用于任意软件部署平台为了保护业务免受来自与软件相关的不能接受的风险,了解风险的意义是很有帮助的。风险是一组威胁业务成功因素的集合。它可以被定义为:一个威胁代理与一个可能含有源海的统交互,该漏泂可被利并造成影婉。虽然这可能看起来象是一个抽象的概念,但可以这样想象它:一个汽车盗窃犯(威胁代理)来到一个停车场(系统)寻找没有锁车门(漏洞)的车,当找到一个时,他们打开门(利用)并拿走里面任何的东西(影响)。所有这些因素在安全软件开发时都扮演了一个角色开发团队采用的方法和攻击者攻击应用程序所采用的方法之间有一个根本区别。开发团队通常采用的方法是基于应用程序的目的行为。换句话说,开发团队根据功能需求文档和用例设计一个应用程序以行特定的任务。而另一方面,攻击者,基于“没有具体说明应拒绝的行为,则被认为是可行的”原则,对于应用程序可以做什么更感兴趣、为了解决这个问题,一些额外的元素需要被集成到软件生命周期的早期阶段。这些新元素是安全,求和瀲〃实例。本指南旨在帮助明确高等级的安全需求,并解决许多常见的滥用情况。Wcb开发团队应当明白,基于客户端的输入验证、隐癒字段和界面控件(例如,下拉键和单选按钮)的客户端控制,所带来的安全性收益是有限的,这一点非常重要。攻击者可以使用工具,比如:客户端的Web代理(例如, oWASP Web scarab,Bup)或网络数据包捕获工具(例如,Wireshark),进行应用程序流量分析,提交定制的请求,并绕过所有的接口。另外, Flash,JavaApplet和其它客户端对象可以被反编译并进行漏润分析。软件的安全漏洞可以在软什开发生命周期的任何阶段被引入,包括最初没有明确的安全需求;创建有逻辑错误的概念设计使用糟糕的编码规范,从而带来了技术漏洞软件部署不当;在维护或者更新过程中引入缺陷。此外,还有重要的一点需要明白,软件漏洞可以超岀软件本专的范围。根据不同的软件、漏河和配套基础设施的性质,一次成功的攻击会影响下面任何或者所有的方面:·软件和其相关的信息;相关服务器的撰作系统后端数据库;在共享环境中的其它应用程序;用户的系统;与用户交互的其它软件中文版ⅴ ersion1.02012年8月安全编码规范硷查列表输入验证:在可信系统(比如:服务器)上执行所有的数据验证识别所有的数据源,并将其分为叫信的和不可信的。验让所有来自不可信数据源(比如:数据库,文件流,等)的数据。应当为应月程序应提供一个集中的输入验证规则。为所有输入明确恰当的字符集,比如:UTF-8。在输入验证前,将薮据按照常用字符进行编码(范化)。丢弃任何没有通过输入验证的数据。确定系统是否支UTF-8扩展字符集,如果支持,在UTF8解码完成以后进行输入验证。在处理以前,验证所有来自客户端的数据,包括:所有参数、URL、HTTP头信息(比如cookie名字和数据值)。确定包括了来自 Javascript、Fash或其他嵌入代码的 post back信息。验证在请求和响应的报头信息中只含有ASC字符核实来自重定可输入的数据(一个攻击者可能向重定向的日标直接提交恶意代码,从而避开应用程序逻辑以及在重定向前执行的任何验证)。验证正确的数据类型验证数据范围。验证数据长度。尽可能采用“白名单”形式,验证所有的输入如果任何潜在的意险字箮必须被作为输入,请确保您执行了额外的控制,比如:输出编码、特定的安全API、以及在应用程序中使用的原因。部分常见的危险字符包括:<>"%0&+1V"。如果您使用的标准骑证规则无法验证下面的输入,那么它们需要被单独验证:o验证空字节(%0)o验证换行符(%0d,%0a,lr,Ⅶn);o验证路径替代字符“点-点-斜杠”(./或∴)。如果支持UTF8扩展字符集编码,验证替代字符:%c0%e%e0%ie/(使用验正双编码或其他类型的编码攻击)。输出编码:在可信系统(比如:服务器)上执行所有的编码。为每一种输出编码方法采用一个标准的、已道过测试的规则。通过语义输出编码方式,对所有返回到客户端的来自于应用程序信仁边界之外的数据进行编码。HTML实体编码是一个例子,但不是在所有的情况下都可用。除非对目标编泽器是安全的,否则请对所有字符进行编码。针对SO、ⅩML和LDAP査询,语义净化所有不可信数据的输出。对于操作系统命令,净化所有不可信数据输出中文版ⅴ ersion1.02012年8月身份验证和密码管理:狳了那些特定设为“公开”的内容以外,对所有的网页和资源要求身份验证所冇的身份验证过程必须在可信系统(比如:服务器)上执行。在任何可能的情况下,建立并使用标准的、已通过测试的身份验证服务。为所有身份验证制使用一个集中实现的方法,其中包括利用库文件请求外部身份验证服务将身份验证逻辑从被请求的资源中隔离开,并使用重定向到或来自集中的身份验证控制。所有的身份验证空制应当安全的处理未成功的身份验证所有的管理和账户營理功能至少应当具有和主要身份验证机制一样的安全性。如果您的应用程序箮理着凭证的存储,那么应当保证只保存了通过使用强加密单向 salted哈希算法得到的密码,并且只有应用程序具有对保存密码和密钥的表/文件的写权限(如果可以避免的话,不要使用MD5算法)。密码哈希必须在可信系统(比如:服冬器)上执行。只有当所有的数裾输入以后,才进行身份验证数据的验证,特别是对连续身份验证机制。身份验证的失败提示信息应当邂免过于明确。比如:可以使用“用户名和/或密码错误”,而不要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致。为涉及敏感信息或功能的外部系统连接使用身份验证用于访问应用程序以外服务的身份验证凭据信息应当加密,并存储在一个可信系统(比如:服务器)中受到保护的地方。源代码不是一个安仝的地方。只使用 Http Post请求传输身份验证的凭据信息。非临时密码只在加密连接中发送或作为加密的数据(比如,一封加密的邮件)。通过邮件重设临时密码可以是一个例外。通过政策或规则加强密码复杂度的要求(比如:要求使用字母、数字和{或特殊符号)。身份验证的凭据信息应当足够复杂以对抗在其所部署环境中的各和威胁攻击。通过政策和规则加强密码长度要求。常用的是8个字符长度,但是16个字符长度更好,或者考虑使用多单词密码短语。输入的密码应当在用户的屏幕上模糊显示(比如:在Web表单中使用 password'输入类型当连续多次登录失败后(比如:通常情况下是5次),应强制锁定账户。账户锁定的时间必须足够长,以狙止暴力攻击猜测登录信息,但是不能长到允许执行一次拒绝服务攻击密码重设和更改操作需要类似于账户側建和身份验证的同样控制等级。密码重设问题应当支持尽可能随机的提问(比如:“最喜愛的书”是一个坏的问题,因为《圣经》是最常见的答案)。如果使用基于邮件的重设,只将临时链接或密码发送到预先注册的邮件地址。临时密码和链接应当有一个短暂的有效期。当再次使用临时密码时,强制修改临时密码。当密码重新设置时,通知用户阻止密码重复使用。密码在被更改前应当至少使用了一天,以阼止密码重用攻击。根据政策或规则的要求,强制定期更改密码。关键系统可能会要求更频繁的更改。更改时间周期必须进行明确为密码填写框禁用“记住密码”功能。中文版ⅴ ersion1.02012年8月用户账号的上一次使用信息(成功或失败)应当在下一次成功登录时向用户报告。执行监控以确定针对使用相同密码的多用户帐户攻击。当用户D可以被得到或被猜到时,该攻击模式用来绕开标准的锁死功能更改所有!商湜供的默认用户⑩和密码,或者禁用相关帐号在执行关键操作以前,对用户再次进行身份验证。为高度敏感或重要的交易账户使用多因子身价验证机制。如果使用了第三方身份验证的代码,仔细检查代码以保证其不会受到任何恶意代码的影响会话管理使用服务器或者框架的会话管理控制。应用程序应当只识别有效的会话标识符。会话标识符必须总是在一个可信系统(比如:服务器)上创建。会话管理控制应当使用通过审查的算法以保让足够的随机会话标识符。为包含已验证的会话标识符的 cookie设置域和路径,以为站点设置一个恰当的限制值。注销功能应当完全终止相关的会话或连接注销功能应当可用于所有受身份验证保护的网页。在平復的风险和业务功能需求的基础上,改置一个尽量短的会话超时时间。通常情况下,应当不超过儿个小时。禁止连续的登录并强訇执行局期性的会话终止,即使是活动的会话。特别是对于支持富网络连接或连接到关键系统的应用程序。终止吋机应当可以根据业务需求调整:并且用广应当收到足够的通知已减少带来的负面影响如果一个会话在登录以前就建立,在成功登录以后,关闭该会话并创建一个新的会话。在任何重新身分验证过程中建立一个新的会话标识符。不允许同一用户ID的并发登录。不要在URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在 Http cook头信息中。比如,不要将会话标识符以GT参数进行传递。通过在服务器上使用恰当的访问控制,保护服务器端会话数据免受来自服务器其他用户的未授权访问。生成一个新的会话标识符并周期性地使旧会话标识符失效(这可以绥解那些原标识符被获得的特定公话劫持情况)。在身份验证的时候,如果连接从HYTP变为 Https,则生成一个新的会话标识符。在应用程序中,推荐持续使用HTPS,而非在HTP和 Https之间转换。为服务器端的操作执行标准的会话管理,比如,通过在每个会话中使用强随机令牌或参数来管理账户。该方法可以用来防止跨站点请求伪造攻击。通过在每个请求或每个会话中使用强随机令牌或参数,为高度敏感或关键的操作提供标准的会话管理。为在TIS连接上传输的 cookie设置“安全属性将 cookie设置为 Httponly属性,除非在应用程序中明确要求了客户端脚木程序读取或者设置ckie的值。访问控制:只使用可信系统对象(比如:服务器端会话对象)以做出访问授权的决定。使用一个单独的全站点部件以检查访问授权。这包括调用外部授权服务的库文件。妄全的处理访间控制失败的操作。中文版ⅴ ersion1.02012年8月如果应用程序无法访问其安全配置信息,则拒绝所有的访问。在每个请求中加强授权掉制,包括:服务器端脚本产生的请求,“ includes”和来自象AJAX和FLASH那样的富客户端技术的请求将有特权的逻辑从其他应用程序代码中隔离廾。狠制只有授权的用户才能访问文件或其他资源,包括那些应用程序外部的直接控制。狠制只有授权的用户才能访问受保护的URL。張制只有授权的用户才能访问受保护的功能狠制只有授权的用户才能访问直接对象引用。狠制只有授权的用户才能访问服务。張制只有授权的用户才能访问应用程序数据。狠制通过使用访问控制来访问用户、数据属性和策略信息。狠制只有授权的用户才能访问与安全相关的配置信息。服务器端执行的访问控制规则和表小层实施的访问控制规则必须匹配。如果状态数据必须存储在客户端,使用加密算法,并在服务器端检査完整性以捕获状态的改变强制应用程序逻辑流程遵照业务规则。狠制单一用户或设备在一段时间内可以执行的事务数量。事务数量时间应当高于实际的业务需求,但也应该足修低以判定自动化攻击。仅使用 referer”头作为补偿性质的检查,它永远不能被单独用来进行身份验证检香,因为它可以被伪造。如果长的身份验证会话被允许,周期性的重新验证用户的身份,以确保他们的权限没有改变。如果发生改变,注销该用户,并强制他们重新执行身份验证执行帐户审计并将没有使用的帐号强制失效〔比如:在用户密码过期后的30天以内)。应用程序必须支持帐户失效,并在帐户停止使用时终止会话(比如:角色、职务状况、业务处理的改变,等等)。服务帐户,或连接到或来自外部系统的帐号,应当只有尽可能小的权限。建立一个“访间控制政策ν以明确一个应用程序的业务规则、薮据类型和身份验证的标准或处理流程,确保访问可以被恰当的提供和控制。这包括了为数据和系统资源确定访问需求。加密规范所有用于保护来自应用程序用户秘密信息的加密功能都必须在一个可信系统(比如:服务器)上执行。保护主要秘密信息免受未授权的访问。安全的处理加密模块失败的操作。为防范对随机数据的猜测攻击,应当使用加密模块中已验证的随札数生成器生成所冇的随机数、随机文件名、随机GUI和随机字符串。应用程序使用的加密模块应当遵从HPS1402或其他等同的标准(请见http://csrc.nist.gov/groups/stm/cmvp/'validation.htmL)建立并使用相关的政策和流程以实现加、解密的密钥管理。错误处理和日志不要在错误响应中泄露敏感信息,包括:系统的详细信息、会话标认符或者帐号信息。中文版 Version1.082012年8月使用错误处型以避免显示调试或堆栈跟踪信息使用通用的错误消息并使用定制的错误贞面。应用程序应当处理应用程序错误,并不依赖服务器配置当错误条件发生时,适当的清空分配的内存。在默认情况下,应当拒绝访间与安全控制相关联的错误处理逻辑。所有的日志记录控制应当在可信系统(比如:服务器)上执行。日志记录控制应当支持记录特定安全事件的成功或者失败操作。确保日志记录包含了重要的旦志事件数据。确保日志记录中包含的不可信数据,不会在查看界面或者软件时以代码的形式被执行。限制只有授权的个人才能访问日志为所有的日志记录采用一个主要的常规操作。不要在日志中保存敏感信息,包括:不必要的系统谇细信息、会话标识符或密码。确保一个执行日志査询分析机制的存在。记录所有失败的输入验证。记录所有的身份验证尝试,特别是失败的验证。记录所有失败的訪问控制。记录明显的修改事件,包括对于状态数据非期待的修改。记录连接无效或者已过期的会话令牌尝试。记录所有的系统例外。记录所有的管理功能行为,包括对于全配置设置的更改。记录所有失败的后端TLS链接。记录加密模块的错误。使用加密哈希功能以验证日志记录的完整性。数据保护:授子最低权限,以限制用户只能访问为完成任务所需要的功能、数据和系统信息。保护所有冇放在服务器上緩冇的或临时拷贝的敏感数据,以避免非授权的访问,并在临时工作文件不再需要时被尽快清除。即使在服务器端,任然要加密存储的高度机密信息,比如,身伏验让的捡证数据。总是使用已经被很好验证过的算法,更多指导信息请参见“加密规范”部分。保护服务器端的源代码不被用户下载。不要在客户端上以明文形式或其他丰加密安仝模式保存密码、连接字符串或其他敏感信息这包括嵌入在不妄全的形式中: MS viewstate、 Adobe flash或者已编译的代码删除用户可访问产品中的注释,以防止泄鼴后台系统或者其他敏感信息。删除不需要的应用程序和系统文档,因为这些也可能向攻击者泄露有用的信息。不要在 Http Get请求参数中包含敏感信息。禁止表单中的自动填充功能,因为表单中可能包含敏感信息,包括身份验证信息。禁止客户端缓存网页,因为可能包含敏感信息。“Cacho-Control:no-store”,可以和HTTP报头控制" Pragma: no-cache”起使用,该控制不是非常有效,但是与HYTP/10向后兼容。应用程序应当支持,当数据不再需要的时候,删除敏感信息(比如:个人信息或者特定财务数据)。中文版ⅴ ersion1.02012年8月为存储在服务器中的敏感信息提供恰当的访问控制。这包括缓存的数据、临时文件以及只允许特定系统用户访间的数据通讯安全:为所有敏感信息采用加密传输。其中应该包括使用TLS对连接的保护,以及支持对敏感文件或非基于HTTP连接的不连续加密。TLS证书应当是有效的,有正确且未过期的域名,并且在需要时,可以和中间证书一起安装没有成功的TLS连接不应当后退成为一个不安全的连接。为所有要求身份验证的访间内容和所有其他的敏感信息提供TLS连接。为包含敏感信息或功能、且连接到外部系统的连接使用TLS。使用配置合理的单一标准TLS连接。为所有的连接明确字符编码当链接到外部站点时,过滤来自 Http referer中包含敏感信息的参数。系统配置:确保服务器、框架和系统部件采用了认可的最新版本。确保服务器、框架和系统部件安装了当前使用版本的所有衤丁关闭目录列表功能。将Web服务器、进程和服务的账户限訇为尽可能低的权限。当例外发生时,妄全的进行错误处理。移除所有不需要的功能和文件。在部署前,移除测试代码和产品不需要的功能。通过将不进行对外检索的路径目录放在一个限离的父目录里,以防止目录结构在 robots. txt文档中暴露。然后:在 robots:txt文档中“禁止”整个父目录,而不是对每个单独目录的“禁止”。明确应用程序采用哪种HTTP方法:GFT或POST,以及是否需要在应用程序不同网页中以不同的方式进行处理。禁用不需要的HYTP方法,比如WebDAV扩展。如果需要使用一个扩展的HTTP方法以支持文件处理,则使用一个好的绎过验证的身份验评机制。如果Web服务器支持HrTP10和1.1,确保以柞似的方式对它们进行配置,或者确保您理解了它们之间可能存在差异(比如:处理扩展的HTP方法)。移除在HTTP相应报头中有关OS、Web服务版本和应用程序框架的无关信息应用程序存储的安全配置信息应当可以以可读的形式输出,以支持审计。使用一个资产管理系统,并将系统部件和软件沣册在其中。将开发环境从生成网络隔离开,并只提供绐授权的开发和测试团队访问。开发环境往往没有实际生成环境那么安全,政击者可以使用这些差别发现共有的弱点或者是可被利用的漏洞。使用一个软件变更管理系统以管理和记录在开发和产品中代码的变更。数据厍安全:使用强类型的参数化查询方法。使用输入验证和输出编码,并桷保处埋了元字符。如果失败,则不执行数裾库命令。确保变量是强类型的,中文版ⅴ ersion1.010