设计差异引发WebServices 安全性问题

简介: 【http://www.enet.com.cn/esoftware/  2007年08月21日15:48  来源:赛迪网  作者:Paul Korzeniowski/Kevin】   随着Web Services应用的发展,厂商们试图得出一套成型的方法来保证应用层信息安全。

http://www.enet.com.cn/esoftware/  2007年08月21日15:48  来源:赛迪网  作者:Paul Korzeniowski/Kevin】


  随着Web Services应用的发展,厂商们试图得出一套成型的方法来保证应用层信息安全。“厂商们已经开发了一整套标准来保护Web Services事务处理的安全”,Forrester研究中心的Randy Heffner说道。 


  最近,对WebServices的关注程度仍在提高,而事实上对Web Services的关注也有其理由,这种创建应用的新方法允许组织或者企业使用其内部系统与合作伙伴或者客户交换信息,给企业应用带来了很大的方便。 

  随着WebServices的潜在价值被越来越多的人意识到,这项应用也给许多公司带来了新的安全问题。“WebServices在传统的安全技术身上穿了洞”,Zap Think公司的高级分析师Jason Bloomberg形象地说道。 

  这些漏洞源于Web Services应用与传统应用在设计上的差异。传统应用在创建时即保证其运行时是“线性”的,即信息是按照有序的方式传播。大多数安全产品都在各种关键点上进行信息安全性检查。例如,防火墙被放置在网络边界上,保证只有被授权的用户才能进入企业网内部。Web Services出现以后,数据可以从不同的入口进入内部网络,也可以从不同的出口出去。因此,许多应用可以绕过网络上的安全信息检查。例如,HTTP协议使用80端口进行数据传输,可以绕过防火墙的安全检查(因为防火墙默认是开放80端口的)。因此,黑客可以使用这样众多的入口点,绕过安全性检查进入企业网内部,获得企业网的控制权限。 

  被新的攻击方式束缚 

  由于设计上的不同,Web Services应用带来了新的攻击类型,例如,恶意代码注入攻击,类似这种攻击很多,但是它们大都遵循一个原则:黑客把恶意代码附加在正常代码上,通过在输入域中输入,从而进入系统。 

  这种攻击手段在使用结构化查询语言SQL的数据库管理系统中尤其流行。另外,XML和轻量级目录访问协议LDAP(Lightweight Directory Access Protocol)在Web Services应用中被普遍使用,它们都容易进行恶意代码注入。例如,如果一个电子商务的XML应用没有验证它的信息发送目标的安全性,黑客就可能获得客户的敏感信息,诸如银行卡卡号、信用卡信息等。使用LDAP恶意代码注入,攻击者可以访问公共目录,访问客户的联系信息,诸如Email地址和个人住址等。 

  为了应对这样的攻击,公司不得不确保自己应用程序的安全性,而不是企业网络的安全。然而,大多数的安全工具不是这样设计的。公司往往有种错误的认识:他们使用了安全套接层协议(SSL)来加密点对点传输,就可以免受恶意代码的攻击。事实上,这并不是应对恶意代码注入攻击的有效方法。 

  准备新的套件 

  随着WebServices应用的发展,厂商们试图得出一套成型的方法来保证应用层信息安全。“厂商们已经开发了一整套标准来保护Web Services事务处理的安全”,Forrester研究中心的Randy Heffner说道。 

  这些成套的标准被称为WSS框架(Web Services Security framework),它能够保证SOAP传输的安全性,SOAP是目前最流行的一种Web Service协议。信息大都是使用HTTP协议传输,但原则上可以使用任何一种协议。WSS框架使得公司能够加密、签名和认证SOAP消息。 

  许多组织实现了这个层面上的安全性。“过去的几年,几乎所有的产品和开发工具都支持WSS”,Burton Group的副总裁Thomas Manes说道。 

  谁在另一端? 

  即使公司采取了这些措施,也仍然要面对安全漏洞。“现实是,公司需要一种方法知道Web Services事务处理的另一端是谁”,Heffner说道。 

  LibertyAlliance正致力于联合认证的研究,如果进行Web services通信的双方有同一种安全“信令”,一方就可以担保另一方的安全性。OASIS则致力于开发WS-Federation,它支持拥有不同类型的安全“信令”的双方的安全交易。 

  联合认证的研究正处于初期成型阶段,而且已经被许多公司的产品采用。目前的状况是:即使Web Services有安全漏洞,公司仍然通过配置使用它们。“有百分之六十的公司实现了自己的Web Services”,Zap Think的Bloomberg说道。 

  权衡风险vs. 酬劳 

  大概有三分之一的企业使用Web Services和第三方客户合作者或者供应商进行信息交换。“公司有时宁可冒一定的风险,因为他们相对确定连接的另一方是安全的。”Heffner解释道。 

  另外,黑客目前不会把注意力集中在Web Services应用上。尽管取了迅速的发展,Web Services应用的数量仍然相对比较少。所以,黑客们目前还是把精力放在了利用诸如微软Windows操作系统等应用广泛的软件产品的安全漏洞上。 

  尽管WebServices的安全性不完美,但是由于其易用性,许多组织和公司都仍然愿意使用它。

 

目录
相关文章
|
11月前
|
存储 SQL 缓存
【数据编制架构】Data Fabric 架构:优点和缺点
【数据编制架构】Data Fabric 架构:优点和缺点
|
11月前
|
存储 监控 API
【可靠性工程】GCP 定义您的可靠性目标
【可靠性工程】GCP 定义您的可靠性目标
|
11月前
|
API UED
【可靠性工程】GCP 可靠性核心原则
【可靠性工程】GCP 可靠性核心原则
|
11月前
|
存储 安全 网络安全
【可靠性工程】Microsoft 可靠性模式
【可靠性工程】Microsoft 可靠性模式
|
11月前
|
存储 缓存 Kubernetes
RPC框架设计的安全性考量
RPC里面该如何提升单机资源的利用率,你要记住的关键点就一个,那就是“异步化”。调用方利用异步化机制实现并行调用多个服务,以缩短整个调用时间;而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行,以提升单机的OPS。
323 0
|
存储 前端开发 区块链
分析:web3.0特性介绍以及系统开发合约技术详细方案
分析:web3.0特性介绍以及系统开发合约技术详细方案
|
前端开发 安全 测试技术
Web3 系统构建:去中心化的原则、模型和方法(下)
在上篇 Web3 系统构建:去中心化的原则、模型和方法(上)中,作者着重讲述了 Web3 系统设计面临的挑战以及如何使用 Web3 系统的组件实现去中心化。下篇将分析几种去中心化模式的实践。
200 0
Web3 系统构建:去中心化的原则、模型和方法(下)
|
存储 安全 测试技术
Web3 系统构建:去中心化的原则、模型和方法(上)
本文最初发布于a16z,由 InfoQ 中文站翻译并分享。
208 0
|
存储 缓存 监控
如何为从 1 到 10 万用户的应用程序,设计不同的扩展方案?
对于创业公司来说,有用户注册是好事情,但是当用户从零扩展到成千上万之后,Web 应用程序又该如何支持呢?
带你读《点石成金:访客至上的Web和移动可用性设计秘笈》之二:我们实际上是如何使用Web的
这是一本关于Web设计原则而不是Web设计技术的书。本书作者是Web设计专家,具有丰富的实践经验,他用幽默的语言为你揭示Web设计中重要但却容易被忽视的问题,只需几个小时,你便能对照书中讲授的设计原则找到网站设计的症结所在,令你的网站焕然一新。