> -----Original Message----- > From: Erik Price [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 12:52 PM > To: Tomcat Users List > Subject: INSECURE to rely on sendRedirect (??) > > > > 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.)
No, but you can return from a servlet's request method :-) [snip] > 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. :) What if you return right after calling sendRedirect? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
