Hi Bill,
I think the issue occurs when using http-method,
does not occur when using http-method-omission.
My proposal is that following contents are added or modified
in the Servlet spec:
1. Behavior of container when it has received HTTP method
other than specified with http-method in web.xml
2. Example of secure configuration(fix unsecure examples)
(not with http-method but with http-method-omission)
Thank you.
Minehiko Iida
> -----Original Message-----
> From: Bill Shannon [mailto:bill.shannon_at_oracle.com]
> Sent: Tuesday, December 18, 2012 2:14 PM
> To: jsr342-experts_at_javaee-spec.java.net
> Subject: [jsr342-experts] Configuring DENY semantic for uncovered HTTP Methods
>
> An issue came up in the Servlet expert group that I'd like to escalate
> to this group.
>
> There's a potential security issue in the Servlet spec in the way that
> permissions are associated with HTTP methods. This issue was raised by
> Jeff Williams of Aspect Security and OWASP (http://www.owasp.og). Ron
> Monzillo on our security team worked with Jeff to propose a solution to
> the Servlet expert group. The reaction from the Servlet expert group was
> (paraphrasing) that this was not an important issue and that people who
> understood the Servlet spec would not make this mistake. They seemed to
> think the solution was worse than the problem and rejected Ron's proposal.
> (If any of you are also members of the Servlet expert group, I'd like to
> hear your perspective.)
>
> I'd prefer not to be in the situation where an independent group has
> pointed out a valid security concern with the Java EE platform and
> we've chosen not to fix it. I'd like to get your feedback...
>
> - Is this a valid concern?
>
> - Should we provide a "fix" in the Servlet spec?
>
> - Is the proposed fix acceptable?
>
> I've included Ron's original description of the problem and the
> proposed fix below. If there's support in this group for fixing
> this problem in the Servlet spec, we'll take this back to the Servlet
> expert group and ask them to reconsider. Those of you with reps on
> the Servlet expert group may need to help.
>
> I'm looking forward to your feedback.
>
> Thanks.
>
>
> -----
>
> Experts,
>
> This proposal was developed in response to a recommendation made by Jeff
> Williams of Aspect and OWASP.
>
> The following article from Aspect Security describes the issue.
>
> https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18
>
> The Servlet constraint grammar provides the ability to enumerate
> (including by omission) the HTTP methods to which the protection
> requirements defined in a constraint apply. When HTTP methods are
> enumerated within a constraint definition, the protections defined
> by the constraint apply only to the methods established by the
> enumeration. We refer to the HTTP methods that are not established
> by the enumeration as "uncovered" methods.
>
> When HTTP methods are not enumerated within a constraint, the protections
> defined by the constraint apply to the complete set of HTTP (extension)
> methods. In that case, there are no uncovered HTTP methods at the
> url-patterns to which the constraint applies.
>
> Servlet requires that a default permit semantic be associated with
> uncovered methods (and with unconstrained url-patterns).
>
> Developers need to understand these rules in order to use the
> security-constraint grammar effectively. Unfortunately it is easy to find
> examples of security-constraint specifications that, as a result of HTTP
> method enumeration, are vulnerable as described in the cited reference.
>
> To address this issue, we are proposing that a new element be defined for
> use in web.xml that when specified, would cause a deny semantic to be
> applied to uncovered HTTP methods.
>
> This new element would be defined within the web-common_3_0.xsd.xml
> schema (with version corrected appropriately) as follows:
>
> <xsd:complexType name="web-appType">
> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> <xsd:element name="module-name" type="javaee:string" minOccurs="0"/>
> <xsd:group ref="javaee:web-commonType"/>
> <xsd:element name="absolute-ordering" type="javaee:absoluteOrderingType"/>
> <xsd:element name="deny-uncovered-http-methods" type="javaee:emptyType">
> <xsd:annotation>
> <xsd:documentation>
>
> When specified, this element causes uncovered http methods
> to be denied. For every url-pattern that is the target of a
> security-constrant, this element causes all HTTP methods that
> are not covered (by a security constraint) at the url-pattern
> to be denied.
>
> </xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> </xsd:choice>
> <xsd:attributeGroup ref="javaee:web-common-attributes"/>
> </xsd:complexType>
>
> This element would only be available via the top level deployment descriptor,
> web.xml. When specified in web.xml, this element would apply to all security
> constraints defined for the web application; including any defined in fragments.
> This element would apply to uncovered methods resulting from the specification
> of security constraints via the web.xml and web-fragment deployment
> descriptors, from the use of the @ServletSecurity annotation, and from the use
> of the setServletSecurity method of the ServletRegistration interface.
>
> This flag would provide a means to ensure that uncovered methods could not be
> the cause of a security breach.
>
> The examples that follow demonstrate how methods may be left uncovered. The
> determination of whether methods are uncovered is made after all the
> constraints that apply to the pattern have been combined as described
> in "Section 13.8.1 Combining Constraints"
>
> To implement this flag it will be necessary for it to effect the processing
> of the @ServletSecurity annotation and the ServletSecurityElement such
> that methods uncovered in these forms will retain their uncovered status
> into constraint combination, after which a deny semantic can be associated
> with any remaining uncovered methods.
>
> When this flag has not been specified the existing semantics will be retained.
>
> Comments?
>
> Ron
>
> More details
>
> EXAMPLES OF UNCOVERED METHODS
>
> Example 1: Security-constraint that enumerates HTTP methods using http-method
> elements, All HTTP methods except GET and POST are uncovered (at the
> url-patterns to which the constraint applies)
>
> [<security-constraint>
> <web-resource-collection>
> <url-pattern>/a/b/c/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>user</role-name>
> </auth-constraint>
> </security-constraint>
>
> Example 2: Security-constraint that enumerates HTTP methods using
> http-method-omission elements, The ommitted HTTP methods, GET and POST, are
> uncovered (at the url-patterns to which the constraint applies)
>
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/d/e/f/*</url-pattern>
> <http-method-omission>GET</http-method-omission>
> <http-method-omission>POST</http-method-omission>
> </web-resource-collection>
> <auth-constraint/>
> </security-constraint>
>
> Example 3: @ServletSecurity annotation that contains one or more HTTP
> method-specific @HttpMethodConstraint elements and that either implicitly
> or explicitly establishes a default HTTP method-independent @HttpConstraint
> (value = EmptyRoleSemantic.PERMIT, rolesAllowed = {}, and
> TransportGuarantee = NONE) to be applied to all other HTTP methods. Like
> Example 1, all methods except those that are the target of an
> @HttpMethodConstraint are uncovered (at the url-patterns to which the
> constraint applies).
>
> [3a] implicit method-independent @HttpConstraint
> (value = EmptyRoleSemantic.PERMIT, rolesAllowed = {}, and
> TransportGuarantee = NONE)
>
> @ServletSecurity(
> httpMethodConstraints = {
> @HttpMethodConstraint(value = "GET", rolesAllowed = "user"),
> @HttpMethodConstraint(value = "POST", rolesAllowed = "user"),
> })
>
> [3b] explicit method-independent @HttpConstraint that establishes a default
> HTTP method-independent @HttpConstraint (value = EmptyRoleSemantic.PERMIT,
> rolesAllowed = {}, and TransportGuarantee = NONE). Note that there are some
> other explicit ways to specify the equivalent of the default HTTP
> method-indpendent @HttpConstraint.
>
> @ServletSecurity(
> value = @HttpConstraint(value = EmptyRoleSemantic.PERMIT,
> rolesAllowed = {}, transportGuarantee = TransportGuarantee.NONE),
> httpMethodConstraints = {
> @HttpMethodConstraint(value = "GET", rolesAllowed = "user"),
> @HttpMethodConstraint(value = "POST", rolesAllowed = "user"),
> })
>
> Example 4: use of the setServletSecurity method of the ServletRegistration
> interface with a ServletSecurityElement parameter that either implicitly
> or explicitly establishes a default HTTP method-indpendent @HttpConstraint
> value (as described in example 3 above). All methods except those that are
> the target of an HttpMethodConstraint element are uncovered (at the
> url-patterns to which the constraint applies).
>
> EFFECT OF ANNOTATION TRANSLATION RULES
>
> Section "13.4.1.2 Mapping @ServletSecurity to security-constraint" defines
> the mapping of the @ServletSecurity annotation and the ServletSecurityElement
> into corresponding web.xml style security-constraints. As defined in
> section 13.4.1.2:
>
> "The @ServletSecurity annotation is used to define one method-independent
> @HttpConstraint followed by a list of zero or more @HttpMethodConstraint
> specifications. The method-independent constraint is applied to all HTTP
> methods for which no HTTP method-specific constraint has been defined.
>
> When no @HttpMethodConstraint elements are included, a @ServletSecurity
> annotation corresponds to a single security-constraint element containing a
> web-resource-collection that contains no http-method elements, and thus
> pertains to all HTTP methods."
>
> The security-constraint elements that result from this mapping combine to
> leave no HTTP methods uncovered (at the corresponding url-patterns).
> Following the mapping, any HTTP methods that were uncovered prior to
> the mapping (as shown in Examples 3 and 4 above) would no longer be
> distinguishable as such. In other words, after the mapping to
> security-constraints, it will be too late to associate a different
> semantic with such methods.
>
> As such, the deny-uncovered-http-methods flag must effect the mapping
> of annotations to security-constraints such that a method-independent
> constraint is NOT created when at least one protected HttpMethodConstraint
> is defined within the @ServletSecurity annotation (or ServletSecurityElement)
> and the value of the @HttpConstraint annotation (or HttpConstraintElement)
> is equivalent to the default @HttpConstraint
> (i.e., value = EmptyRoleSemantic.PERMIT, rolesAllowed = {}, and
> TransportGuarantee = NONE). An HttpMethodConstraint is protected if it's
> protection value differs from that of the default @HTTPConstraint.
>
> In summary, to implement a flag to be used to change the semantic applied
> to uncovered HTTP methods, it will be necessary for it to effect the
> interpretation of the @ServletSecurity and ServletSecurityElement such that
> methods uncovered in these forms will retain their uncovered status into
> constraint combination, after which time a deny semantic can be associated
> with any remaining uncovered methods.