Насколько актуальна функция ниже?
Критика, пожелания, что можно или нужно изменить - исправить? Если не сложно как?

Заранее благодарен за ответ.



Это сообщение отредактировал(а) kat_ru - 4.3.2008, 15:50

зачем столько strpos в этом случае сделть легче через регулярное выражение

Согласен c A1ekcandr, проще через 1 регулярное выражение.

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

Например так?



GeneralElectric
    Избавить адресную строку от ненужных символов...
Хотя наверно проще и надежней сделать список только разрешенных символов.

Прочитай описание синтаксиса регэкспов и поясни нафига ты этот забор из | построил?

Вот именно, а ещё лучше сразу весь URI проверить на соответствие: |^[a-z 0-9\\.:_-/]+$|i 

P.S. Что тут на форуме за злобный баг, слеши обратные расставляющий???




Это сообщение отредактировал(а) source777 - 5.3.2008, 00:32

У меня с регулярками туго... ((( Не понимаю и писец... Перечитывал уже раз 10 на php.net

Если не сложно можете по символьно объяснить логику вот этого выражения: " |^[a-z 0-9\\.:_-/]+$|i  "

| - открывающий ограничитель шаблона
^ - начало строки
[ - начало символьного класса, допускающего:
a-z - лат.буквы
  - пробел (не понимаю только, нафига он в урле — по-моему, он лишний)
0-9 - цифры (можно написать короче - \d)
\\ - обратный слеш (заэкранирован, чтобы PHP не подумал, что это заэкранированная точка. Кстати, в урле обратный слеш, имхо, тоже не нужен)
. : _ / - любой из этих символов
- - вообще-то, между символами внутри квадратных скобок задает диапазон символов. Но в данном случае начало диапазона (_ - 0x5F) находится в кодовой таблице раньше его конца (/ - 0x2F), поэтому, судя по мануалубудет интерпретироваться как собственно дефис. Лучше, конечно, подобных неоднозначностей не допускать и следовать совету выше.
] - конец символьного класса
+ - означает, что входящие в класс символы могут встречаться один и более раз
$ - конец строки.
| - закрывающий ограничитель шаблона
i - модификатор, указывающий на независимость от регистра

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

[cuted]он не заэкранирован, это как раз заэкранированная точка, но этот дурацкий форум добавляет обратные слеши в моих сообщениях и к кавычкам \" \' и к обратным слешам \\... ТАМ ДОЛЖЕН БЫТЬ ОДИН ОБРАТНЫЙ СЛЕШ, А НЕ ДВА. не смогли на форуме нормально addslashes, stripslashes применить...

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

По всякому бывает, пример Wkipedia нормально обрабатывает пробелы в URL, так что может и пригодиться, но это конечно по желанию...


kat_ru, общий смысл |^[a-z 0-9\\.:_-/]+$|i состоит в том, чтобы проверить, что URL состоит из латинских букв, цифр, пробелов, точек, значков подчёркивания, дефисов, двоеточий, прямых и обратных слешей. 
Ещё более мощным решением будет вырезать из URL все символы кроме вышеобозначенных, тогда сайт даже не заметит, что была попытка ввести какие-то иные символы...

P.S. Поскольку я уже отчаялся добиться от этого форума вменяемой работы, то смотри вложение, надеюсь хотя бы его форум не испаганит... Код там 100%-рабочий вместе с большим комментарием...

Это сообщение отредактировал(а) skyboy - 6.3.2008, 00:55

Присоединённый файл ( Кол-во скачиваний: 5 )
 clear_uri.php 1,28 Kb

Я делаю так:

Если у вас уже готовый скрипт то интегрировать можно так:

А смысл в такой фильтрации на входе? Фильтровать нужно:
1. На этапе вставки в базу (от того, тчо может вызвать креш базы)
2. На выводе данных (от всего, чего мы не ждем в выводе)

А то как-то сомнительна практическая ценность получается.
1. Как сохранить html (это нужно практически в каждом проекте)? 
2. Вы расчитываете, что в базе у вас корректные данные, т.к. вы их туда вставили. Но вы забываете, что отдаете проект заказчику. И он может, например, импортировать данные в базу минуя ваши фильтры.

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

Это сообщение отредактировал(а) flashaa - 6.3.2008, 11:46

В квадратных скобках точку экранировать не надо.


Сорри, прошу доказательств. Желательно не через браузер (который любезно сам заменяет пробелы на %20 при сабмите), а в виде скриншота сессии телнета.

предположим на страничке есть <div id="main"></div>
в случае если зайти на страничку по такой ссылке: http://host/?a=<script>getE...).innerHTML=XSS Here!</script> то это и будет XSS.



Для POST данных нужен немного другой подход... ибо каждая форма имеет свой обработчик. А например mysql_escape_string (кстати: mysql_real_escape_string) не сработает и даже выведет ошибку в случае если нет активного соединения с БД...




строка "header("location: ".$NQString."", true, 301);"

301 Статус заголовка HTTP скажет поисковикам например, что страница переехала окончательно и накопленный рейтинг надо бы перенести на $NQString.

Ведь если на множество форумов распространят ссылку http://host/?a=<script>getE...L="XSS Here!";</script> то это цитируемость страницы... которая переместиться на http://host/?

Поправьте если не прав...

Спасибо всем! Думаю вопрос решен...

Да ну? Яваскрипт из адресной строки может выполниться в одном случае - по "ссылке" с "протоколом" javascript:. Другое дело, если в коде страницы где-то вызывается echo $_GET['a']  без проверки (например, перед результатами поиска отображается сама поисковая фраза) - тогда да, возможностей "творчески переосмыслить" эту страницу масса . Но это как раз второй случай в списке solenko.


Правильно, это ее документированное поведение. Потому что зачем она нужна, если не собираетесь ничего записывать? А если собираетесь - то почему не готовы? ;)

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

Если ты не заметил, там сначала 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 (все атрибуты в кавычках и т.д.) - да. По крайней мере, сам пока дыр не вижу...

Получается, развесистая функция 
а) не нужна вообще
б) тем более не нужна на входе
в) на выходе все сделает 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


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

Ну, жили же волшебные кавычки много лет. И до сих пор живут на многих сайтах. 
Но вреда-то от них не так уж много. Ну поругается немного source777, на неверно отображённый рег, но это ведь не смертельно =)


Ну, я для себя решил, что htmlspecialchars+rawurlencode предохраняют меня от XSS. Буду рад услышать возражения.

так приемлимое или универсальное? ты его сформулируй в виде кода и определись, ибо слова \"универсальное\" и \"приемлимое\" явно несочетаемы...


Это сообщение отредактировал(а) source777 - 8.3.2008, 15:59

С тем багом, кстати, вообще какая-то сверхъестественная загадка. Волшебные кавычки явно ни при чем - не могут же они по-разному работать для разных пользователей? Есть шанс найти еще одно исключение для FAQ-а ;)


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