Non consentire i metodi HTTP su Tomcat distingue tra maiuscole e minuscole?

Ho inserito quanto segue nel web.xml della mia applicazione per tentare di non consentire PUT, DELETE, ecc .:

 <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, quindi adesso:

Se faccio una richiesta con il metodo di DELETEottengo un 403 indietro.

Se faccio una richiesta con il metodo di deleteottengo un 403 indietro.

MA

Se faccio una richiesta con il metodo DeLeTeottengo OK!

Come posso fare in modo che non facciano distinzione tra maiuscole e minuscole?

Modifica: lo sto testando con un programma 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.Textè una casella di testo in cui sto digitando il nome del metodo. Quando c'è un 403, viene generata un'eccezione che viene catturata nel blocco catch.

Cache_test.jsp contiene:

<%
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());
%>

Indipendentemente dal comportamento errato di Tomcat rispetto allo standard HTTP, è necessario utilizzare una whitelist per consentire metodi specifici anziché una blacklist.

Ad esempio, la seguente whitelist bloccherà tutti i metodi tranne il maiuscolo / minuscolo GET e 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>

(Nota: richiede Tomcat 7+. Coloro che utilizzano versioni precedenti dovranno studiare altre soluzioni, ad esempio un filtro servlet.)

arbitro

Bene, dopo un rapido test su alcuni server casuali che contengono la Server: Apache-Coyottefirma dell'intestazione nelle loro risposte HTTP, sembra che tu abbia ragione perché l'invio get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\ncon una semplice connessione netcat ha funzionato ogni volta mentre un codice HTTP 400 avrebbe dovuto essere ricevuto.

Per esempio :

$ { 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

Devo dire che sono un po 'scioccato qui e non sarei sorpreso di vedere quel comportamento esteso a tutti i metodi HTTP / 1.1 in questo caso.

Dovresti compilare una segnalazione di bug sul loro strumento di tracciamento dei bug e inviare una mail alla mailing list appropriata perché questa è una brutta violazione di RFC 2616 (vedi sotto) con conseguenze negative.

5.1.1 Metodo

  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