Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability)
Bojan,
Just move the code you wrote into a context object, reference it and
poof! Velocity gets OutOfMemory, too. Bad code is limited to front ends.
Velocity is nice. It is an excellent project, and Geir is possibly the
most responsive and helpful project leader I have ever encountered.
But there IS programming in a Velocity page--it's just in Yet Another
Templating Language, one that both your developers and your web
designers have to learn. That creates opportunities for confusion.
(Especially where velocimacros are involved.)
-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 10:34 PM
To: Tomcat Developers List
Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source
disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that -
firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom =
)
#foreach( $i in [-2147483648..2147483648] ) #set($oom =
$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom ) #end
Bad code can kill ANY system for the determined(disgruntled)
developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my
clients' JSP's
on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply
decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
More informative errors from Jasper-generated code?
I am using Tomcat 4.0.3, Windows 2000, JDK 1.4 I was getting the following stack trace from a JSP: ApplicationDispatcher[/SpendMetrix]: Servlet.service() for servlet jsp threw exception javax.servlet.ServletException at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContex tImpl.java:463) at org.apache.jsp.getInfo$jsp._jspService(getInfo$jsp.java:3432) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) etc... which is quite unhelpful because line 3432 in getInfo$jsp.java is just the location of the catch-all exception handler. The actual cause of the exception is lost in the mists. I edited getInfo$jsp.java by hand and added a t.printStackTrace and recompiled it, which handily located the real error. That got me thinking, why couldn't Jasper do this? Maybe PageContextImpl.handlePageException() could print (or, better yet, log) the initial Throwable before re-throwing the ServletException. I'm surprised that I don't get the root cause through the chained exception facility of JDK 1.4, since that's what I'm using. handlePageException does throw new ServletException(t) so I should get the root cause from the stack trace. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper performance
At 07:51 AM 5/18/01, Geir wrote: Those aren't comparable, 'Velocity templates' and 'general purpose servlet container', because Velocity is just a template tool - you still need the servlet and servlet container. That was exactly my point when I said Velocity doesn't really do anything to prevent DOS attacks, either. Any Velocity app requires a servlet back-end, and if I'm going to host user apps, I'm going to have to let them install servlets, in which case they can put in the same ever-looping code. - Dennis Doubleday email: [EMAIL PROTECTED] yourfit.com, Inc. web: http://www.yourfit.com/
Re: Jasper performance
At 08:35 PM 5/16/01, Jon wrote: Also, there is a reason for the #foreach... http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html Jon, I agree with most of your points. I am a new Velocity user and I am very impressed by its combination of power and simplicity. Reading/writing XSLT specs is an exercise in masochism. However, I don't see how Velocity is really avoiding the fundamental problem described in the document you referenced. If you are an ISP hosting Velocity-based pages, you are certainly going to have to let that 14 year old kid install both templates and class files; templates by themselves won't accomplish much. So the incompetent or malicious client can easily make the same mistake in his Command class that he would have made in the JSP page, and therefore also create a DOS attack on all servlets hosted in that JVM. No? - Dennis Doubleday email: [EMAIL PROTECTED] yourfit.com, Inc. web: http://www.yourfit.com/
