【ACCESS精品源码栏目提醒】:网学会员鉴于大家对ACCESS精品源码十分关注,论文会员在此为大家搜集整理了“企业网站安全防护规划方案_精品 - 实施方案”一文,供大家参考学习
企业网站安全防护规划方案 用 IISASP 建网站的安全性分析: 随着 Internet 的发展,Web 技术日新月异,人们已经不再满足于静态 HTML技术,更多的是要求动态、交互的网络技术。
继通用网关接口(CGI)之后,微软推出的 IISASP 的解决方案作为一种典型的服务器端网页设计技术,被广泛应用在网上银行、电子商务、网上调查、网上查询、BBS、搜索引擎等各种互联网应用中。
与此同时,
Access 数据库作为微软推出的以标准 JET 为引擎的桌面型数据库系统,由于具有操作简单、界面友好等特点,具有较大的用户群体。
目前,IISASPAccess 是中小型 Internet 网站的首选方案。
但是,该解决方案在为我们带来便捷的同时,也带来了严峻的安全问题。
安全隐患分析: IISASPAccess 解决方案的主要安全隐患来自
Access 数据库的安全性,其次在于 ASP 网页设计过程中的安全意识和措施。
数据库可能被下载 在 IISASPAccess 网站中,如果有人通过各种方法获得或者猜到数据库的存储路径和文件名,则该数据库就可以被下载到本地。
例如:对于网上书店数据库,一般命名为 book.mdb、store.mdb 等,存储路径一般为“URL/database”或放在根目录“URL/”下,这样,任何人敲入地址:“URL/database/store.mdb”, 数据库就可以被下载了。
数据库可能被解密 由于
Access 数据库的加密机制比较简单,即使设置了密码,解密也很容易。
该数据库系统通过将用户输入的密码与某一固定密钥(例如:
Access 97 为 86 FBEC 37 5D 44 9C FA C6 5E 28 E6 13)进行“异或”来形成一个加密串,并将其存储在.mdb 文件从地址“H42”开始的区域内。
我们可以轻松地编制解密程序,一个几十行的小程序就可以轻松地获得任何
Access 数据库的密码。
因此,只要数据库被下载,其信息就没有任何安全性可言了。
ASP 页面的安全性 (1)源代码安全性隐患。
由于 ASP 程序采用非编译性语言,大大降低了程序源代码的安全性。
如果黑客侵入站点,就可以获得 ASP 源代码;同时对于租用服务器的用户,因个别服务器出租商的职业道德问题,也会造成 ASP 应用程序源代码泄露。
(2)程序设计中容易被忽视的安全性问题。
ASP 代码使用表单实现交互,而相应的内容会反映在浏览器的地址栏中,如果不采用适当的安全措施,只要记下这些内容,就可以绕过验证直接进入某一页面。
例如在浏览器中敲入“...page.aspx1”,即可不经过表单页面直接进入满足“x1”条件的页面。
因此,在验证或注册页面中,必须采取特殊措施来避免此类问题的产生。
提高 IISASP 网站安全性的方法 防止数据库被下载 由于
Access 数据库加密机制过于简单,有效地防止数据库被下载,就成了提高 ASPAccess 解决方案安全性的重中之重。
以下两种方法简单、有效。
(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 inputfileoutputfile其中:/s 是屏蔽屏幕输出;/f 指定输出文件是否覆盖同名输入文件;/xl 指是 /l否在.asp 文件的顶部添加Language 指令; defLanguag 指定缺省的脚本语言/e defExtension 指定待加密文件的扩展名。
注册验证 为防止未经注册的用户绕过注册界面直接进入应用系统,我们采用 Session对象进行注册验证。
例如,我们制作了下面的注册页面。
设计要求注册成功后系统启动 hrmis.asppage1 页面。
假设,不采用 Session对象进行注册验证,则用户在浏览器中敲入“URL/hrmis.asppage1”即可绕过注册界面,直接进入系统。
网站入侵与防御: JavaScript 包含的 Ajax 是 Web2.0 应用的一个重要组成部分。
该部分的进化发展使网络变成了超级平台。
该转变同时也催生了新品种的病毒和蠕虫,比如YamannerSamy 以及 Spaceflash 等等。
GoogleNetflixYahoo 以及 MySpace等门户网站在过去的几个月里都因为新的漏洞而蒙受一定损失。
黑客们可以利用这些漏洞进行钓鱼,跨站点脚本XSS以及跨站点伪造XSRF请求等攻击。
Ajax 中没有固有的安全漏洞,但是对该技术向量的适配显著地改变了网络应用的开发途径以及方法论。
以前,DCOM 和 CORBA 组成核心中间件层的时候,将数据和对象序列化非常困难。
Ajax 使用简单的 GETPOST 或者 SOAP 调用,来转换XMLHTMLJS ArrayJSONJS Objects 以及其他定制的对象;全部这些操作都不需要调用中间件层。
Ajax 的这种综合能力使应用服务器与浏览器之间的数据交换非常流畅。
从服务器端传来的信息动态地被注入到当前的 DOM 相关环境,然后浏览器的 DOM 状态重置。
在讲安全漏洞之前,我们先来看看促成 Web2.0 漏洞的关键因素。
多重分散的终端点以及隐藏调用——Web2.0 应用与 Web1.0 的主要区别就是信息访问机制的区别。
比起它的前身 Web1.0 Web2.0 应用有数个 Ajax 终点。
潜在的Ajax 调用分散于整个浏览器页面,并且能够被各个事件分别调用。
开发者很难应付 Ajax 调用的这种分散性,并且由于这些调用是隐藏的,不那么明显,它还可能导致代码不规范。
认证混乱——输入和输出内容认证是应用的重要因素之一。
Web2.0 应用使用桥,mashups还有反馈等等。
很多情况下,它假定“另一方”(读取服务器端或者客户端代码)已经实现了认证,这种混乱就导致了双方都没有实现适当的认证控制。
不受信任的信息来源——Web2.0 应用从很多不受信任的来源比如反馈,博客,搜索结果中获得信息。
这些内容在提供给终端浏览器之前从来没有被认证,这就有可能引发跨站点攻击。
黑客还有可能在浏览器中加载 JavaScript,以便迫使浏览器发出跨域的调用并打开安全漏洞。
那样的话,这些致命的漏洞就能被病毒和蠕虫利用。
数据序列化——浏览器可以调用 Ajax 来实施数据序列化。
它可以获取 JSarrayObjectsFeedsXML 文件,HTML 块以及 JSON。
如果这些序列块中的某一个被解析并修改了,黑客们就可以强迫浏览器执行恶意脚本。
不受信任信息与数据序列化的结合,对终端用户的安全是致命的。
动态脚本构成和执行——Ajax 会建立一个后端通道,从服务器获取数据,然后将它传送给 DOM。
实现这一点的必要条件就是动态地执行 JavaScripts,以便随时更新 DOM 或者浏览器页面缓存的状态。
Ajax 通过调用定制的功能或者 eval功能。
未经认证的内容或者使用不安全的调用,轻则导致会话内容泄露,重则迫使浏览器执行恶意内容等各种后果。
Web2.0 应用可能因为上面提到的 1 个或多个失误而变得易受攻击。
如果开发者不够审慎,没有花心思在安全管理上的话,那么服务器和浏览器端都会出现安全问题。
以下是 10 个可能的安全漏洞的简要说明。
(1)畸形的 JS 对象序列JavaScript 支持面向对象编程OOP技术。
它有很多不同的内置对象,也允许用户自己创建对象。
使用者可以用 new object 或者自己编辑如下代码来创建新的对象。
message from : johnexample.com to : jerryvictim.com subject : I am fine body : Long message here showsubject : functiondocument.writethis.subject 这是一个简单的消息对象,其中有 2 个字段需要电子邮件地址。
我们可以使用Ajax 来将该对象序列化并用 JavaScript 代码编译。
程序员可以将它赋值到变量或者 eval。
如果攻击者发送嵌入了脚本的恶意“主题”,那么读者就将成为跨站点脚本攻击的受害者。
JS 对象既包含数据也包含方法。
对 JS 对象序列的不当使用将产生可以被诡计多端的注入代码利用的安全漏洞。
2JSON 对注入JavaScript 对象符号JSON是一个简单而有效的少量数据交换格式,它包含对象,数组,Hash 表,向量以及列表数据结构。
JavaScript Python C C C和 Perl languages 都支持 JSON。
JSON 序列在 Web2.0 应用中是个非常有效的交换机制。
开发者频繁使用 Ajax 和 JSON,获取并传送必要的信息给 DOM。
下面是个简单的带有不同的 name 值对的 JSON 对象:“bookmarks”对象。
bookmarks:Link:www.example.comDesc:Interesting link黑客们可以在 Link 或者 Desc 中注入恶意脚本。
如果 DOM 和可执行程序被注入了,XSS 目录也会被注入。
这是使终端用户感染恶意内容的另一种方法。
3JS 数组中毒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 块来自运行在 SOAPREST 或者XML-RPC 的网络服务。
这些网络服务是由从第三方的代理桥那里接收过来的。
如果这些第三方 XML 数据流被攻击者修改过,那么攻击者就可能向其中注入恶意内容。
浏览器从它自带的 XML 解析器接收该数据流。
该解析器容易受不同的 XML 炸弹的攻击。
人们也可以在该数据流中注入脚本,这样就可以导致跨站点脚本攻击XSS。
浏览器接收未经认证的 XML 数据流的话,这就会危及终端客户端的安全。
5DOM 中脚本注入前四个漏洞都是由于序列化问题引起的。
一旦浏览器收到序列化的对象数据流,开发者会发出某种调用来访问 DOM。
这种调用的目的是将新内容“重写”或者“重填”入 DOM 中,可以调用 eval这个定制功能,也可以使用document.write。
如果这些调用是在不受信任信息流上进行的,浏览器就有可能由于 DOM 的操作漏洞而受攻击。
攻击者可以用很多 document.调用来向 DOM环境中注入 XSS。
例如,这段 JavaScript 代码:Document.writeproduct-review。
在这里,“Product-review”是从第三方 blog 上获得的变量。
如果它含有 JavaScript 会怎样?答案很明显。
这个 JavaScript 就会被浏览器运行。
(6)跨域访问和回调Ajax 不能从浏览器跨域访问。
所有比较流行的浏览器都有个安全特性,那就是拦截跨域访问。
一些网站服务为对象序列提供回调功能。
开发者可以使用这个功能来把网站服务整合到浏览器本身。
人们可以把该功能名传回,这样浏览器一找到回调对象数据流,它就会被浏览器中早已有的特殊功能名执行。
这个回调对使用浏览器内认证的开发者来说是个额外负担。
如果输入的对象数据流未经浏览器认证那么终端客户端就会成为跨域攻击的目标。
不管是有意还是无意的,跨域服务可以向浏览器中注入恶意内容。
该跨域调用在当前 DOM 环境中运行,于是导致当前对话也易受攻击。
在实现应用之前,人们需要仔细检查整个跨域功能。
(7)RSS 和 Atom 注入 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-RPCSOAP 或者 REST 与后端网络服务进行对话的,通过GET 和 POST 可以进行这些调用。
换句话说,人们可以对这些网络服务进行跨站点调用,从而危及受害者与网络服务接口的身份信息。
XSRF 这个攻击向量很有趣,它在这个新界定的端点情况中创造了新的层次。
这些终点可能是为 Ajax 或者网络服务而准备的,但它们也有可能被跨域请求所激活。
对安全漏洞的攻击以及相应对策Web2.0 应用有多个终端点;每个点都是威胁的侵入点。
为了保证安全,我们应当保护好所有这些点。
在将第三方信息发送给客户端之前要对其进行彻底处理。
为了处理 Ajax 序列,必须在它们到达 DOM 之前对输入数据流进行验证。
XML 解析以及跨域安全问题也需要额外重视,并实施更好的安全管理措施。
我们应当遵循那个最简单最笨拙的原则:不让未经认证的跨域信息进入浏览器。
有趣的是,到目前为止,安全专家们都不主张使用客户端脚本来进行输入验证,因为这很容易被规避掉。
Web2.0 促成了很多浏览器安全相关的新的漏洞。
利用这些安全漏洞很难但不是不可能。
安全问题以及促成因素结合起来将严重影响那些大的网络团体,比如能被攻击者蠕虫和病毒利用的那些组织。
最终将导致身份信息的泄漏。
安全总结:以上简单讲了一些可能出现的关于 Ajax 漏洞。
还有很多其他潜在的漏洞,比如利用跨域代理来在浏览器中建立单项通道或者存储变量。
Web2.0 中很多逻辑都转到了客户端。
这会将整个应用暴露给一些严重的威胁。
对整合来自多方的、不受信源的数据的迫切要求也将全面增加风险向量:XSSXSRF跨域问题以及客户端上的序列,还有不安全的网站服务,服务器端的XML-RPC 和 REST 访问。
相反地,Ajax 可被用来构造优美的无缝数据整合。
但是,任一不安全的调用或者信息流都会使其产事与愿违的效果,从而促成可被利用的安全漏洞。
因此服务器结合网络整体安全防护是开展工作业务的先决条件。