摘要：在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这些漏洞类似的问题，如IBMWebsphereApplicationServer3.0.21、BEASystemsWeblogic4.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

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的唯一功能就是将请求导向一个自定义的类似404notfound的出错页面，不同的服务器设置的地方也不同。

如果没有使用任何静态页面或图像，可以配置一个默认的servlet，并将"/"映射到这个默认的servlet。这样当收到一个未映射到某个servlet的URL时，这个默认的servlet就会被调用。在这种情况下，默认的servlet可以仅仅返回"未找到文件"。如果使用了静态的页面或图像，仍然可以作这样的配置，但是需要让这个默认的servlet处理对合法的静态页面和图像的请求。

另一种可能就是将*.jsp+、*.jsp.和*.jsp等映射到一个servlet，而该servlet只是返回"未找到文件"。对于*.jsp%00和*.jsp%20这样的情况，映射应以未经编码的形式输入。例如，对于*.jsp%20的映射应输入"*.jsp"。注意%20被转换成一个空格字符。

3．2插入特殊字符串引起JSP源代码暴露

插入特殊字符串引起的漏洞有很多，例如BEAWebLogicEnterprise5.1中，文件路径开头为"/file/"的漏洞、IBMWebSphere3.0.2中"/servlet/file/"文件开头漏洞等等。

如果在IBMWebSphere3.0.2中的一个请求文件的URL为"login.jsp":http://site.running.websphere/login.jsp，那么，用户在访问http://site.running.websphere/servlet/file/login.jsp时将看到这个文件的源代码。

原因是由于IBMWebSphere3.0.2是调用不同的servlets对不同的页面进行处理，如果一个请求的文件是未进行注册管理的，WebSphere会使用一个默认的servlet调用。如果文件路径以"/servlet/file/"作开头这个默认的servlet会被调用这个请求的文件会未被分析或编译就显示出来。

3.2.1解决方法

在服务器软件的网站下载最新的补丁。

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并设置Denyfromall等属性。

另一种解决方法就是在每个重要目录下添加一个默认起始页面如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:webappfadssad.jsp(???????????)这样的错误，这样就可以知道你网站在c:webapp目录下，也许一般人不太在意，但是对于一个黑客来说足够了。

原因是由于负责JSP执行的相关Servlet中处理异常的时候没有过滤掉这种情况。

3.4.1解决方法

对于因为文件不存在引起的绝对路径暴露问题，有两种解决方法。一种方法是下载最新的补丁。另一种方法是找到服务器软件的JSP执行映射Servlet文件(当然是class后缀的)，将它用软件反编译，在反编译后的源代码中找到处理Eception的方法，然后将方法中的处理部分全部注释掉，并将请求导向到一个自定义的出错页面中，这样问题就解决了。

结束语

通过上面内容我们可以看出，JSP还是存在着很多安全上的问题的，客观的说，服务器软件的开发商在内部测试中不可能将系统中的所有BUG找出来，即使发布了软件后，被发现的漏洞也只会是其中的很小一部分，将来还会不断的有新的安全问题出现，所以我们必须时刻提高警惕，并注意自己网站的安全。

参考文献

Bergsten著，《JSP设计》，中国电力出版社

http://www.99net.net

http://www.mhdn.net