IT运维管理,创造商业价值!
中国IT运维网首页 | 资讯中心 | 运维管理 | 信息安全 | CIO视界 | 云计算 | 最佳案例 | 运维资源 | 专题策划 | 知识库 | 论坛

变得更加糟糕的Java安全问题

2007年05月16日
赛迪网安全社区/lvvl

一年前的Javaone上,Fortify 软件公司的创始人 和首席科学家Brian Chess做了一个题为“12个Java技术安全陷阱和如何避免它们”的演讲。

一年后,我们在解决那些固有的弱点,包括XSS,跨平台脚步,SQL注入,以及允许导入c或者c++代码的本地方法上——还有伴随它们的BUG上,有何长进呢?毫无进展——除非你认为后退也是一种进展的话。

情况变得更糟了,Chess在eweek的采访中说,“我有证据证明这一点。”

Fortify作为原代码分析技术的销售商,它有个常见Java编程错误和弱点的大数据库,不仅是从它的客户那里收集来的,还有Java Open Review项目运行一年以来的收集到的。

在那个项目中,Fortify使用了findBUGs,这是一个静态分析工具,可以寻找Java代码中的BUG,查看开源项目中的代码,例如Apache, Azureus 和Tomcat。Fortify对每个受到怀疑的代码集进行分析,在线发布它找到的问题,然后将其与项目维护者共享弱点的细节。

那么Fortify从运行的项目中找到的是否代表了开源代码的错误密度是“庞大的”,Chess说,他特别指出了去年Fortify检查的一个项目:Net Trust,每1000行代码中大约有12.215个错误。

“这对于名字里面带着一个‘可靠’字眼的项目来说是个巨大的数字,”Chess说。

足够讽刺的是,Net Trust 是Google的一个项目,用来创建一个针对单点登录和认证机制的安全机制。“但是他们是学生做的,所以代码不是很好,”Chess说。

Net Trust是众多显示Java安全陷阱的例子中的一个,尽管这件事情公布于众已经有一段时间了,但是它还是在继续诱惑更多的程序员将全部时间投入到这种语言的成长中来。

Java 专家 William Pugh同意Chess关于Java安全陷阱变得更糟的看法。“XSS正在逐渐成为一个非常大的问题,”他在Eweek的采访中说。“类似Fortify公司的工具集的工具可以寻找XSS的问题,但是要在你的代码中清除XSS(漏洞)是不容易的。我们看到的统计数字表明它正在成为Java应用程序中的最大的安全漏洞,如果不算所有的网络攻击的话,”他说。

Pugh是位于College Park的马里兰大学计算机科学系的教授,也是Fortify公司用在Java Open Review项目中的FindBUG的作者。

除了XSS之外,Pugh说人们在谈论Java安全的时候最经常说的另外2个问题通常就是不被信任的恶意代码和SQL注入。“在你运行Applet的时候……(问题是,)那些Applet能做什么?它们可以用任何方式修改你正在运行的程序的行为吗?”

“人们在服务器上运行原始材料,他们不运行不受信任的代码,”他说。“但是另一种受到更大关注的安全攻击类型是SQL注入……那些一直都是大问题。”

令问题更严重的是安全代码的教学在最好的情况下,也是良莠不齐的。

要解释安全编码指导的缺乏,Chess指出了他最近的发现,就是Java巨人,Sun公司,特别是Sun Servlet编程指导(Sun公司的将Java连接到网络上的最简单方法)中包含了跨网站脚本攻击的内容。

一个关于XSS弱点的例子就是来自Sun的指导中的这些代码:

try { firstname = request.getparameter("firstname"); } catch (exception
e) { e.printstacktrace(); }
username = firstname;
...
pw.print("
thanks for your feedback, " + username + "!
");

这个代码可以让攻击者向受害人浏览器执行的应用程序中注入代码,Chess说。

“这些代码期望拥护可以输入类似bob的名字,”Chess在一封电子邮件中写道。“但是攻击者可以输入一些内容,让数据看起来这个样子: ,然后受害人的浏览器就开始执行一个名为senddatatomothership()的函数。”

服务器端代码的安全版本,Chess说,应该对输入进行检查,确保它只包含所期望的字符,没有可执行的脚步。

“SQL注入问题仍然稳坐Java安全陷阱列表的头把交椅,”他说。“开发人员们信任他们不应该信任的输入。”

如果这些问题来自Sun,那么我们还能信任谁?“你将会看到,指导手册从未提到过安全措施,”Chess说。“记住这一点,那么指导手册中包含跨网站脚本攻击漏洞就一点也不令人惊奇了。”

问题是Java——以及其他网络编程语言——都把XSS列为“确实容易犯的错误,”他说。“想想写出来的最简单的网页:当你构建Java网络语言程序的时候最先做的事情。你输入你的名字,然后它输出你好,brian。Java提供的实现‘你好,世界’功能的函数就允许XSS。”

构建到Java语言的网络框架也容易在Java代码中写入XSS漏洞,他说。

“比这更糟的是,当我们开始教人们如何编写Java代码的时候,我们给他们的是带有XSS漏洞的代码范例,”他说。

正如它现在承担的,注意最常见的Java安全陷阱的责任完全在开发人员身上。

那么这种情况是否可以得到矫正?可以,但是没有那么容易,Chess说。朝着解决方案前进的一个步骤就是修改浏览器,让XSS更坚固。所要做的就是改变网络标准,并且让所有的浏览器巨人——微软,Mozilla,和苹果——签署协议。

即使是有人去和他们说要进行这样的计划,仍然需要向数百万的用户推出一个新的浏览器“我们能够改变得最快的,也需要数年时间,”Chess说。“改变框架或者语言的基础结构,确实需要很长一段时间。”

XSS理应受到如此抨击的原因就是,这种情况越来越类似于10年的缓冲器溢出的情况了。这两个安全漏洞对于攻击者来说都是如此强大,Chess说,因为它可以为攻击者提供向系统中注入代码并且提供彻底的接管。

缓冲器溢出之所以成为这样的一个问题的原因是C和C++框架让它们很容易创建,他说。原来发生在缓冲器溢出,现在是发生在XSS身上。

尽管它们之间的区别在于缓冲器溢出是很难被探测的,Chess说,它需要攻击者相当了解系统的体系结构,以及在这台机器上的情况。“XSS漏洞则很容易探测,”他说。“只要到你当地的书店去,买一本有关Javascript的书,你就可以在XSS上开始了。”

尽管情况并不好,但是也不是你垂头丧气的时候。Fortify已经看到了开源项目中的开发人员毫无疑问正在努力阻止XSS。这样的项目可能还会有一些XSS漏洞,但是相比较那些数字为50的,无能的开发人员所进行的类似规模的项目,情况已经好很多。

“我们看到,当开发人员将注意力放在上面的时候,他们就可以将它们的数字降低,”Chess说。

然而,Chess说, Fortify还没有看到开发人员觉醒,开始在Java代码编写过程中采用安全措施的翻天覆地的变化。除了依赖那些开发人员之外,一种更有效的方式就是与框架的所有人和软件制造商讨论,让他们看看,要使网络变成一个更加安全的编程的所在,还能够做些什么,Chess说。然而,这也不是一朝一夕可以纠正的。

“还有很长的路要走,”他说。

发表评论请到:http://bbs.cnitom.com

相关阅读

图文热点

Power架构产品创新 IBM推动其本土化发展
Power架构产品创新 IBM推动其本土化发展自从1990年,IBM推出基于RISC系统的新产品线RS/6000(现称eServer p系列)之后,...
WAF:高校Web应用安全守护者
WAF:高校Web应用安全守护者最近几年高校网站被攻击的事件时有发生,造成了不良影响,因此越来越多的高校开始...

本类热点