Wenn Sie HTTP-Methoden unter Tomcat nicht zulassen, wird zwischen Groß- und Kleinschreibung unterschieden?

Ich habe Folgendes in die web.xml meiner Anwendung eingefügt, um zu versuchen, PUT, DELETE usw. Nicht zuzulassen:

 <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, also jetzt:

Wenn ich eine Anfrage mit der Methode von mache, DELETEbekomme ich eine 403 zurück.

Wenn ich eine Anfrage mit der Methode von mache, deletebekomme ich eine 403 zurück.

ABER

Wenn ich eine Anfrage mit der Methode von mache, DeLeTebekomme ich OK!

Wie kann ich dafür sorgen, dass diese Groß- und Kleinschreibung nicht berücksichtigt wird?

Bearbeiten: Ich teste es mit einem C # -Programm:

    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.Textist ein Textfeld, in das ich den Methodennamen eingebe. Wenn es eine 403 gibt, wird eine Ausnahme ausgelöst, die im catch-Block abgefangen wird.

Die Datei cache_test.jsp enthält:

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

Unabhängig von Tomcats falschem Verhalten in Bezug auf den HTTP-Standard sollten Sie eine Whitelist verwenden, um bestimmte Methoden anstelle einer Blacklist zuzulassen.

Die folgende Whitelist blockiert beispielsweise alle Methoden mit Ausnahme der Groß- und Kleinschreibung GET und 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>

(Hinweis: erfordert Tomcat 7+. Wer ältere Versionen verwendet, muss andere Lösungen untersuchen, z. B. einen Servlet-Filter.)

Ref

Nun, nach einem kurzen Test über einige zufällige Server, Server: Apache-Coyottederen HTTP-Antworten get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\neine Headersignatur enthalten , scheint es richtig zu sein, dass das Senden mit einer einfachen Netcat-Verbindung jedes Mal funktioniert, wenn ein 400-HTTP-Code hätte empfangen werden sollen.

Zum Beispiel :

$ { 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.@[email protected].......
..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

Ich muss sagen, dass ich hier ein bisschen schockiert bin und ich wäre nicht überrascht zu sehen, dass sich dieses Verhalten in diesem Fall auf alle HTTP / 1.1-Methoden erstreckt.

Sie sollten einen Fehlerbericht über das Fehlerverfolgungstool ausfüllen und eine E-Mail an die entsprechende Mailingliste senden, da dies eine hässliche Verletzung von RFC 2616 (siehe unten) mit schwerwiegenden Folgen ist.

5.1.1 Methode

  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