На заметку девелоперу. Учимся писать безопасный код. Часть 1.

SecureBlog

На заметку девелоперу. Учимся писать безопасный код. Часть 1.

Дата: 17.05.2008, Категория: Кодинг

Решил продолжить тему, затронутую в блоге Raz0r'а и рассказать о некоторых недоработках самого php. В частности рассмотрю примеры реализации атак и расскажу как от этих атак можно защититься.

Уязвимости в функциях ereg(), ereg_replace(), mb_ereg_match()

Использование этих функций опасно тем, что она не являются бинарно-совместимыми функциями, соответственно она воспринимают NULL байт как конец строки и прекращает ее обработкую. Следовательно существует возможность обойти фильтр. Уязвимый код:

<?php
(ereg('/',$_GET['page'])) ? die('...') : $page = $_GET['page'];
include('/home/user/public_html/'.$page.'.php');
?>

Примером для эксплуатации бреши (php-include) в этом куске кода может послужить url вида:
/script.php?page=%00../../../../../etc/passwd%00

Или такой пример:

<?php
(ereg('<',$_GET['page'])) ? die('...') : $page = $_GET['page'];
echo $page;
?>

/script.php?page=%00<script>alert(/xss/)</script>

В результате увидим сообщение с надписью xss, что дает нам пример для эксплуатации данной уязвимости.

Данные функции используются довольно часто, по этому стоит уделить внимание защите от этих багов. Как же защититься от них?
В случае с первым куском кода, безопаснее использовать проверку страниц так:

<?php
$pages = array('index','preved','etc');
(isset($_GET['page']) && in_array($_GET['page'],$pages)) ? $page = $_GET['page'] : $page = 'index';
// дальше выводим контент в зависимости от страницы
?>

Этот способ наиболее удобен для скриптов с постоянными станицами, то есть когда все страницы(index, preved, etc) заранее известны.
В случае со вторым куском кода лучше использовать htmlspecialchars() и проверку на существование $page.

Хитрый intval(), (int)

Функция intval() возвращает TRUE, если в аргументе присутствует хотя бы одна цифра на первом месте. Мало кто из программистов знает это, по этому очень часто используют intval() в своих скриптах, не подозревая о потенциальной опасности. Пример уязвимого кода:

<?php
$var = $_GET['var'];
(intval($id) && (int)$id) ? mysql_query("SELECT $var FROM table") : die('не число');
?>

/script.php?var=1'etc

Безопасным решением является использование функции is_numeric() или конструкции вида:

<?php
$var = intval($_GET['var']); // $var = (int)($_GET['var']);
mysql_query("SELECT $var FROM table");
...
?>

То есть сразу присвоить переменной $_GET['var'] тип INT, а не проверять это через if().

magic_quotes_gpc

'Магические кавычки', опция php, экранирующая кавычки (') и бэкслэши, в результате чего, при определенных запросах к бд, использующих кавычки, предотвращает возможность sql-injection. Не многим известно, что при magic_quotes_gpc = on, автоматически слэшируются лишь _GET, _POST, _COOKIE и _REQUEST запросы. То естьтакие запросы, как _FILES, _SERVER, _SESSION, _ENV... остаются открытыми, то есть не подвергаются слэшированию. Думаю, тут понятно, как можно использовать это в своих целях, например посылая http запрос скрипту, получающего user-agent пользователя и http-referer и записывает, например, в бд. Если программист по какой-то причине не поставил фильтр на эти данные, возможно произвести blind sql-injection, в случае добавления referer'a, user-agent'a или еще чего-нибудь в таблицу, или sql-injection, в случае если идет выборка данных из таблицы, например по полученному user-agent'у.
Решением послужит фильтрация ВСЕХ входящих данных от пользователя через регулярные выражения или функциями. Пример такой функции можно посмотреть здесь.

$_SERVER[HTTP_...]

Как я уже писал абзатцем выше, дыры существуют и в http заголовках. Наиболее часто используемые в скриптах заголовки - user-agent, http-referer, client-ip, etc...
Как известно, некоторые из них легко подделываются, по этому следует учесть это, отфильтровав все входящие данные. Использование http-заголовков в скриптах очень частое явление среди программистов, по этому стоит уделить фильтрации особое внимание.

Источник: Antichat (Elekt)

Нет комментариев