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的方法,然后将方法中的处理部分全部注释掉,并将请求导向到一个自定义的出错页面中,这样问题就解决了。
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的方法,然后将方法中的处理部分全部注释掉,并将请求导向到一个自定义的出错页面中,这样问题就解决了。