瑞星企业安全中心 > 行业安全

企业网站安全防护规划方案

  • 用IIS+ASP建网站的安全性分析:
  • 随着Internet的发展,Web技术日新月异,人们已经不再满足于静态HTML技术,更多的是要求动态、交互的网络技术。继通用网关接口(CGI)之后,微软推出的IIS+ASP的解决方案作为一种典型的服务器端网页设计技术,被广泛应用在网上银行、电子商务、网上调查、网上查询、BBS、搜索引擎等各种互联网应用中。与此同时,Access数据库作为微软推出的以标准JET为引擎的桌面型数据库系统,由于具有操作简单、界面友好等特点,具有较大的用户群体。目前,IIS+ASP+Access是中小型Internet网站的首选方案。但是,该解决方案在为我们带来便捷的同时,也带来了严峻的安全问题。

  • 安全隐患分析:
  • IIS+ASP+Access解决方案的主要安全隐患来自Access数据库的安全性,其次在于ASP网页设计过程中的安全意识和措施。

  • 数据库可能被下载
  • 在IIS+ASP+Access网站中,如果有人通过各种方法获得或者猜到数据库的存储路径和文件名,则该数据库就可以被下载到本地。例如:对于网上书店数据库,一般命名为book.mdb、store.mdb等,存储路径一般为“URL/database”或放在根目录“URL/”下,这样,任何人敲入地址:“URL/database/store.mdb”, 数据库就可以被下载了。

  • 数据库可能被解密
  • 由于Access数据库的加密机制比较简单,即使设置了密码,解密也很容易。该数据库系统通过将用户输入的密码与某一固定密钥(例如: Access 97为86 FB EC 37 5D 44 9C FA C6 5E 28 E6 13)进行“异或”来形成一个加密串,并将其存储在*.mdb文件从地址“&H42”开始的区域内。我们可以轻松地编制解密程序,一个几十行的小程序就可以轻松地获得任何Access数据库的密码。因此,只要数据库被下载,其信息就没有任何安全性可言了。

  • ASP页面的安全性
  • 1)源代码安全性隐患。由于ASP程序采用非编译性语言,大大降低了程序源代码的安全性。如果黑客侵入站点,就可以获得ASP源代码;同时对于租用服务器的用户,因个别服务器出租商的职业道德问题,也会造成ASP应用程序源代码泄露。
    2)程序设计中容易被忽视的安全性问题。ASP代码使用表单实现交互,而相应的内容会反映在浏览器的地址栏中,如果不采用适当的安全措施,只要记下这些内容,就可以绕过验证直接进入某一页面。例如在浏览器中敲入“...page.asp?x=1”,即可不经过表单页面直接进入满足“x=1”条件的页面。因此,在验证或注册页面中,必须采取特殊措施来避免此类问题的产生。

  • 提高IIS+ASP网站安全性的方法
  • 防止数据库被下载
  • 由于Access数据库加密机制过于简单,有效地防止数据库被下载,就成了提高ASP+Access解决方案安全性的重中之重。以下两种方法简单、有效。
    1)非常规命名法。为Access数据库文件起一个复杂的非常规名字,并把它放在几个目录下。例如,对于网上书店的数据库,我们不把它命名为“book.mdb”或“Store.mdb”,而是起个非常规的名字,例如:faq9jl.mdb,再把它放在如./akkt/kj61/acd/av5 的几层目录下,这样黑客想通过猜的方式得到Access数据库文件名就很难了。
    2)使用ODBC数据源。在ASP程序设计中,如果有条件,应尽量使用ODBC数据源,不要把数据库名写在程序中,否则,数据库名将随ASP源代码的失密而一同失密。

  • ASP页面进行加密
  • 为有效地防止ASP源代码泄露,可以对ASP页面进行加密。我们曾采用两种方法对ASP页面进行加密。一是使用组件技术将编程逻辑封装入DLL之中;二是使用微软的Script Encoder对ASP页面进行加密。使用组件技术存在的主要问题是每段代码均需组件化,操作比较繁琐,工作量较大,而使用Encoder对ASP页面进行加密,操作简单、收效良好。Script Encoder的运行程序是SCRENC.EXE,使用方法是:
    SCRENC [/s] [/f] [/xl] [/l defLanguage ] [/e defExtension] inputfile outputfile
    其中:/s 是屏蔽屏幕输出;/f 指定输出文件是否覆盖同名输入文件;/xl 指是否在.asp文件的顶部添加@Language指令;/l defLanguag指定缺省的脚本语言; /e defExtension 指定待加密文件的扩展名。

  • 注册验证
  • 为防止未经注册的用户绕过注册界面直接进入应用系统,我们采用Session对象进行注册验证。例如,我们制作了下面的注册页面。
    设计要求注册成功后系统启动hrmis.asp?page=1页面。假设,不采用Session对象进行注册验证,则用户在浏览器中敲入“URL/hrmis.asp?page=1”即可绕过注册界面,直接进入系统。

  • 网站入侵与防御
  • JavaScript包含的Ajax是Web2.0应用的一个重要组成部分。该部分的进化发展使网络变成了超级平台。该转变同时也催生了新品种的病毒和蠕虫,比如Yamanner,Samy 以及Spaceflash等等。Google,Netflix,Yahoo 以及MySpace等门户网站在过去的几个月里都因为新的漏洞而蒙受一定损失。黑客们可以利用这些漏洞进行钓鱼,跨站点脚本(XSS)以及跨站点伪造(XSRF)请求等攻击。
    Ajax中没有固有的安全漏洞,但是对该技术向量的适配显著地改变了网络应用的开发途径以及方法论。以前,DCOM和CORBA组成核心中间件层的时候,将数据和对象序列化非常困难。Ajax使用简单的GET,POST或者SOAP调用,来转换XML,HTML,JS Array,JSON,JS Objects以及其他定制的对象;全部这些操作都不需要调用中间件层。Ajax的这种综合能力使应用服务器与浏览器之间的数据交换非常流畅。从服务器端传来的信息动态地被注入到当前的DOM相关环境,然后浏览器的DOM状态重置。在讲安全漏洞之前,我们先来看看促成Web2.0漏洞的关键因素。
    多重分散的终端点以及隐藏调用——Web2.0应用与Web1.0的主要区别就是信息访问机制的区别。比起它的前身Web1.0, Web2.0应用有数个Ajax终点。潜在的Ajax调用分散于整个浏览器页面,并且能够被各个事件分别调用。开发者很难应付Ajax调用的这种分散性,并且由于这些调用是隐藏的,不那么明显,它还可能导致代码不规范。
    认证混乱——输入和输出内容认证是应用的重要因素之一。Web2.0应用使用桥,mashups,还有反馈等等。很多情况下,它假定“另一方”(读取服务器端或者客户端代码)已经实现了认证,这种混乱就导致了双方都没有实现适当的认证控制。
    不受信任的信息来源——Web2.0应用从很多不受信任的来源比如反馈,博客,搜索结果中获得信息。这些内容在提供给终端浏览器之前从来没有被认证,这就有可能引发跨站点攻击。黑客还有可能在浏览器中加载JavaScript,以便迫使浏览器发出跨域的调用并打开安全漏洞。那样的话,这些致命的漏洞就能被病毒和蠕虫利用。
    数据序列化——浏览器可以调用Ajax来实施数据序列化。它可以获取JS array,Objects,Feeds,XML文件,HTML 块以及JSON。如果这些序列块中的某一个被解析并修改了,黑客们就可以强迫浏览器执行恶意脚本。不受信任信息与数据序列化的结合,对终端用户的安全是致命的。
    动态脚本构成和执行——Ajax会建立一个后端通道,从服务器获取数据,然后将它传送给DOM。实现这一点的必要条件就是动态地执行JavaScripts,以便随时更新DOM或者浏览器页面缓存的状态。Ajax通过调用定制的功能或者eval()功能。未经认证的内容或者使用不安全的调用,轻则导致会话内容泄露,重则迫使浏览器执行恶意内容等各种后果。
    Web2.0应用可能因为上面提到的1个或多个失误而变得易受攻击。如果开发者不够审慎,没有花心思在安全管理上的话,那么服务器和浏览器端都会出现安全问题。以下是10个可能的安全漏洞的简要说明。
    1)畸形的JS对象序列
    JavaScript支持面向对象编程(OOP)技术。它有很多不同的内置对象,也允许用户自己创建对象。使用者可以用new object() 或者自己编辑如下代码来创建新的对象。

    message = { from : "john@example.com", to : "jerry@victim.com",
    subject : "I am fine", body : "Long message here", showsubject :
    function(){document.write(this.subject)} };


    这是一个简单的消息对象,其中有2个字段需要电子邮件地址。我们可以使用Ajax来将该对象序列化并用JavaScript代码编译。程序员可以将它赋值到变量或者eval()。如果攻击者发送嵌入了脚本的恶意“主题”,那么读者就将成为跨站点脚本攻击的受害者。JS对象既包含数据也包含方法。对JS对象序列的不当使用将产生可以被诡计多端的注入代码利用的安全漏洞。
    (2)JSON对注入
    JavaScript对象符号(JSON)是一个简单而有效的少量数据交换格式,它包含对象,数组,Hash表,向量以及列表数据结构。JavaScript, Python, C, C++, C# 和Perl languages都支持JSON。JSON序列在Web2.0应用中是个非常有效的交换机制。开发者频繁使用Ajax和JSON,获取并传送必要的信息给DOM。下面是个简单的带有不同的name值对的JSON对象:“bookmarks”对象。

    {"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]}


    黑客们可以在Link或者Desc中注入恶意脚本。如果DOM和可执行程序被注入了,XSS目录也会被注入。这是使终端用户感染恶意内容的另一种方法。
    (3)JS数组中毒
    JS数组是另一个比较普遍的序列化对象。人们可以很容易地跨平台移植它,并且它在使用不同语言的结构中也很有效。感染一个JS数组可以扰乱整个DOM环境。黑客们可以在浏览器中使用简单的跨站点脚本攻击JS数组。下面是一个JS数组的例子:

    new Array(“Laptop”, “Thinkpad”, “T60”,
    “Used”, “900$”, “It is great and I have used it for 2 years”)


    该数组是从一个拍卖二手笔记本的网站传出来的。如果这个数组对象在服务器端没有被仔细处理,黑客就可以在最后字段中注入脚本。这种注入将危及浏览器安全并被攻击者利用。
    (4)被修改的XML数据流
    Ajax调用接受来自多个地址的XML。这些XML块来自运行在SOAP,REST或者XML-RPC的网络服务。这些网络服务是由从第三方的代理桥那里接收过来的。如果这些第三方XML数据流被攻击者修改过,那么攻击者就可能向其中注入恶意内容。
    浏览器从它自带的XML解析器接收该数据流。该解析器容易受不同的XML炸弹的攻击。人们也可以在该数据流中注入脚本,这样就可以导致跨站点脚本攻击(XSS)。浏览器接收未经认证的XML数据流的话,这就会危及终端客户端的安全。
    (5)DOM中脚本注入
    前四个漏洞都是由于序列化问题引起的。一旦浏览器收到序列化的对象数据流,开发者会发出某种调用来访问DOM。这种调用的目的是将新内容“重写”或者“重填”入DOM中,可以调用eval()这个定制功能,也可以使用document.write()。如果这些调用是在不受信任信息流上进行的,浏览器就有可能由于DOM的操作漏洞而受攻击。攻击者可以用很多document.*()调用来向DOM环境中注入XSS。

    例如,这段JavaScript代码:Document.write(product-review)。
    在这里,“Product-review”是从第三方blog上获得的变量。如果它含有JavaScript会怎样?答案很明显。这个JavaScript就会被浏览器运行。


    6)跨域访问和回调
    Ajax不能从浏览器跨域访问。所有比较流行的浏览器都有个安全特性,那就是拦截跨域访问。一些网站服务为对象序列提供回调功能。开发者可以使用这个功能来把网站服务整合到浏览器本身。人们可以把该功能名传回,这样浏览器一找到回调对象数据流,它就会被浏览器中早已有的特殊功能名执行。
    这个回调对使用浏览器内认证的开发者来说是个额外负担。如果输入的对象数据流未经浏览器认证那么终端客户端就会成为跨域攻击的目标。不管是有意还是无意的,跨域服务可以向浏览器中注入恶意内容。该跨域调用在当前DOM环境中运行,于是导致当前对话也易受攻击。在实现应用之前,人们需要仔细检查整个跨域功能。
    7RSSAtom注入
    联合的反馈,RSS以及Atom,是最普遍的一种将站点更新信息传到网络上的方法。许多新闻,博客,门户站点等等,都在网络上共享多个反馈。反馈是标准的XML文档,并且可以被任何程序接收。Web2.0应用使用窗口小部件或者浏览器内部元件整合了联合反馈。这些组件调用Ajax来访问反馈。
    这些反馈可以被终端用户方便地选择。一旦用户选择了它们,这些反馈就会被解析并注入到DOM中。那么如果这个反馈在注入之前没有被适当地认证过,就会出现一些安全问题。人们可以往浏览器中注入恶意链接或者JavaScript代码。注入之后,最终结果是XSS和对话被黑客拦截。
    8)单击炸弹
    Web2.0应用可能不会很简单地就被黑客攻下,但他们可以对它进行基于事件的注入。人们可以将带有"onclick"字样的恶意链接用JavaScript注入。这样,浏览器就带着个随时等待终端用户右键点击来触发的炸弹。一旦用户点击了链接或按钮,能够启动炸弹的那个事件被启动了,那么攻击就成功了。此类攻击会导致对话被恶意代码拦截。
    这也是由于人们从那些没有经过正确验证的不受信任源处获得的信息,所导致的安全漏洞。为了利用该安全漏洞,它需要终端客户端触发一个事件。这个事件也许是诸如点击按钮或者链接的这种无害事件,但是点击后就使会用户损失惨重。它可能引起某个恶意事件,将当前对话信息发送给目标,又或者在当前浏览器环境中执行一系列脚本攻击。
    (9) 基于Flash的跨域访问
    黑客们可以使用Flash插件的Ajax接口,从而用浏览器中的JavaScritps发出GET和POST请求。这个接口使黑客们能进行跨域调用。为了避免安全问题,该Flash插件实现了根据策略访问其他域的功能。该策略可以通过在域的根部放置crossdomain.xml文件来配置。如果放置的文件配置不当——很普遍的现象——它就可能允许跨域访问。下面是一个配置不当的XML文档:
    现在可以从浏览器自身发出跨域调用了。这个结构还有一些其他安全问题。基于Flash的丰富网络应用(RIA)如果配置错误的话,很容易由于Ajax的跨域访问Bug而被攻击。
    (10) XSRF
    跨域伪造请求(XSRF)是个老牌的攻击向量了,它迫使浏览器向不同的域发出HTTP GET或者POST请求;这些请求可以跨域在运行的应用逻辑中启动某种事件。它可能请求修改密码或者电子邮件地址等。浏览器调用它后,它重放cookie并获得身份认证。这就是该请求的关键部分。如果某个应用只根据cookie来判识身份,那么该攻击就会成功。
    Web2.0中Ajax是就XML-RPC,SOAP或者REST与后端网络服务进行对话的,通过GET和POST可以进行这些调用。换句话说,人们可以对这些网络服务进行跨站点调用,从而危及受害者与网络服务接口的身份信息。XSRF这个攻击向量很有趣,它在这个新界定的端点情况中创造了新的层次。这些终点可能是为Ajax或者网络服务而准备的,但它们也有可能被跨域请求所激活。
    对安全漏洞的攻击以及相应对策
    Web2.0应用有多个终端点;每个点都是威胁的侵入点。为了保证安全,我们应当保护好所有这些点。在将第三方信息发送给客户端之前要对其进行彻底处理。
    为了处理Ajax序列,必须在它们到达DOM之前对输入数据流进行验证。XML解析以及跨域安全问题也需要额外重视,并实施更好的安全管理措施。我们应当遵循那个最简单最笨拙的原则:不让未经认证的跨域信息进入浏览器。有趣的是,到目前为止,安全专家们都不主张使用客户端脚本来进行输入验证,因为这很容易被规避掉。
    Web2.0促成了很多浏览器安全相关的新的漏洞。利用这些安全漏洞很难但不是不可能。安全问题以及促成因素结合起来将严重影响那些大的网络团体,比如能被攻击者蠕虫和病毒利用的那些组织。最终将导致身份信息的泄漏。

    安全总结:
    以上简单讲了一些可能出现的关于Ajax漏洞。还有很多其他潜在的漏洞,比如利用跨域代理来在浏览器中建立单项通道或者存储变量。
    Web2.0中很多逻辑都转到了客户端。这会将整个应用暴露给一些严重的威胁。对整合来自多方的、不受信源的数据的迫切要求也将全面增加风险向量:XSS,XSRF,跨域问题以及客户端上的序列,还有不安全的网站服务,服务器端的XML-RPC和REST访问。相反地,Ajax可被用来构造优美的无缝数据整合。但是,任一不安全的调用或者信息流都会使其产事与愿违的效果,从而促成可被利用的安全漏洞。因此服务器结合网络整体安全防护是开展工作业务的先决条件。


    瑞星客户服务中心

    企业网络安全顾问张 劲