Опрос на LUG.RU

Как вы думаете, нужна ли интеграция с социальными сетями?:
 Хостинг, домен
Серверное оборудование

Кардинальный метод защиты от XSS и атак по подстановке SQL-запросов

Уважаемые участники LUG.RU! Напоминаем вам, что у нас есть своя jabber-конференция lug@conference.jabber.ru, которой не только можно, но и нужно переодически пользоваться. Smiling Для этого вы можете использовать любой клиент из этого списка.

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.


Ден Каминский (Dan Kaminsky), получивший известность обнаружением фундаментальной уязвимости в DNS, представил универсальную технику защиты от "SQL Injection" (подстановка SQL-запросов) и XSS (межсайтовый скриптинг) атак. Суть техники защиты от подстановки SQL-запросов в том, что при работе с пользовательскими данными в запросе к СУБД фигурируют не открытые данные, а строка в base64-представлении, в которой изначально отсутствуют спецсимволы. В отличие от традиционной практики анализа вводимых пользователем данных и экранирования опасных символов перед формированием запроса, метод Каминского по своей сути исключает человеческий фактор и возможность недосмотра при проверке.

Для наглядности рассмотрим пример. Допустим в программе имеется строка

     $conn->query("select * from table where fname=$fname;");

в случае отсутствия должных проверок в переменной $fname может оказаться SQL-код, т.е. имеет место классическая "SQL Injection" уязвимость. Следуя методике Каминского, поменяв данную конструкцию на

     $conn->query(eval(b('select * from table where fname=^^fname;')));

, где "b" - функция враппер для подстановки операций base64-кодирования для переменных, отмеченных через маркер "^^". В итоге к СУБД будет сформирован запрос:

     select * from table where fname=b64d("VehHU.....=")

как видим, какое бы ни было содержимое переменной fname при обращении к СУБД оно будет всегда представлено валидной строкой, которая будет перекодирована из base64-представления уже силами СУБД.

Похожая техника предлагается и для защиты от XSS-атак, все выводимые на страницу блоки данных изначально поступают в base64-представлении и отображаются через задействование специального JavaScript-враппера, декодирующего base64-строку и выводящего блок в заданную позицию без его интерпретации браузером.

Пример с реализацией необходимых для осуществления защиты функций на языках PHP и JavaScript, а также дополнение к MySQL с функциями обработки строк base64 (в PostgreSQL поддержка base64 реализована через штатные функции encode/decode), доступны для свободной загрузки. Презентацию с подробным описанием метода можно посмотреть здесь.

Источник.