由于Web服务器提供了几种不同的方式将请求转发给应用服务器,并将修改过的或新的网页发回给最终用户,这使得非法闯入网络变得更加容易。
而且,许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序,这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。
其次,许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施,因为端口80或443(SSL,安全套接字协议层)必须开放,以便让应用程序正常运行。Web应用程序攻击包括对应用程序本身的DoS(拒绝服务)攻击、改变网页内容以及盗走企业的关键信息或用户信息等。
总之,Web应用攻击之所以与其他攻击不同,是因为它们很难被发现,而且可能来自任何在线用户,甚至是经过验证的用户。迄今为止,该方面尚未受到重视,因为企业用户主要使用防火墙和入侵检测解决方案来保护其网络的安全,而防火墙和入侵检测解决方案发现不了Web攻击行动。
常见的Web应用安全漏洞
下面将列出一系列通常会出现的安全漏洞,并且简单解释一下这些漏洞是如何产生的。
已知弱点和错误配置
已知弱点包括Web应用使用的操作系统和第三方应用程序中的所有程序错误或者可以被利用的漏洞。这个问题也涉及到错误配置,包含有不安全的默认设置或管理员没有进行安全配置的应用程序。一个很好的例子就是你的Web服务器被配置成可以让任何用户从系统上的任何目录路径通过,这样可能会导致泄露存储在Web服务器上的一些敏感信息,如口令、源代码或客户信息等。
隐藏字段
在许多应用中,隐藏的HTML格式字段被用来保存系统口令或商品价格。尽管其名称如此,但这些字段并不是很隐蔽的,任何在网页上执行“查看源代码”的人都能看见。许多Web应用允许恶意的用户修改HTML源文件中的这些字段,为他们提供了以极小成本或无需成本购买商品的机会。这些攻击行动之所以成功,是因为大多数应用没有对返回网页进行验证;相反,它们认为输入数据和输出数据是一样的。
后门和调试漏洞
开发人员常常建立一些后门并依靠调试来排除应用程序的故障。在开发过程中这样做可以,但这些安全漏洞经常被留在一些放在Internet上的最终应用中。一些常见的后门使用户不用口令就可以登录或者访问允许直接进行应用配置的特殊URL。
跨站点脚本编写
一般来说,跨站点编写脚本是将代码插入由另一个源发送的网页之中的过程。利用跨站点编写脚本的一种方式是通过HTML格式,将信息帖到公告牌上就是跨站点脚本编写的一个很好范例。恶意的用户会在公告牌上帖上包含有恶意的JavaScript代码的信息。当用户查看这个公告牌时,服务器就会发送HTML与这个恶意的用户代码一起显示。客户端的浏览器会执行该代码,因为它认为这是来自Web服务器的有效代码。
参数篡改
参数篡改包括操纵URL字符串,以检索用户以其他方式得不到的信息。访问Web应用的后端数据库是通过常常包含在URL中的SQL调用来进行的。恶意的用户可以操纵SQL代码,以便将来有可能检索一份包含所有用户、口令、信用卡号的清单或者储存在数据库中的任何其他数据。
更改cookie指的是修改存储在cookie中的数据。网站常常将一些包括用户ID、口令、帐号等的cookie存储到用户系统上。通过改变这些值,恶意的用户就可以访问不属于他们的帐户。攻击者也可以窃取用户的cookie并访问用户的帐户,而不必输入ID和口令或进行其他验证。
输入信息控制
输入信息检查包括能够通过控制由CGI脚本处理的HTML格式中的输入信息来运行系统命令。例如,使用CGI脚本向另一个用户发送信息的形式可以被攻击者控制来将服务器的口令文件邮寄给恶意的用户或者删除系统上的所有文件。
缓冲区溢出
缓冲区溢出是恶意的用户向服务器发送大量数据以使系统瘫痪的典型攻击手段。该系统包括存储这些数据的预置缓冲区。如果所收到的数据量大于缓冲区,则部分数据就会溢出到堆栈中。如果这些数据是代码,系统随后就会执行溢出到堆栈上的任何代码。Web应用缓冲区溢出攻击的典型例子也涉及到HTML文件。如果HTML文件上的一个字段中的数据足够的大,它就能创造一个缓冲器溢出条件。
直接访问浏览
直接访问浏览指直接访问应该需要验证的网页。没有正确配置的Web应用程序可以让恶意的用户直接访问包括有敏感信息的URL或者使提供收费网页的公司丧失收入。
Web应用安全两步走
Web应用攻击能够给企业的财产、资源和声誉造成重大破坏。虽然Web应用增加了企业受攻击的危险,但有许多方法可以帮助减轻这一危险。首先,必须教育开发人员了解安全编码方法。仅此项步骤就会消除大部分Web应用的安全问题。其次,坚持跟上所有厂商的最新安全补丁程序。如果不对已知的缺陷进行修补,和特洛伊木马一样,攻击者就能很容易地利用你的Web应用程序穿过防火墙访问Web服务器、数据库服务器、应用服务器等等。将这两项步骤结合起来,就会大大减少Web应用受到攻击的风险。同时管理人员必须采取严格措施,以保证不让任何东西从这些漏洞中溜过去。
……