В предыдущей статье я говорил о некоторых распространенных уязвимостях, которые могут повлиять на ваше веб-приложение на PHP. Но есть и другие вещи, помимо этих десяти (ну, ладно, семи) атак, о которых стоит подумать, когда вы разрабатываете. Итак, эта статья предлагает сборник разных вещей, связанных с безопасностью; вещи, которые вы должны делать, вещи, которые вы не должны делать, вещи, которые другие люди могут пытаться делать, все, что нужно, чтобы сделать статью достаточно долго, чтобы мой редактор был доволен ею.
Профиль безопасности PHP
Иногда, когда ты слоняешься по барам, ты слышишь, как люди (не постоянные клиенты, конечно, но просто люди, которые просто бродят) говорят, что PHP не очень безопасный язык. В прошлом были некоторые законные основания для таких чувств.
Большинство исторических проблем могут быть связаны с плохими настройками по умолчанию. Хорошим примером являются глобальные регистры, которые устарели в 5.3, а затем полностью удалены в 5.4. Там нет смысла говорить об этом; это больше не проблема, но давайте просто скажем, что это дало людям возможность писать потенциально небезопасный код. Незащищенность, возникшая из-за настроек php.ini
Одна большая вещь в пользу PHP — это язык на стороне сервера. В отличие от JavaScript или HTML, который выполняется непосредственно в браузере пользователя или в котором можно просмотреть код, код PHP интерпретируется на сервере, и только результаты отправляются в браузер. Конечно, если сервер настроен неправильно, это может привести к загрузке кода PHP в браузер, но это не то, что происходит каждый день.
Одна вещь, которая иногда мешает PHP, но которая также является одной из его сильных сторон, это его гибкость. Не все должно быть просто так, чтобы приложение PHP работало. У вас могут быть свободные концы, и код все еще будет работать. К сожалению, хакеры в бизнесе держат слабые стороны, и поэтому написание безопасного кода часто начинается с жесткого, технически правильного кода.
Фильтр входных данных
Это звучит так просто: проверьте данные, введенные на ваших веб-страницах, и убедитесь, что они не опасны. Например, кто бы этого не сделал, чувак? Ответ удивительного числа людей.
Существует определенная школа мысли, которая утверждает, что любой, кто является специалистом по информатике, должен быть подвергнут мошенничеству на семестр. Знаете, люди подходят к ним и предлагают дать 100 долларов, если они могут просто выдвинуть им 20 долларов, необходимые для получения их «чека». Или электронные письма от адвоката, где-то, где говорится, что родственник, о котором они никогда не слышали, только что оставил им 25 миллионов фунтов, и все, что им нужно сделать, чтобы заявить, что это отправить их банковскую информацию. Цель, конечно, состоит в том, чтобы научить компьютерных людей, что мир не является дружественным местом. Мы установили область из 256 символов, чтобы пользователь мог вводить комментарии, и некоторые люди будут использовать это пространство для ввода команд SQL в попытке выполнить атаку SQL-инъекцией. Больше нет чести?
Если вы настроили страницу, на которой разрешен любой тип записи в произвольной форме, вам необходимо внимательно просмотреть этот ввод и убедиться, что вы не допустили ничего плохого. Используйте функцию filter_input()
К счастью, на SitePoint уже есть две замечательные статьи, связанные с этим. Первый — проверка входных данных с использованием функций фильтра Тоби Осборна, а второй — ClamAV в качестве фильтра проверки в Zend Framework Мэтью Сеттером. Между этими двумя статьями вы сможете получить представление об этой потенциальной проблеме.
Отчет об ошибках
Возможно, вы захотите, чтобы сообщения об ошибках появлялись на вашем экране во время разработки, чтобы дать вам подсказку, когда что-то пойдет не так с вашим скриптом. Но когда вы находитесь в производстве, вы действительно хотите, чтобы это произошло? Каждый бит информации — это пища для хакера, и даже информация о ваших неудачах может оказаться полезной для тех, кто хочет уничтожить ваш сайт. Следовательно, вы никогда не должны отображать ошибки на экране, когда вы находитесь в производстве.
Как вы контролируете это? Слава Богу, файл php.ini На самом деле, в php.ini
-
error_reportingОчевидно, вы хотите знать обо всем, поэтому разумно установить это значение какE_ALL -
display_errorsУстановите это значение «включено» во время разработки и «выключено» для производства. Нет смысла давать хакерам больше информации, чем необходимо; пусть они делают тяжелую работу. -
log_errorsОчевидно, вы хотели бы это на производстве. -
error_logОчевидно, чтобы это вступило в силу, нам нужноlog_errors
С этими установленными флагами вы можете получить всю информацию, необходимую во время тестирования, и в то же время защитить себя на производстве.
Фиксация сессии
В предыдущей статье я говорил о перехвате сеанса, но есть еще один тип атаки, который может произойти с вашими сеансами: фиксация сеанса. Фиксация — это то, где вы обмануты, используя идентификатор сессии, предоставленный хакером. Как это произошло?
Обычно фиксация сеанса происходит, когда вы нажимаете на ссылку, которая содержит параметр PHPSESSID Эта ссылка может привести вас к форме, в которой проверяется ваша личность, и теперь ваша личность привязана к идентификатору сеанса, который вам дал злоумышленник, что позволяет им просматривать любую страницу вашего сайта и получать доступ к данным, связанным с этой страницей.
К счастью, предотвратить это относительно легко. Начните с проверки следующих значений в php.ini
-
session.use_cookiesОн должен быть установлен в 1 или не установлен вообще. -
session.use_only_cookies -
Session.use_trans_sidЭто должно быть установлено в 0. -
session.nameОбычно это значение «PHPSESSID», и зная, что это немного облегчает хакерам. Измените это на более неясное значение.
Кроме того, хорошее правило, которому следует следовать, — всегда выполнять вызов session_regenerate_id() Это будет гарантировать, что идентификатор сеанса не тот, который предоставлен злоумышленником, и поможет защитить вас от этой ситуации.
Проблемы с пользовательскими данными
Если ваш сайт каким-либо образом использует пользовательские данные, то у вас есть дополнительные проблемы, за которыми нужно следить. Прежде всего, и, возможно, прежде всего вы хотите подумать о трафике данных в браузер и на сервер и обратно. Это легкая цель много раз, особенно когда очень много людей работают в открытых беспроводных сетях. Возможно, вы захотите использовать SSL-соединение (например, HTTPS) на своем веб-сайте для всех ваших транзакций. Даже шифрование соединения с базой данных, которое устанавливает PHP, не может быть и речи, в зависимости от характера вашей конфигурации.
В этой области следует обратить внимание на способность злоумышленника украсть пароли из вашей базы данных. Это немного выходит за рамки этой статьи, так как в основном речь идет о том, как зашифровать ваши пароли, чтобы их нельзя было легко восстановить с помощью радужных таблиц или других методов атаки. Я предлагаю проверить статью Почему вы должны использовать Bcrypt для хэширования сохраненных паролей от Callum Hopkins для получения дополнительной информации.
Резюме
Это все? Я имею в виду, если вы сделаете все как в этой, так и в моей предыдущей статье, будет ли ваш сайт безопасным? Да, конечно. И храните все свои деньги в бумажном пакете и всегда носите их с собой.
Есть больше способов обойти безопасность, чем, ну, в общем, есть много других вещей. В конце концов, если вы делаете только одну вещь, подумайте о том, как вы можете стать уязвимыми, и не доверяйте никаким пользовательским данным, если они не были тщательно очищены.
Да, я знаю, это было две вещи. Вы поняли, что не доверяете людям?
Изображение через Fotolia