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.
ErikPaul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
