tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Price <epr...@ptc.com>
Subject INSECURE to rely on sendRedirect (??)
Date Fri, 24 Jan 2003 17:52:25 GMT

A few weeks ago I posted a question on this list asking if using 
response.sendRedirect() is a secure means of preventing a user agent 
from accessing content.  (For instance, in a scenario where, to access 
the content, the session is consulted for a key of some sort.  If the 
key is found, continue, otherwise a sendRedirect() is used to send the 
user to an error page.)

Since a redirect is performed using an HTTP header (rather than at the 
server, like RequestDispatcher.forward()), the user agent is not 
*obligated* to respect the redirect.  This means that relying on a 
redirect to protect secure data might be a mistake.  In other server 
side languages (Perl, PHP), you can call exit immediately after setting 
the header to ensure that the sensitive data is not sent from the server 
to the user agent in the event that the user agent does not respect the 
redirect.  However, as Paul Yunusov on this list pointed out to me, you 
cannot simply exit a servlet, it is not the same as a PHP or Perl 
script.  (The original message is appended to this one.)

The servlet spec says that further output should not be sent from a 
servlet that has called response.sendRedirect(), which means that in 
theory the sensitive data is protected.  However, I have run into a case 
where sendRedirect() does *not* prevent a request from being made to a JSP:

I am running Tomcat 4.0.6 and have a Filter named SecurityFilter mapped 
to a JSP named "main.jsp".  SecurityFilter consults the session for a 
key that is set when a user successfully passes through a login system. 
  If the key is present, then the Filter does nothing and the "main.jsp" 
page is served to the user.  However, if the key is not present, the 
Filter calls response.sendRedirect() to send the user to the login page. 
  In my case, "main.jsp" retrieves a bean from the session with the 
<jsp:useBean> tag.

THE PROBLEM:  When a user who has not yet started a session and 
registered the bean that "main.jsp" is looking for attempts to request 
"main.jsp", SecurityFilter should redirect the user to the login page. 
However, what actually happens is that for some reason the redirect is 
not happening immediately when it is called, and the Filter calling 
doFilterChain(), which means "main.jsp", which means that the JSP throws 
an exception because it cannot find the bean in the session.

Summary:

1) Calling sendRedirect() from a Filter does not happen before the 
Filter calls its doFilterChain() method
2) This means relying on sendRedirect() to protect sensitive data is 
probably not safe.

There could be a flaw in my logic, or I could simply be stating the 
obvious and everyone knew this.  If either of those is the case, please 
point out my fallacy and I apologize for wasting everyone's time. :)


Erik

PS: to correct my situation, should I just not call doFilterChain() in 
my Filter if the login key is not found?  Or would that violate the 
Filter spec....?



Paul Yunusov wrote:
> On Friday 10 January 2003 03:42 pm, Erik Price wrote:
> 
>>Paul Yunusov wrote:
>>
>>>sendRedirect() in HttpServletResponse will send an HTTP redirect response
>>>to the client so the client's browser itself makes a new request to the
>>>new URL (main.jsp in your case). It results in the new URL being shown in
>>>the browser's address field.
>>
>>Paul, this is exactly what I was looking for!  Thank you.  My only fear
>>is that if the client User Agent doesn't respect the HTTP Redirect (say
>>it is a malicious Perl script or something), does the servlet know not
>>to transmit any further data?  Or should I manually call System.exit()
>>after the response.sendRedirect() call?
> 
> 
> 
> Well, the API docs say "After using this method, the response should be 
> considered to be committed and should not be written to" so I guess the 
> developer rather than the servlet should know not to transmit any further 
> data from the servlet.
> 
> Definitely no System.exit() in servlets as that would theoretically attempt to 
> shut down the Tomcat process itself but I don't know anything about any 
> practical repercussions. You could try that and let us know what happened. 
> :-)
> 
> 
> 
>>>Note that the original request's parameters, which were sent to the
>>>servlet, are lost but check the sendRedirect()'s documentation for more
>>>details.
>>
>>That is okay, I will be storing data in the session in the LoginServlet
>>so the original parameters can be dropped.  Thank you very much again.
> 
> 
> Yes, holding the data in the session is what I thought you'd do, and I am glad 
> I could be of any help.
> 
> 
>>
>>Erik
> 
> 
> Paul
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message