2013-04-13 11 views
3

У меня странная проблема при использовании FILTER_SANITIZE_STRING на переменной (заполненной человеком). Кажется, что он линяет символ < и любой текст, который появляется после этого. Символ > остается нетронутым.FILTER_SANITIZE_STRING удаляет символ <<<<<<<<<<<<<<<<<<<<<<<<><<>

Я полагаю, он считает, что < является тегом HTML, который нужно удалить, однако за ним нет закрывающего тега, поэтому я не знаю, почему он будет вести себя так. Есть ли способ заставить его оставить < на месте и все еще дезинформировать то, как он должен?

+1

Это то, что он делает, http://php.net/manual/en/filter. filters.sanitize.php Чтобы избежать этого результата, не используйте его. – mario

+0

Что вы * хотите * это сделать? – deceze

+0

Я хочу, чтобы он дезинформировал строку, удалив теги html/php и т. Д. Что работало нормально, пока кто-то не сообщил мне, что символ <и все, что находится за ним, удалены, даже это было что-то вроде: "Blabla <это другой текст », что приведет к« Блабле ». – Sempiterna

ответ

3

Корневая проблема заключается в том, что при использовании FILTER_SANITIZE_STRING для стирания тегов HTML вы обрабатываете свой ввод как HTML. Согласно вашему описанию, ваш ввод представляет собой простой текст. Таким образом, фильтр может только повредить входные данные, как уже сообщали пользователи.

Хотя это, по-видимому, довольно популярная техника, я никогда не понимал концепцию чередования HTML-тегов в обычном тексте как метод санитарной обработки. Если это не HTML, вам не нужно заботиться о тегах HTML, по той же причине, что вам не нужно заботиться о ключевых словах SQL или командах командной строки. Это ничего, кроме данных.

Но, конечно, когда Вы вводите вашу строку в HTML после этого вам нужно, чтобы избежать его, чтобы убедиться, что:

  1. Ваши данные отображаются как есть
  2. Результат остается в силе HTML

Именно поэтому htmlspecialchars() существует. Аналогичным образом, вам необходимо использовать соответствующий механизм эвакуации, когда вы динамически генерируете любой другой код: SQL, JavaScript, JSON ...

+0

У вас там есть точка. Я пытался защитить приложение от атак, но я предполагаю, что было бы достаточно безопасно полностью пропустить FILTER_SANITIZE_STRING (или strip_tags()) и просто использовать htmlspecialchars() в самом конце, прежде чем добавлять его в базу данных, в которой я был уже делать. Это также htmlencode теги open/close php. – Sempiterna

+4

Я бы не применял 'htmlspecialchars()' перед сохранением данных. Это затрудняет его использование для чего-либо другого, отображающего его на веб-сайте. Я бы сохранил исходные исходные данные и преобразовал их при их фактическом использовании. Недостаточно заметно перегрузка утечки по требованию. –

Смежные вопросы