JSP安全初探

 

JSP 和其它的 PHP 、 ASP 工作机制不一样，虽然它也是一种 web 编程语言。首次调用 JSP 文件其实是执行一个编译为 Servlet 的过程。注意我们就要在这上边做文章，明白吗？我们要干的事情是，让 JSP 在编译前被浏览器当作一个文本或其它文件发送给客户端，或在 JSP 装载的时候不去执行编译好的 Servlet 而直接读 JSP 的内容并发送给客户端。

　　明白了道理及所要达到的目的就好下手了，仔细观察调用及返回过程可以发现： JSP 被编译为了 Servlet 保存在指定的目录下，如: http : //www.x.com/lovehacker/index.jsp很可能存放在X:/IBM/WAServer/temp/default_host/ default_app/pagecompile/_lovehacker_index_xjsp.class，这是已经编译过的index.jsp。 _lovehacker_index_xjsp.class显然是我们不需要的文件，而且我们得到它的可能性也不大，我们要干的是不去执行 _lovehacker_index_xjsp.class而是直接读index.jsp的内容。

　　据分析最初的 xxx . JSP 暴露源代码也是因为前边的这种想法造成的，本来目录中存放了一个 _xxx_xjsp . class ，但访问 xxx . JSP 本来是个合法的请求，而又找不到对应的 Servlet 所以就把 xxx . JSP 当做一个文本或其它文件发送给了用户。

　　也许这是因为 IBM HTTP SERVER 配置不当造成的，但相信如果能成功的话，会有一种成就感，很爽的哦！

　　顺便说一下暴露文件存放真实路径可能会带来的危害：

　　 1 ．先会让入侵者了解磁盘配置情况
　　 2 ．明的入侵者甚至可以分析出管理员的水平高低
　　 3 ．为入侵者修改你的首页提供了方便（起码不用在找你的 WEB 目录在那个磁盘了）
　　 4 ．可能被利用一些其它的 CGI 的漏洞查找到 Web 目录下的文件如 XX . ASP 、 XX . JSP 、 XX . PHP 等

　　 JSP 安全问题主要有哪几方面？

　　本节重点在于对 jsp 安全问题进行分类阐述和提出解决的建议，所以每种类型的安全问题只采用了一个例子，对于其它各种漏洞的具体细节如涉及到何种软件版本何种操作系统等就不一一进行阐述了，有兴趣的读者可以到 jsp 爱好者( http : //jspbbs.yeah.net)或者国外的安全站点 (http://www.securityfocus.com)进行查看和参考。

　　根据目前已经发现的 jsp 安全问题，不妨将它们分为以下几类，源代码暴露类、远程程序执行类和其他类别, 下面来看看具体的东西吧。

　　一、源代码暴露类

　　源代码暴露类别主要指的是程序源代码会以明文的方式返回给访问者。
　　我们知道不管是 jsp 还是 asp 、 php 等动态程序都是在服务器端执行的，执行后只会返回给访问者标准的 html 等代码。这是理论上的东西，实际运行起来由于服务器内部机制的问题就有可能引起源代码暴露的漏洞，简单的例子只要在程序文件名后加几个简单的字符就可能获得程序代码，如常见微软 asp 的 global . asa +. htr 、 XXXX . asp % 81 等等漏洞。

　　 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 、+漏洞等等。

　　例子：举个老一点的 JSP 大写例子， Tomcat3 . 1 下在浏览器中本来是 http : //localhost:8080/inde.jsp，可以正常解释执行，但是如果将inde.jsp改为inde.JSP或者inde.Jsp等等试试看，你会发现浏览器会提示你下载这个文件，下载后源代码可以看个一干二净。

　　原因： jsp 是大小写敏感的， Tomcat 只会将小写的 jsp 后缀的文件当作是正常的 jsp 文件来执行，如果大写了就会引起 Tomcat 将 index . JSP 当作是一个可以下载的文件让客户下载。老版本的 WebLogic 、 WebShpere 等都存在这个问题，现在这些公司或者发布了新版本或者发布了补丁解决了这问题。

　　解决办法：一是在服务器软件的网站上下载补丁；因为作者以前用过 asp 一段时间，接触了很多 IIS 的漏洞，它的有效解决方法是去掉不必要的映射如 htr 、 htx 等，在 jsp 中我们同样可以参考 IIS 的解决方法，不同的是不是去掉而是添加映射，方法为在服务器设置中添加一些映射如. JSP 、. Jsp 、. jsp % 2E 等，将他们映射到一个自己写的 servlet ，这个 Servlet 的唯一功能就是将请求导向一个自定义的类似 404 not found 的出错页面，不同的服务器设置的地方也不同，请参考相应的文档。第二种解决方法可以在没有补丁的时候采用。

　　 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 ．路径权限引起的文件 jsp 源代码暴露

　　我们知道，大部分的 jsp 应用程序在当前目录下都会有一个 WEB - INF 目录，这个目录通常存放的是 JavaBeans 编译后的 class 文件，如果不给这个目录设置正常的权限，所有的 class 就会曝光。

　　例子：如果采用的是 Apache1 . 3 . 12 加上第三方 jsp 软件形式的 WEB 服务器，因为 Apache1 . 3 . 12 默认的设置是可以读取目录的，如果程序在 http : //site.running.websphere/login.jsp，只要修改一下http: //site.running.websphere/WEB-INF/所有这个目录下以及这个目录下的子目录中的class文件可以看个一干二净的，还可以下载到本机上。

　　也许有人会说 class 是经过编译的，就算被人下载也没有什么关系，但是现在 class 反编译为 Java 代码的软件也很多，有人曾经采用 JAD 软件对下载的 class 文件反编译了一下，居然和原始的 Java 文件几乎一模一样，变量名都没有变，更惊奇的是还可以重新编译为 class 文件正常使用。

　　安全问题更大的就是，网页制作者开始把数据库的用户名密码都写在了 Java 代码中，现在一反编译谁都能看到数据库的重要信息。通过数据库的远程连接功能，可以轻松的进入到你的数据库中，所有信息全部在他手中。附带说一句，如果用户能获得 SQL Server 的用户名口令，进入数据库中可以执行任意的 dos 命令如查看 c :/文件、建立和删除目录等，那样整个 Windows 系统都不安全了。

　　解决方法： IIS 以前一个有效地解决 asp 漏洞的方法，就是将 asp 程序单独放置一个目录，目录设置上用户权限只能执行不能读取。在 jsp 环境下同样可以通过设置服务器的环境来解决这个问题，简单的说，就是将一些比较重要的目录如 WEB - INF 、 classes 等设置上访问的权限，不允许读而取只允许执行。以 apache 下解决为例，可以在 httpd . conf 文件中添加一目录 WEB - INF 并设置 Deny from all 等属性。

　　另一种比较笨的解决方法就是在每个重要目录下添加一个默认起始页面如 index . htm 等，这样读取目录就会返回给访问者这个文件而不是其它了。建议采用的一种方法。

　　更为重要的是密码的保存问题。在 jsp 中可以写一个 property 文件，放置在 WINNT 系统目录下，然后用 Bean 来读取数据库信息，这样通过源代码知道了数据库信息存在 WINNT 中的. property 文件里面，但也很难访问它，这样就算源代码被人知道起码数据库是安全的。

　　 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 中处理异常的时候没有过滤掉这种情况。

　　解决方法：一是下载最新的补丁；如果当时的 web 服务器软件没有这个补丁，可以找到服务器软件的 jsp 执行映射 Servlet 文件(当然是 class 后缀的)，将它用 JAD 软件反编译，在反编译后的源代码中找到处理 Exception 的方法，然后将方法中的处理部分全部注释掉，并将请求导向到一个自定义的出错页面中，这样问题就解决了。

　　二、远程程序执行类

　　这类漏洞的特点就是可以通过 url 地址在浏览器中执行任意服务器上的命令和程序，从而引起安全问题。如 Allaire JRUN 2 . 3 远程执行任意命令漏洞、 iPlanet Web Server 4 . x 存在一个缓冲区溢出漏洞等等。
例子： Allaire 的 JRUN 服务器 2 . 3 上输入下面的 url 地址 http : //jrun:8000/servlet/jsp/../../path/sample.txt，可以访问到WEB目录以外的文件，如果是exe文件，还有可能会引起执行。

　　原因：如果 URL 请求的目标文件使用了前缀 "/servlet/" ，则 JSP 解释执行功能被激活。这时在用户请求的目标文件路径中使用 "../" ，就有可能访问到 WEB 服务器上根目录以外的文件。目标主机上利用该漏洞请求用户输入产生的一个文件，将严重威胁到目标主机系统的安全。

　　解决方法：安装最新的补丁。

　　三、其他类别

　　这些类别的范围就有点大了，可以包括数据库如 SQL Server 、 Oracle 、 DB2 等的漏洞，也可以包括操作系统如 WindowsNT / 2000 、 Linu 等的漏洞。这些东西的漏洞可以说都是致命的，如利用 Linux 的某些漏洞可以轻易获得管理员权限来远程控制服务器，获得系统的完全控制权限，这样要获得 jsp 源代码或者摧毁服务器比踩死一只蚂蚁还要轻松的多。

　　四、全文总结

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

　　一个好的建议就是多看安全文章，这些安全文章一般都会有详细的信息如软件的版本号、漏洞原因等等，最重要的是还附带了解决办法或者是补丁的下载链接，推荐的安全站点是国内的安全站点 www . cnns . net 或者国外的 http : //www.securityfocus.com站点；另外一个好的建议就是多装补丁程序，访问自己所使用的软件公司主页，从那上面获得最新的补丁程序，做得比较好的就是微软的站点，安全公告和补丁都特别及时。

　　最后想用一句话作为全文的结尾：一个优秀的黑客不一定是个好的 jsp 程序员，一个优秀的 jsp 程序员一定要是个好的准黑客。

　　哪些方式可实现 Java Servlet 及 JSP 的应用安全？

　　一个 web 应用程序可拥有多种资源，经常有许多敏感的信息在没有保护措施的情况下在开放性网络上传输。在这种环境下，实际上许多 web 应用程序有一定程度的安全性要求。大多数的 servlet 容器有明确的机制和结构来达到这种安全要求。虽然保证和执行的细节可能有些不同，但是，都具有下面的特点：

　　 1 ． Authentication ：通讯实体相互验证对方的行为是以一个明确的身份在进行的一种机制。
　　 2 ． Access control for resources ：对某组用户来说，对数据库的某些操作是受到限制的，或对有些程序强调可用性，完整性或保密性的一种机制。
　　 3 ． Data Integrity ：数据在传递过程中保证不被第三方修改的一种机制。
　　 4 ． Confidentiality or Data Privacy ：保证数据只被那些授权使用的用户使用，能被安全传递的一种机制。

　　 Java Servlet ， JSP 中安全性通过如下几种方式实现：

　　一、 Declarative Security

　　 Declarative security 指的是表达一个应用的安全结构，包括角色，存取控制，和在一个应用的外部表单所要求的验证。在 web application 中发布描述器是实施 declarative security 的一种主要的工具。

　　发布者把 application 所要求的逻辑完整性映射为在特定运行环境下的安全策略。在运行时， servlet container 使用这些策略来强迫验证。

　　二 、 Programmatic Security

　　当 declarative security 不能够完全表达一个 application 的安全模型时，就可以使用 programmatic Security 。 Programmatic Security 包括 HttpServletRequest 接口的下列方法：
　　 getRemoteUser
　　 isUserInRole
　　 getUserPrincipal

　　 getRemoteUser 方法返回经过客户端验证的用户名。 IsUserInRole 向 container 的安全机制询问一个特定的用户是否在一个给定的安全角色中。 GetUserPrinciple 方法返回一个 Java . security . Pricipal 对象。这些 APIs 根据远程用户的逻辑角色让 servlet 去完成一些逻辑判断。它也可以让 servlet 去决定当前用户的主要名字。如果 getRemoteUser 返回 null 值（这意味着没有用户被验证），那么 isUserInRole 就总会返回 false ， getUserPrinciple 总会返回 null 。

　　三 、 Roles

　　一个 Roles 就是由 Application Developer 和 Assembler 所定义的一个抽象的逻辑用户组。当一个 application 被发布的时候， Deployer 就把这些角色映射到在运行环境中的安全认证，例如组或规则。

　　一个 servlet container 能够为规则执行一些说明或编程安全，这些规则是与调用这些 principal 的安全属性所输入的要求相联系的。例如：

　　 1 ．当 deployer 把一个安全角色映射为操作环境下的一个用户组，调用 principle 所属的用户组就从安全属性中获得。如果 principle 的用户组与在操作环境下的用户组相匹配，那么 principle 就是一个安全角色。
　　 2 ．当 deployeer 把一个安全角色映射为一个在安全方针域中的 principle 名时，调用 principle 的确 principle 名就被从安全属性中提取出来。如果两者相同的话，调用的 principle 就是安全的。

　　四、 Authentication

　　一个 web 客端能够使用下面的一种机制来对 web 服务器验证一个用户。

　　 HTTP Digest Authentication
　　 HTTPS Client Authentication
　　 HTTP Basic Authentication
　　 HTTP Based Authentication

　　五、 HTTP Basic Authentication

　　 HTTP Basic Authentication 是一个定义在 HTTP / 1 . 1 规范中的验证机制。这种机制是以用户名和密码为基础的。一个 web server 要求一个 web client 去验证一个用户。作为 request 的一部分， web server 传递被称之为 realm 的字符串，用户就是在它里面被验证的。注意： Basic Authentication 机制的 realm 字符串不一定反映任何一种安全方针域。 Web client 得到这些用户名和密码，然后把它传递给 web server 。 Web server 然后在一个特定的领域验证这些用户。

　　由于密码是使用一种 64 位的编码来传递，而且目的 server 没有验证，所以 Basic Authentication 不是一种安全的验证协议。然而一些附加的保护像使用一种安全传输机制（ HTTPS ）或在网络层使用安全措施能够解决一些问题。

　　六、 HTTP Digest Authentication

　　与 HTTP Digest Authentication 一样， HTTP Digest Authentication 根据用户名和密码验证一个用户。然而密码的传输是通过一种加密的形式进行的，这就比 Basic Authentication 所使用的 64 位编码形式传递要安全的多。这种方法没有像 HTTPS Client Authentication 的个人密钥方案安全。由于 Digest Authentication 当前不被广泛使用， servlet containers 不要求支持它但是鼓励去支持它。

　　七、 HTTPS Client Authentication

　　使用 HTTPS （ HTTP over SSL ）的终端用户验证是一种严格非验证机制。这种机制要求用户去处理公共密钥证明（ Public Key Certification PKC ）。当前， PKCs 在 e - commerce 应用中是有用的。不适应 J2EE 的 servlet containers 不要求支持 HTTPS 协议。

　　八、 Server Tracking of Authentication Information

　　就像映射在角色中的安全标识一样，运行环境是环境的说明而不是应用的说明。

　　 1 ．在 web application 的发布环境创建一个登录机制和策略。
　　 2 ．对发布在同一个 container 的 application 能够使用同样的验证信息来代表这些 application 的 principal 。
　　 3 ．仅仅当通过安全策略域时要求用户重新验证。

　　因此，一个 servlet container 要求在 container 层来跟踪这些验证信息，而不是在 application 层。允许一个经验证的用户拒绝一个使用其它资源的 application ，这些是通过受同样安全性标识限制的 container 管理的。