OWASP 10要素增强Web应用程序安全.docx
《OWASP 10要素增强Web应用程序安全.docx》由会员分享，可在线阅读，更多相关《OWASP 10要素增强Web应用程序安全.docx（22页珍藏版）》请在冰豆网上搜索。
OWASP10要素增强Web应用程序安全
OWASP10要素增强Web应用程序安全
随着Web应用程序的增多，随之而来的就是这些Web应用程序所带来的安全漏洞。
不遵从规范化的编码指导，会使企业、员工以及企业的客户面对严重的安全风险，遭到各种恶意攻击。
我们将向大家介绍OpenWebApplicationSecurityProject（开放式Web应用程序安全项目，OWASP）10要素，以及OWASP建议大家在软件开发生命周期中应该嵌入的标准化方法。
商业风险
现在的企业都在向客户提供通过浏览器访问企业信息的功能，同时集成Web服务的应用程序也越来越多，这些都导致企业所面临的风险不断增加。
这并不代表开发人员没有认真的对待程序开发工作，只是当Web应用程序的数量越来越多，其潜在的隐患也会越来越频繁的暴露在互联网下。
根据OWASP的观点：
“当企业发布了一个Web应用程序，它们就是在邀请全球的网民向其发送HTTP请求。
而攻击内容也可以随着这些正常的HTTP请求穿过防火墙，过滤系统，系统平台上的安全措施以及网络中的入侵检测系统，而不被企业所发现。
这意味着企业的Web应用程序代码本身就是企业安全围墙的一部分。
随着企业所采用的Web应用程序数量和复杂度的增加，企业的安全围墙将更多的暴露在网络中。
”
目前，企业所开发的很多新应用程序都是Web应用程序。
另外，Web服务也越来越频繁的被用来集成Web应用程序或与Web应用程序进行交互。
所带来的问题就是，Web应用程序和服务的增长已经超越了程序开发人员所接受的安全培训以及安全意识的范围。
随着存在安全隐患的Web应用程序数量的增长，OWASP也总结出了Web应用程序的十大脆弱点。
在这个10要素列表中，不但包括了Web应用程序的脆弱性介绍，还包括了OWASP的建议内容，帮助程序开发人员和企业尽量避免这些脆弱点给企业系统带来的风险。
OWASP10要素中还包括了一个指南，帮助企业决定该如何向客户提供信息。
比如联邦贸易委员会（FTC）就在2003年1月的商业案例文档中将这个列表作为了信息安全的参考内容。
同年，FTC还将OWASP10要素列表作为指控Guess公司没有尽力做好客户的信息安全保护工作的参考资料。
10要素列表
以下列表来自OWASP10要素项目:
（OWASP,2006）:
（1）UnvalidatedInput非法输入--在数据被输入程序前忽略对数据合法性的检验，是一个常见的编程漏洞。
随着我们对Web应用程序脆弱性的调查，非法输入的问题已经成为了大多数Web应用程序安全漏洞的一个主要特点。
（2）BrokenAccessControl失效的访问控制--大部分企业都非常关注对已经建立的连接进行控制，但是，允许一个特定的字符串输入可以让攻击行为绕过企业的控制。
（3）BrokenAuthenticationandSessionManagement失效的账户和线程管理--良好的访问控制并不代表万事大吉了。
企业还应该保护用户的密码，会话令牌，账户列表以及其它任何可以给攻击者提供有利信息帮助他们攻击企业网络的内容。
（4）CrossSiteScripting（XSS）Flaws跨站点脚本攻击--XSS是一种常见的攻击。
当攻击脚本被嵌入企业的Web页面或其它可以访问的Web资源中，当没有保护能力的台式机访问这个页面或资源时，脚本就会被启动。
这种问题可以影响成百上千的员工以及企业客户的终端电脑。
（5）BufferOverflows缓存溢出--缓存溢出问题一般出现在较早的编程语言如C语言编写的程序中。
这种编程错误其实也是由于没有很好的确定输入内容在内存中的位置所草成的。
在本文的后续部分中，我们会讲到，通过一些高级的编程环境，如Java以及.Net，可以很好的控制此类问题。
（6）InjectionFlaws注入式攻击--如果没有成功的阻止带有语法含义的输入内容，有可能导致对数据库信息的非法访问。
比如在Web表单中输入的内容，应该保持简单，并且不应该还有可被执行的代码内容。
（7）ImproperErrorHandling异常错误处理--当错误发生时，向用户提交错误提示是很正常的事情，但是如果提交的错误提示中包含了太多的内容，就有可能会被攻击者分析出网络环境的结构或配置。
（8）InsecureStorage不安全的存储--对于Web应用程序来说，妥善的保存密码，用户名，以及其它与身份验证有关的信息是非常重要的工作。
对这些信息进行加密是非常有效的方式，但是一些企业会采用那些未经实践验证的加密解决方案，其中就可能存在漏洞。
（9）ApplicationDenialofService程序拒绝服务--与拒绝服务攻击（DoS）类似，应用程序的DoS攻击利用大量非法用户抢占应用程序资源，导致合法用户无法使用该Web应用程序。
（10）InsecureConfigurationManagement不安全的配置管理--有效的配置管理过程可以为Web应用程序和企业的网络架构提供良好的保护。
针对以上列表，我有两点要说明一下。
首先，这个列表并不能涵盖企业的Web应用程序中的全部脆弱点，它只是OWASP的成员组织最常遇到的问题，因此也是你应该着重检查的内容。
第二，这个列表并没有先后顺序。
它只是根据每个OWASP成员根据自己企业的Web应用程序环境的脆弱性所排列的。
OWASP一直在更新它的10大脆弱性排名。
先前已有发表有关2004年OWASP十大排名的文章，这里笔者想深入探究这些OWASP相信会给网络应用环境带来最高风险的10大脆弱性。
在该系列的第1部分中，我给出了2004年的OWASP10大脆弱性列表。
那篇文章不久，我收到了一封来自AndrewvanderStock，OWASP的执行理事的电子邮件。
信中他叫我关注即将修订的新列表。
OWASP计划在三月份发布2007年10大脆弱性清单。
因此，现在我也要修订一下我的这个系列，把2007年的脆弱性包括进来。
2007年OWASP的10大排名：
2004和2007年的名单有些类似，见表A。
其中，未经验证的输入（Unvalidatedinput）、缓存溢出（bufferoverflows）、不安全的配置管理（insecureconfigurationmanagement），以及拒绝服务（denialofservice）被去除了。
另一方面，损坏的验证和会话管理（brokenauthenticationandsessionmanagement）被一分为二，作为两项列入。
列表中包含的新脆弱性有（根据RC1）：
A3.不安全的远程文件包含（InsecureRemoteFileInclude）：
对远程文件包含易感的代码允许攻击者包含进入恶意的代码和数据，最后导致破坏性攻击，比如，服务器被完全攻陷。
A5.跨站请求伪造（CrossSiteRequestForgery，CSRF）：
跨站请求伪造攻击会强制一个已登录受害者的浏览器向易受攻击的网络应用程序发送预验证（pre-authenticated）的请求，然后受害者的浏览器开始执行恶意行为，为攻击者谋利。
A9.不安全的通信（InsecureCommunications）：
敏感信息总需要保护，可应用程序却常常在给网路交通加密时失败。
2007年的脆弱性选取来自对MITRE2006年脆弱性趋势进行的10大应用程序安全问题的筛选。
关于2007年OWASP10大排名，MITRE的数据如图A所示。
表 A
2007年 OWASP10大排名
2004年 OWASP10大排名
A1. 跨站脚本，CrossSiteScripting（XSS）
A4. 跨站脚本CrossSiteScripting（XSS）
A2.注入缺陷， InjectionFlaws
A6. 注入缺陷， InjectionFlaws
A3. 不安全的远程文件包含，InsecureRemoteFileInclude（新）
_
A4. 不安全的直接对象引用，InsecureDirectObjectReference
A2. 破坏的访问控制，BrokenAccessControl（在2007年被分成两类）
A5. 跨站请求伪造，CrossSiteRequestForgery（CSRF）（新）
_
A6. 信息泄漏和异常错误处理，InformationLeakageandImproperErrorHandling
A7. 异常错误处理，ImproperErrorHandling
A7. 损坏的验证和会话管理，BrokenAuthenticationandSessionManagement
A3. 损坏的验证和会话管理，BrokenAuthenticationandSessionManagement
A8. 不安全的加密存储，InsecureCryptographicStorage
A8.不安全的存储，InsecureStorage
A9.不安全的通信 InsecureCommunications（新）
在A10下讨论，不安全的配置管理
A10.URL访问限制失败，FailuretoRestrictURLAccess
A2. 损坏的访问控制，BrokenAccessControl（在2007年被分成两类）
_
A1. 未经严整的输入，UnvalidatedInput
_
A5.缓存溢出，BufferOverflows
_
A9. 拒绝服务，DenialofService
_
A10. 不安全的配置管理，InsecureConfigurationManagement
图AMITRE脆弱性趋势
图表之外
其中未经验证的输入被去除了，一开始让人感到有点惊讶。
而且，对2004和2007年的脆弱性列表进行进行一番表面审查，也能发现这个脆弱性是很多其他弱点的共同根由。
然而，这种忽落可能并非那么非常重大，因为在2007年的列表中，许多脆弱性都把合法输入验证作为一项重要的漏洞防御措施。
溢出脆弱性（即，缓存溢出、整数溢出[integeroverflow]，及格式串问题[formatstringissue]）也被忽略了，因为这些问题多出自低级别的开发语言，如C或者C++。
现在最常见的网络开发环境对这类问题不是那么敏感。
图B显示的是各流行的开发环境中溢出脆弱性发生的可能性比较。
图B溢出脆弱性发生可能性（来自OWASP缓存溢出,2006）
通过该表可以看出，很显然今天最常使用的开发语言和网络应用程序开发环境（例如，Java、.NET、Perl）都是安全的。
但这不等于说，例如使用.NET技术就能让你完全免疫。
编程语言或者开发环境自身内部的错误可能也会引入些许溢出问题。
另一个企业开发应用程序时常犯的错误是，一方面依赖于开发环境（比如.NET）的安全性，一方面又调用用不安全的低级别语言（如c和c++）写成的外部工具和应用程序。
用不安全语言写的工具和应用程序数目越是巨大，如果把它们整合进入网络应用程序，那么风险也会越大。
尽管拒绝服务（DoS）攻击漏洞现在仍是问题，在MITRE的等级排名上却比较靠后，在这里不能上榜。
但这不应该解释为我们可以不把DoS当回事了。
最后，不安全的配置管理同样也没能进入2007年排名。
这是唯一一项我相信应该保留的脆弱性。
对于确保网络应用程序可靠，维持一个安全、稳定的程序运行环境非常重要。
除了应用程序在其上运行的服务器外，其他下层架构提供的支持服务包括：
数据存储（Datastorage）
目录服务（Directoryservices）
邮件（Mail）
消息（Messaging）
一个有效的配置管理程序是保护信息资产的关键元素。
对网络的攻击都是机会主义的。
换言之，盗密者总是在找容易的目标，攻陷这样的目标所需工作量最低。
基础架构的配置可能不必是网络应用程序的实际组件，但是，它必须提供一个强健的环境，让基于网络的服务得以进行。
结语
在接下来的文章中，我将探讨2007年的OWASP10大排名。
我们要看这些脆弱性排名靠前的原因，及如何防御潜在的漏洞利用。
根据RC1，防御好10大脆弱性可以构建安全基础，降低下列问题的发生可能性：
钓鱼攻击（Phishingattack），它能够利用上述所有10个脆弱性，尤其是XSS、低强度或者不存在的鉴别（authentication）或者授权检查（authorizationcheck）。
隐私侵犯（Privacyviolation），这由不充分的合法性检查、不完善的商业规则、和不够强的授权检查造成。
身份盗窃（Identitytheft），这由弱或者没有加密控制、远程文件包含，及鉴别、商业规则和授权检查的问题造成。
跨站点脚本是Web程序很常见的漏洞，不论是个人用户还是商业用户，都会由于这种漏洞而遭受攻击。
这里我们将详细介绍跨站点脚本的脆弱性，以及由此使得个人用户和企业用户所面临的风险。
最后还会介绍如何消除或者抵御这类攻击。
我们将着重介绍Web应用程序中最大的脆弱性领域――跨站点脚本（XSS）。
XSS的脆弱性由来已久，然而，随着越来越多的蠕虫和病毒利用这一脆弱性进行破坏活动，企业系统中与XSS相关的安全风险也越来越明显。
什么是XSS?
XSS漏洞一般出现在可以注入代码的Web程序中。
利用这一漏洞的脚本可能来自服务器，但是并不在服务器上执行，而是在客户端的工作站上执行。
目前有三种基本的XSS漏洞攻击：
映射，存储和基于DOM（文档对象模块）
其中反射攻击最为常见。
这类漏洞经常出现在网页中可以动态输入内容并返回结果的区域。
搜索页面就是一个很典型的例子。
当攻击者发现了存在这一漏洞的网页，他只需要将脚本输入文本框。
当页面重新显示整段文字时，脚本便被执行了。
在很多情况下，黑客通过一些社会学工程来引诱用户点击经过特殊处理的链结，从而导致攻击发生。
这种方式可以让黑客将脚本注入到网页中。
（JeremiahGrossman,"Cross-siteScriptingWormsandViruses,"April2006）
存储型弱点正如其名字所表示的意思。
攻击者将恶意代码提交到有XSS漏洞的网站，或者网站的某个经常被用户访问的部分。
比如一些社会网站以及用户提交评论的页面。
当受害者打开相应的页面时，恶意脚本就会在用户不知情的情况下自动执行。
因为浏览器认为这个存储型恶意脚本是来自受信的Web网站或服务器的。
以下是一个非常简单的存储型脚本攻击的例子。
脚本一般会插入到表单中，这在很多论坛或者拥有大量用户的服务器上很常见。
比如黑客会将以下代码通过正常的发贴方式上传到在线论坛：
当不知情的用户打开这个帖子，代码就会在用户的电脑上执行。
虽然我给出的这段代码没有任何有害的内容，但是如果代码中包含了以下内容，就不那么乐观了：
◆显示许可权限错误信息
◆提示用户输入密码
◆将用户的密码通过邮件发送到黑客设定的服务器上
最后一种XSS弱点是基于DOM的攻击。
作为AJAX的一部分，DOM是一种：
“让程序员可以访问和控制Web页面文档内容的接口。
它提供了一种结构化的面向对象的方法，可以对页面中特定的内容进行检索以及设定对象的属性。
”（MikeHall,"IntroductiontotheDocumentObjectModel,"2007）.
在客户端的脚本中，存在DOM漏洞。
一般来说这出现在脚本模块访问URL需要参数的时候。
如果脚本使用的参数信息没有经过编码或过滤就写入到了HTML文件中，那么很有可能会存在XSS漏洞。
有关这方面的例子和更详细的说明，可以参考2005年AmitKlein的文章"DOMBasedCrossSiteScriptingorXSSoftheThirdKind,"基于DOM的XSS攻击难以防御。
因为DOM页面层中的所有方法都是受信的，植入在参数中的恶意代码可以和其他代码一样被执行。
与存储型XSS攻击一样，DOM脚本攻击的防御还是要依靠程序员在编程时的细心和安全意识。
商业冲击
根据Grossman的观点，当攻击者成功利用XSS漏洞进行攻击后，可能进一步实施以下工作：
◆强制发送电子邮件信息
◆转移资本
◆删除或修改数据
◆使用被害人的电脑攻击其他服务器
◆下载非法内容
基本上说，Web网页脚本所能做的工作，黑客都可以通过成功的XSS攻击而实施。
预防XSS攻击
由于很多Web应用程序都包含有漏洞，因此最好的预防XSS攻击的方式就是检测输入内容的合法性。
比如，确保输入内容中不包括尖括号。
这看上去很简单，但确是防御XSS攻击一个非常有效的手段。
根据McClure,Scambray,以及Kurtz的说法：
“我们遇到的几乎所有的XSS攻击都没有对输入内容的尖括号进行屏蔽或者重新编码”（HackingExposed,p.565）。
但是这并不仅仅是尖括号的问题。
任何语法符号都不应该被允许。
语法符号可能是来自数据库，或其他服务器。
输入Web应用程序的任何内容必须经过过滤，确保用户最终看到的是单纯的文本内容。
企业应对XSS攻击的方式还包括：
1.教育员工在点击电子邮件中的链结或即时消息中的链结时，要特别小心。
2.建立互联网接入控制策略，限制企业员工访问高风险网站（比如成人网站以及盗版媒体网站）以及未知风险的网站。
3.确保用户的电脑上都安装了最新版的防火墙软件和反病毒软件。
设置防火墙限制流出的数据。
4.确保所有敏感功能不会通过机器人或者第三方服务器来启动。
（Grossman）.
5.手动或自动进行代码扫描，主动发现潜在的XSS漏洞。
总结
XSS漏洞会给企业网络带来严重的安全风险。
企业的敏感数据很可能由于XSS漏洞被泄露出去。
正如我们上面介绍的，预防XSS攻击，需要企业终端用户以及程序员的协同努力，通过良好的技术方案抵御这种人为危害。
这里我将向大家介绍位于列表第二位的注入式漏洞。
首先我们会简要介绍一下注入式攻击，然后深入分析SQL注入式攻击。
因为SQL注入式攻击是企业Web应用程序最容易遭受的攻击类型。
什么是注入式缺陷?
简单地讲，注入式缺陷可依让攻击者通过“巧妙”的内容输入来改变应用程序的执行动作。
比如改变接入控制，允许攻击者创建、修改、删除或者读取任何该应用程序可以读取的数据。
根据OWASP的说明，最糟的情况可以使得Web应用程序彻底崩溃。
注入式缺陷是由于程序开发人员对于用户输入的字符内容的假定过于简单而引起的。
程序员没有考虑到用户可能会输入一些含有语义性内容的字符串，或者程序员没有对Web程序的输入内容进行全面有效的审核和过滤。
注入式攻击主要包括三类：
◆系统调用
◆Shell命令
◆SQL注入
本文下面的内容将详细介绍SQL注入攻击的细节。
如果想了解更多注入漏洞的信息，可以查看InjectionFlaws。
SQL注入式攻击
在这种注入式漏洞中，用户输入的内容是不会被过滤的。
因此攻击者可以在输入的内容中加入SQL语句以及参数，从而实现数据库操作。
2004年StephenKost在它的报告（AnIntroductiontoSQLInjectionAttacksforOracleDevelopers）中介绍了四种基本的SQL注入攻击：
◆SQL操作—攻击者通过变量操作改变SQL语句（e.g.,UNION）。
攻击者还可以通过修改WHERE对象获取更多的数据库信息。
◆代码注入—在代码注入式攻击中，黑客在现有的SQL代码中加入一条活多条新的SQL语句。
如果数据库在处理每个请求时不允许执行多个操作语句，那么就可以有效地避免这类SQL注入式攻击。
◆功能调用注入—在一个SQL语句中加入功能调用，可以构成一个功能调用形式的注入式攻击。
这种攻击可以造成系统功能调用或者对数据表中的内容进行操作。
◆缓冲溢出—这种攻击主要针对那些没有打补丁的数据库服务器。
通过输入特定的内容造成系统错误或执行恶意代码。
下面我们就来看看针对Oracle数据库的SQL操作攻击范例。
图A显示的是由Web程序开发人员编写的用户登录系统中检测用户名和密码的代码。
图ASQL操作攻击范例（预期输入）（Kost,2004）
而图B显示了由攻击者输入的用户名和密码。
这里我们可以看到，攻击者在输入密码的时候加入了OR运算符，并且加入了a=a，这使得密码判断总为TRUE。
由于操作优先于规则的原则，WHERE对于任何一个密码都会得到TRUE的结论。
图BSQL操作攻击范例 （任意输入）（Kost,2004）
有关其他攻击类型的范例，我们可以查看KevinSpett写的SPIDynamics公司文档SQLInjection。
防御SQL注入攻击
防御任何类型的注入式攻击的最主要的方式就是对输入内容进行检查。
这包括Web应用程序的各个界面获取的外来输入内容。
图C展示了Web应用程序可能获取外来输入内容的四个渠道。
图CWeb应用程序输入
来自这几种途径的用户输入内容都有可能改变Web应用程序对数据库内容的访问、处理和显示。
比如攻击者可以在查询请求中添加、删除或者修改URL参数。
被隐藏的表单可能会被修改，也可能出现表单重复提交的情况。
而数据库的信息，尤其是由其他程序写入的区域，很可能被有目的的或者偶然的被感染。
这些漏洞的类型和数量完全是根据系统程序的漏洞和攻击者的智慧来确定的。
抵御此类攻击的最有力方式就是加强代码的安全性。
以下列出了Web应用程序开发团队应当遵守的一些原则：
1.对任何输入内容进行检查。
接受所有可以接受的内容，拒绝所有不能接受的内容。
2.在服务器上进行二次检查.在客户端上的内容检查并不是真正意义上的检查。
比如黑客很容易在自己的终端上禁用脚本执行，从而防止客户端的内容检查脚本运行，使得他可以输入恶意代码并成功地提交表单。
3.防止过分详细的错误提示。
攻击者经常会故意输入错误的内容，进而分析系统给出的错误提示信息，从中获取系统信息，发现可能存在的漏洞。
4.使用积极的过滤而不是消极的过滤。
换句话说，就是检查应该输入什么，而不是检查不应该输入什么。
只规定哪些内容不应该输入，会留下太多的漏洞。
因为有很多内容都不应该被输入，软件开发人员不可能一次都总结出来。
积极的过滤方式应该包括：
a.是否是正确的数据类型（字符串，整数，等）
b.是否要求带有参数
c.字符编码是否允许
d.输入内容是否达到了内容长度的最大或者最小界限
e.是否允许输入空值
f.如果应该输入数字，那么确定数字大小的范围。
g.输入内容是否造成了数据重复，如果是，判断这种情况是否可以接受。
h.输入内容是否符合格式要求（比如是否采用正则表达式）
i.如果是通过下拉列表选取的内容，确保其包含了有效的值
5.实行内部代码检查机制或"buddychecks".也就是让你的程序员之间互相检查代码。
在本系列文章的后面，我会讲到自动实现这一检查的方式。
当然，在检查时要确保合法的数据被允许，非凡的数据不被允许。
6.消除语法符号的输入。
确保来自用户提交的内容不会被执行。
把用户输入的尖括号改为方括号，或其他符号。
7.使用"最低权限"限制数据库用户的权限。
升级会员 