Этот пост является продолжением прошлой статьи, в которой шла речь о проблемах генераторов случайных чисел в PHP с примером эксплоита для Wordpress через уязвимость в phpBB2. В этот раз рассмотрим интересную особенность случайных чисел, сгенерированных с помощью функции rand(), а также способы защиты от подобного рода атак в своих веб-приложениях.
Стефан Эссер не перестает меня удивлять: в этот раз в своем блоге он рассказал об особенностях генерации случайных чисел в PHP, которые при особых условиях позволяют предугадывать случайные значения. Его находки открывают возможность для реализации совершенно новых атак – Cross Application Attacks, в основе которых лежит неправильное использование веб-приложениями функций для генерации случайных чисел. При этом одно веб-приложение, не имея полноценных уязвимостей, но обладающее погрешностью в вычислении случайных чисел, открывает дверь для реализации атаки на совершенно другое веб-приложение, находящееся на том же сервере. В качестве примера Стефан описал алгоритм проведения атаки на Wordpress через дыру в phpBB2. Так как подтверждение его концепции в виде эксплоита отсутствует, я решил провести собственное исследование и написать рабочий PoC. После нескольких дней тестирования на локальном веб-сервере, я пришел к выводу, что уязвимость действительно имеет место, и ее эксплуатация вполне реальна. В результате мной был написан эксплоит для Wordpress < = 2.6.1 посредством phpBB2, позволяющий сменить пароль администратора, не имея доступа к его почтовому ящику.
Совсем недавно известный эксперт по безопасности Стефан Эссер (Stefan Esser) опубликовал в своем блоге статью, посвященную новой уязвимости, связанной с особенностями сравнения строк и автоматического усечения данных в MySQL. Именно Стефан обнаружил знаменитую дыру zend_hash_del_key_or_index, после чего в Сети появилось множество эксплоитов для популярных веб-приложений. Похоже в этот раз дело грозит обернуться теми же последствиями.
Я уже не раз излагал свои мысли по поводу принципов грамотной фильтрации входящих данных, этот пост будет своеобразным дополнением, подкрепленным живым примером.
Недавно столкнулся с интересной SQL-инъекцией на одном популярном ресурсе, посвященному взлому и хакингу. С одной стороны, признаки успешно внедренного SQL-кода были явными, однако поведение уязвимого веб-приложения при особых запросах говорило о наличии некой фильтрации на определенные ключевые слова. Например запрос ‘ OR 1=1/* успешно проходил, но, подставив AND вместо OR, я постоянно получал пустую страницу – это, очевидно, следствие возникшей ошибки синтаксиса SQL-запроса. Проанализировав ответы скрипта, я убедился, что, во-первых, проверка на ключевые слова действительно имела место, и, во-вторых, производилась не просто проверка, а вырезание из строки запроса всех совпадений со списком ключевых слов. На PHP это выглядело бы примерно так:
<?php
$badwords = array("AND","UNION","SELECT","WHERE","INSERT","UPDATE","DELETE");
str_replace($badwords,"",$GET['id']);
?>
Обойти такую проверку сущий пустяк.
У многих разработчиков сложилось мнение, что хранимые процедуры могут спасти от любой SQL-инъекции. Напомню, что хранимые процедуры (stored procedures, SP), это функции, написанные на языке SQL, с помощью которых выполнются заранее подготовленные запросы к базе данных. Хранимая процедура, как и функция в любом другом языке программирования, имеет входные и возвращаемые данные, позволяет оперировать переменными и, самое главное, облегчает жизнь разработчику, избавляя его от однотипных рутинных работ. Немаловажным является тот факт, что хранимые процедуры позволяют динамически составлять запросы, при этом входящие в хранимую процедуру данные поступают как параметры, обладающие определенным типом и длиной, что исключает возможность SQL-инъекций. Тем не менее внедрить SQL-код можно! Рассмотрим, при каких обстоятельствах возможны SQL-инъекции в хранимых процедурах на примере MySQL.
Не так давно один из представителей группы по безопасности из компании Mozilla, а именно Brandon Sterne объявил о начале разработки специального механизма для браузера FireFox, который будет регулировать поведение веб-содержимого и политику его ограничения в среде браузера. Идея об ограничении содержимого впервые была предложена в блоге Robert «RSnake» Hansen, известного специалиста по web-безопасности. Его мысли были быстро подхвачены и развиты сотрудниками из Mozilla Security Team. В итоге общая концепция воплотилась в Site Security Policy, о котором я сегодня и хотел бы рассказать.
Всем известны два типа XSS:
Однако далеко не всем известен еще один тип XSS, а именно межсайтовый скриптинг через DOM (DOM-based или Type 0 (3) XSS). Объектная модель документа (DOM) является формой отображения иерархии HTML (а также XML) для JavaScript. XSS-атаки через DOM возможны благодаря недостаточной обработке на уровне JavaScript таких объектов DOM, как document.URL, document.location, document.referrer и некоторых других. Принципиальным отличием данного типа XSS является тот факт, что данные вообще не встраиваются в HTML-код. Несомненно, это вызывает определенные трудности для систем IDS в плане выяления фактов атак и эффективной фильтрации входящих данных, так как уязвимость заключена не на стороне серверных скриптов, а прямо в JavaScript-коде. Read more »
Если в Internet Explorer только ожидаются новые XSS-фильтры, то пользователи Firefox уже больше года имеют возможность эффективно защитить себя от различного рода межсайтовых атак, используя плагин NoScript. Данное расширение действительно заслуживает похвал, так как отлично справляется с XSS, CSRF и другими атаками. Также плагин способен блокировать Java, Flash, MS Silverlight и другие потенциально опасные компоненты веб-страниц. NoScript имеет поддержку списка разрешенных сайтов (aka whitelist), а также возможность создания исключений XSS-защиты, задаваемых в формате регулярных выражений.
Плагин входит в десятку самых популярных на сайте addons.mozzila.org.
«Существует ли браузер безопаснее, чем Firefox? Да, это Firefox с NoScript»
Вчера на официальном блоге Microsoft Internet Explorer были опубликованы сведения, касающиеся новых мер, направленных на повышение безопасности восьмой версии популярного браузера. Похоже, что разработчики IE всерьез занялись данным вопросом, – по крайней мере описание всех изменений в модели безопасности браузера выглядит внушительно =) В этом посте я затрону лишь самые любопытные на мой взгляд новшества.
IDS (Intrusion Detection System) или система предотвращения вторжений является одним из средств защиты от различных атак. Среди типов IDS можно выделить сетевые и локальные IDS. Сетевая IDS обеспечивает безопасность целой подсети; как правило, она работает на аппаратном уровне, т.е. встроена в маршрутизатор или другие сетевые устройства. Локальная IDS располагается непосредственно на том компьютере, который необходимо защищать от различных атак извне. В этом случае контроль обеспечивается на программном уровне. Многие файрволы и брэндмауэры так или иначе включают в себя модуль IDS, а самой известной системой подобного рода является Snort. Главное назначение IDS – это предотравщение таких атак, как переполнение буфера, сканирование портов, отказ в обслуживании (DoS).
PHPIDS в этом отношении выделяется среди традиционных систем обнаружения вторжений Read more »
 |