Должен ли я отклонять URL-адреса, длина которых превышает ожидаемую?

Question

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Взято по ссылке -

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

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

Сафари (браузер) - Минимум 80 000 символов будут работать».

Answer 6

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

Answer 7

Я бы сказал нет.Это просто ложная безопасность.Просто программируйте хорошо и проверяйте свои запросы на наличие плохих вещей.Этого должно быть достаточно.

Кроме того, это не перспектива на будущее.

Answer 8

Да.Если оно слишком длинное и вы в этом уверены, отклоните его как можно скорее.Если можете, отклоните его до того, как он достигнет вашего приложения (например, это сделает IISLockdown).

Однако не забудьте учитывать кодировку символов.

Answer 9

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

Answer 10

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

Answer 11

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

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

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

Answer 12

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

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

Answer 13

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

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

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

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

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

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

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