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

Форум программистов > PHP: Общие вопросы > XSS Link Cleaner

Автор: kat_ru 4.3.2008, 15:44

Насколько актуальна функция ниже? Критика, пожелания, что можно или нужно изменить - исправить? Если не сложно как? Заранее благодарен за ответ. Код     function XSSLinkCleaner() {         $flag = 0;         $QString = html_entity_decode( urldecode( $_SERVER['QUERY_STRING'] ) );         $var = explode("&", $QString);              foreach($var as $k => $v) {                 if (                     !strpos($v, "<")  and !strpos($v, ">")  and                     !strpos($v, "'")  and !strpos($v, "/")  and                     !strpos($v, ".")  and !strpos($v, ",")  and                     !strpos($v, "|")  and !strpos($v, "%")  and                     !strpos($v, ";")  and !strpos($v, "*")  and                     !strpos($v, "?")  and !strpos($v, "}")  and                     !strpos($v, "{")  and !strpos($v, "]")  and                     !strpos($v, "[")  and !strpos($v, "+")  and                     !strpos($v, "-")  and !strpos($v, "(")  and                     !strpos($v, ")")  and !strpos($v, "^")  and                     !strpos($v, "$")  and !strpos($v, "~")  and                     !strpos($v, "@")  and !strpos($v, "!")  and                     !strpos($v, " ")  and !strpos($v, "\"") and                     !strpos($v, "\\") and !strpos($v, "^")  and                     !strpos($v, "`")  and !strpos($v, ":")                 ) {                     if (!is_null($v) and $v !== "") $var_tmp[] = $v;                 } else $flag = 1;             }             if (isset($var_tmp) and count($var_tmp) > 0) {                 foreach($var_tmp as $k => $v) {                     $NQString .= ($k == 0) ? "?".$v : $v;                 }             } else $NQString = "?";             if ($flag == 1) header("Location: ".$NQString."", TRUE, 301);     }

Автор: A1ekcandr 4.3.2008, 15:51

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

Автор: mishaSL 4.3.2008, 16:44

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

Автор: GeneralElectric 4.3.2008, 16:51

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

Автор: kat_ru 4.3.2008, 17:42

Например так? Код     function XSSLinkCleaner() {         $flag = 0;         $QString = html_entity_decode( urldecode( $_SERVER['QUERY_STRING'] ) );         $var = explode("&", $QString);         $preg = "[!|@|#|\\$|%|\^|&|\*|\(|\)|-|_|<|>|\?|,|;|:|\"|'|`|~|\\\|\||{|}|\[|\]]";         if (is_array($var) and count($var) > 0) {             foreach ($var as $k => $v) {                 if (!is_null($v) and $v !== "") {                     if (preg_match($preg, $v)) $flag = 1;                     else $NQString .= ($k == 0) ? "?".$v : "&".$v;                 }             }             if ($flag == 1) {                 $NQString = ($NQString == "" or is_null($NQString)) ? "?" : $NQString;                 header("location: ".$NQString."", true, 301);             }         }     } GeneralElectric     Избавить адресную строку от ненужных символов... Хотя наверно проще и надежней сделать список только разрешенных символов.

Автор: source777 5.3.2008, 00:29

Цитата   $preg = \"[!|@|#|\\\\$|%|\\^|&|\\*|\\(|\\)|-|_|<|>|\\?|,|;|:|\\\"|\'|`|~|\\\\\\|\\||{|}|\\[|\\]]\"; Прочитай описание синтаксиса регэкспов и поясни нафига ты этот забор из | построил? Цитата(kat_ru @  4.3.2008,  17:42 ) Хотя наверно проще и надежней сделать список только разрешенных символов. Вот именно, а ещё лучше сразу весь URI проверить на соответствие: |^[a-z 0-9\\.:_-/]+$|i  P.S. Что тут на форуме за злобный баг, слеши обратные расставляющий???

Автор: kat_ru 5.3.2008, 01:45

Цитата(source777 @  5.3.2008,  00:29 ) Цитата(kat_ru @  4.3.2008,  17:42 Найти цитируемый пост) Хотя наверно проще и надежней сделать список только разрешенных символов. Вот именно, а ещё лучше сразу весь URI проверить на соответствие: |^[a-z 0-9\\.:_-/]+$|i  P.S. Что тут на форуме за злобный баг, слеши обратные расставляющий??? У меня с регулярками туго... ((( Не понимаю и писец... Перечитывал уже раз 10 на php.net Если не сложно можете по символьно объяснить логику вот этого выражения: " |^[a-z 0-9\\.:_-/]+$|i  "

Автор: SelenIT 5.3.2008, 03:36

Цитата(kat_ru @  5.3.2008,  01:45 ) по символьно объяснить логику вот этого выражения: " |^[a-z 0-9\\.:_-/]+$|i  "  | - открывающий ограничитель шаблона ^ - начало строки [ - начало символьного класса, допускающего: a-z - лат.буквы   - пробел (не понимаю только, нафига он в урле — по-моему, он лишний) 0-9 - цифры (можно написать короче - \d) \\ - обратный слеш (заэкранирован, чтобы PHP не подумал, что это заэкранированная точка. Кстати, в урле обратный слеш, имхо, тоже не нужен) . : _ / - любой из этих символов - - вообще-то, между символами внутри квадратных скобок задает диапазон символов. Но в данном случае начало диапазона (_ - 0x5F) находится в кодовой таблице раньше его конца (/ - 0x2F), поэтому, судя по http://www.php.net/manual/ru/reference.pcre.pattern.syntax.php Цитата Символ минус '-' внутри класса используется для задания символьного диапазона. Например, [d-m] соответствует любому символу, находящемуся между 'd' и 'm', включая сами символы 'd' и 'm'. В случае, если '-' необходим, как член класса, он должен находиться в такой позиции, в которой он не может интерпретироваться как диапазон (как правило, это первый и последний символ описания класса) либо экранироваться при помощи обратного слеша. будет интерпретироваться как собственно дефис. Лучше, конечно, подобных неоднозначностей не допускать и следовать совету выше. ] - конец символьного класса + - означает, что входящие в класс символы могут встречаться один и более раз $ - конец строки. | - закрывающий ограничитель шаблона i - http://www.php.net/manual/ru/reference.pcre.pattern.modifiers.php, указывающий на независимость от регистра Все вместе означает, что строка должна от начала до конца состоять из ненулевого количества символов, перечисленных в классе, без учета регистра букв.

Автор: source777 6.3.2008, 00:27

Цитата(SelenIT @  5.3.2008,  03:36 ) \\\\ - обратный слеш (заэкранирован, чтобы PHP не подумал, что это заэкранированная точка. Кстати, в урле обратный слеш, имхо, тоже не нужен) [cuted]он не заэкранирован, это как раз заэкранированная точка, но этот дурацкий форум добавляет обратные слеши в моих сообщениях и к кавычкам \" \' и к обратным слешам \\... ТАМ ДОЛЖЕН БЫТЬ ОДИН ОБРАТНЫЙ СЛЕШ, А НЕ ДВА. не смогли на форуме нормально addslashes, stripslashes применить... Цитата Лучше, конечно, подобных неоднозначностей не допускать и следовать совету выше Да, дефис лучше заэкранировать, но в свете вышеобозначенной проблемы, это добавило бы ещё больше неоднозначностей из за повторного экранирования слешей движком форума... Цитата(SelenIT @  5.3.2008,  03:36 )  пробел (не понимаю только, нафига он в урле — по-моему, он лишний) По всякому бывает, пример Wkipedia нормально обрабатывает пробелы в URL, так что может и пригодиться, но это конечно по желанию... kat_ru, общий смысл |^[a-z 0-9\\.:_-/]+$|i состоит в том, чтобы проверить, что URL состоит из латинских букв, цифр, пробелов, точек, значков подчёркивания, дефисов, двоеточий, прямых и обратных слешей.  Ещё более мощным решением будет вырезать из URL все символы кроме вышеобозначенных, тогда сайт даже не заметит, что была попытка ввести какие-то иные символы... P.S. Поскольку я уже отчаялся добиться от этого форума вменяемой работы, то смотри вложение, надеюсь хотя бы его форум не испаганит... Код там 100%-рабочий вместе с большим комментарием...

Автор: Хрипа 6.3.2008, 10:25

Я делаю так: Код $arr = array_merge($_POST,$_GET); foreach($arr as $key => $value) $arr[$key] = mysql_escape_string(strip_tags($value)); Если у вас уже готовый скрипт то интегрировать можно так: Код foreach($_GET as $key => $value) $_GET[$key] = mysql_escape_string(strip_tags($value));

Автор: solenko 6.3.2008, 11:00

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

Автор: flashaa 6.3.2008, 11:46

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

Автор: SelenIT 6.3.2008, 12:54

Цитата(source777 @  6.3.2008,  00:27 ) это как раз заэкранированная точка В квадратных скобках точку экранировать не надо. Цитата(source777 @  6.3.2008,  00:27 ) пример Wkipedia нормально обрабатывает пробелы в URL Сорри, прошу доказательств. Желательно не через браузер (который любезно сам заменяет пробелы на %20 при сабмите), а в виде скриншота сессии телнета.

Автор: kat_ru 6.3.2008, 14:07

Цитата А смысл в такой фильтрации на входе? Фильтровать нужно: 1. На этапе вставки в базу (от того, тчо может вызвать креш базы) 2. На выводе данных (от всего, чего мы не ждем в выводе) А то как-то сомнительна практическая ценность получается. 1. Как сохранить html (это нужно практически в каждом проекте)?  2. Вы расчитываете, что в базе у вас корректные данные, т.к. вы их туда вставили. Но вы забываете, что отдаете проект заказчику. И он может, например, импортировать данные в базу минуя ваши фильтры. предположим на страничке есть <div id="main"></div> в случае если зайти на страничку по такой ссылке: http://host/?a=<script&gt;getElementById('main').innerHTML=XSS Here!</script> то это и будет XSS. Цитата Я делаю так: Выделить всёкод PHP 1: 2:      $arr = array_merge($_POST,$_GET); foreach($arr as $key => $value) $arr[$key] = mysql_escape_string(strip_tags($value)); Если у вас уже готовый скрипт то интегрировать можно так: Выделить всёкод PHP 1:      foreach($_GET as $key => $value) $_GET[$key] = mysql_escape_string(strip_tags($value)); Для POST данных нужен немного другой подход... ибо каждая форма имеет свой обработчик. А например mysql_escape_string (кстати: mysql_real_escape_string) не сработает и даже выведет ошибку в случае если нет активного соединения с БД... Код    function XSSLinkCleaner() { ........................             if ($flag == 1) {                 $NQString = ($NQString == "" or is_null($NQString)) ? "?" : $NQString;                 header("location: ".$NQString."", true, 301);             }         }     } строка "header("location: ".$NQString."", true, 301);" 301 Статус заголовка HTTP скажет поисковикам например, что страница переехала окончательно и накопленный рейтинг надо бы перенести на $NQString. Ведь если на множество форумов распространят ссылку http://host/?a=<script&gt;getElementById('main').innerHTML=&quot;XSS Here!";</script> то это цитируемость страницы... которая переместиться на http://host/? Поправьте если не прав... Спасибо всем! Думаю вопрос решен...

Автор: SelenIT 6.3.2008, 14:24

Цитата(kat_ru @  6.3.2008,  14:07 ) в случае если зайти на страничку по такой ссылке: http://host/?a=<script&gt;getE...).innerHTML=XSS Here!</script> то это и будет XSS. Да ну? Яваскрипт из адресной строки может выполниться в одном случае - по "ссылке" с "протоколом" javascript:. Другое дело, если в коде страницы где-то вызывается echo $_GET['a']  без проверки (например, перед результатами поиска отображается сама поисковая фраза) - тогда да, возможностей "творчески переосмыслить" эту страницу масса . Но это как раз второй случай в списке solenko. Цитата(kat_ru @  6.3.2008,  14:07 ) кстати: mysql_real_escape_string) не сработает и даже выведет ошибку в случае если нет активного соединения с БД... Правильно, это ее документированное поведение. Потому что зачем она нужна, если не собираетесь ничего записывать? А если собираетесь - то почему не готовы? ;)

Автор: source777 6.3.2008, 16:49

Цитата(solenko @  6.3.2008,  11:00 ) А смысл в такой фильтрации на входе? Смысл очень большой, и состоит он в том, чтобы показывалась нормальная страница, если пользователь случайно или специально введёт что-то типа кавычки, вместо какого-нить невменяемого сообщения типа страница не найдена... Никто не отменяет фильтрацию при обращении к БД, но это оффтопик в данном случае... Цитата(SelenIT @  6.3.2008,  12:54 ) Сорри, прошу доказательств. Желательно не через браузер (который любезно сам заменяет пробелы на %20 при сабмите), а в виде скриншота сессии телнета.  Если ты не заметил, там сначала urldecode вызывается, след никаких %20 в строке уже не будет, а вот пробелы будут. яснышко? Цитата(SelenIT @  6.3.2008,  12:54 ) В квадратных скобках точку экранировать не надо. ничего, не помешает.

Автор: Feldmarschall 6.3.2008, 17:00

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

Автор: source777 7.3.2008, 00:58

Цитата(Feldmarschall @  6.3.2008,  17:00 ) Во-первых, solenko задал вопрос про фильтрацию не тебе, а Хрипа.  Да? Где это указано в его сообщении? Цитата(Feldmarschall @  6.3.2008,  17:00 ) Во-вторых, не теряй нить разговора с SelenIT. Речь шла о том, что пробела никакого в урле быть, разумеется, не может.И википедия, разумеется, никакие пробелы в урле не понимает. Это должно быть понятно любому человеку, который хоть непного представляет себе работу протокола НТТР, в котором пробел является служебным символом. Тем более, что SelenIT подробно все объяснил. Это я подробно всё объяснил, а ты RTFM по функции urldecode, может уразумеешь откуда там пробелы берутся... Причём я это уже объяснял, но ты НАСТОЛЬКО невнимательно читаешь реплики собеседников, что даже не заметил...

Автор: SelenIT 7.3.2008, 01:04

source777, мы с Feldmarschallом прицепились исключительно к фразе Цитата(source777 @  6.3.2008,  00:27 ) пример Wkipedia нормально обрабатывает пробелы в URL Тут уж урлдекодом не отбиться, придется отвечать за сказанное . Хотя, если вдуматься, фраза Цитата(source777 @  5.3.2008,  00:29 ) ещё лучше сразу весь URI проверить на соответствие: |^[a-z 0-9\\.:_-/]+$|i  тоже явно не подразумевала URL-декодирование (по определению URI), так что нефиг отмазываться

Автор: source777 7.3.2008, 01:22

Цитата(SelenIT @  7.3.2008,  01:04 ) тоже явно не подразумевала URL-декодирование (по определению URI), так что нефиг отмазываться это было очевидное(из кода) идеоматическое сокращение \"URI после обработки функцией urldecode\"(откуда ж я знал, что здесь даже комодераторам надо всё разжевывать...), а вы бы лучше на код внимательнее смотрели, тогда бы понимали что имеется в виду!..

Автор: SelenIT 7.3.2008, 01:28

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

Автор: source777 7.3.2008, 01:29

Цитата(SelenIT @ 7.3.2008,  01:04) source777, мы с Feldmarschallом прицепились исключительно к фразе Цитата(source777 @  6.3.2008,  00:27 ) пример Wkipedia нормально обрабатывает пробелы в URL Тут уж урлдекодом не отбиться, придется отвечать за сказанное Да уж вы  с Feldmarschallом, напоминает название одного фильма \"...ой и ещё ...ее\", с точки зрения пользователя, он вводит пробел, и его не колышит, что он сначала заменяется на %20, а потом на _. К тому же %20 - это в данном случае есть ничто иное как обозначение пробела и его вполне корректно пробелом и называть...  Яснышко?

Автор: Feldmarschall 7.3.2008, 01:33

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

Автор: SelenIT 7.3.2008, 01:35

Цитата(source777 @  7.3.2008,  01:29 ) с точки зрения пользователя, он вводит пробел, и его не колышит Вот я, как пользователь, которого не колышет, и попросил показать пример - в телнете . Почему нельзя, если это корректно? Цитата(source777 @  7.3.2008,  01:29 ) К тому же %20 - это в данном случае есть ничто иное как обозначение пробела и его вполне корректно пробелом и называть... Логично... Если на сарае написано известно что (любимое слово Арт.Лебедева), значит, сарай - это оно самое и есть   Так, что ли, по этой логике? Программирование - это область точной науки. Играть со словами и убеждать самого себя "да я ж совсем другое имел в виду" тут бессмысленно - программа все равно будет делать не это, а буквально то, что ты ей сказал. Яснышко?   Добавлено через 1 минуту и 20 секунд ...ох, придет сейчас PARROT и надерет нам всем троим уши...

Автор: Feldmarschall 7.3.2008, 01:40

SelenIT, давай отстанем от википедии. В конце концов, яндекс тоже корректно обрабатывает пробелы в урле. Если говорить о раскодированном варианте. Ведь нас, по большому счету, интересует не уличить друг дружку в неправоте, а сделать нормальную функцию. Чем и предлагаю совместно заняться =) Для начала я бы четко ограничил область её  применения. В каких случаях нас интетесует защита от XSS?

Автор: SelenIT 7.3.2008, 01:49

Feldmarschall, хм... мне казалось, что насчет применимости все по местам давно http://forum.vingrad.ru/index.php?showtopic=199171&view=findpost&p=1434482 solenko, а дальше пошел чистый флейм...

Автор: Feldmarschall 7.3.2008, 01:57

Я не могу настаивать на своем мнении, но мне кажется, что solenko отвечал не автору. Возможно, я так думаю потому, что сам хотел ответить Хрипа то же самое. По сути же вопроса комментарий solenko не совсем в тему: переданное в квери стринг обычно не пишут в базу. Но эти рассуждения, как раз, хорошая база для определения области применения. Значит, с при помещении в базу у нас все просто: на входе мускулевский искейп, на выходе - htmlspecialchars. И никаких XSS. Теперь переходим к обработке урлов.  Тут тоже, наверное, не стоит резать все чохом, а обрабатывать только там, где нужно. Насколько я себе представляю механизм, мы делаем поиск с пространичным выводом: Код ?query=word&page=1 и подставляем это дело в ссыки на страницы. malicious user подпихивает нам вместо word конструкцию, которую мы сами, своими руками, пишем в ссылку. так?

Автор: SelenIT 7.3.2008, 02:11

Feldmarschall, пожалуй, ты прав. Меня сбило с толку, что следующим постом автор ответил solenko. Цитата(Feldmarschall @  7.3.2008,  01:57 ) malicious user подпихивает нам вместо word конструкцию, которую мы сами, своими руками, пишем в ссылку. так? Так. Получается, теоретически там может быть (после URL-декодирования) что-то вроде " onclick="злобный_скрипт_в_одну_строку". Но опять же, опасно это только при выводе в HTML и точно так же обезвреживается htmlspecialchars-ом, разве нет? Опять же, если мы собираем ссылки руками, скорее всего мы их сразу же урленкодим (напр., тем же http_build_query), а что опасного может быть в заурленкоденной строке?

Автор: Feldmarschall 7.3.2008, 09:31

Цитата(SelenIT @  7.3.2008,  02:11 )  Но опять же, опасно это только при выводе в HTML  Ну так я ведь и пишу именно о самом, что ни на есть, выводе в HTML. Цитата(SelenIT @  7.3.2008,  02:11 ) скорее всего мы их сразу же урленкодим  О! А вот это в самую точку. Действительно - urlencode-им. А саму строку поиска, выводимую в поле формы - htmlspecialchars-им. Получается, именно эти две функции гарантируют нас от XSS? вроде бы, они предусамтривают все варианты вывода данных обратно юзеру... Или нет?

Автор: SelenIT 7.3.2008, 11:41

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

Автор: Feldmarschall 7.3.2008, 11:50

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

Автор: source777 7.3.2008, 13:18

Цитата(Feldmarschall @  7.3.2008,  01:33 ) Если этот рег просматривает строку после декодирования, то в нем не хватает как минимум поддержки русских букв. И многих других символов, вполне передающихся через квери стринг.  Да, пож-та добавляй, я ж и про пробел говорил, что это на усмотрение разработчика, ибо нет такой цели охватить все валидные символы(\" \' к ним тоже относятся), есть цель ограничить допустимые символы теми, которые будут использоваться... Цитата(SelenIT @  7.3.2008,  01:35 ) Программирование - это область точной науки. Играть со словами и убеждать самого себя "да я ж совсем другое имел в виду" тут бессмысленно - программа все равно будет делать не это, а буквально то, что ты ей сказал. Яснышко?  smile Поверь мне, это всё такая фигня по сравнению с тем, что весами измеряют массу!

Автор: SelenIT 7.3.2008, 13:45

Цитата(source777 @  7.3.2008,  13:18 ) это всё такая фигня по сравнению с тем, что весами измеряют массу! Засчитано    . Но помнить об этой тонкости все же стоит - мало ли, вдруг придется взвешивать что-либо в падающем самолете, напр., для проверки, выдержит ли парашют... ;)

Автор: Feldmarschall 7.3.2008, 16:54

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

Автор: source777 7.3.2008, 17:30

Цитата(Feldmarschall @  7.3.2008,  16:54 ) source777, как показало наше небольшое исследование, цель ограничить допустимые символы не имеет прямого отношения к исходной задаче - защите от XSS зато попутно обеспечивает первый уровень защиты от SQL-инъекций. Да и топик-стартер сказал, что он понимает под XSS: Цитата(kat_ru @  4.3.2008,  17:42 ) Избавить адресную строку от ненужных символов... естественно это имеет мало общего с XSS в принципе, однако именно в этом и была исходная задача...

Автор: SelenIT 7.3.2008, 17:32

Цитата(Feldmarschall @  7.3.2008,  16:54 ) отдельным пунктом идет информация, помещаемая в теги <script> А когда такое бывает нужно? Имхо, кто вставляет юзерские данные в теги <script>, тому никакая фильтрация не поможет...

Автор: kat_ru 7.3.2008, 17:41

Цитата http ://host/1.php?page=1&a=%3Cscript%3Ealert(123);%3C/script%3E Не совсем красивая ссылка не правда ли? Да и действительно вдруг забудешь вот - это? Цитата О! А вот это в самую точку. Действительно - urlencode-им. А саму строку поиска, выводимую в поле формы - htmlspecialchars-им. в этом случае редирект с 301 статусом на адрес http ://host/1.php?page=1 будет куда лучше и полезнее... ;) а относительно - пробелов, кириллицы и т.п. дык это индивидуально )))

Автор: Feldmarschall 7.3.2008, 17:45

SelenIT, перейди в список тем форума, и подведи мышку к знаку вопроса в квадратных скобочках ;-) А потом согласись, что это весьма распространенная практика source777, у SQL инъекций, как и у осетрины, не бывает уровней свежести. уровень только один. данные прослешиваются обкавычиваются управляющие элементы выбираются из вариантов, заранее прописаных в скрипте, или приводятся к инту. Все.  Больше никаких уровней нет. Тут наоборот - чем больше уровней, тем меньше защита. У семи нянек дитя без глазу - говорит русская пословица. Один уровень, но сделанный с пониманием проблемы, надежнее десяти, но основанных на слухах и домыслах. Именно поэтому я хочу решать исходную задачу, а не то, что написал автор. Добавлено через 14 минут и 7 секунд kat_ru, об этом и речь. Что есть универсальные решения, которые работают для любых случаев, а есть системы, состоящие из заплаток, ставящихся "индивидуально". Здесь тот же самый неверный подход, который мы видим в борьбе с SQL инъекциями. Прослешивание/обкавычивание нужно делать всегда. Не только, и не столько ради защиты, а потому что синтаксис такой. И добавлять к этому синтаксису проверки на разнообразные "вредные символы" - бессмысленно. И вредно. Получается, у нас не база данных, а дискотека с фейсконтролем.  Так и в твоем случае. Урленкодить надо всегда. Не потому что защита, а потому что синтаксис такой.  Соблюдаешь ты синтаксис пхп? И синтаксис хтмл надо соблюдать.

Автор: source777 7.3.2008, 18:41

Цитата(Feldmarschall @  7.3.2008,  17:45 ) source777, у SQL инъекций, как и у осетрины, не бывает уровней свежести. уровень только один. данные прослешиваются обкавычиваются управляющие элементы выбираются из вариантов, заранее прописаных в скрипте, или приводятся к инту. Все.  Больше никаких уровней нет. Вот от такой точки зрения и получается куча кривых сайтов, которые URL типа http://site/page/\'1 никогда не отобразят так же как http://site/page/1, а как говорится сообщение об ошибке - первый шаг к завершению взлома..  Лишая защиту многоуровневости - ты лишаешь сайт многих разных вкусностей, например лога попыток SQL-инъекций, для дальнейшего забанивания IP. Цитата(Feldmarschall @  7.3.2008,  17:45 ) Тут наоборот - чем больше уровней, тем меньше защита. У семи нянек дитя без глазу - говорит русская пословица. Один уровень, но сделанный с пониманием проблемы, надежнее десяти, но основанных на слухах и домыслах. Кстати многоуровневая система защиты применяется везде, где хоть чуточку думают о безопасности... Цитата(Feldmarschall @  7.3.2008,  17:45 ) Что есть универсальные решения, которые работают для любых случаев, а есть системы, состоящие из заплаток, ставящихся "индивидуально". Ууу, как всё запущено, обзови ещё это священным Граалем и поклоняйся ему...  Пока ты ничего универсального правда не придумал... ведь вышеописанную ситуацию твой код обработать не сможет, т.к. получит либо \'1, либо 0, но никак не нужное значение = 1.

Автор: kat_ru 7.3.2008, 18:52

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

Автор: SelenIT 7.3.2008, 20:46

Цитата(Feldmarschall @  7.3.2008,  17:45 ) перейди в список тем форума, и подведи мышку к знаку вопроса в квадратных скобочках ;-) Каюсь, ни одной не нашел. И сам ни разу не встречался... Цитата(source777 @  7.3.2008,  18:41 ) куча кривых сайтов, которые URL типа http://site/page/\'1 никогда не отобразят так же как http://site/page/1 Имхо, как раз отображать одно и то же для разных урлов - криво, и с точки зрения SEO, и чисто эстетически. Я бы для первого урла выдавал 404 и не парился. Цитата(source777 @  7.3.2008,  18:41 ) не нужное значение = 1 Чем это оно нужное? Очевидно же, что это ошибка, равно как и http://site/page/nepomnuvrodebylo1 - нет такого раздела, и баста... Цитата(source777 @  7.3.2008,  18:41 ) Лишая защиту многоуровневости - ты лишаешь сайт многих разных вкусностей, например лога попыток SQL-инъекций Где связь? И чем фильтрация query_string-а может помочь логированию иньекций? Имхо, наоборот помешает - насколько я понял, при твоем подходе для описанной ситуации в лог запишется безобидная единичка...  Если на то пошло, то настоящая многоуровневость - это именно то, за что ратует Feldmarschall, когда с каждой заразой борются прицельно в том месте, где она может дать о себе знать: с SQL-иньекцией (включая лог попыток таковой) - при составлении запроса, с XSS - при выводе. И лишает ее как раз попытка нагородить все заборы в одном месте, как в том анекдоте ("...надеть ср-во от гол. боли, намазать йодом, надеть поверх другое, намазать зеленкой, перебинтовать... и никаких половых контактов!").

Автор: source777 7.3.2008, 21:42

Цитата(SelenIT @  7.3.2008,  20:46 ) Чем это оно нужное? Очевидно же, что это ошибка Это такая же ошибка, как и то, что возможно универсальное решение... В мире так мало что универсально, даже законы сохранения имеют границы применимости, поэтому любое \"универсальное\" решение имеет как минимум одну ошибку...

Автор: SelenIT 7.3.2008, 21:54

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 этого юзера "на карандаш", чтоб при повторном подозрительном запросе забанить его (если хочется;)...

Автор: Feldmarschall 7.3.2008, 22:05

SelenIT, вы незаметно перешли к обсуждению вопросов юзабилити. А эти вопросы, в отличие от технических, действително имеют много вариантов решения.  Думаю, тут давно уже пора поставить точку.  Каждый остался при своем мнении, и врядли его уже изменит. Хочу сказать спасибо автору и source777 за то, что они заставили меня лишний раз задуматься о проблеме XSS и придумать приемлемое универсальное решение. Жаль только, что source777 не привел конкретных примеров неудачности универсального решения, а ограничился общими фразами о том, что это плохо. Подход kat_ru... Не знаю. Наверное, имеет право на существование. Он сродни волшебным кавычкам: "а вдруг сам прослешить забудешь? Лучше мы на автомате все входящее прослешим! а что данные побьются, то это не беда. пострипаем при нужде".

Автор: SelenIT 7.3.2008, 22:14

Цитата(Feldmarschall @  7.3.2008,  22:05 ) вы незаметно перешли к обсуждению вопросов юзабилити Имхо, тут вопрос на стыке юзабилити и защитного программирования, а именно - что делать с мусором на входе. Безотносительно к юзабилити (которым ради безопасности, действительно, и малость пожертвовать не грех) я категорически не согласен с вариантом, при котором мусор на входе рассматривается как вариант штатного случая, да еще идет гадание, какого именно. Цитата(Feldmarschall @  7.3.2008,  22:05 ) примеров неудачности универсального решения Сорри, тут уже я потерял нить, что мы в итоге приняли за таковое? У меня сложилось мнение, что речь была о чем-то абстрактном  Цитата(Feldmarschall @  7.3.2008,  22:05 ) спасибо автору и source777 +1 Цитата(Feldmarschall @  7.3.2008,  22:05 ) Подход kat_ru... Не знаю. Наверное, имеет право на существование. В каких ситуациях?

Автор: Feldmarschall 7.3.2008, 22:26

Ну, жили же волшебные кавычки много лет. И до сих пор живут на многих сайтах.  Но вреда-то от них не так уж много. Ну поругается немного source777, на неверно отображённый рег, но это ведь не смертельно =) Цитата(SelenIT @  7.3.2008,  22:14 ) что мы в итоге приняли за таковое? Ну, я для себя решил, что htmlspecialchars+rawurlencode предохраняют меня от XSS. Буду рад услышать возражения.

Автор: source777 7.3.2008, 22:34

Цитата(Feldmarschall @  7.3.2008,  22:05 ) придумать приемлемое универсальное решение. так приемлимое или универсальное? ты его сформулируй в виде кода и определись, ибо слова \"универсальное\" и \"приемлимое\" явно несочетаемы...

Автор: SelenIT 7.3.2008, 22:43

Цитата(Feldmarschall @  7.3.2008,  22:26 ) поругается немного source777, на неверно отображённый рег С тем багом, кстати, вообще какая-то сверхъестественная загадка. Волшебные кавычки явно ни при чем - не могут же они по-разному работать для разных пользователей? Есть шанс найти еще одно исключение для FAQ-а ;) Цитата(Feldmarschall @  7.3.2008,  22:26 ) htmlspecialchars+rawurlencode предохраняют меня от XSS Я того же мнения, плюс аксиома "все значения атрибутов - в кавычках". Для меня это общий принцип (универсальный;), на основании которого я всегда могу сделать Цитата(source777 @  7.3.2008,  22:34 ) приемлемое решение для каждого конкретного случая. И пока не вижу разумных случаев, где этого не было бы достаточно.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)