月度归档:2009年01月

JSP漏洞大观

 综述:服务器漏洞是安全问题的起源,黑客对网站的攻击也大多是从查找对方的漏洞开始的。所以只有了解自身的漏洞,网站管理人员才能采取相应的对策,阻止外来的攻击。下面介绍一下一些服务器(包括Web服务器和JSP服务器)的常见漏洞。

  Apache泄露重写的任意文件漏洞是怎么回事?

  在Apache1.2以及以后的版本中存在一个mod_rewrite模块,它用来指定特殊URLS在网络服务器文件系统上所映射的绝对路径。如果传送一个包含正确表达参数的重写规则,攻击者就可以查看目标主机上的任意文件。

  下面举例说明重写规则指令(其中第一行只有是包含漏洞的):

  RewriteRule /test/(.*) /usr/local/data/test-stuff/$1

  RewriteRule /more-icons/(.*) /icons/$1

  RewriteRule /go/(.*) http://www.apacheweek.com/…

  受影响的系统:

  1)Apache 1.3.12

  2)Apache 1.3.11win32

  3)Apache 1.2.x

  不受影响系统:Apache 1.3.13

  怎样解决在HTTP请求中添加特殊字符导致暴露JSP源代码文件?

  Unify eWave ServletExec 是一个 Java/Java Servlet 引擎插件,主要用于 WEB 服务器,例如:Microsoft IIS, Apache, Netscape Enterprise 服务器等等。

  当一个 HTTP 请求中添加下列字符之一,ServletExec 将返回 JSP 源代码文件。

.

  %2E

  +

  %2B

  \

  %5C

  %20

  %00  

  成功的利用该漏洞将导致泄露指定的JSP文件的源代码,例如:使用下面的任意一个URL请求将输出指定的JSP文件的源代码:

  1)http://target/directory/js…

  2)http://target/directory/js…

  3)http://target/directory/js…

  4)http://target/directory/js…

  5)http://target/directory/js…\

  6)http://target/directory/js…

  7)http://target/directory/js…

  8)http://target/directory/js…

  受影响的系统:

  1)Unify eWave ServletExec 3.0c

  2)Sun Solaris 8.0

  3)Microsoft Windows 98

  4)Microsoft Windows NT 4.0

  5)Microsoft Windows NT 2000

  6)Linux kernel 2.3.x

  7)IBM AIX 4.3.2

  8)HP HP-UX 11.4

  解决方案:

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

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

  Tomcat有哪些漏洞?

  Tomcat 3.1 存在暴露网站路径问题

  Tomcat 3.1 是在 Apache 软件环境下开发的一个支持 JSP 1.1 和 Servlets 2.2 的软件。它存在一个安全问题当发送一个不存在的 jsp 请求时会暴露网站上网页的全路径。

  举例:

  http://narco.guerrilla.suc…

  结果显示:

Error: 404

Location: /anything.jsp

JSP file “/appsrv2/jakarta-tomcat/webapps/ROOT/anything.jsp” not found

  解决方案:升级到新版本

  Tomcat 暴露JSP文件内容

  Java Server Pages (JSP)类型的文件是以'.jsp'扩展名在Tomcat 上注册,Tomcat 是文件名大小写敏感的,'.jsp'和'.JSP'是不同类型的文件扩展名。如果提交有'.JSP'的链接给Tomcat,而Tomcat找不到'.JSP'就会以默认的'.text'文件类型来响应请求。因为在NT系统中大小写文件名是非敏感的,所以被请求的文件会以文本的形式送出。

  如果在UNIX服务器上会出现”file not found”的错误信息。

  如何在windows下对Tomcat实施代码保护

  Tomcat的一些版本有泄露源代码的漏洞,如果在浏览器中调用JSP页面时将该文件的后缀改成大写,这个JSP文件的源代码将完全输出到浏览器中(也许浏览器窗口中什么都没有,这时你只需查看HTML源文件就可以发现)。如此一来,网站的源代码是不是都会暴露在互联网上那?

  不用担心,解决方法很简单,把各种后缀的组合全部写到Tomcat_Home\conf \web.xml里就可以了,这样Tomcat会将不同后缀名的JSP分开对待,就不会泄露代码了。

    jsp

    *.jsp

    jsP

    *.jsP

   ?lt;servlet-name>jSp

    *.jSp

    jSP

    *.jSP

    Jsp

    *.Jsp

    JsP

    *.JsP

    JSp

    *.JSp

    JSP

    *.JSP

  Allair Jrun漏洞有哪些漏洞?

  Allair JRUN 非法读取 WEB-INF 漏洞

  在Allaire 的 JRUN 服务器 2.3版本中存在一个严重的安全漏洞。它允许一个攻击者在 JRun 3.0 服务器中查看 WEB-INF 目录。

  如果用户在提交 URL 请求时在,通过附加一个”/”使该 URL 成为畸形的 URL,这时 WEB-INF 下的所有子目录将会暴露出来。攻击者巧妙的利用该漏洞将能够远程获得目标主机系统中 WEB-INF 目录下的所有文件的读取权限。

  例如使用下面这个 URL 将会暴露 WEB-INF 下的所有文件:

http://site.running.jrun:8…

  受影响的系统:Allaire JRun 3.0

  解决方案:下载并安装补丁:

Allaire patch jr233p_ASB00_28_29

http://download.allaire.co…

Windows 95/98/NT/2000 and Windows NT Alpha

Allaire patch jr233p_ASB00_28_29tar

http://download.allaire.co…

UNIX/Linux patch – GNU gzip/tar  

  Allaire JRUN 2.3 查看任意文件漏洞

  Allaire 的 JRUN 服务器 2.3上存在多重显示代码漏洞。该漏洞允许攻击者在 WEB 服务器上查看根目录下的任意文件的源代码。

  JRun 2.3 使用 Java Servlets 解析各种各样类型的页面(例如:HTML, JSP等等)。基于rules.properties 和 servlets.properties 的文件设置,可能利用URL前缀”/servlet/”调用任何servlet。

  它可能使用 Jrun 的 SSIFilter servlet 在目标系统上检索任意的文件。下列 2 个例子显示出能被用来检索任意的文件的 URLs :

http://jrun:8000/servlet/c… est.jsp

http://jrun:8000/servlet/c…

http://jrun:8000/servlet/c… ./../../../../winnt/repair/sam

http://jrun:8000/servlet/s…

http://jrun:8000/servlet/s…

http://jrun:8000/servlet/s…

  注意:假设JRun在主机” jrun “上运行,端口8000。

  受影响的系统:Allaire JRun 2.3.x

  解决方案:下载并安装补丁:

Allaire patch jr233p_ASB00_28_29

http://download.allaire.co…

Windows 95/98/NT/2000 and Windows NT Alpha

Allaire patch jr233p_ASB00_28_29tar

http://download.allaire.co…

UNIX/Linux patch – GNU gzip/tar

  Allaire JRUN 2.3远程执行任意命令漏洞

  Allaire 的 JRUN 服务器 2.3上存在一个安全漏洞,允许远程用户把在 WEB 服务器上的任意文件作为JSP代码编译/执行。   如果URL请求的目标文件使用了前缀”/servlet/”,则JSP解释执行功能被激活。这时在用户请求的目标文件路径中使用”../”,就有可能访问到 WEB 服务器上根目录以外的文件。在目标主机上利用该漏洞请求用户输入产生的一个文件,将严重威胁到目标主机系统的安全。

  例如:

http://jrun:8000/servlet/c… /temp.txt

http://jrun:8000/servlet/j…

  受影响的系统:Allaire JRun 2.3.x

  解决方案:下载并安装补丁:

Allaire patch jr233p_ASB00_28_29

http://download.allaire.co…

Windows 95/98/NT/2000 and Windows NT Alpha

Allaire patch jr233p_ASB00_28_29tar

http://download.allaire.co…

UNIX/Linux patch – GNU gzip/tar  

  JRun 2.3.x 范例文件暴露站点安全信息

  JRun 2.3.x 在 JRUN_HOME/servlets 目录下有一些 servlet 范例文件,这个目录是 JRun 2.3.x 用于加载和执行 servlets 文件。所有扩展名为 “.Java” 或 “class” 的文件必须被删除,这是因为这些文件会暴露站点的安全信息。例如:

http://www.xxx.xxx/servlet… 会暴露当前服务器保持的HTTP连接信息。JRUN_HOME/jsm-default/services/jws/htdocs 目录下的内容也应被删除掉。这个目录保存有演示服务器功能的 '.jsp' 文件,其中一些文件牵涉到访问服务器文件系统和暴露服务器设置的问题。例如对文件 “viewsource.jsp” 的路径检查是默认关闭的,它可被用于访问服务器文件系统。

  解决方案:

  1)安装 2.3.3 service pack

  2)从服务器上删除所有的说明文档、演示编码、范例和教材,包括安装 JRun   2.3.x 时存放于 JRUN_HOME/servlets 目录和JRUN_HOME/jsm-default/services/jws/htdocs 目录里的文档。

  相关站点:http://www.allaire.com/

  IBM WebSphere Application Server有哪些漏洞?

  1、IBM WebSphere Application Server 3.0.2 存在暴露源代码漏洞

IBM WebSphere Application Server 允许攻击者查看 Web server 根目录以上的所有文件。IBM WebSphere 使用 Java Servlets 处理多种页面类型的分析(如 HTML, JSP, JHTML, 等等)。In addition 不同的 servlets 对不同的页面进行处理,如果一个请求的文件是未进行注册管理的,WebSphere 会使用一个默认的 servlet 作调用。如果文件路径以”/servlet/file/”作开头这个默认的 servlet 会被调用这个请求的文件会未被分析或编译就显示出来。

  受影响系统:IBM WebSphere 3.0.2 的所有版本

  举例:

  如果一个请求文件的 URL 为 “login.jsp”::  http://site.running.websph…那么访问  http://site.running.websph…将看到这个文件的源代码。

  解决方案:下载并安装补丁

http://www-4.ibm.com/softw…

  相关站点:http://www-4.ibm.com/softw…

  IBM WebSphere Application Server 暴露JSP文件内容

  Java Server Pages (JSP)类型的文件是以'.jsp'扩展名在WebSphere Application Serve 上注册,WebSphere 是文件名大小写敏感的,'.jsp'和'.JSP'是不同类型的文件扩展名。如果提交有'.JSP'的链接给WebSphere,而WebSphere找不到'.JSP'就会以默认的'.text'文件类型来响应请求。因为在NT系统中大小写文件名是非敏感的,所以被请求的文件会以文本的形式送出。

  如果在UNIX服务器上会出现”file not found”的错误信息。

  解决方案:点击此处下载补丁

  相关站点:http://www-4.ibm.com/softw…

  BEA WebLogic有哪些暴露源代码漏洞?

  受影响版本:

  所有系统上的

  BEA WebLogic Enterprise 5.1.x

  BEA WebLogic Server and Express 5.1.x

  BEA WebLogic Server and Express 4.5.x

  BEA WebLogic Server and Express 4.0.x

  BEA WebLogic Server and Express 3.1.8  

  这个漏洞使攻击者能读取 Web 目录下所有文件的源代码。

  WebLogic 依赖四个主要 Java Servlets to 服务不同类型的文件。这些 servlets 是:

  1)FileServlet – for 简单 HTML 页面

  2)SSIServlet – for Server Side Includes 页面

  3)PageCompileServlet – for JHTML 页面

  4)JSPServlet – for Java Server 页面

  看着weblogic.properties 文件, 这儿是各个 servlets 的注册值:

  1)weblogic.httpd.register.file=weblogic.servlet.FileServlet

  2)weblogic.httpd.register.*.shtml=weblogic.servlet.ServerSideIncludeServlet

  3)weblogic.httpd.register.*.jhtml=weblogic.servlet.jhtmlc.PageCompileServlet

  4)weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet

更多的 weblogic.properties 文件, 如果一个请求文件是没有注册管理的,那么就会调用一个默认的 servlet 。以下是展示默认的 servlet 是如何注册的。

  # Default servlet registration

  # ————————————————

  # Virtual name of the default servlet if no matching servlet

  # is found weblogic.httpd.defaultServlet=file  

  因此如果 URL 中的文件路径开头为 “/file/” , 将会引致 WebLogic 调用默认的 servlet, 那将会使网页未加分析和编译而直接显示。

  论证:

  只要在想看的文件原来的 URL 路径之前加入 “/file/” 就会让文件未经分析和编译,直接暴露源代码。如:http://site.running.weblog… ,那么只要访问 http://site.running.weblog… 就会在 WEB 浏览器里看到文件的内容。

  以下是使用方法:

  1. 通过强制使用 SSIServlet 查看未分析的页面 :

  服务器站点通过 WebLogic 中的 SSIServlet 处理页面,它在weblogic.properties 文件中注册以下信息:weblogic.httpd.register.*.shtml= weblogic.servlet.ServerSideIncludeServlet

  通过 URL 使用 SSIServlet 自动处理通配符 (*) 。因此 如果文件路径开头为 /*.shtml/,将强制文件由 SSIServlet 处理。如果使用其它文件类型如 .jsp 和 .jhtml, 就能查看未分析的 jsp 和 jhtml 代码。举例:http://www.xxx.com/*.shtml/login.jsp

  2. 通过强制使用 FileServlet 查看未分析的页面 :

  WebLogic 使用 FileServlet 配置 ConsoleHelp servlet ,在weblogic.properties 文件的以下内容可得知:

# For Console help. Do not modify.

weblogic.httpd.register.ConsoleHelp= weblogic.servlet.FileServlet

weblogic.httpd.initArgs.ConsoleHelp=\defaultFilename=/weblogic/admin/help/NoContent.html

weblogic.allow.execute.weblogic.servlet.ConsoleHelp=everyone  

  因此如果文件路径以 /ConsoleHelp/ 开头将导致 WebLogic 使用 FileServlet,使未分析或编译的文件作页面显示出来,举例:http://www.xxx.com/Console…

  解决方案:

  不要使用示例中的设置方法设置 FileServlet 。这可能会让你的 JSP/JHTML 文件的源代码暴露出来。请查看在线文档:

  http://www.weblogic.com/do…

  示例的 registrations 如下:

  weblogic.httpd.register.file=weblogic.servlet.FileServlet

  weblogic.httpd.initArgs.file=defaultFilename=index.html

  weblogic.httpd.defaultServlet=file

  有两种方法可以避免这个问题:

  (1)注册那些文件 servlet 使用随机用户名,加大猜测难度。例如使用象这样注册文件 servlet 为 12foo34:

  weblogic.httpd.register.12foo34=weblogic.servlet.FileServlet

  weblogic.httpd.initArgs.12foo34=defaultFilename=index.html

  weblogic.httpd.defaultServlet=12foo34

  (2)注册文件 servlet 使用 wild cards 声明你将使用所有这些文件扩展名作服务。举例注册文件 servlet 为 .html 文件服务:

  weblogic.httpd.register.*.html=weblogic.servlet.FileServlet

  weblogic.httpd.initArgs.*.html=defaultFilename=index.html

  weblogic.httpd.defaultServlet=*.html

  使用上面的方法重复加入以下类型的文件 *.gif, *.jpg, *.pdf, *.txt, etc.

  注意:这些信息是备有证明在 BEA WebLogic Server and Express 说明档的:http://www.weblogic.com/do…

  另:请留意新版本并升级吧。

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.c…进行查看和参考。

  根据目前已经发现的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…,可以正常解释执行,但是如果将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.websph…,那么访问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.websph…,只要修改一下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/fdas…,就会返回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/j…,可以访问到WEB目录以外的文件,如果是exe文件,还有可能会引起执行。

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

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

  三、其他类别

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

  四、全文总结

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

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

  最后想用一句话作为全文的结尾:一个优秀的黑客不一定是个好的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管理的。

子网划分的优点及如何划分子网

子网划分(subnetting)的优点:

  1.减少网络流量

  2.提高网络性能

  3.简化管理

  4.易于扩大地理范围

  How to Creat Subnets

  如何划分子网?首先要熟记2的幂:2的0次方到9次方的值分别为:1,2,4,8,16,32,64,128,256和512.还有要明

白的是:子网划分是借助于取走主机位,把这个取走的部分作为子网位.因此这个意味划分越多的子网,主机将越

网数来计算

在求子网掩码之前必须先搞清楚要划分的子网数目,以及每个子网内的所需主机数目。

1)将子网数目转化为二进制来表示

2)取得该二进制的位数,为 N

3)取得该IP地址的类子网掩码,将其主机地址部分的的前N位置 1 即得出该IP地址划分子网的子网掩码。

如欲将B类IP地址168.195.0.0划分成27个子网:

1)27=11011

2)该二进制为五位数,N = 5

3)将B类地址的子网掩码255.255.0.0的主机地址前5位置 1,得到255.255.248.0,即为划分成 27个子网的B类

IP地址 168.195.0.0的子网掩码。

利用主机数来计算

1)将主机数目转化为二进制来表示

2)如果主机数小于或等于254(注意去掉保留的两个IP地址),则取得该主机的二进制位数,为 N,这里肯定

N<8。如果大于254,则 N>8,这就是说主机地址将占据不止8位。

3)使用255.255.255.255来将该类IP地址的主机地址位数全部置1,然后从后向前的将N位全部置为 0,即为子网

掩码值。

如欲将B©类IP地址168.195.0.0划分成若干子网,每个子网内有主机700台(17):

1) 700=1010111100

2)该二进制为十位数,N = 10(1001)

3)将该B类地址的子网掩码255.255.0.0的主机地址全部置 1,得到255.255.255.255,然后再从后向前将后10位

置0,即为:11111111.11111111.11111100.00000000,即255.255.252.0。这就是该欲划分成主机为700台的B类

IP地址 168.195.0.0的子网掩码。

 

 Subnet Masks

  子网掩码用于辨别IP地址中哪部分为网络地址,哪部分为主机地址,有1和0组成,长32位,全为1的位代表网络

号.不是所有的网络都需要子网,因此就引入1个概念:默认子网掩码(default subnet mask).A类IP地址的默认子

网掩码为255.0.0.0;B类的为255.255.0.0;C类的为255.255.255.0

  Classless Inter-Domain Routing(CIDR)

  CIDR叫做无类域间路由,ISP常用这样的方法给客户分配地址,ISP提供给客户1个块(block size),类似这

样:192.168.10.32/28,这排数字告诉你你的子网掩码是多少,/28代表多少位为1,最大/32.但是你必须知道的1点

是:不管是A类还是B类还是其他类地址,最大可用的只能为30/,即保留2位给主机位

  CIDR值:

   1.掩码255.0.0.0:/8(A类地址默认掩码)

  

2.掩码255.128.0.0:/9

  

3.掩码255.192.0.0:/10

  

4.掩码255.224.0.0:/11

  

5.掩码255.240.0.0:/12

  

6.掩码255.248.0.0:/13

  

7.掩码255.252.0.0:/14

  

8.掩码255.254.0.0:/15

  

9.掩码255.255.0.0:/16(B类地址默认掩码)

  

10.掩码255.255.128.0:/17

  

11.掩码255.255.192.0:/18

  

12.掩码255.255.224.0:/19

  

13.掩码255.255.240.0:/20

  

14.掩码255.255.248.0:/21

  

15.掩码255.255.252.0:/22

  

16.掩码255.255.254.0:/23

  

17.掩码255.255.255.0:/24(C类地址默认掩码)

  

18.掩码255.255.255.128:/25

19.掩码255.255.255.192:/26

   20.掩码255.255.255.224:/27

   21.掩码255.255.255.240:/28

   22.掩码255.255.255.248:/29

   23.掩码255.255.255.252:/30

  

Subnetting Class A,B&C Address

  划分子网的几个捷径:

  1.你所选择的子网掩码将会产生多少个子网?:2的x次方-2(x代表掩码位,即2进制为1的部分)

  2.每个子网能有多少主机?: 2的y次方-2(y代表主机位,即2进制为0的部分)

  3.有效子网是?:有效子网号=256-10进制的子网掩码(结果叫做block size或base number)

  4.每个子网的广播地址是?:广播地址=下个子网号-1

  5.每个子网的有效主机分别是?:忽略子网内全为0和全为1的地址剩下的就是有效主机地址.最后有效1个主

机地址=下个子网号-2(即广播地址-1)

  根据上述捷径划分子网的具体实例:

  C类地址例子:网络地址192.168.10.0;子网掩码255.255.255.192(/26)

  1.子网数=2*2-2=2

  2.主机数=2的6次方-2=62

  3.有效子网?:block size=256-192=64;所以第一个子网为192.168.10.64,第二个为192.168.10.128

  4.广播地址:下个子网-1.所以2个子网的广播地址分别是192.168.10.127和192.168.10.191

  5.有效主机范围是:第一个子网的主机地址是192.168.10.65到192.168.10.126;第二个是192.168.10.129到

192.168.10.190

  B类地址例子1:网络地址:172.16.0.0;子网掩码255.255.192.0(/18)

  1.子网数=2*2-2=2

  2.主机数=2的14次方-2=16382

  3.有效子网?:block size=256-192=64;所以第一个子网为172.16.64.0,最后1个为172.16.128.0

  4.广播地址:下个子网-1.所以2个子网的广播地址分别是172.16.127.255和172.16.191.255

  5.有效主机范围是:第一个子网的主机地址是172.16.64.1到172.16.127.254;第二个是172.16.128.1到

172.16.191.254

  B类地址例子2:网络地址:172.16.0.0;子网掩码255.255.255.224(/27)

  1.子网数=2的11次方-2=2046(因为B类地址默认掩码是255.255.0.0,所以网络位为8+3=11)

  2.主机数=2的5次方-2=30

  3.有效子网?:block size=256-224=32;所以第一个子网为172.16.0.32

最后1个为172.16.255.192

  4.广播地址:下个子网-1.所以第一个子网和最后1个子网的广播地址分别是172.16.0.63和172.16.255.223

  5.有效主机范围是:第一个子网的主机地址是172.16.0.33到172.16.0.62;最后1个是172.16.255.193到

172.16.255.223

  Variable Length Subnet Masks(VLSM)

  变长子网掩码(VLSM)的作用:节约IP地址空间;减少路由表大小.使用VLSM时,所采用的路由协议必须能够支

持它,这些路由协议包括RIPv2,OSPF,EIGRP和BGP