1

I'm using a web.xml to try and disable the HTTP methods we're not using and to return a body that doesn't contain any tomcat info.

So I've changed the web.xml of the app to have:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>TRACE</http-method>
        <http-method>PUT</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>DELETE</http-method>
        <http-method>HEAD</http-method>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

So the blocked methods are returning 403 with an empty body, for forbidden. But TRACE is returning a 405 with a Tomcat HTML page.

I tried redirecting all errors through an ErrorServlet with:

<error-page>
    <location>/ErrorServlet</location>
</error-page>

Which just makes sure that the content body is 0. But that doesn't seem to intercept these.

So why is TRACE being treated differently?

Thanks

Iain
  • 29
  • 1
  • 1
  • 9

1 Answers1

0

It makes perfect sense to me, because in all cases except TRACE you're submitting a requests for a web resource identified by a URL and code 403 means that an access to the resource is denied. Try to get access to the same resource using allowed methods. Probably it's forbidden for them as well?

TRACE on the other hand doesn't require an access to any resource, it simply echoes the client's input, so 405 ("METHOD NOT ALLOWED") looks appropriate for this case.

It's a good idea to have custom error pages. Examples specific for each error code can be found here: https://serverfault.com/questions/254102/custom-error-pages-on-apache-tomcat

Community
  • 1
  • 1
Oleg Gryb
  • 5,122
  • 1
  • 28
  • 40
  • Thanks. Well we're trying to always return empty bodies as it is a rest api with no view elements. So sending back html to the C++ client is a bit of a waste. We want to try and suppress all of tomcats normal error pages for security. – Iain Jul 31 '14 at 15:29
  • Adding a specific error page of /ErrorServlet for 405 pages seems to have done the trick. – Iain Jul 31 '14 at 15:33
  • Security wise, it's a good idea that makes perfect sense for API, however if you're dealing with live users and browsers, it would be nice to generate a generic message without providing any technical details - it'll make hacker's life more difficult :) – Oleg Gryb Jul 31 '14 at 15:33