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

Если ты не заметил, там сначала urldecode вызывается, след никаких %20 в строке уже не будет, а вот пробелы будут. яснышко?

ничего, не помешает.

source777, ты очень невнимательно читаешь реплики собеседников.
Во-первых, solenko задал вопрос про фильтрацию не тебе, а Хрипа. или ты хочешь сказать, что согласен с его методом?
Во-вторых, не теряй нить разговора с SelenIT. Речь шла о том, что пробела никакого в урле быть, разумеется, не может.
И википедия, разумеется, никакие пробелы в урле не понимает. Это должно быть понятно любому человеку, который хоть непного представляет себе работу протокола НТТР, в котором пробел является служебным символом. Тем более, что SelenIT подробно все объяснил.

Да? Где это указано в его сообщении?


Это я подробно всё объяснил, а ты RTFM по функции urldecode, может уразумеешь откуда там пробелы берутся... Причём я это уже объяснял, но ты НАСТОЛЬКО невнимательно читаешь реплики собеседников, что даже не заметил...

source777, мы с Feldmarschallом прицепились исключительно к фразе

Тут уж урлдекодом не отбиться, придется отвечать за сказанное . Хотя, если вдуматься, фраза

тоже явно не подразумевала URL-декодирование (по определению URI), так что нефиг отмазываться 

это было очевидное(из кода) идеоматическое сокращение \"URI после обработки функцией urldecode\"(откуда ж я знал, что здесь даже комодераторам надо всё разжевывать...), а вы бы лучше на код внимательнее смотрели, тогда бы понимали что имеется в виду!..

source777, то, что эта фраза относилась к коду kat_ru, было абсолютно неочевидно - для большинства людей фраза, начинающаяся с "а лучше сразу <сделать по-другому>" звучит как предложение полной альтернативы, а не маленького усовершенствования 

Но во фразе про Википедию даже этими "очевидными умолчательствами" не прикрыться, там просто явный ляп  

Это сообщение отредактировал(а) SelenIT - 7.3.2008, 01:29

Да уж вы  с Feldmarschallом, напоминает название одного фильма \"...ой и ещё ...ее\", с точки зрения пользователя, он вводит пробел, и его не колышит, что он сначала заменяется на %20, а потом на _. К тому же %20 - это в данном случае есть ничто иное как обозначение пробела и его вполне корректно пробелом и называть...  Яснышко? 

source777, давай определимся.
Если этот рег просматривает строку после декодирования, то в нем не хватает как минимум поддержки русских букв. И многих других символов, вполне передающихся через квери стринг.

Вот я, как пользователь, которого не колышет, и попросил показать пример - в телнете . Почему нельзя, если это корректно?


Логично... Если на сарае написано известно что (любимое слово Арт.Лебедева), значит, сарай - это оно самое и есть   Так, что ли, по этой логике?

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

Добавлено через 1 минуту и 20 секунд
...ох, придет сейчас PARROT и надерет нам всем троим уши... 

SelenIT, давай отстанем от википедии.
В конце концов, яндекс тоже корректно обрабатывает пробелы в урле. Если говорить о раскодированном варианте.

Ведь нас, по большому счету, интересует не уличить друг дружку в неправоте, а сделать нормальную функцию.
Чем и предлагаю совместно заняться =)

Для начала я бы четко ограничил область её  применения.
В каких случаях нас интетесует защита от XSS? 

Feldmarschall, хм... мне казалось, что насчет применимости все по местам давно расставил solenko, а дальше пошел чистый флейм...

Я не могу настаивать на своем мнении, но мне кажется, что solenko отвечал не автору. Возможно, я так думаю потому, что сам хотел ответить Хрипа то же самое.

По сути же вопроса комментарий solenko не совсем в тему: переданное в квери стринг обычно не пишут в базу.

Но эти рассуждения, как раз, хорошая база для определения области применения.
Значит, с при помещении в базу у нас все просто: на входе мускулевский искейп, на выходе - htmlspecialchars. И никаких XSS.

Теперь переходим к обработке урлов. 
Тут тоже, наверное, не стоит резать все чохом, а обрабатывать только там, где нужно.
Насколько я себе представляю механизм, мы делаем поиск с пространичным выводом:

и подставляем это дело в ссыки на страницы.
malicious user подпихивает нам вместо word конструкцию, которую мы сами, своими руками, пишем в ссылку. так?

Feldmarschall, пожалуй, ты прав. Меня сбило с толку, что следующим постом автор ответил solenko.


Так. Получается, теоретически там может быть (после URL-декодирования) что-то вроде " onclick="злобный_скрипт_в_одну_строку". Но опять же, опасно это только при выводе в HTML и точно так же обезвреживается htmlspecialchars-ом, разве нет?

Опять же, если мы собираем ссылки руками, скорее всего мы их сразу же урленкодим (напр., тем же http_build_query), а что опасного может быть в заурленкоденной строке?

Это сообщение отредактировал(а) SelenIT - 7.3.2008, 03:00

Ну так я ведь и пишу именно о самом, что ни на есть, выводе в HTML.



О! А вот это в самую точку. Действительно - urlencode-им. А саму строку поиска, выводимую в поле формы - htmlspecialchars-им.

Получается, именно эти две функции гарантируют нас от XSS? вроде бы, они предусамтривают все варианты вывода данных обратно юзеру... Или нет?

Имхо, в случае корректного HTML (все атрибуты в кавычках и т.д.) - да. По крайней мере, сам пока дыр не вижу...