|
一,源代码暴露类
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文件 堶情A但也很难访
问它,这样就算源代码被人知道起码资料库是安全的.
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 伺服器上根目录以外的文件.目标主机上利用该漏洞请求用户输入
产生的一个文件,将严重威胁到目标主机系统的安全.
解决方法:安装最新的补丁.
把这个老帖子翻出来的原因,是据说Tomcat 5.0.19 Windows又出现大写暴露源代码的问题了,有兴趣的朋友
可是试看看,如果是真的,那tomcat那帮家夥又在老地方摔了一交.  |
