设计差异引发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的安全性不完美,但是由于其易用性,许多组织和公司都仍然愿意使用它。

 

目录
相关文章
|
1月前
|
存储 前端开发 安全
如何确保前端框架数据驱动方式的数据加密存储的兼容性?
确保前端框架数据驱动方式的数据加密存储的兼容性需要综合考虑多个因素,通过充分的评估、测试、关注和更新,以及与其他技术的协调配合,来提高兼容性的可靠性,为用户提供稳定和安全的使用体验。
37 2
|
4月前
|
安全 关系型数据库 数据库
FastAPI数据库操作秘籍:如何通过高效且安全的数据库访问策略,使你的Web应用飞速运转并保持数据完整性?
【8月更文挑战第31天】在构建现代Web应用时,数据库操作至关重要。FastAPI不仅简化了API创建,还提供了高效数据库交互的方法。本文探讨如何在FastAPI中实现快速、安全的数据处理。FastAPI支持多种数据库,如SQLite、PostgreSQL和MySQL;选择合适的数据库可显著提升性能。通过安装相应驱动并配置连接参数,结合ORM库(如Tortoise-ORM或SQLAlchemy),可以简化数据库操作。使用索引、批量操作及异步处理等最佳实践可进一步提高效率。同时,确保使用参数化查询防止SQL注入,并从环境变量中读取敏感信息以增强安全性。
241 1
|
消息中间件 存储 数据可视化
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
136 1
|
消息中间件 设计模式 缓存
聊聊结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性
聊聊结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性
|
存储 缓存 Kubernetes
RPC框架设计的安全性考量
RPC里面该如何提升单机资源的利用率,你要记住的关键点就一个,那就是“异步化”。调用方利用异步化机制实现并行调用多个服务,以缩短整个调用时间;而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行,以提升单机的OPS。
499 0
|
存储 安全 网络安全
【可靠性工程】Microsoft 可靠性模式
【可靠性工程】Microsoft 可靠性模式
|
API UED
【可靠性工程】GCP 可靠性核心原则
【可靠性工程】GCP 可靠性核心原则
|
存储 监控 API
【可靠性工程】GCP 定义您的可靠性目标
【可靠性工程】GCP 定义您的可靠性目标
|
存储 SQL 缓存
【数据编制架构】Data Fabric 架构:优点和缺点
【数据编制架构】Data Fabric 架构:优点和缺点
|
安全 算法 网络协议