CONTRAST: Verb Tampering Weakness /WEB-INF/web.xml file

Vulnerability ID: 3AQD-PMW1-2WNR-4XKN

Application Name: AgentMessageGeneratorJava

Vulnerability Link: http://localhost:19080/Contrast/static/ng/index.html#/7c6cfec5-a187-4d5e-984a-d11d96d2ef63/applications/6394f24f-037b-43bb-8ac2-05fa5fb5d862/vulns/3AQD-PMW1-2WNR-4XKN

What Happened?

The /WEB-INF/web.xml file had a misconfigured <security-constraint> that appears to be bypassable in the following section:

393: <servlet-mapping> 394: <servlet-name>Encode2Servlet</servlet-name> 395: <url-pattern>/encode2</url-pattern> 396: </servlet-mapping> 397: 398: <security-constraint> 399: <web-resource-collection> 400: <web-resource-name>Test</web-resource-name> 401: <url-pattern>/ping</url-pattern> 402: <http-method>GET</http-method> 403: </web-resource-collection> 404: </security-constraint> 405: 406: </web-app>

What's the risk?

The application has a misconfigured <security-constraint> in web.xml that appears to be bypassable. The way <security-constraint> values are interpreted have a rather dangerous quirk. Let's look at an example: <security-constraint> <web-resource-collection> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>

This rule limits access to the /admin directory to users with the "admin" role. Many tutorials and public examples of security configurations list POST, GET (and sometimes others) for the HTTP methods (also called "verbs") under which a security constraint applies. Unfortunately, the specification works in an unexpected and insecure way. Rather than DENYING methods not specified in the rule, they ALLOW any method not listed. Ironically, by listing specific methods in their rule, developers are actually allowing more access than they intend. Attackers can manipulate the HTTP method to attempt to bypass such security controls. The use of the HEAD method to access anything in the /admin/* space is the easiest attack. The attacker can also try any of the other methods specified in the RFCs. Sometimes, like in the case of making requests directly to JSPs, one can send an arbitrary string such as "NONSENSE" for the method, and the JSP will render correctly.

Recommendation

The most complete fix for this issue is simple: simply remove any <http-method> entries from your <security-constraint>. If you want to selectively enable constraints per individual HTTP methods, you can setup multiple, overlapping constraints to make sure that if a method "falls through" a constraint, it is still handled by a more general constraint that puts some blanket protections across the entire authenticated portion of the site.

So, here's the unsafe version:

<security-constraint> <web-resource-collection> <url-pattern>/admin/*</url-pattern>  <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>

And after we remove the HTTP methods, we're left with a safe-by-default constraint:

  &lt;security-constraint&gt;
     &lt;web-resource-collection&gt;
        &lt;url-pattern&gt;/admin/*&lt;/url-pattern&gt;
        &lt;!-- Safe! No &lt;http-method&gt; entries! --&gt;
     &lt;/web-resource-collection&gt;
     &lt;auth-constraint&gt;
        &lt;role-name&gt;admin&lt;/role-name&gt;
     &lt;/auth-constraint&gt;
  &lt;/security-constraint&gt;

First Event

(no event)

Last Event

(no event)

HTTP Request

(No HTTP Request)

References

https://www.owasp.org/index.php/Testing_for_HTTP_Verb_Tampering_(OTG-INPVAL-003)

Code-Racing / brickyard