2011-01-26 2 views
0

xss.phpНастройки PHP расширение фильтра по умолчанию

<?php 
header('Content-Type:text/html; charset=UTF-8'); 

var_dump(ini_get('filter.default')); 

if (isset($_GET['name'])) { 
    echo $_GET['name']; 
    exit(); 
} 

просматривающие http://localhost/xss.php?name=%3Cscript%3Ealert('XSS')%3C/script%3E

выход:

строка (10) "unsafe_raw"

Я был под впечатлением, что это будет безопасно для уязвимостей XSS из-за фильтра расширение, но это не так! Он выводит диалоговое окно предупреждения javascript. Мои вопросы:

  • Почему фильтр по умолчанию небезопасен. Я читал, что unsafe_raw не защищает от XSS?
  • Как защитить PHP от этой уязвимости. Я мог бы изменить свой php.ini, но я бы хотел сделать это во время выполнения, но ini_set, .htaccess не работают по умолчанию в моем поле Ubuntu. Я хочу, чтобы это повлияло на время выполнения, так что все экземпляры php (при развертывании на других машинах) безопасны. Это возможно, или мне действительно нужно посыпать мой код filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS);, чтобы сделать его безопасным.

P.S: Этот код является безопасным, а также не смотря на то плохое, но если бы я мог установить его во время выполнения, было бы лучше.

<?php 
header('Content-Type:text/html; charset=UTF-8'); 

$_GET = filter_input_array(INPUT_GET, FILTER_SANITIZE_STRING); 
if (isset($_GET['name'])) { 
    echo $_GET['name']; 
    exit(); 
} 

ответ

2

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

Даже w3fools говорит:

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

Вам необходимо использовать его в сочетании с опцией _FLAG_STRIP_ * или _FLAG_ENCODE_ *, чтобы сделать его полезным.

И что касается FILTER_SANITIZE_SPECIAL_CHARS, вам лучше всего использовать только htmlspecialchars().

Почему фильтр по умолчанию небезопасен.

Чтобы не повредить существующие сценарии, настройки фильтра по умолчанию предназначены для того, чтобы ничего не делать.

Как защитить PHP от этой уязвимости. Я мог бы изменить свой php.ini, но я хотел бы сделать это с во время выполнения, но ini_set ...

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

Установка функции фильтра по умолчанию с помощью ini_set() невозможна AFAIK, потому что фильтр работает в основном как magic_quotes. Он запускается только один раз во всех исходных данных, когда PHP запускается. Вызов ini_set не влияет на существующие входные массивы.

+0

Вы должны прочитать эту запись в блоге от Rasmus => http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html. Он говорит, что не покроет его код, но использует расширение pecl, filter_raw_string безопасно! Вам больше не нужен htmlspecialchars(). – Alfred

+0

@Alfred: Я прочитал от него лучшее объяснение, не могу найти его прямо сейчас. Но он, конечно, не использует * просто * '_raw_string'. У него есть конфигурация, которая равна '$ _REQUEST = array_map_rec (" htmlspecialc ", ...)' – mario

+0

Хорошо, спасибо! Было бы здорово, если бы вы нашли ссылку как-то :). – Alfred

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