Такая защита от XSS сработает?

Question

[Юрий Денисов]

Добрый день! Наткнулся на статью, где автор приводит такую функцию

function defender_xss($arr){
   $filter = array("<", ">","="," (",")",";","/");
     foreach($arr as $num=>$xss){
        $arr[$num]=str_replace ($filter, "|", $xss);
     }
       return $arr;
} 
//используйте  функцию перед обработкой входящих данных:
$_REQUEST=defender_xss($_REQUEST);

так же пишет что кусок

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

вставленный в htaccess тоже даст плюс.

Вопрос вот в чём. Будет ли нормально работать такая защита? Если да, то обязательно ли использовать htaccess, или достаточно будет пропускать данные через функцию на php и всё? Какие косяки могут вылезти при использовании данной функции?

Comments

[Юрий Денисов]

и не лучше ли тупо обрезать тогда ненужные символы чем менять их на | ?

Answer 1

[Дмитрий С]

array("<", ">","="," (",")",";","/") - ну а если у Вас действительно на входе текст с кавычками и скобками?

Да и саму фильтрацию лучше делать перед выводом на страницу, дабы в БД хранились актуальные данные.

Answer 2

[Mikhail Osher]

www.php.net/manual/ru/function.htmlspecialchars.php

// upd

Защита от XSS происходит исключительно в момент рендеринга данных.

Answer 3

[Юрий Денисов]

@Hakkunamatata @Miraage т.е. получается в базу всё можно писать спокойно, проверять только на SQL инъекции, а уже при выводе во избежании недоразумений ставить htmlspecialchars? и это спасёт от XSS?

Comments

[Дмитрий С]

@denissov @OnYourLips Не знаю, что вы подразумеваете под "проверять", но экранировать строки и прогонять числа через intval перед записью в БД вроде бы не сложно

[Юрий Денисов]

@OnYourLips это статья больше про PDO вроде? Если бы я использовал PDO я бы просто готовил запрос до самого запроса. Плюс для использования класса который в конце статьи надо переписать половину сайта.

[Дмитрий С]

@OnYourLips чудесно, но вы бы прежде чем говорить, что что-то "очень глупо" хоть разобрались бы, как реализовано экранирование данных в том же PDO, которое расхваливает автор статьи. А то получается "слышу звон, да не знаю где он".

[Юрий Денисов]

@Hakkunamatata т.е. получается в полях где ожидаются только числа используем intval, а там где строки можно проверять по паттерну, если не ок то посылаем, если ок то пишем в базу предварительно на всякий случай юзая mysql_real_escape_string?

[Дмитрий С]

@OnYourLips Вы говорите штампами а суть моего поста ведь не об этом. Что действительно важно, так это с умом подходить к тому, что собираетесь сделать. Форматировать данные нужно перед записью , а уж как вы это делаете - Ваш личный выбор. Справедливости ради скажу, что и сам предпочитаю предопределённые запросы. Но не всегда им есть место.

[Юрий Денисов]

@OnYourLips т.е. я могу скачать этот класс, заинклудить его, с его помощью работать с базой и забить на sql инъекции.
Если мне надо выбрать какую-то строку то я пишу так
SELECT * FROM category WHERE id=?i', $id_for_query
Здесь получается вместо ?i будет подставлено значение $id_for_query правильно?
А для нескольких параметров делать так?
SELECT * FROM category WHERE id=?i' AND name=?s, $id_for_query, $name_for_query
Недопонял как делать update.

Answer 4

[Виталий Желтяков]

Подход совершенно правильный. Причина XSS и SQL Inj - отсутствие фильтрации пользовательских данных.

Приведённый пример фильтрации поможет только от элементарных атак, т.к. можно передавать данные используя спецсимволы и сущности.

Я лично предпочитаю строить защиту на основе "белых списков" и экранирования

Comments

[Юрий Денисов]

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

[Dmitry Demin]

@OnYourLips чем-то вы мне свидетелей иеговы напоминаете:)

[Dmitry Demin]

@OnYourLips тут я спорить не буду, однако не слишком ли вы назойливо это озвучиваете?)

[Виталий Желтяков]

@OnYourLips C Вами не соглашаются, потому что ваш подход годен для мелких обособленных задач. Прибавьте к этому, что он не охватывает всех проблем взлома через инъекции.

[Виталий Желтяков]

@OnYourLips Я её читал, даже где-то писал критику про неё. Вы не до конца понимаете механизм плейсхолдеров, поэтому всецело ему доверяете. Но белые списки и плейсхолдеры не перекрывают всех возможностей взлома через инъекции.

[Виталий Желтяков]

@OnYourLips Я же написал в самом начале - через метасимволы и сущности.