Безопасность Ваших Php Скриптов

Armus

Новичок
Репутация
10 / 955
Как всегда, начну с теории. От безопасности скриптов зависит правильная работа ваших сайтов и форумов, а также отношение ваших посетителей к вам. К примеру, если ваш сайт, “испортят”, то у посетителей может сложиться не очень хорошее впечатление о вашем сайте, и они к вам больше не придут. Даже, несмотря на то, что вы уже все исправили, т.к. первое впечатление о сайте остается надолго, и посетитель, разочаровавшийся в вас один раз, больше не зайдет к вам, даже при очень заманчивых уговорах.


Теперь подумаем, что же можно сделать такого, чтобы, не случилось неприятностей с работой ваших php-скриптов и как правильнее их будет защитить. Перечислю основные положения:

1. Всегда разбивайте один большой скрипт на несколько маленьких, ненужно запихивать в один скрипт все, что может пригодиться, так как, в крайнем случае, для объединения скриптов можно воспользоваться функцией include.

2. Всегда храните пароли для доступа к сайту зашифрованными или используйте md5() для получения и сравнения хэш-суммы пароля.

3. Никогда не передавайте в качестве параметров имена других скриптов, т.к. этим можно воспользоваться. Лучше сделать небольшой скрипт, который в зависимости от значения какого-либо параметра, выбирает, какой скрипт лучше include()’ить. Делается это очень просто с помощью оператора switch().

4. Проверяйте, откуда и как был запущен ваш скрипт. Эту задачу можно решить по-разному.

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

b. Если же ваш скрипт работает отдельно, то можно проверять значения с помощью getenv(), к примеру, проверять getenv('QUERY_STRING') или getenv('HTTP_REFERER'). Но это не дает никаких гарантий, т.к. эти значения можно без проблем изменить, если запускать ваш скрипт с другого сайта

c. Ну и самое важное используйте .htaccess, о нем много статей у меня на сайте в разделе “статьи”.

5. Еще можно попробовать технологии Zend, в частности Zend Optimizer, но главное, что нужно учесть при использовании продуктов данного производителя, то, что на сервере, у хостера должен быть установлен пакет Zend для PHP, в большинстве случаев он установлен по умолчанию. Все подробности о продуктах Zend и их возможностях можно найти на их официальном сайте http://www.zend.com/.


Конечно, важно еще понимать, какие данные можно передавать через строку браузера, а какие нет. К примеру, на многих сайтах часто встречается ошибка, когда пароль передают скрипту в качестве параметра, через строку браузера использую метод Get, вместо метода Post, не учитывая, что браузер сохраняет почти все запросы к просмотренным страницам, а от туда несложно получить и пароль, несмотря на то, что он даже urlencode()'ированн.


Ну и в конце статьи небольшой совет, касающийся безопасности ваших серверных приложений:
никогда не раздавайте налево и на право свои скрипты, которые вы писали лично для себя, или для своего сайта. Т.к. найти брешь в чужом скрипте гораздо легче, когда видишь его исходный текст и можешь понять его работу в целом.
 
Полность с твоей статьёй согласен, спасибо за неё. Так же не забывайте о защите web сервера. Делаем пароли от SSH, панелей управлений, и тд. от 15 символов. И желательно такого типа s4h24dnv21i*ozc7. И желательно менять их хотябы раз в месяц.
Так же желательно закрыть внешние конекты для mysql оставить только конекты от localhost'a ( если база и сам скрипт на одной машине ).
 
Теперь подумаем, что же можно сделать такого, чтобы, не случилось неприятностей с работой ваших php-скриптов и как правильнее их будет защитить. Перечислю основные положения:

1. Всегда разбивайте один большой скрипт на несколько маленьких, ненужно запихивать в один скрипт все, что может пригодиться, так как, в крайнем случае, для объединения скриптов можно воспользоваться функцией include.

2. Всегда храните пароли для доступа к сайту зашифрованными или используйте md5() для получения и сравнения хэш-суммы пароля.

1. А в чем безопасность, кроме антиоптимизации? Вы не подумайте, я не агитирую за хранение в одном файле, просто где тут безопасность-то?
2. Никогда не храните в md5. Храните, например в sha1 и при этом солите. md5 давно взламывается без супер-усилий.

Самые основные бреши в безопасности - это sql-инъекции и xss. Неполное ограничение полномочий так же часто приводит к плохим последствиям. Если нет большого опыта в разработке, используйте для панели администратора отдельную таблицу с логинами и паролями.
Слабая процедура восстановления пароля, подмена содержания (подгрузка через iframe), брутфорс - так же имеют большое влияние в хаке ваших сайтов.
Есть еще не мало видов атак, но для начала необходимо научиться защищаться от основных.
 
Так же по теме:

В принципе, я не большой специалист по безопасности. Да и тема настолько обширная и многогранная, что одной заметкой её охватить невозможно. Поэтому я сначала писать не собирался. Но со временем выяснилось, что даже очевидные вещи неизвестны многим программистам. Поэтому я решил собрать здесь несколько рекомендаций самого базового уровня.

Основной принцип написания безопасных программ - это контроль данных, приходящих от пользователя.
Есть несколько основных типов атак, которым может подвергнуться сайт, и мы их сейчас рассмотрим.

Файлы
В хорошем современном сайте уже редко можно встретить передачу имени файла в скрипт - данные хранятся в базе, а модули подключаются по более сложным алгоритмам, чем просто передача имени файла в адресной строке. Однако начинающие программисты просто без этого не могут. Доходит до анекдота - "хочу, чтобы было index.php?module=news потому что news.php - не солидно, сайт не выглядит крутым!". Ну, на что не пойдешь ради того, чтобы выглядеть круто. Надо только не забывать о безопасности. О том, что подсунуть для инклюда можно через адресную строку что угодно - от файла на другом сервере (с любым пхп-кодом!), до файла на своем - с настройками или паролями.

Для борьбы с такими подстановками есть несколько методов. Можно проверять имя файла регулярками, но мне ближе всего функция basename(), которая отрезает от имени файла все лишнее.
Если надо передавать файл вместе с путем к нему, к примеру, themes/green/balloons.php, то проверка будет сложнее. Поэтому я бы рекомендовал, все-таки, передавать только имя файла. Или не передавать ничего.

SQL Injection
Следующий тип атак довольно подробно рассмотрен в уже имеющейся статье на этом сайте, \"Кавычки \". Cоставление запросов, слеши, SQL Injection. Хочется лишь добавить, что защита от инъекций - не главное в соблюдении правильного синтаксиса, а побочный продукт, и синтаксис надо соблюдать всегда. Особенно - учитывая инъекции второго порядка, когда данные в запрос подставляются не от пользователя, а уже лежащие на сервере.

Eval
Удивительно, но многие программисты не осознают того факта, что применять eval к пользовательским данным - это все равно, что лично вручать вору ключ от сейфа. Этой функцией и так-то следует пользоваться очень осторожно, а на обработку ей введенных пользователем данных и вовсе должен быть жесткий запрет.
При этом следует понимать, что пользовательские данные остаются таковыми и после того, как пользователь непосредственно отправил их в скрипт. Полученные из базы данных при последующих исполнениях скрипта, они не становятся менее опасными.

XSS
Тип атаки, так же получивший распространение сравнительно недавно. В отличие от всех предыдущих, которые атакуют непосредственно код скрипта, XSS атакует его функциональность: заставляет выполнять пользователя действия, нужные хакеру, или ворует его, пользователя, данные.
Методы весьма разнообразны и многочисленны, однако наиболее распространенный и опасный - это внедрение javascript инструкций в безобидные теги - <img>, <a> и так далее.
Наиболее действенным методом борьбы с этим является полный запрет на ввод пользователем какого бы то ни было HTML кода. Методов борьбы с этим достаточно много, но следует помнить, что функция strip_tags() не убирает опасные вставки из разрешенных тегов. поэтому лично я предпочитаю пользоваться функцией htmlspecialchars(), при выводе любых пользовательских данных.
Но главная проблема при защите от XSS - не сам метод, а последовательность его применения. практически все известные атаки были произведены в тех частях сайта, где никто и подумать не мог об обработке пользовательских данных. А зря. Обрабатывать их надо везде и всегда.

CSRF, Cross-site Request Forging
Формирование на сайте хакера запроса, который будет выполнен браузером пользователя (и, как следствие - со всеми правами пользователя!). То есть, просто авторизация от этой атаки не спасает. Для защиты от этого типа атак следвет взять за правило добавлять ко всем важным формам скрытое поле, содержащее уникальную строку (сгенерированную случайным образом только для этой формы), записывать её в сессию и сравнивать при обработке формы. Хакер добавить такую строку в свою форму не сможет, и атака не сработает.

HTTP Injection
XSS уязвимость, похожая на mail injection, только объектом атаки являются не заголовки письма, а HTTP-заголовки. Атака экзотическая, но знать про неё надо. Хакеру ничего не стоит дописать к урлу код с яваскриптом, который благополучно через переменную PHP_SELF или REQUEST_URI программист сам вставит в свою страницу.

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

ОПС
Статья Сергея Круглова, http://www.captcha.ru/articles/antihack/
 
Bull Shit..

Dostatochno vsego lish ogranichit dostup k serveru pi IP , nastrit prava na chtenie I redaktirovanie faylov v ftp , ne derjat neskolko saytov na odnom serve. I ne soxranyat paroli v brauzere :)
 
1. А в чем безопасность, кроме антиоптимизации? Вы не подумайте, я не агитирую за хранение в одном файле, просто где тут безопасность-то?
некоторые критичные для работы скрипта классы/функции можно вынести за пределы рабочего каталога веб-сервера

2. Никогда не храните в md5. Храните, например в sha1 и при этом солите. md5 давно взламывается без супер-усилий.
тогда уж сразу sha2
хотя как по мне, то использование соли гораздо критичнее чем алгоритм хеширования
 
md5 еще актуален, главное уметь пользоваться. использовать двойной md5 и ключ:
Код:
$key - ключ
$password - пароль
md5(md5($password+$key))

и опять же, шифрование пароля это защита юзеров от администрации))
 
Сверху