В этой статье представлены элементарные принципы защиты PHP-скриптов, которые должен знать каждый веб-программист.
Сейчас всё чаще защита веб-скриптов сводится к проверке и ограничению их входных данных. Делается это для ограничения возможностей зловредных пользователей или просто для защиты от неправильных данных. Такая защита от кулхацкеров, не от хакеров, т.к. последние редко ищут дыры в скриптах с целью дефейса или по каким-либо другим своим личным надобностям, атака чаще сводится к взлому сервера, к получению привилегированных учетных записей на нем, с которых можно сделать запланированное. Но защита "от дурака" тоже важна, даже если у себя на сайте вы и не храните секретные коды запуска ракет или планы эвакуации для пентагона. Об элементарной, но эффективной защите и пойдет речь.
1. Итак, для начала неплохо было бы ограничить поступающие в скрипт входные данные. Никогда нельзя доверять данным, пришедшим в скрипт извне.
Так можно ограничить длину строки. К примеру, ограничить длину ника, вводимого в форме. Функция возвращает часть переменной $str. В данном случае функция вернет строку длинной не более 10 символов, начиная с нулевого, т.е. отбросит все символы, после десятого символа, если таковые имеются. Последний параметр функции является опциональным, т.е. необязательным, можно просто задать substr($str, 5) - в таком случае возвратом функции будет строка, часть переменной $str начиная с пятого символа.
Не стоит надеяться только на атрибут size в полях формы, не забывайте, что данные в ваш скрипт могут прийти откуда угодно, а не только из предусмотренной вами формой.
2. Также очень важно проверять поступающие данные на достоверность.
Функция возвращает true, если переменная $str пустая [не содержит данных], false - в противном случае.
Функция возвращает строку, очищенную от пустых символов вначале и конце строки [пробелы, символы табуляции, перевода строки].
Функция возвратит строку, очищенную от html и php тегов. В качестве второго параметра, начиная с версии PHP 3.0.13, можно задавать разрешенные теги, т.е. те теги, которые не будут вырезаться из строки. Например:
PHP код:
$str= strip_tags($str, '<a><i><b>' );
htmlspecialchars( $str);
Функция заменяет символы в строке $str, имеющие специальное значение в html, на их безопасные эквиваленты:
PHP код:
& на &
< на <
> на >
" на "
' на '
В качестве второго параметра можно задавать способ интерпретации кавычек. По умолчанию стоит ENT_COMPAT - преобразует только двойные кавычки, не трогая одиночные. ENT_QUOTES - преобразует оба типа кавычек. ENT_NOQUOTES - никакие кавычки не преобразуются.
Например:
PHP код:
$str = htmlspecialchars( '<a href="test">Test</a>' , ENT_QUOTES);
С помощью регулярных выражений можно (нужно!) многое. Часто требуется заменять какие-либо символы в тексте вручную. Например:
PHP код:
$str= ereg_replace( "n", '<br>', $str);
Данное выражение заменит в $str все символы с кодом 10 ["n" - перевод строки] на строку
Очень желательно чтобы в поля e-mail и url были введены именно адрес электронной почты и адрес сайта соответственно, а не то, что душе угодно:
PHP код:
preg_match( '/^([a-z0-9_-.])+@([a-z0-9_-])+(.([a-z0-9])+)+$/' ,$email);
Такая запись устанавливает условие на содержимое переменной $email. Функция вернет true, если данные в переменной похожи на адрес электронной почты, false - в противном случае.
PHP код:
preg_match( '/^([a-z0-9_-.])+(.([a-z0-9/])+)+$/' ,$url);
Таким регулярным выражением можно проверить и url на правильность
3. Всегда желательно прятать структуру скриптов, чтобы об их работе пользователю было известно как можно меньше.
Первым делом скрипты не должны выдавать предупреждения [warning] и тем более ошибки [error] в браузер, и вообще не должны их выдавать.
Много предупреждений возникает по поводу undefined variable - то бишь при попытке использования несуществующей переменной. Почему переменная может не существовать это отдельный вопрос, но всегда лучше это предупредить функцией isset().
Функция возвращает true, если переменная определена, false - в противном случае.
Использование get-метода передачи данных в скрипт, на мой взгляд, не желательно. Во-первых, эстетическая сторона - выглядит адресная строка отвратительно и непонятно для пользователя. Во-вторых, частично открывает структуру работы скрипта. Если метод get у вас нигде не используется, то лучше вообще абстрагироваться от него.
С методом post ситуация похожая:
register_globals
- директива, которая задает возможность (или невозможность) регистрации глобальных переменных, т.е. при получении данных из формы [post] или из адресной строки [get], по умолчанию создаются глобальные переменные с соответствующими именами [имя поля или имя параметра в адресной строке]. Это естественно, но безобразно.. (парадокс!) и вообще в некоторых случаях ведет к дырам в скриптах. Желательно так писать сценарии, чтобы они по возможности старались обходиться без директивы register_globals. Отключить это безобразие в .htaccess файле можно следующим образом:
php_flag register_globals Off
В таком случае данные get и post будут храниться в глобальных ассоциативных массивах
PHP код:
$HTTP_GET_VARS
и
$HTTP_POST_VARS
Для отключения неиспользуемых возможностей или их детальной кофигурации также могут пригодиться следующие директивы:
track_vars - доступность глобальных ассоциативных массивов переменных среды, сервера, get, post и cookie.
variables_order - порядок регистрации переменных среды, сервера, get, post и cookie.
register_argc_argv - переменные $argv и $argc на основе информации, поступившей методом get.
file_uploads - возможность обрабатывать закачку файлов.
Подробнее об этих и других директивах - мануал по Apache [php.ini, .htaccess].
4. Никогда не бывает лишним удостовериться в том, что данные в скрипт пришли именно с вашего сайта.
PHP код:
if(ereg( '^http://' .$HTTP_HOST ,getenv ('HTTP_REFERER' )));
Регулярное выражение проверяет, содержится ли в HTTP_REFERER имя хоста вашего сайта. Если нет, то можно послать деморализующее сообщение в браузер и завершить работу скрипта. Но не стоит 100%но доверять такой проверке, т.к. HTTP_REFERER при большом желании злоумышленник может подделать и законспирироваться под имя хоста.
5. Ну и последний совет касается авторизации. Если кто не знает, есть программы-переборщики паролей и ими можно пытаться подобрать пароль к интерфейсу авторизации на вашем сайте. Явный тому пример - программа
Brustus AET-2. Замечательная вещь и даже во многих случаях результативная [выделенный канал + большая база словарей + несложный пароль].
Так вот, от подобных переборов в большинстве случаев тоже можно оградиться - все зависит от конкретной реализации. В любом случае защита сводится к ведению лога неудачных попыток авторизироваться. В
код авторизации добавляется следующее:
PHP код:
if( file_exists( 'log.txt') && filesize( 'log.txt')> 1024) exit;
Т.е. до авторизации делается проверка - если существует лог неудачных авторизаций и его размер [в байтах] больше 1024, то скрипт прекращает свою работу [или выдает деморализующее сообщение
], не доходя до
самого процесса авторизации. На этом перебор у злоумышленника завершится.
Ну вот, используя перечисленные принципы элементарной защиты, кулхацкер, встретившись с ней, будет злостно деморализован. Приведенные методы много раз опробованы и до сих пор не подводили.
(c) www.zeosmaster.com/
Защита Php-скриптов
Похожие темы
Комбинированный вид