DO NOT REPLY [Bug 11603] New: - security fails for http-method != GET when user is forced to login

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11603>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11603

security fails for http-method != GET when user is forced to login

           Summary: security fails for http-method != GET when user is
                    forced to login
           Product: Tomcat 4
           Version: 4.0.4 Final
          Platform: Other
               URL: http://www.secuityfilter.org/tomcat/http-method-bug.war
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: max@maxcooper.com


With a deployment descriptor like this:
<web-app>
  <welcome-file-list>
    <welcome-file>/index.jsp</welcome-file>
  </welcome-file-list>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Block POSTs to /showMessage.jsp</web-resource-name>
      <url-pattern>/showMessage.jsp</url-pattern>
      <http-method>POST</http-method>
    </web-resource-collection>
  </security-constraint>
  <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
      <form-login-page>/loginForm.jsp</form-login-page>
      <form-error-page>/loginError.jsp</form-error-page>
    </form-login-config>
  </login-config>
</web-app>

...no one should be able to POST to /showMessage.jsp. However, if an 
unauthenticated user makes such a POST, they will be sent through the login 
form, ending up with a redirect which results in a GET for /showMessage.jsp. 
Tomcat fails to recognize this request as a POST and allows the user to 
perform the GET. This is a problem because you can't effectively block access 
based on http-methods other than GET. All a user need do is make sure they 
aren't logged in before they make such a request, and the container will 
execute their request as if it was a GET. Of course, it is a GET in the end, 
but I think it needs to be interpreted by the container as being of the same 
method that caused the trip through the login sequence (i.e. use 
SavedRequest.getMethod() instead of the method from the current request when 
checking for authorization).

This would be a major problem if someone wanted to block POST (or any method 
besides GET) requests to their application or a part of their application.

The URL I included in this bug report will allow you to download a test 
application that demonstrates this problem.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>