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
<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.
In this case, is it going to prevent method/verb HEAD through special request headers above?
Will these entries disable the use of verb tunneling using headers such as X-HTTP-Method, XHTTP-Method-Override?
Or if this is not appropriate fix, then what should we do to prevent this issue?