Форум АНТИЧАТ - Советы и хитрости по безопасному оформлению скриптов

В этой статье я хочу рассказать о том, какие можно предпринять меры, чтобы увеличить время использование найденной злоумышленником уязвимости, и успеть предпринять меры! Тут показаны некоторые распространенные ошибки начинающий программистов! надеюсь эта статья им будет полезна! В общем приступаем!

1. Болтун - находка для шпиона!

Первый совет касается манеры оформления форм скрипта и взаимодействия с базой данных!
Я начал замечать, что очень часто программисты используют одинаковые имена для полей в html-форме и столбцов в базе данных. Это с одной стороны удобно для самого программиста, однако этим программисты делают великую услугу злоумышленникам.
Приведу пример, злоумышленник обнаружил уязвимость типа "SQL-injection" на сайте, и нашел таблицу с юзерами. Первое что он попытается сделать? (сужу по себе) Он сначала попытается проверить наличие столбцов типа "username", "password" и т.п, а уже в случае неудачи анализирует сайт для поиска названия столбца. Я например постоянно смотрю исходный код страницы авторизации.

Вот плохой пример:

Цитата:

...
Form
<input name="login" type="text">
<input name="password" type="password">
...

Base

TABLE `users` (
`login`,
`password`,
)

Вот более-менее приемлимый пример:

Цитата:

...
Form
<input name="adm_login" type="text">
<input name="adm_passwd" type="password">
...

Base
TABLE `users` (
`auth_login`,
`auth_pass`,
)

Вот такая вот с первого взгляда не шибко то и опасная оплошность помогала определять имена столбцов на некоторых "не нашенских" сайтах (итальянские, бразильские, французские) где программисты используют в качестве имен зачастую слова своего языка, а не английского, причем иногда и на сленге, т.е. даже с переводчиком было трудно подобрать поле.

2. Молчание - золото! (Продолжение пункта "Болтун - находка для шпиона!")

Итак, практически похожая оплошность программистов.
Зачастую бывает, что программисты присваиваивают обычной переменной либо аргументу функции прямое, "человеко-читаемое" значение (т.е. значения типа insert, update, view, show, add и т.п.), опять же делается для удобства самого программиста, и читаемости кода. Это конечно со стороны культуры кода отлично, однако со стороны безопасности этого лучше не делать.
А например сделать для самого себя условие наподобие "insert"==1, "show"==2 и т.д. а передавать уже целочисленное значение, которое не отображает действие. И написать в коде комментарий с расшифровкой этих манипуляций рядом с функцией, дабы после выходных не забыть чего наделали! =)
Это конечно не очень удобно, зато осложнит злоумышленнику изучение алгоритма выполнения скрипта.

3. Семь раз отмерь...

Также многие программисты совершают ошибку описанную ниже либо из-за лени, либо из-за каких-то природных катаклизмов, ничем другим это не обьясняется!
Встречаются такие случаи, когда перед записью в базу ограничивают ввод в поле формы "maxlength", потом обрезают переменную (на всякий случай! =) ) "substr" и ей подобными, в это же время абсолютно не устанавливая тип и длину данных в самой базе (например все поля без разбора имеют тип "text") Естественно делая подобное, программисты не задумываются, что злоумышленник имея некую уязвимость не в 100% случаях произведет запись в базу именно из любезно предоставленной программистом переменной, а из какой либо другой, причем без проверок! =)
Ведь гораздо лучше совместить вышеуказанные ограничения по размеру с ограничением в структуре базы.
Например для MD5 хеша пароля подойдет тип varchar(32) , а для столбца с номером ICQ тип tinyint(9) и т.д.
Дальше интереснее! =) Читаем!

4. Глумимся над злоумышленником

4.1 Админка

Итак, опять давайте попробуем размышлять как злоумышленник! =)
Представим, что злоумышленник обнаружил уже упомянутую уязвимость типа "SQL-injection", удачно вытянул из базы логин и хеш админа, что он делает дальше? А? Именно! Пойдет искать админку! и даю 99% будет искать в начале частые имена (не рассматриваем случаи с robots.txt и общей формой входа) - admin, login, webadmin, cpanel, и т.п.
Но, мы же добрые, и хитрые программисты! =) Давайте создадим папочку (или просто файлик) с именем /admin/ закинем туда один файлик index.php с подобным содержанием:

PHP код:


		
			
<html>

<head>

<title>Admin Panel</title>

</head>

<body>

<?

if(empty($_POST['login']))

{

    print '<form action="" method="post">';



    print 'Login <br>';

    print '<input name="login" type="text"> <br>';

    print 'Password <br>';

    print '<input name="password" type="password"> <br>';



    print '<input type="submit" value="enter">';

    print '</form>';

}

else

{

    print 'Login and/or Password is not correct! Please re-enter!';

}

?>

</body>

</html>

Вот у нас и получился фейк нашей настоящей админки! (для пущей уверенности можно сделать еще вывод ошибок при вводе запрещенных символов, проверку на пустоту переменной, если хекер не ввел данные и т.п. в общем максимально приблизить к реальности)
Как видите это просто произвол! =) При любом вводе логина и пароля будет выводится ошибка!
А реальная админка будет находится в какой-нибудь папочке типа "good_cpanel_for_best_user"

4.2. Ошибки 404 и 403

Продолжаем обманывать нашего гостя!
Для начала создадим файл .htaccess в корне сайта со следующим содержанием

Цитата:

ErrorDocument 404 http://your_site.ru/index.php?error=404
ErrorDocument 403 http://your_site.ru/index.php?error=403

Далее в указанном файле index.php добавим несколько строк подобного содержания

PHP код:


		
			
if(@$_GET['error']==404)

{

print ‘Not Found <br>’;

} 



if(@$_GET['error']==403)

{

print ‘Forbidden<br>’;

}

Разберем написаное! В файле .htaccess мы заменили дефолтные страницы ошибок на свою, причем мы заменили не просто на index.php, а еще и присвоили переменной error код ошибки! Зачем? Дальше расскажу!
А в индексном файле сделали вывод этих ошибок.

Кажется ничего сверхъестественного не сделали… Продолжаем.
Теперь давайте снова пофантазируем! Допустим у нас есть директория на сайте под именем files, в ней хранятся какие то наши файлы, мы естественно закрыли к ней доступ в файле .htaccess, а при заходе по адресу http://your_site.ru/files/ нам выдает ошибку 403, причем не простую, а редиректит на http://your_site.ru/index.php?error=403, где нас и оповещают об ошибке. Надеюсь тут все понятно! Это будет наш отвлекающий маневр! Злоумышленник увидит, что при запросе несуществующего файла/директории выдается ошибка 404, а при отсутствии доступа 403.
Теперь подумаем что можно сделать с этим… Точно! Можно еще лучше спрятать админку!
Ранее мы сделали подставную, фейковую админку, а своей присвоили сложное имя, а все же если хакер узнает название админки? Будет плохо… Прячем админку!
Создадим в папке с админкой индексный файл index.php следующего содержания

PHP код:


		
			
<?php

header("Location: http://your_site.ru/index.php?error=404");

?>

Т.е.при заходе в директорию с админкой /good_cpanel_for_best_user/ сработает индексный файл и редиректит хакера на ту же страницу, что и при отсутствии директории, т.е. 404. (надеюсь понятно выразился, просто красноречия не хватает…) Таким образом создастся зрительное впечатление, что директории /good_cpanel_for_best_user/ не существует. Естественно в этой папке придется сделать нужные (для администрирования) файлы с названиями отличными от index.php.

5. Только жесткий контроль!!!

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

PHP код:


		
			
function get_error($int)

{

    $int = intval($int);

    // Мелкие ошибки

    $error[0] = 'Вы неверно ввели проверочный код, пожалуйста попробуйте еще раз! <br>'; 

    $error[1] = 'Вы не ввели логин, повторите ввод! <br>';

    $error[2] = 'Вы не ввели пароль, повторите ввод! <br>';



    // ошибки средней важности

    $error[20] = 'Авторизация провалена!<br>';

    $error[21] = 'Неверный идентификатор сессии!<br>';



    // Важные ошибки

    $error[30] = 'Файл не найден!<br>';

    $error[31] = 'Запрашивался недоступный файл!<br>';



    // Весьма важные, либо критические ошибки

    $error[50] = 'Попытка доступа к закрытым разделам сайта!<br>';

    $error[51] = 'Введен неверный пароль доступа к панели администрирования!<br>';



    if($int>=50)

    {

        echo send_mail('admin@your_site.ru',$int);

    }



    return $error[$int];

}

Суть функции в том, что каждой ошибке присваивается свой номер в зависимости от важности. Выводить ошибку в скрипт следующим образом вместо обычного
print 'Error';
написать
print get_error(number_of_error);

Подобная функция позволяет вести контроль за ошибками! Например в этой функции показан пример, что при вызове ошибки номер которой больше 50 (т.е. критические ошибки) отсылается админу письмо с нужными данными. Также можно сделать ранжирование, например

Цитата:

Ошибки 0-20 – ничего не предпринимать
21-30 – только лишь записать в лог.
31-41 – сообщить админам находящимся на сайте+записать в лог
41-51 – написать на e-mail, ICQ админу сайта.

Принцип работы простой, зато очень удобный!

Ну, вот как бы и все пока! Надеюсь, что это кому-нибудь, да будет полезно!
С Ув. Twoster