Désactiver les méthodes HTTP sur Tomcat est-il sensible à la casse?

J'ai mis ce qui suit dans le web.xml de mon application pour tenter de refuser PUT, DELETE, etc.:

 <security-constraint>
 <web-resource-collection>
  <web-resource-name>restricted methods</web-resource-name>
  <url-pattern>/*</url-pattern>
  <http-method>DELETE</http-method>
  <http-method>PUT</http-method>
  <http-method>SEARCH</http-method>
  <http-method>COPY</http-method>
  <http-method>MOVE</http-method>
  <http-method>PROPFIND</http-method>
  <http-method>PROPPATCH</http-method>
  <http-method>MKCOL</http-method>
  <http-method>LOCK</http-method>
  <http-method>UNLOCK</http-method>
  <http-method>delete</http-method>
  <http-method>put</http-method>
  <http-method>search</http-method>
  <http-method>copy</http-method>
  <http-method>move</http-method>
  <http-method>propfind</http-method>
  <http-method>proppatch</http-method>
  <http-method>mkcol</http-method>
  <http-method>lock</http-method>
  <http-method>unlock</http-method>
 </web-resource-collection>
 <auth-constraint />
 </security-constraint>

Ok, alors maintenant:

Si je fais une demande avec la méthode de DELETEje reçois un 403.

Si je fais une demande avec la méthode de deleteje reçois un 403.

MAIS

Si je fais une demande avec la méthode de DeLeTej'obtiens OK!

Comment puis-je faire en sorte qu'ils ne respectent pas la casse?

Edit: je le teste avec un programme C #:

    private void button1_Click(object sender, EventArgs e)
    {
        textBox1.Text = "making request";
        System.Threading.Thread.Sleep(400);
        WebRequest req = WebRequest.Create("http://serverurl/Application/cache_test.jsp");
        req.Method = txtMethod.Text;
        try
        {
            HttpWebResponse resp = (HttpWebResponse)req.GetResponse();

            textBox1.Text = "Status: " + resp.StatusCode;

            if (resp.StatusCode == System.Net.HttpStatusCode.OK)
            {
                WebHeaderCollection header = resp.Headers;
                using (System.IO.StreamReader reader = new System.IO.StreamReader(resp.GetResponseStream(), ASCIIEncoding.ASCII))
                {
                    //string responseText = reader.ReadToEnd();
                    textBox1.Text += "\r\n" + reader.ReadToEnd();
                }
            }
        }
        catch (Exception ex)
        {
            textBox1.Text = ex.Message;
        }
    }

txtMethod.Textest une zone de texte où je tape le nom de la méthode. Lorsqu'il y a un 403, une exception est levée qui est interceptée dans le bloc catch.

Le cache_test.jsp contient:

<%
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
response.setHeader("Pragma","no-cache");

out.print("Method used was: "+request.getMethod());
%>

Indépendamment du comportement incorrect de Tomcat en ce qui concerne la norme HTTP, vous devez utiliser une liste blanche pour autoriser des méthodes spécifiques plutôt qu'une liste noire.

Par exemple, la liste blanche suivante bloquera toutes les méthodes sauf la casse GET et HEAD.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>HEAD</http-method-omission>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

(Remarque: nécessite Tomcat 7+. Ceux qui utilisent des versions plus anciennes devront rechercher d'autres solutions, par exemple un filtre de servlet.)

Réf.

Eh bien, après des tests rapides sur certains serveurs aléatoires détenant la Server: Apache-Coyottesignature d'en-tête dans leurs réponses HTTP, il semble que vous avez raison, car l'envoi get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\navec une simple connexion netcat a fonctionné à chaque fois alors qu'un code HTTP 400 aurait dû être reçu.

Par exemple :

$ { echo -en "get / HTTP/1.1\r\nHost: <target_IP>:8080\r\n\r\n" ; } | nc <target_IP> 8080

01:14:58.095547 IP 192.168.1.3.57245 > <target_IP>.8080: Flags [P.], seq 1:42, ack 1, win 115, options [nop,nop,TS val 4294788321 ecr 0], length 41
E..]C.@.@..Y......p.....A..v.......s.......
..D.....get / HTTP/1.1
Host: <target_IP>:8080

[...]

01:14:58.447946 IP <target_IP>.8080 > 192.168.1.3.57245: Flags [.], seq 1:1409, ack 43, win 65494, options [nop,nop,TS val 7981294 ecr 4294787971], length 1408
E...f...i.....p.............A..............
.y....C.HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Tue, 27 Jan 2015 00:15:14 GMT

Je dois dire que je suis un peu choqué ici et je ne serais pas surpris de voir ce comportement étendu à toutes les méthodes HTTP / 1.1 dans ce cas.

Vous devez remplir un rapport de bogue sur leur outil de suivi des bogues et envoyer un e-mail à la liste de diffusion appropriée car c'est une vilaine violation de la RFC 2616 (voir ci-dessous) avec de mauvaises conséquences.

5.1.1 Méthode

  The Method  token indicates the method to be performed on the
  resource identified by the Request-URI. The method is case-sensitive.

      Method         = "OPTIONS"                ; Section 9.2
                     | "GET"                    ; Section 9.3
                     | "HEAD"                   ; Section 9.4
                     | "POST"                   ; Section 9.5
                     | "PUT"                    ; Section 9.6
                     | "DELETE"                 ; Section 9.7
                     | "TRACE"                  ; Section 9.8
                     | "CONNECT"                ; Section 9.9
                     | extension-method
      extension-method = token