Должен ли я отклонять URL-адреса дольше ожидаемого?

Question

Я занимаюсь разработкой приложения, и у меня есть URL в формате www.example.com/some_url/some_parameter/some_keyword. По дизайну я знаю, что максимальная длина этих URL-адресов будет максимальной (и все же будет действительной). Должен ли я проверять длину URL-адреса при каждом запросе, чтобы защитить от переполнения буфера / атак внедрения? Я считаю, что это очевидно, но я не эксперт по безопасности, поэтому, возможно, я что-то упускаю.

Answer 1

Глубокая защита - хороший принцип. Но ложные меры безопасности - плохой принцип. Разница зависит от множества деталей.

Если вы действительно уверены, что любой URL-адрес, превышающий N, является недействительным, вы можете также отклонить его. Но если это правда, и если остальная часть вашей проверки правильности ввода, то она все равно будет отклонена позже. Таким образом, все эти проверки могут, возможно, смягчить ущерб, вызванный какой-то другой ошибкой в ​​вашем коде. Часто лучше тратить время на размышления о том, как избежать этих ошибок, чем на то, что N может быть.

Если вы проверяете длину, то все же лучше не полагаться на это ограничение длины в другом месте вашего кода. Это позволяет более тесно связать различные проверки и усложнить изменение предела в следующей версии, если вы измените спецификацию и вам потребуется принимать более длинные URL-адреса. Например, если ограничение длины становится оправданием для размещения URL-адресов в стеке без должной заботы и внимания, то вы можете настроить кого-то на падение.

Answer 2

Если вы не ожидаете ввода, отклоните его.

Вы должны всегда проверять свои входные данные и, конечно, отбрасывать все, что находится за пределами ожидаемого диапазона. Если вы уже знаете, что ваш URL, по правде говоря, не будет превышать определенной длины, то отклонить его до того, как он попадет в приложение, кажется разумным.

Answer 3

Safari, Internet Explorer и Firefox имеют различную максимальную длину, которую он принимает.

Я голосую за самый короткий из трех.

http://www.boutell.com/newfaq/misc/urllength.html

Вытащено из ссылки -

" Microsoft Internet Explorer (браузер) - 2 083 символа

Firefox (Браузер) - После 65 536 символов строка адреса больше не отображает URL-адрес в Windows Firefox 1.5.x. Однако более длинные URL будут работать. Я прекратил тестирование после 100 000 символов.

Safari (Браузер) - Работает не менее 80 000 символов. "

Answer 4

Единственное, что я вижу, что может вызвать проблемы, это то, что, хотя сегодня ваш URL никогда не будет превышать N, вы не можете гарантировать, что это не будет продолжаться вечно. И через год, когда вы вернетесь к редактированию, чтобы URL-адрес имел длину N + y, вы можете забыть изменить код отклонения URL-адреса.

Вам всегда будет лучше проверить параметры URL перед их использованием.

Answer 5

как вы можете быть уверены, что все URL длиннее N недействителен? Если вы можете быть уверены, тогда не должно быть больно ограничивать это просто проверкой работоспособности - но не позволяйте этому обмануть вас, заставляя думать, что вы предотвратили класс эксплойта.

Answer 6

О боже, много ответов, много хороших моментов, так что рассыпайтесь, так что позвольте мне попытаться объединить все это. tl; dr imo, это слишком низкий уровень для кода прикладного уровня.

Да, URL может иметь длину любой , но на практике браузеры имеют ограничение. Конечно, это защищает вас от атак на браузер только тех людей, которые хотят ограничить себя этими векторами, поэтому вам нужен какой-то способ обработки активных попыток атаки.

Хорошо, это может защитить от переполнения буфера. Ну, только если вы работаете на низком уровне и не думаете о таких проблемах. Большинство языков в наши дни поддерживают строки довольно хорошо и не позволяют им просто переполняться. Если вы имели дело с какой-то очень низкоуровневой системой, фактически считывая данные в виде байтов и переводя их в строковый тип, то, конечно, у вас должен быть какой-то способ обнаружить и обработать это, но не так уж сложно выделить память, и передавайте известные суммы за раз, просто следите за тем, сколько памяти вы откладываете. Честно говоря, если вы имеете дело с этим низким уровнем, вам действительно следует использовать что-то еще.

Хорошо, а как насчет простого отклонения на основе длины строки? Основным недостатком этого является потенциал для ложного чувства безопасности. Иными словами, некоторые области кода могут быть «неаккуратными» и уязвимыми для тех самых эксплойтов, которые вы пытаетесь избежать. Вы, безусловно, должны быть осторожны, чтобы убедиться, что этот «глобальный» лимит на самом деле достаточен, но, учитывая ваш формат URI, вы можете иметь возможность, чтобы эти «части» сообщали, какова их максимальная длина, и централизовали проверку длины ( вся строка и ее составляющие); по крайней мере, таким образом, если одна часть должна допускать более длинную строку, легче справиться с изменением.

Это, конечно, имеет некоторые преимущества, например, очень быстро иметь возможность сравнивать длину строки и сразу отклонять запрос ... но не забывайте быть «хорошо себя вести» сайте вы должны отправить правильный ответ, объясняющий, почему сервер отклоняет это. Однако на практике вы действительно думаете, что вам придется справляться с таким количеством «неправильных» URL-адресов, несомненно, они будут ошибаться во многих других отношениях.

Почему-то вам не хотелось говорить, какой язык вы используете. В языках высокого уровня, таких как Java или Python, есть несколько очень хороших библиотек для работы с «веб-материалами». Java позволит вам указывать шаблоны для URI, включая использование регулярных выражений для этого шаблона, поэтому, если вам нужно имя в URL, вы можете иметь что-то вроде @Path("/person/(.{0..100}"), чтобы ограничить параметр до 100 символов. Я был бы удивлен, если бы подобие Ruby или Python не имело эквивалента, они хотели бы рекламировать себя в качестве хороших веб-языков.

Наконец, независимо от длины, есть множество вещей, которые вам нужно будет проверить, а не только длина. Необходимость беспокоиться о длине URI, вызывающей переполнение буфера, - вещь очень низкого уровня, и она должна быть очень общей, то есть должна обрабатывать любой запрос, даже один с потенциально URI 1 ГБ; заметьте, я сказал «обрабатывать», а не «принять его и передать его на прикладной уровень», он может отклонить его на этом низком уровне, что также может вызвать системные события.

Answer 7

Хорошо, давайте предположим, что такой N существует. Как уже отмечалось, неверно сформированный URL, который длиннее N символов, будет в любом случае отклонен другой проверкой ввода. Однако, на мой взгляд, это открывает совершенно новую вещь для размышлений:

Используя эту константу, вы можете проверить свою другую проверку. Если другие проверки не смогли определить определенный URL-адрес как недействительный, однако URL-адрес длиннее, чем N символов, этот URL-адрес вызывает ошибку и должен быть записан (и, возможно, все приложение должно быть закрыто, поскольку они могут создать недопустимый недействительный URL).

Answer 8

Лучше проверить, что в запросе , чем проверить длину URL.

В будущем ваши потребности могут измениться, и в этот момент вам придется удалить или изменить проверку длины URL-адреса, что может привести к ошибкам.

Если это окажется проверенной уязвимостью безопасности, вы можете реализовать ее.

Answer 9

Если вы знаете, что действительные URL-адреса не могут превышать N байтов, то это звучит как хороший способ быстро отклонить попытки межсайтового скриптинга без особых усилий.

Answer 10

Лучше, чем проверка длины, я думаю, вы должны проверить содержимое. Вы никогда не знаете, как собираетесь использовать свою схему URL в будущем, но вы всегда можете очистить свои входные данные. Проще говоря, очень сложная вещь: не доверяйте предоставленным пользователем данным. Не помещайте это непосредственно в запросы к БД, не eval (), не принимайте ничего как должное.