在JSP技术得到广泛应用的同时,由于源代码泄漏而引起的JSP安全性也受到了广泛的关注。本文分析了几种造成源代码泄漏的因素,并针对每种因素提出了各自的解决方法。
关键词:JSP 源代码 泄漏
引言
JSP编程语言自从推出之日起,由于他的快速、平台无关、可扩展、面向对象等特性得到了越来越广泛的应用,越来越多的厂家研发出了各种各样的支持平台如IBM 公司的WebSphere、BEA公司的WebLogic等等,也有越来越多的网站开始将自己的平台架构在JSP 环境中。
但是随之而来的就是一系列的安全问题,如源代码暴露漏洞、远程任意命令执行漏洞等等,一些用JSP做的网站,由于存在各种各样的漏洞,能够被黑客轻松的下载程式的源代码,对网站的安全构成威胁。
造成JSP源代码暴露的原因
服务器漏洞是安全问题的起源,黑客对网站的攻击也大多是从查找对方的漏洞开始的。所以只有了解自身的漏洞,网站管理人员才能采取相应的对策,阻止外来的攻击。
虽然JSP也是一种web编程语言,但是他和其他的web编程语言如PHP、ASP的工作机制是不相同的。
首次调用JSP文档其实是执行一个编译为Servlet的过程。试图下载JSP源代码的人(比如黑客)往往利用JSP的各种漏洞,让JSP文档在编译前被浏览器当作一个文本或其他文档发送给客户端,或在JSP装载的时候不去执行编译好的Servlet而直接读JSP的内容并发送给客户端,从而让源代码一览无余。
JSP源代码泄漏的几种类型
源代码暴露类别主要指的是程式源代码会以明文的方式返回给访问者.
我们知道不管是JSP还是ASP、PHP等动态程式都是在服务器端执行的,执行后只会返回给访问者标准的html 等代码。这是理论上的东西,实际运行起来由于服务器内部机制的问题就有可能引起源代码暴露的漏洞,简单的例子是只要在程式文档名后加几个简单的字符就可能获得程式代码,如常见微软ASP 的global.asa+.htr、XXXX.asp%81等等漏洞。
3.1 添加特别后缀引起JSP源代码暴露
在JSP中也存在着和asp这些漏洞类似的问题,如IBM Websphere Application Server 3.0.21、BEA Systems Weblogic 4.5.1、Tomcat3.1等JSP文档后缀大写漏洞;JSP 文档后加特别字符如Resin1.2的%82、../漏洞;ServletExec的%2E、+漏洞、%2E、+、%2B、\ 、%5C、%20、%00 等。
黑客假如利用该漏洞,将导致泄露指定的JSP文档的源代码。例一:使用下面的任意一个URL请求将输出指定的JSP文档的源代码:
1)http://target/directory/jsp/file.jsp.
2)http://target/directory/jsp/file.jsp%2E
3)http://target/directory/jsp/file.jsp+
4)http://target/directory/jsp/file.jsp%2B
5)http://target/directory/jsp/file.jsp\
www.bitsCN.com
6)http://target/directory/jsp/file.jsp%5C
7)http://target/directory/jsp/file.jsp%20
8)http://target/directory/jsp/file.jsp%00
等等。
例二,在Tomcat3.1下,在浏览器中本来能够正常解释执行的是http://localhost:8080/inde.jsp,但是假如将inde.jsp改为inde.JSP或inde.Jsp等等试试看,您会发现浏览器会提示您下载这个文档,下载后源代码能够看个一干二净。
原因是JSP是大小写敏感的,Tomcat只会将小写的JSP后缀的文档当作是正常的JSP文档来执行,假如大写了就会引起Tomcat将inde.JSP当作是个能够下载的文档让客户下载。老版本的WebLogic、WebShpere等都存在这个问题,现在这些公司或发布了新版本或发布了补丁解决了这问题。
3.1.1 解决办法
解决这种由于添加后缀引起的源代码泄漏有两种方法,一种方法是在服务器软件的网站上下载补丁;另外一种方法是在服务器配置中添加一些映射如.JSP 、.Jsp、.jsp%2E等,将他们映射到一个自己写的servlet,这个Servlet的唯一功能就是将请求导向一个自定义的类似404 not found的出错页面,不同的服务器配置的地方也不同。
假如没有使用任何静态页面或图像,能够配置一个默认的 servlet,并将”/”映射到这个默认的 servlet。这样当收到一个未映射到某个 servlet 的 URL 时,这个默认的servlet 就会被调用。在这种情况下,默认的 servlet 能够仅仅返回”未找到文档”。假如使用了静态的页面或图像,仍然能够作这样的配置,但是需要让这个默认的servlet 处理对合法的静态页面和图像的请求。 中国.网管联盟
另一种可能就是将*.jsp+、*.jsp.和*.jsp\等映射到一个 servlet,而该servlet只是返回”未找到文档”。对于*.jsp%00和*.jsp%20这样的情况,映射应以未经编码的形式输入。例如,对于*.jsp%20的映射应输入”*.jsp “。注意%20被转换成一个空格字符。
3.2 插入特别字符串引起JSP源代码暴露
插入特别字符串引起的漏洞有很多,例如BEA WebLogic Enterprise 5.1中,文档路径开头为 “/file/” 的漏洞、IBM WebSphere 3.0.2中”/servlet/file/”文档开头漏洞等等。
假如在IBM WebSphere 3.0.2中的一个请求文档的 URL 为”login.jsp”:http://site.running.websphere/login.jsp,那么,用户在访问http://site.running.websphere/servlet/file/login.jsp 时将看到这个文档的源代码。
原因是由于IBM WebSphere 3.0.2是调用不同的 servlets 对不同的页面进行处理,假如一个请求的文档是未进行注册管理的,WebSphere 会使用一个默认的 servlet 调用。假如文档路径以”/servlet/file/”作开头这个默认的 servlet 会被调用这个请求的文档会未被分析或编译就显示出来。
3.2.1 解决方法
在服务器软件的网站下载最新的补丁。 bitsCN.nET中国网管博客
3. 3 路径权限引起的文档JSP源代码暴露
这种漏洞在正常的JSP漏洞中没有反映出来,但是我们知道,大部分的JSP应用程式在当前目录下都会有一个WEB-INF目录,这个目录通常存放的是JavaBeans编译后的class 文档,假如不给这个目录配置正常的权限,任何的class就会曝光。
也许有人认为class是经过编译的,就算被下载也没有什么关系,但是现在class 反编译为java代码的软件也很多,采用反编译软件对下载的class文档反编译后,和原始的java文档几乎一模相同,连变量名都没有变,还能够正常使用。
更大的安全问题是,有的软件研发人员把数据库的用户名密码都写在了java代码中,现在一反编译谁都能看到数据库的重要信息。通过数据库的远程连接功能,能够轻松的进入到数据库中,任何信息将全部被别人掌控。
3.3.1 解决方法
有一个方法能够有效地解决由于路径权限引起的代码泄漏问题,就是将ASP程式单独放置一个目录,配置该目录上的用户权限只能执行不能读取。在JSP环境下同样能够通过配置服务器的环境来解决这个问题:将一些比较重要的目录如WEB-INF、classes等配置上访问的权限,不允许读而取只允许执行。以Apache 下解决为例,能够在httpd.conf文档中添加一目录WEB-INF并配置Deny from all等属性。
中国.网管联盟
另一种解决方法就是在每个重要目录下添加一个默认起始页面如index.htm等,这样读取目录就会返回给访问者这个文档而不是其他了。
相比较而言,建议采用第一种方法。
更为重要的是密码的保存问题,在ASP 研发中,能够将密码文档保存在系统目录如WINNT 下,然后用一个com来读取这个文档,这样就算看到了ASP源代码也不知道数据库信息了。在JSP中我们也能够写一个property文档,放置在WINNT系统目录下,然后用Bean来读取数据库信息,这样通过源代码知道了数据库信息存在WINNT中的.property文档里面,但也很难访问他,这样就算源代码被人知道起码数据库是安全的。
3. 4 文档不存在引起的绝对路径暴露问题
这个问题现在已出现了很多,因为微软IIS 中也有比较多的类似问题,如微软IIS5.0中的*.idc暴露绝对路径漏洞。同样的这些问题现在出现在JSP环境中,这个漏洞暴露了web程式的绝对硬盘地址,和其他漏洞结合就具备比较大的危害了。
例如:在特定的服务器软件下,访问一个不存在的JSP文档如 <http://localhost:8080/fdasfas.jsp>,就会返回java.servlet.ServletEception: java.io.FileNotFoundEception: c:\web\app\fadssad.jsp (???????????)这样的错误,这样就能够知道您网站在c:\web\app目录下,也许一般人不太在意,但是对于一个黑客来说足够了。
原因是由于负责JSP 执行的相关Servlet中处理异常的时候没有过滤掉这种情况。
3.4.1 解决方法
对于因为文档不存在引起的绝对路径暴露问题,有两种解决方法。一种方法是下载最新的补丁。另一种方法是找到服务器软件的JSP 执行映射Servlet文档(当然是class 后缀的),将他用软件反编译,在反编译后的源代码中找到处理Eception的方法,然后将方法中的处理部分全部注释掉,并将请求导向到一个自定义的出错页面中,这样问题就解决了。
结束语
通过上面内容我们能够看出,JSP还是存在着很多安全上的问题的,客观的说,服务器软件的研发商在内部测试中不可能将系统中的任何BUG找出来,即使发布了软件后,被发现的漏洞也只会是其中的很小一部分,将来还会不断的有新的安全问题出现,所以我们必须时刻提高警惕,并注意自己网站的安全。
今天的文章JSP中的源代码泄漏问题分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/33037.html