HOWTO: Disable HTTP Methods in Tomcat
Introduction
In the Apache web server, if you want to disable access to specific methods, you can take advantage of mod_rewrite and disable just about anything, often with only one or two lines of configuration file entries. In Apache Tomcat, security is enforced by way of security constraints that are built into the Java Servlet specification. These are not contained within the main server.xml file within tomcat but within the web.xml configuration file.
The Java Servlet specification contains a fairly complete collection of security-related configuration parameters that allows you to do, among other things, disable HTTP methods, enable SSL on specific URIs, and allow access to specific resources based upon user role. Security constraints are the way to protect web content within Java-based applications. One common item that crops up in security related scans are HTTP methods allowed on a web site or within a web application. For those of us running our web sites using Apache Tomcat and not a front-end web server like Apache or IIS, having a good understanding of how security constraints work will be vital. This particular HOWTO will examine the steps necessary to disable access to specific HTTP methods.
A security constraint utilizes an xml syntax, just like other configuration directives in web.xml. Values in the examples are bolded to provide better readability. Example 1 is a basic web site, which serves up nothing but JSPs, images, scripts, and styles and does not contain any forms for a user to fill out. Network Security wants all HTTP methods disabled with the exception of HTTP HEAD and GET requests.
Example 1 – Basic Web Site – No Forms
01
// Sample Security Constraint
02
<security-constraint>
03
<web-resource-collection>
04
<web-resource-name><strong>restricted methods</strong></web-resource-name>
05
<url-pattern>/*</url-pattern>
06
<http-method>PUT</http-method>
07
<http-method>POST</http-method>
08
<http-method>DELETE</http-method>
09
<http-method>OPTIONS</http-method>
10
<http-method>TRACE</http-method>
11
</web-resource-collection>
12
<auth-constraint />
13
</security-constraint>
All constraints start out with a <security-contraint> deployment descriptor. The <web-resource-collection> comprises a set of URIs and HTTP Methods that are allowable within that set of URIs. In the example above, a <url-pattern> of /* (meaning everything under the root of the web site has been constrained to only allow access to GET and HEAD only. Setting an authorization constraint to <auth-constraint />, sets an All Users policy so this example literally means: “For any user, deny access to PUT, POST, DELETE, OPTIONS, and TRACE methods”. In a stock Tomcat installation, if I were to send an HTTP OPTIONS request, for example, to the web site, it would work. In my newly constrained configuration, OPTIONS requests now fail with an HTTP Status code of 403 – Forbidden.
The second example below takes our basic web site example a step further where a “Contact Us” form has been made available. The site user would fill out a form located under /contact and data would be passed using HTTP POST.
Example 2 – Basic Web Site with Contact Form
view sourceprint?
01
// Sample Security Constraint
02
<security-constraint>
03
<web-resource-collection>
04
<web-resource-name>restricted methods</web-resource-name>
05
<url-pattern>/*</url-pattern>
06
<http-method>PUT</http-method>
07
<http-method>POST</http-method>
08
<http-method>DELETE</http-method>
09
<http-method>OPTIONS</http-method>
10
<http-method>TRACE</http-method>
11
</web-resource-collection>
12
<auth-constraint />
13
</security-constraint>
14
15
<security-constraint>
16
<web-resource-collection>
17
<web-resource-name><strong>Contact Form</strong></web-resource-name>
18
<url-pattern>/contact/*</url-pattern>
19
<http-method>PUT</http-method>
20
<http-method>DELETE</http-method>
21
<http-method>OPTIONS</http-method>
22
<http-method>TRACE</http-method>
23
</web-resource-collection>
24
<auth-constraint />
25
</security-constraint>
Recent Comments