Issue Details (XML | Word | Printable)

Key: JSP-33
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: markt_asf
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Improving protection for HTTP verb tampering

Created: 21/Nov/12 02:08 PM   Updated: 09/Jan/13 12:48 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Participants: kchung and markt_asf

 Description  « Hide

During a wider discussion on the Servlet EG mailing list [1], it was observed that the JSP specification implies that containers override HttpServlet.service() for JSPs rather than the individual doXxx() methods. This creates problems when applications apply different security constraints to different HTTP verbs as JSPs will respond to any verb - potentially bypassing the security constraint.

A very useful addition to the JSP specification would be a mechanism to control which HTTP verbs a JSP should respond to.

My first idea for implementing this is as a page directive. Something along the lines of:

<@page httpMethods="GET,HEAD,POST" %>

with a corresponding support in web.xml such as


My initial thoughts for a default value is "GET,HEAD,POST"

This is an initial idea of how this could be implemented. I'm sure there are other ways to achieve the same result.



kchung added a comment - 08/Jan/13 07:31 PM

The Http methods that a JSP should receive is actually determined by the servlet container, so specifying the methods in the jsp-property-group is neither convenient nor appropriate. In fact, I don't think the JSP spec needs to say anything on this, since it will not affect the behavior of a JSP page, and should be left to the container implementation.

markt_asf added a comment - 08/Jan/13 07:40 PM

Where (in what specification) does it state that the container determines which verbs are to be responded to?

How should the container determine which verbs are valid and which are not?

The JSP page author knows which verbs are valid for a given JSP page and they should be able to control that from within the JSP page.

A container level solution is not appropriate as different JSPs may be intended to respond to different groups of verbs. This needs to be controllable per JSP page.

kchung added a comment - 08/Jan/13 10:44 PM

I think the only verbs that a JSP page author cares is GET and POST, and even then, he/she does care which. I cannot think of a use case where one would write a JSP page to respond to other verbs.

Would it help if I add a clarification in the spec to say that a JSP page must be rendered for the methods GET, POST, and HEAD, with the same response, and that the behavior for other methods is undefined?

markt_asf added a comment - 08/Jan/13 10:52 PM

I can't think of use cases for other verbs either. I'd be happy with a limit of GET, HEAD & POST. However, I suspect that someone, somewhere may have a use for other verbs. If there is a demand, that will just lead to container specific configuration for enabling the other verbs. I'd like to avoid that if possible - hence my proposal.

My preferences are:

  • my original proposal in the description
  • your proposal above
  • do nothing

I really don't like the "do nothing" option because of the knock-on impact it has for security.

kchung added a comment - 09/Jan/13 12:48 AM

So, I'll include my clarification in the JSP MR, maybe sometime next week.

Your proposal also works, but I don't like adding page directives and config elements unless it is absolutely necessary. It'll certainly generate more work for both of us!