Получается, развесистая функция 
а) не нужна вообще
б) тем более не нужна на входе
в) на выходе все сделает htmlspecialchars

Вот теперь тема действительно соответствует статусу решённой =)

Впрочем, хотелось бы подождать мнений других участников.
Вообще, короткое и точное определение XSS (не принципа, а формализация учзвимости) не помешало бы.
А то глупо решать задачу, не представляя точно, в чем она заключается...

Да, пож-та добавляй, я ж и про пробел говорил, что это на усмотрение разработчика, ибо нет такой цели охватить все валидные символы(\" \' к ним тоже относятся), есть цель ограничить допустимые символы теми, которые будут использоваться...

Поверь мне, это всё такая фигня по сравнению с тем, что весами измеряют массу!  

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

source777, как показало наше небольшое исследование, цель ограничить допустимые символы не имеет прямого отношения к исходной задаче - защите от XSS

Разве что, отдельным пунктом идет информация, помещаемая в теги <script>.
Здесь надо разобраться с правилами экранирования.

Это сообщение отредактировал(а) Feldmarschall - 7.3.2008, 16:57

зато попутно обеспечивает первый уровень защиты от SQL-инъекций. Да и топик-стартер сказал, что он понимает под XSS:

естественно это имеет мало общего с XSS в принципе, однако именно в этом и была исходная задача...

А когда такое бывает нужно? Имхо, кто вставляет юзерские данные в теги <script>, тому никакая фильтрация не поможет...

Не совсем красивая ссылка не правда ли?
Да и действительно вдруг забудешь вот - это?


в этом случае редирект с 301 статусом на адрес http ://host/1.php?page=1 будет куда лучше и полезнее... ;)

а относительно - пробелов, кириллицы и т.п. дык это индивидуально )))

SelenIT, перейди в список тем форума, и подведи мышку к знаку вопроса в квадратных скобочках ;-)
А потом согласись, что это весьма распространенная практика

source777, у SQL инъекций, как и у осетрины, не бывает уровней свежести.
уровень только один.
данные прослешиваются обкавычиваются
управляющие элементы выбираются из вариантов, заранее прописаных в скрипте, или приводятся к инту.
Все. 
Больше никаких уровней нет.

Тут наоборот - чем больше уровней, тем меньше защита. У семи нянек дитя без глазу - говорит русская пословица.
Один уровень, но сделанный с пониманием проблемы, надежнее десяти, но основанных на слухах и домыслах.

Именно поэтому я хочу решать исходную задачу, а не то, что написал автор.

Добавлено через 14 минут и 7 секунд
kat_ru, об этом и речь.
Что есть универсальные решения, которые работают для любых случаев, а есть системы, состоящие из заплаток, ставящихся "индивидуально".

Здесь тот же самый неверный подход, который мы видим в борьбе с SQL инъекциями.
Прослешивание/обкавычивание нужно делать всегда. Не только, и не столько ради защиты, а потому что синтаксис такой.
И добавлять к этому синтаксису проверки на разнообразные "вредные символы" - бессмысленно. И вредно. Получается, у нас не база данных, а дискотека с фейсконтролем. 

Так и в твоем случае. Урленкодить надо всегда. Не потому что защита, а потому что синтаксис такой. 
Соблюдаешь ты синтаксис пхп? И синтаксис хтмл надо соблюдать. 

Вот от такой точки зрения и получается куча кривых сайтов, которые URL типа http://site/page/\'1 никогда не отобразят так же как http://site/page/1, а как говорится сообщение об ошибке - первый шаг к завершению взлома.. 
Лишая защиту многоуровневости - ты лишаешь сайт многих разных вкусностей, например лога попыток SQL-инъекций, для дальнейшего забанивания IP.

Кстати многоуровневая система защиты применяется везде, где хоть чуточку думают о безопасности...

Ууу, как всё запущено, обзови ещё это священным Граалем и поклоняйся ему... 
Пока ты ничего универсального правда не придумал... ведь вышеописанную ситуацию твой код обработать не сможет, т.к. получит либо \'1, либо 0, но никак не нужное значение = 1.



Это сообщение отредактировал(а) source777 - 7.3.2008, 18:53

Чту и уважаю! И соответственно соблюдаю.

Каюсь, ни одной не нашел. И сам ни разу не встречался...


Имхо, как раз отображать одно и то же для разных урлов - криво, и с точки зрения SEO, и чисто эстетически. Я бы для первого урла выдавал 404 и не парился.


Чем это оно нужное? Очевидно же, что это ошибка, равно как и http://site/page/nepomnuvrodebylo1 - нет такого раздела, и баста...


Где связь? И чем фильтрация query_string-а может помочь логированию иньекций? Имхо, наоборот помешает - насколько я понял, при твоем подходе для описанной ситуации в лог запишется безобидная единичка... 

Если на то пошло, то настоящая многоуровневость - это именно то, за что ратует Feldmarschall, когда с каждой заразой борются прицельно в том месте, где она может дать о себе знать: с SQL-иньекцией (включая лог попыток таковой) - при составлении запроса, с XSS - при выводе. И лишает ее как раз попытка нагородить все заборы в одном месте, как в том анекдоте ("...надеть ср-во от гол. боли, намазать йодом, надеть поверх другое, намазать зеленкой, перебинтовать... и никаких половых контактов!").

Это такая же ошибка, как и то, что возможно универсальное решение... В мире так мало что универсально, даже законы сохранения имеют границы применимости, поэтому любое \"универсальное\" решение имеет как минимум одну ошибку...

source777, я имел в виду, что для системы, ожидающей http://site/page/1, появление на входе http://site/page/'1 - явно нештатная ситуация, и   выдавать при ней тот же контент, что и для http://site/page/1 - имхо, некорректно. И вообще разные URL для одного контента - зло. В данном примере, имхо, логично (и для пользователя, и для поисковиков) выдать кастомную страницу 404 со ссылками на http://site/page/1, http://site/page/11 и т.п. ("возможно, вам нужно это?"), как это делает, например, онлайновый PHP-мануал . Плюс на всякий случай взять IP этого юзера "на карандаш", чтоб при повторном подозрительном запросе забанить его (если хочется;)...

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

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

Хочу сказать спасибо автору и source777 за то, что они заставили меня лишний раз задуматься о проблеме XSS и придумать приемлемое универсальное решение.
Жаль только, что source777 не привел конкретных примеров неудачности универсального решения, а ограничился общими фразами о том, что это плохо.

Подход kat_ru... Не знаю. Наверное, имеет право на существование. Он сродни волшебным кавычкам: "а вдруг сам прослешить забудешь? Лучше мы на автомате все входящее прослешим! а что данные побьются, то это не беда. пострипаем при нужде".

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


Сорри, тут уже я потерял нить, что мы в итоге приняли за таковое? У меня сложилось мнение, что речь была о чем-то абстрактном 


+1


В каких ситуациях?