jsp服务器安全 jsp服务器的安装与配置
jsp有哪些漏洞?
JSP漏洞大观
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名与空间、网页空间、营销软件、网站建设、岳阳楼网站维护、网站推广。
Apache泄露重写的任意文件漏洞是怎么回事？
在Apache1.2以及以后的版本中存在一个mod_rewrite模块，它用来指定特殊URLS在网络服务器文件系统上所映射的绝对路径。如果传送一个包含正确表达参数的重写规则，攻击者就可以查看目标主机上的任意文件。
下面举例说明重写规则指令（其中第一行只有是包含漏洞的）：
RewriteRule /test/(.*) /usr/local/data/test-stuff/$1
RewriteRule /more-icons/(.*) /icons/$1
RewriteRule /go/(.*)
受影响的系统：
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）.
2）
3）
4）
5）\
6）
7）
8）
受影响的系统：
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 请求时会暴露网站上网页的全路径。
举例：
结果显示：
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 下的所有文件：
受影响的系统：Allaire JRun 3.0
解决方案：下载并安装补丁：
Allaire patch jr233p_ASB00_28_29
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
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 ：
est.jsp
. ./../../../../winnt/repair/sam
注意：假设JRun在主机" jrun "上运行，端口8000。
受影响的系统：Allaire JRun 2.3.x
解决方案：下载并安装补丁：
Allaire patch jr233p_ASB00_28_29
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
UNIX/Linux patch - GNU gzip/tar Allaire JRUN 2.3远程执行任意命令漏洞
Allaire 的 JRUN 服务器 2.3上存在一个安全漏洞，允许远程用户把在 WEB 服务器上的任意文件作为JSP代码编译/执行。 如果URL请求的目标文件使用了前缀"/servlet/"，则JSP解释执行功能被激活。这时在用户请求的目标文件路径中使用"../"，就有可能访问到 WEB 服务器上根目录以外的文件。在目标主机上利用该漏洞请求用户输入产生的一个文件，将严重威胁到目标主机系统的安全。
例如：
/temp.txt
受影响的系统：Allaire JRun 2.3.x
解决方案：下载并安装补丁：
Allaire patch jr233p_ASB00_28_29
Windows 95/98/NT/2000 and Windows NT Alpha
Allaire patch jr233p_ASB00_28_29tar
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连接信息。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 目录里的文档。
相关站点：
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":： 那么访问 将看到这个文件的源代码。
解决方案：下载并安装补丁
相关站点：
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"的错误信息。
解决方案：点击此处下载补丁
相关站点：
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/" 就会让文件未经分析和编译，直接暴露源代码。如： ，那么只要访问 就会在 WEB 浏览器里看到文件的内容。
以下是使用方法:
1. 通过强制使用 SSIServlet 查看未分析的页面 :
服务器站点通过 WebLogic 中的 SSIServlet 处理页面，它在weblogic.properties 文件中注册以下信息：weblogic.httpd.register.*.shtml= weblogic.servlet.ServerSideIncludeServlet
通过 URL 使用 SSIServlet 自动处理通配符 （*） 。因此 如果文件路径开头为 /*.shtml/，将强制文件由 SSIServlet 处理。如果使用其它文件类型如 .jsp 和 .jhtml, 就能查看未分析的 jsp 和 jhtml 代码。举例：*.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，使未分析或编译的文件作页面显示出来，举例：
解决方案：
不要使用示例中的设置方法设置 FileServlet 。这可能会让你的 JSP/JHTML 文件的源代码暴露出来。请查看在线文档:
示例的 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 说明档的：
另：请留意新版本并升级吧。
装杀毒软件或者360后 导致JSP服务器内网无法被访问
首先 对于一家公司来说 360 它起不了多大作用 因为360 它不是正规的杀毒软件 ，360它适用于家庭 网吧 ，但是公司安360 有点靠不住 真的 说实话我攻击一家安360的公司 最多5分钟 ， 告诉你 把360 卸掉 然后重新启动 在安装正版的杀毒软件 比如说（卡巴斯基企业版）正经不错 ，自带防火墙 然后再安360卫士 杀系统表面的毒用360还可以 但是想杀深层的 还是用杀毒软件吧 最起码比360靠得住 然后把JSP从新设置一下 、
jsp中都有哪些注释方式?为了提高站点的安全性,应该采用哪种注释方式?
今天在弄JSTL标签的时候，用到了c:redirect重定向标签的时候遇到一个很是蛋疼的问题，就是当我测试完成这个标签的时候，我想测试其他的内容，由于它是重定向的(浏览器地址会发生改变的),这样肯定会影响我后面的测试，于是我就想把这行代码注释了:
!--c:redirect url="/include.jsp"/c:redirect--
然后测试其他的内容了，但是问题来了，我每次刷新浏览器的时候，还是重定向了，我就纳闷了，这句话不是注释了吗？怎么还是执行了，然后我就把这句话删除了，这时候就好了，此时就怀疑这个注释到底有没有用，然后上网查看资料，知道这种注释对于Jsp是没有用的，它是html/xml的原版注释，应该使用
%--c:redirect url="/include.jsp"/c:redirect--%
这个注释就可以了，随后又想起来了，还有Java中原版注释：//和/**/，其实也可以这样注释的:
%//--c:redirect url="/include.jsp"/c:redirect--%,
这个和上面的两种有什么区别呢？这时候就可能需要jsp的执行过程了，这里就简单说一下：每个jsp页面都会被jsp引擎翻译成servlet.java的，具体内容可以到tomcat目录下的work文件夹中的项目工程中找到对应的文件，所以最后一种注释是彻底的注释了，因为他在servlet.java中就被注释了，而前面的两种注释在servlet.java代码中是没有被注释的，下面就是servlet.java中的代码片段:
使用%//....%注释的：
out.write(" --\r\n");
out.write(" brbr\r\n");
out.write(" \r\n");
out.write(" !-- c:redirect标签的使用:重定向打开include.jsp页面 --\r\n");
out.write(" ");
//c:redirect url="/include.jsp"/c:redirect
这里可以看到，这句话直接被注释了，即:Jsp中%...%中的内容会原封不动的翻译成servlet.java
使用%----%注释的:
out.write(" --\r\n");
out.write(" brbr\r\n");
out.write(" \r\n");
out.write(" !-- c:redirect标签的使用:重定向打开include.jsp页面 --\r\n");
out.write(" ");
使用!----注释的:
out.write(" --\r\n");
out.write(" brbr\r\n");
out.write(" \r\n");
out.write(" !-- c:redirect标签的使用:重定向打开include.jsp页面 --\r\n");
out.write(" !--");
if (_jspx_meth_c_005fredirect_005f0(_jspx_page_context))
return;
综上所述可以发现，原因可能在于那段代码：
if (_jspx_meth_c_005fredirect_005f0(_jspx_page_context))
return;
这个方法是针对redirect标签的做判断的，所以原因就在这个方法内部，可以自行查看，需要注意的是，如果使用%...%和%----%的话，servelet.java中是没有这个方法的，这一点更能说明为什么!----注释没有效果了!
总结:
1.第一种注释:
!--注释内容--
这是HTML/XML的原版注释，会老老实实的发到客户端的，有什么见不得人的就别用这个写了
2.第二种注释:
%--注释内容--%
有% %的东西都是写给JSP应用服务器看的，不会发到客户端的。编译器将其置之不理，html也无缘与其相见，被应用服务器打入冷宫了。这个注释感觉比较多余，不知道专门又搞一个这种注释干什么。
3.第三种注释:
%
//当行注释
/**
多行注释
*/
%
分享标题：jsp服务器安全 jsp服务器的安装与配置
分享链接：http://cdiso.cn/article/dopsjdd.html
