JSP安全性初探----天极网 - 达人(被人煮了)

2004/11/25 | JSP安全性初探----天极网
类别(软件破解及黑客技术) | 评论(0) | 阅读(125) | 发表于 10:47: JSP安全性初探----天极网

作者：天极网文章来源：天极网点击数：215 更新时间：2004-11-24
转贴于华夏黑客同盟 www.77169.org　

综述：有几种办法可以暴露JSP代码，不过经过大量测试，这和WEB SERVER的配置有绝对的关系，就拿IBM Websphere Commerce Suite而言，还有别的方法看到JSP源代码，但相信是IBM HTTP SERVER的配置造成的。

　　如果想发现JSP暴露源代码的BUG的话，首先需要了解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\_l
ovehacker_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下在浏览器中本来
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默认的设置是可以读取目录的，如果程序
site.running.websphere/login.jsp，只要修改一下
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文件如
localhost:8080/fdasfas.jsp，就会返?..ervletEception:
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地址
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 找出来，即使发布了软件后，被发现的漏洞也只会是其中
的很小一部分，将来还会不断的有新的安全问题出现，所以我们必须
时刻提高警惕，并注意自己网站的安全。

　　一个好的建议就是多看安全文章，这些安全文章一般都会有详细
的信息如软件的版本号、漏洞原因等等，最重要的是还附带了解决办
法或者是补丁的下载链接，推荐的安全站点是国内的安全站点
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管理的。转贴于华夏黑客同盟 www.77169.org; 0

http://hbwazxf.5d.cn/

评论Comments