基于OWASP的WEB应用安全检测与防范

符泉麟

0 引言

随着互联网的发展，拉近了人与人之间的距离。不管相隔多远，都能通过各种方式进行交流，人人都是互联网的主角，就像人类社会一样，为了使社会的安定就需要法律的制约，而互联网也需要各种检测和分析来保证其安全性。

不安全的WEB应用，已经在破坏着我们生活中的各个方面。随着数字化架构变得越来越复杂并相互关联，实现应用程序安全的难度也呈指数级增加。要完全保证WEB应用的安全是没有银弹的，当你试图思考安全扫描器或应用防火墙的时候，实际上不存在一下子就能解决WEB应用安全问题的方法，并且随着软件安全性与软件的用户友好性是成反比的。所以，必须找到一种检测和分析方法，来找出企业组织所面临的最严重的安全风险，同时提高人们对应用程序安全的关注度。

本文根据OWASP最新统计出的Top 5的WEB应用安全风险，对这些风险进行深入分析并提供检测和预防手段，进而保证WEB应用的安全。

1 OWASP的简介

OWASP(Open Web Application Security Project)是一个开放的、非盈利组织，致力于协助政府、企业开发升级的各类应用程序，以保证其可信任性。因为，没有商业压力，所以，能够提供切实可行的、同时具有成本效益的应用安全信息。虽然OWASP 支持使用商业安全技术，但它不隶属于任何技术公司。OWASP 基金会是一个确保项目长期成功的非盈利性实体。

2 WEB应用安全风险的发展历史

互联网应用程序所受到的威胁，随着攻击者和新技术的提升以及日益复杂的系统在不断改变。为了跟随前进的步伐，OWASP组织会每过几年，对这TOP 10排行榜进行更新，更新情况，如表1所示：

表1 2007年版本和2010年最新版本的对比

从表1中可以看出，很多安全风险是长期存在的，所以，要对这些风险特别重视，还有些如恶意文件执行，这个问题在很多环境中仍然是一个严重的问题。但是，其在2007年版本中提出的普遍性，由大量PHP应用程序问题而导致的。PHP现在已经采用了更多默认的安全配置，从而降低了这个问题的严重程度。

3 WEB应用安全风险的检测和分析

根据OWASP的安全性统计，以下将针对排名前5的风险，进行深入的分析与讲解，并提供检测和防范的方法。这5个风险，基本涵盖了 Web应用安全方面百分之七十的问题，所以，掌握以下5点，对于提高Web应用安全性来说意义重大。

3.1 注入

注入攻击漏洞，例如SQL，OS以及LDAP注入。这些攻击，发生在不可信的数据作为命令或者查询语句，被发送给解析器的时候。攻击者发送的恶意数据，可以欺骗解释器，以执行计划外的命令或者访问未被授权的数据。如应用程序在存在漏洞的SQL语句的构造中，使用不可信数据：

攻击者在浏览器中将“id”参数的值，修改成’or’1’=’1。这样查询语句的意义就变成了从数据库 accounts表中返回所有的记录，而不是只有目标客户的信息。在最严重的情况下，攻击者能够使用这一漏洞，调用数据库中特殊的储存过程，从而达到完全接管数据库。

检测WEB应用是否存在注入漏洞的最好的办法，就是确认所有解释器的使用，都明确地将不可信数据从命令语句或查询语句中区分出来。对于SQL调用，这就意味着在所有准备语句和储存过程中使用绑定变量，并避免使用动态查询语句。检查应用程序是否安全使用解释器的最快最有效的方法是代码审查。代码分析工具能帮助安全分析者，找到使用解释器的代码并追踪应用的数据流。为执行应用程序的自动动态扫描器提供一些信息，帮助确认一些注入漏洞是否存在。然而，扫描器并非总能达到解释器每个分支，所以不容易检测到一个攻击是否成功。

防止注入漏洞，需要将不可信数据从命令及查询中区分开。最佳选择是使用安全的、完全避免使用解释器或提供参数化界面的API。但要注意，有些参数化的API，如果使用不当，仍然会引入注入漏洞。如果没法使用一个参数化的API，那么你应该使用解释器的具体的escape语法来避免特殊字符。

3.2 跨站脚本(XSS)

当应用程序收到含有不可信的数据时，在没有进行适当的验证和转义的情况下，就将它发送给一个网页游览器，这就会产生跨站脚本攻击。XSS允许攻击者在受害者的游览器上执行脚本，从而劫持用户会话，危害网站，或者将用户转向恶意网站。如应用程序在下面HTML代码段的构造中，使用未经验证或转义的不可信的数据：

攻击者在浏览器中修改‘CC’参数为如下值：

这导致受害者访问此页面时，将会话ID发送到攻击者的网站，使得攻击者能劫持用户当前会话。

检查WEB应用是否有XSS漏洞，你需要确保发送给浏览器的所有用户提供的输入都是安全的。同时，你还需要确保用户输入在被显示在页面之前，都经过了恰当的转义。恰当的输出编码，能确保这样的输入总是被视为浏览器中的文本，而不是可能被执行的动态内容。使用专用工具都能自动找出一些跨站脚本漏洞。然而每一个应用程序使用不同的方式生成输出页面，并且使用不同的浏览器端解释器，这使得自动检测变得很困难。因此，要想达到全面覆盖，必须使用一种结合的方式，在自动检测的基础上，同时采用人工代码审核和手动渗透测试。

防止跨站脚本将不可信数据与动态的浏览器内容区分开。最好的办法是，根据数据将要置于HTML的上下文中所有的不可信数据转义。除非用户界面框架已经提供转义，开发者需要在应用程序中提供转义。

3.3 失效的身份认证和会话管理

与身份认证和会话管理相关的应用程序功能，往往得不到正确的实现，这就导致攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞，去冒充其他用户的身份。如：机票预订应用程序支持URL重写，把会话ID放在URL里：http://example.com/sale/saleitems;jsessionid=12345890GGGF SSDSDFS?dest=Shanghai

该网站一个经过认证的用户，希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话 ID。当他的朋友们使用上面的链接时，他们将可以使用他的会话和信用卡。

要检查这类漏洞，就需要特别关注认证凭证和会话ID。当存储认证凭证时，就需要多问自己几个问题：是否总是使用hash或加密保护？认证凭证是否可猜测或者能够通过薄弱的帐户管理功能（例如账户创建、密码修改、密码恢复、弱会话ID）重写？会话ID是否暴露在URL里？会话ID会超时吗？成功注册后,会话ID会轮转？密码、会话ID和其他认证凭据是否只通过TLS连接传输？

要防范这类漏洞，最好是让开发人员采用一套成熟的认证和会话管理控制系统。如果是从新研发的话，那就需要一一检查前面提出的问题。

3.4 不安全的直接对象引用

当开发人员暴露一个对内部实现对象的引用时，例如，一个文件，目录或者数据库密钥，就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些引用去访问未授权数据。如应用程序在访问帐户信息的SQL调用中，使用未验证数据。攻击者能轻易在浏览器中输入http://example.com/ account?acct=notmyacct然后可以将“acct”参数，修改成他所想要的任何账户号码。如果应用程序没有进行恰当的验证，攻击者就能访问任何用户的账户。

检测一个应用程序是否存在不安全的直接对象引用漏洞，最好的办法，就是验证其所有的对象引用，都具有适当的防御能力。要达到这一目的，可以考虑对于资源的直接引用，应用程序需要验证用户有权限访问他们所请求的具体资源。如果该引用是间接引用，那么应用程序需要保证该间接引用，只能映射到授权给当前用户访问的直接引用的值。

要防止不安全的直接对象引用，需要选择一个适当的方法来保护每一个用户可访问的对象，可以使用基于用户或者会话的间接对象引用。这样能防止攻击者直接攻击未授权资源。在服务器端，应用程序需要将每个用户的间接引用映射到实际的数据库关键字。还有任何来自不可信源的直接对象引用，都必须通过访问控制检测。

3.5 跨站请求伪造(CSRF)

一个跨站请求伪造攻击，迫使登录用户的游览器伪造的HTTP请求，包括该用户的会话cookie和其他认证信息，发送到一个存在漏洞的WEB应用程序。这就允许了攻击者迫使用户游览器，向存在漏洞的应用程序发送请求，而这些请求被应用程序认为是用户的合法请求。如应用程序允许用户提交不包含任何保密字段的状态改变请求。

因此，攻击者构建一个请求，用于将受害用户账户中的现金转移到自己账户。然后攻击者在其控制的多个网站的图片请求或iframe中嵌入这种攻击。

如果受害用户通过 example.com认证后，访问任何一个这样的恶意网站，伪造的请求将包含用户的会话信息，导致该请求被授权执行。

检测应用程序是否存在该漏洞的最简单的方法，就是确认是否每个链接都为每个用户提供了不可预测的令牌。如果没有这样不可预测的令牌，攻击者就能够伪造恶意请求。重点关注那些调用能够改变状态的功能的链接，因为他们是跨站请求伪造攻击的最重要的目标，还要注意会话、源 IP地址和其他浏览器自动发送的信息，不能作为防攻击令牌，因为他们已经包含在伪造的请求中。

要防止跨站请求伪造，需要在每个 HTTP请求的主体或者URL中，添加一个不可预测的令牌。这种令牌至少应该对每个用户会话来说是唯一的，或者也可以对每个请求是唯一的。最好的方法是将独有的令牌包含在一个隐藏字段中。这将使得该令牌通过HTTP请求主体发送，避免其被包含在URL中从而被暴露出来。

4 银行ATM监控项目实施安全检测的效果

银行ATM监控是以监控银行ATM为中心，并提供远程控制 ATM、产生流水和统计报表。在银行实施此项目产品初期，银行重金请了专业安全团队来检测该产品的安全性，但结果很不乐观，为我们提出几十条整改意见，如密码采用MD5这种已被认为不安全的Hash算法、多处有注入漏洞、Struts，spring，hibernate的配置也有多处不合理并导致了部分URL访问没做限制等。这个结果，给我们公司敲响了警钟。于是成立了专门的安全小组，并采用以上的WEB安全检测和防范方法，对公司的每个项目进行自检并对每个员工进行WEB应用安全知识讲座。此后的项目中，客户对我们产品的安全性非常的满意。这不但提升了公司的形象，而且加强了公司整体的安全意识。

5 结束语

随着Internet的发展，人们对WEB应用更为依赖，企业WEB应用安全性也变的越来越重要。正所谓安全第一，WEB应用用户友好性很好，但如果安全充斥着安全漏洞，Server经常被黑客攻击，甚至用户的个人私密信息遭暴露，这后果将是非常的严重。因此，企业或个人在创建WEB应用时，必需实时把安全放在第一，时时刻刻采用此方法来检测和防范Web应用风险，并通过以下方法更好的杜绝风险，并做到防范于未然。

1)关注最新的安全技术动态，时时关注服务器，数据库及操作系统等方面的漏洞，及时更新。

2)虽说安全风险的百分之七十涵盖在此安全与检测方法中，但其实还有百分之三十需要进一步的研究，来保证整个Web应用的万无一失。

3)如果公司规模一般，那可以采用第三方的安全框架来保证WEB应用的安全。

4)如果公司对业务和安全的要求比较高，那需要有专业的安全小组来监督开发，并加强员工的安全意识

[1]刘彬，SQL注入式攻击分析，[j]电脑知识与技术，2009年04月

[2]肖云，基于Spring Security安全的Web应用开发，[j]计算机与现代化，2011年06月

[3]Russo,A.,Securing Timeout Instructions in Web Applications,[C]Computer Security Foundations Symposium,2009