Я поместил следующее в web.xml моего приложения, чтобы попытаться запретить PUT, DELETE и т.д .:
<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>
Хорошо, теперь:
Если я делаю запрос с методом DELETE
я получаю 403 обратно.
Если я делаю запрос с методом delete
я получаю 403 обратно.
НО
Если я делаю запрос с методом, DeLeTe
я получаю ОК!
Как я могу запретить эти нечувствительные к регистру?
Изменить: я тестирую его с помощью программы на 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
текстовое поле, в котором я набираю имя метода. Когда есть 403, генерируется исключение, которое захватывается в блоке catch.
Cache_test.jsp содержит:
<%
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());
%>
HttpWebRequest
будет без учета регистра распознавать и преобразовывать стандартные методы HTTP в верхний регистр. Кроме того, он задокументирован как разрешающий только стандартные методы HTTP. Наилучшим вариантом является использование необработанного потока TCP (например, в netcat или PuTTY raw, или telnet и т. Д.).Ответы:
Независимо от неправильного поведения Tomcat по отношению к стандарту HTTP, вы должны использовать белый список, чтобы разрешить определенные методы, а не черный список.
Например, следующий белый список заблокирует все методы, кроме чувствительного к регистру
GET
иHEAD
.(Примечание: требуется Tomcat 7+. Те, кто использует более старые версии, должны будут исследовать другие решения, например, фильтр сервлетов.)
ссылка
источник
<auth-constraint />
и тогда это только позволяет все.http-method-omission
впервые был определен в Servlet API 3.0, который реализован Tomcat 7+: tomcat.apache.org/whichversion.html . К сожалению, это означает, что это не будет работать в Tomcat 6 и старше (примечание: 5 уже EOL). Вы можете попробовать другое предложенное решение в связанном вопросе SO, который рекомендует установить два отдельныхsecurity-constraint
s - я не смог подтвердить, что один работает в 7, поэтому не включил его в этот ответ.Что ж, после быстрого тестирования на некоторых случайных серверах, содержащих
Server: Apache-Coyotte
подпись заголовка в их ответах HTTP, кажется, что вы правы, так как отправкаget / HTTP/1.1\r\nHost: <target_IP>\r\n\r\n
с простым соединением netcat работала каждый раз, когда должен был быть получен код HTTP 400.Например :
Должен сказать, что я немного шокирован, и я не удивлюсь, если в таком случае это поведение распространится на все методы HTTP / 1.1.
Вы должны заполнить отчет об ошибке в их инструменте отслеживания ошибок и отправить письмо в соответствующий список рассылки, потому что это одно ужасное нарушение RFC 2616 (см. Ниже) с плохими последствиями.
источник
get
extension-method
есть синтаксис,token
который включает все буквенно-цифровые символы и некоторые символы, а не только методы, специально перечисленные в RFC. Почти каждая часть HTTP является расширяемой, если и клиент, и сервер соглашаются с тем, как они слишком расширяются, включая определение ваших собственных строчных методов. Строка запроса "get / HTTP / 1.1" синтаксически хороша, она просто нарушает RFC, так как имя метода должно быть чувствительным к регистру.extension-method
Здесь, чтобы оставить дверь открытой для следующих RFC, это не для того, чтобы добавить свои собственные методы из области RFC и притвориться, что вы используете службы, совместимые с HTTP / 1.1. Таким образом, 400 должно быть возвращено, потому что такой метод еще не появился в последнем RFC, таким образом, сегодня это недействительный токен. Если токен действителен в отношении текущего списка методов и реализован на стороне сервера, но не разрешен, то следует вернуть 405. 501 должен быть возвращен, если метод действителен, но не реализован на стороне сервера.