![]() |
Защита Php-скриптов
В этой статье представлены элементарные принципы защиты PHP-скриптов, которые должен знать каждый веб-программист.
Сейчас всё чаще защита веб-скриптов сводится к проверке и ограничению их входных данных. Делается это для ограничения возможностей зловредных пользователей или просто для защиты от неправильных данных. Такая защита от кулхацкеров, не от хакеров, т.к. последние редко ищут дыры в скриптах с целью дефейса или по каким-либо другим своим личным надобностям, атака чаще сводится к взлому сервера, к получению привилегированных учетных записей на нем, с которых можно сделать запланированное. Но защита "от дурака" тоже важна, даже если у себя на сайте вы и не храните секретные коды запуска ракет или планы эвакуации для пентагона. Об элементарной, но эффективной защите и пойдет речь. 1. Итак, для начала неплохо было бы ограничить поступающие в скрипт входные данные. Никогда нельзя доверять данным, пришедшим в скрипт извне. PHP код:
Не стоит надеяться только на атрибут size в полях формы, не забывайте, что данные в ваш скрипт могут прийти откуда угодно, а не только из предусмотренной вами формой. 2. Также очень важно проверять поступающие данные на достоверность. PHP код:
PHP код:
PHP код:
PHP код:
PHP код:
Например: PHP код:
PHP код:
PHP код:
PHP код:
PHP код:
3. Всегда желательно прятать структуру скриптов, чтобы об их работе пользователю было известно как можно меньше. Первым делом скрипты не должны выдавать предупреждения [warning] и тем более ошибки [error] в браузер, и вообще не должны их выдавать. Много предупреждений возникает по поводу undefined variable - то бишь при попытке использования несуществующей переменной. Почему переменная может не существовать это отдельный вопрос, но всегда лучше это предупредить функцией isset(). PHP код:
Использование get-метода передачи данных в скрипт, на мой взгляд, не желательно. Во-первых, эстетическая сторона - выглядит адресная строка отвратительно и непонятно для пользователя. Во-вторых, частично открывает структуру работы скрипта. Если метод get у вас нигде не используется, то лучше вообще абстрагироваться от него. С методом post ситуация похожая: register_globals - директива, которая задает возможность (или невозможность) регистрации глобальных переменных, т.е. при получении данных из формы [post] или из адресной строки [get], по умолчанию создаются глобальные переменные с соответствующими именами [имя поля или имя параметра в адресной строке]. Это естественно, но безобразно.. (парадокс!) и вообще в некоторых случаях ведет к дырам в скриптах. Желательно так писать сценарии, чтобы они по возможности старались обходиться без директивы register_globals. Отключить это безобразие в .htaccess файле можно следующим образом: php_flag register_globals Off В таком случае данные get и post будут храниться в глобальных ассоциативных массивах PHP код:
track_vars - доступность глобальных ассоциативных массивов переменных среды, сервера, get, post и cookie. variables_order - порядок регистрации переменных среды, сервера, get, post и cookie. register_argc_argv - переменные $argv и $argc на основе информации, поступившей методом get. file_uploads - возможность обрабатывать закачку файлов. Подробнее об этих и других директивах - мануал по Apache [php.ini, .htaccess]. 4. Никогда не бывает лишним удостовериться в том, что данные в скрипт пришли именно с вашего сайта. PHP код:
5. Ну и последний совет касается авторизации. Если кто не знает, есть программы-переборщики паролей и ими можно пытаться подобрать пароль к интерфейсу авторизации на вашем сайте. Явный тому пример - программа Brustus AET-2. Замечательная вещь и даже во многих случаях результативная [выделенный канал + большая база словарей + несложный пароль]. Так вот, от подобных переборов в большинстве случаев тоже можно оградиться - все зависит от конкретной реализации. В любом случае защита сводится к ведению лога неудачных попыток авторизироваться. В код авторизации добавляется следующее: PHP код:
самого процесса авторизации. На этом перебор у злоумышленника завершится. Ну вот, используя перечисленные принципы элементарной защиты, кулхацкер, встретившись с ней, будет злостно деморализован. Приведенные методы много раз опробованы и до сих пор не подводили. (c) www.zeosmaster.com/ |
всё знакомо =) правда я обычно на достоверность провеяю if =)
|
блин зачем мусор собирать в разделе =(
|
На самом-то деле, как мне кажется для фильтрации:
1. XSS достаточно использовать striptags/htmlspecialchars/htmlentities 2. SQL достаточно испольльзовать mysql_escape_string/mysql_real_escape_string 3. PHP-Include достаточно создать массив нужных файлов и / или осуществлять выборку через case. Регулярки тоже вариант. Кстати, во 2ом случае можно использовать функции проверки содержимого переменной, например, на присутствие только цифровых символов (is_int). Помогает присутствие magic_quotes_gpc, фильтрацию нужно также употреблять с учетом результата выполнения функции get_magic_quotes_gpc Защититься от заливки шелла? хм.. регулярка на расширения + список разрешенных. Ну и .htaccess настроить, запретить выполнение php для папок вроде uploads. По поводу ошибок: error_reporting(0) спасает, хотя при грамотном стиле программирования ошибки не должны появляться. ps: перевод строки - "\n", фильтрация "n" затронет все вхождения этого символа и слово "antichat" превратится в "atichat". pps: все, что выше - сугубо мое личное мнение. я не претендую на звание php-программиста, занимаюсь изучением сравнительно недавно и, скорее всего, многого не знаю) Если я где-то не прав и вы меня поправите, я буду только рад) |
2 n1†R0x
Мало того, что прав, так еще и в одном посте обобщил большую половину той кучи статей и талмудов, которые на эту тему написаны. |
хм... не очень понял про
PHP код:
|
Цитата:
"если размер лога больше 1024 байт то скрипт завершается." exit() - аналог die() |
Цитата:
|
Цитата:
|
Цитата:
если лог используется скриптом, в нем должно быть предусмотрено создание текстового файла. следовательно, программно. Цитата:
да. читай ман по die / exit, работа скрипта завершается. |
| Время: 22:56 |