2

The attacker request uses a trusted HTTP verb such as GET or POST, but adds request headers such as X-HTTP-Method, XHTTP-Method-Override, X-Method-Override, or a query parameter such as _method to provide a restricted verb such as PUT or DELETE. Such a request is interpreted by the target application using the verb in the request header instead of the actual HTTP verb.

What I figured out to restrict this is to add the following entries in web.xml:

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

According to these entries my application only allows GET and POST requests for all URL patterns and it restrict all other HTTP methods.

The security constraint will apply to all methods except those that were named in the omissions, and the constraint will apply only to the resources matched by the patterns in the constraint.

My questions:

  1. In this case, is it going to prevent method/verb HEAD through special request headers above?

  2. Will these entries disable the use of verb tunneling using headers such as X-HTTP-Method, XHTTP-Method-Override?

  3. Or if this is not appropriate fix, then what should we do to prevent this issue?

2
  1. The example configuration should block the use of the HEAD verb, assuming that the server which has this configuration is receiving the verb at all (e.g. if you have a weird proxy setup which fakes HEAD requests by making a GET call, then dropping the body, it won't have any effect).

  2. No, other headers will still be present - the server doesn't know that the other headers are treated as verbs by the application. If you want to prevent the use of other methods passed in this way, the best option is probably to remove the headers which the application can interpret as HTTP verbs. Depending on the application, this may break some functionality - I've seen applications which use this method of passing verbs for delete functions, or to allow modifications to records.

From your description, it sounds like the problem lies not in the use of HTTP verbs, but in how the application allows the actions they relate to to be performed, possibly with inappropriate permissions. It's hard to say without further knowledge about your application, but blocking a specific method of performing an action is likely to be less effective than blocking the action itself, within the application, unless appropriate authorisation is supplied.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.