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

Ден Каминский (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), доступны для свободной загрузки (http://recursion.com/interpolique.html). Презентацию с подробным описанием метода можно посмотреть http://www.scribd.com/doc/33001026/Interpolique.

17.06.2010
http://www.opennet.ru/opennews/art.shtml?num=26997

http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=225700088

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

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

опять таки это в КАЖДЫЙ запрос надо вставлять, а не проще тогда юзать real escape string для каждого запроса?

Вот было бы что-то глобальное, как например способ с .htaccess который полностью фильтрует весь сайт целиком, тогда было бы интереснее.

оке. теперь горик-второй подождем это в бд

защита от ламо-кодеров ценой увеличения CPU time

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

Мда, ну и глупость этот чел предложил.

А че за функция b() ТО, искал искал ,так и не нашел , че за врапер, просто там еще eval добавляется, мож там еще испонения кода гденить есть ?*

Хыыыыыыыыы!!!! Особые обстоятельства детектед!!! Ми просто смотрю в будущее

я что то совсем не понял! =(
select * from table where fname=b64d("VehHU.....=")

получается, что я ему отправляю запрос вида
select * from table where fname=b64d("Jw==")
после преобразования получится один фиг
select * from table where fname='
? =\


UPDATE:

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

З.Ы. Этот треш на равне с БолдженОС прямо... каникулы чтоли такие

Метод оказался слишком кардинальным для Античата :\