Безопасность — это не список того, что вы делаете. Безопасность — это способ мышления, способ взглянуть на вещи, способ общения с миром, который говорит: «Я не знаю, как они это сделают, но я знаю, что они попытаются меня подставить» и затем, вместо того, чтобы раствориться в экзистенциальном фанке, проявить инициативу, чтобы предотвратить проблему.
Но вы не можете противостоять статистике. Никто не собирается читать статью под названием «Кодирование для безопасности». Всем нужна статья с номером в ней: «8 самых распространенных атак безопасности PHP и как их избежать», «23 вещи, которые нельзя сказать супер модели» и «15 причин избежать радиационного отравления». Итак, «10 самых уязвимых мест безопасности PHP».
SQL-инъекция
Номер один в списке попаданий — атака SQL-инъекцией. В этом случае кто-то вводит фрагмент SQL (классический пример — оператор отбрасывания базы данных, хотя есть много возможностей, которые не включают в себя удаления, которые могут быть столь же разрушительными), в качестве значения в вашем URL или веб-форме. Не берите в голову, как он знает, как называются ваши таблицы; это совсем другая проблема. Вы имеете дело с коварным и находчивым противником.
Итак, что вы можете сделать, чтобы избежать этого? Прежде всего, вам нужно с подозрением относиться к любым данным, которые вы принимаете от пользователя. Поверьте, все хорошо? Просто посмотрите на семью вашего супруга … они странные и странные, некоторые опасно.
Чтобы предотвратить подобные вещи, используйте подготовленные операторы PDO. Я не хочу проходить полное обсуждение PDO сейчас. Достаточно сказать, что подготовленные заявления отделяют данные от инструкций. При этом он предотвращает обращение с данными как с чем-либо, кроме данных. Для получения дополнительной информации вы можете прочитать статью Тимоти Борончик ( Mothrate from MySQL Extension to PDO ).
XSS (межсайтовый скриптинг)
Прокляните чёрные сердца, которые процветают на этом типе обмана. Родители, поговорите с вами сегодня, дети, чтобы они не стали злыми XSS’ерами!
Суть любой атаки XSS — это внедрение кода (обычно кода JavaScript, но это может быть любой код на стороне клиента) в вывод вашего сценария PHP. Эта атака возможна, когда вы отображаете данные, которые были отправлены вам, например, как если бы вы делали сообщения на форуме. Злоумышленник может опубликовать в своем сообщении код JavaScript, который делает невероятные вещи на вашем сайте. Пожалуйста, не заставляй меня вдаваться в детали; мое сердце плачет от того, на что способны эти разбойники.
Для получения дополнительной информации и как защитить себя, я предлагаю прочитать эти прекрасные статьи на PHPMaster:
- Перекрестные атаки сценария Джорджа Фекетта
- Проверка входных данных с использованием функций фильтра Тоби Осборна
Откровение исходного кода
Это связано с тем, что люди могут видеть имена и содержимое файлов, которые им не нужны в случае сбоя в конфигурации Apache. Да, я копаю это, это вряд ли произойдет, но это может и довольно легко защитить себя, так почему бы и нет?
Мы все знаем, что PHP на стороне сервера — вы не можете просто сделать исходный код для просмотра кода скрипта. Но если что-то случится с Apache, и вдруг ваши сценарии будут представлены в виде простого текста, люди увидят исходный код, который они никогда не должны были видеть. Часть этого кода может перечислять доступные файлы конфигурации или содержать конфиденциальную информацию, такую как учетные данные базы данных.
Решение сосредоточено вокруг того, как вы устанавливаете структуру каталогов для своего приложения. То есть проблема не в том, что плохие люди могут видеть какой-то код, а в том, какой код они могут видеть, если конфиденциальные файлы хранятся в общедоступном каталоге. Храните важные файлы в общедоступном каталоге, чтобы избежать последствий этой ошибки.
Для получения дополнительной информации об этом, включая пример того, как может выглядеть ваша структура каталогов, см. Пункт 5 этой статьи . Для дополнительного обсуждения по этой теме, смотрите обсуждение этого форума .
Удаленное включение файлов
Подождите, пока я пытаюсь объяснить это: удаленное включение файлов — это когда удаленные файлы включаются в ваше приложение. Довольно глубоко, а? Но почему это проблема? Потому что удаленный файл не заслуживает доверия. Он мог быть злонамеренно изменен, чтобы содержать код, который вы не хотите запускать в своем приложении.
Предположим, у вас есть ситуация, когда на вашем сайте www.myplace.com есть библиотека www.goodpeople.com/script.php. Однажды ночью www.goodpeople.com скомпрометирован и содержимое файла заменено злым кодом, который испортит ваше приложение. Затем кто-то заходит на ваш сайт, вы извлекаете обновленный код, и Бэм! Так как же это остановить?
К счастью, исправить это относительно просто. Все, что вам нужно сделать, это зайти на ваш php.ini и проверить настройки этих флагов.
-
allow_url_fopen— указывает, могут ли быть включены внешние файлы. По умолчанию это значение включено, но вы хотите отключить его. -
allow_url_include— указывает, могут ли функцииinclude(),require(),include_once()и require_once () ссылаться на удаленные файлы. По умолчанию это отключено, и отключениеallow_url_fopenотключает это тоже.
Session Hijacking
Перехват сеанса — это когда негодяй крадет и использует чужой идентификатор сеанса, который является чем-то вроде ключа от сейфа. Когда между клиентом и веб-сервером устанавливается сеанс, PHP сохранит идентификатор сеанса в файле cookie на стороне клиента, который, вероятно, называется PHPSESSID. Отправка идентификатора с запросом страницы дает вам доступ к информации о сеансе, сохраненной на сервере (который заполняет $_SESSION массив $_SESSION ).
Если кто-то украл ключ сессии, это плохо? И ответ таков: если вы не делаете ничего важного на этом занятии, тогда ответ — нет. Но если вы используете этот сеанс для аутентификации пользователя, то это позволит некоторому мерзкому человеку войти в систему и приступить к работе. Это особенно плохо, если пользователь важен и имеет большие полномочия.
Так как же люди крадут эти сессионные идентификаторы и что могут с этим сделать порядочные, богобоязненные люди, такие как мы?
Идентификаторы сессий обычно крадут с помощью атаки XSS, поэтому предотвращение их — это хорошая вещь, которая дает двойную выгоду. Также важно менять идентификатор сессии так часто, как это практически возможно. Это уменьшает ваше окно кражи. Из PHP вы можете запустить функцию session_regenerate_id() чтобы изменить идентификатор сессии и уведомить клиента.
Для тех, кто использует PHP5.2 и выше (да, не так ли?), Есть настройка php.ini , которая препятствует предоставлению JavaScript доступа к идентификатору сеанса ( session.cookie.httponly ). Или вы можете использовать функцию session_set_cookie_parms() .
Идентификаторы сеансов также могут быть уязвимы на стороне сервера, если вы используете службы общего хостинга, которые хранят информацию о сеансах в глобально доступных каталогах, таких как /tmp . Вы можете заблокировать проблему, просто сохранив идентификатор сеанса в месте, доступном только для ваших сценариев, либо на диске, либо в базе данных.
Подделка межсайтовых запросов
Подделка межсайтовых запросов (CSRF), также известная как Brett Maverick или Shawn Spencer, Gambit, включает в себя обман довольно невольного пользователя в выдаче запроса, который, скажем так, не отвечает его наилучшим интересам. Но вместо того, чтобы продолжать рассказывать о CSRF-атаках, обратимся к выдающемуся примеру того, какой именно контент мы имеем здесь на PHPMaster: Предотвращение подделок межсайтовых запросов от Мартина Псинаса.
Обратный путь в каталогах
Эта атака, как и многие другие, ищет сайт, на котором безопасность не является такой, какой должна быть, и, если она обнаруживается, она вызывает доступ к файлам, которые владелец не планировал сделать общедоступными. Он также известен как атака ../ (точка, точка, косая черта), атака по лазанию и атака с возвратом.
Есть несколько способов защиты от этой атаки. Во-первых, очень, очень сильно желать, чтобы этого не случилось с вами. Иногда желают помочь феи и единороги. Иногда это не так. Второе — определить, какие страницы можно вернуть для данного запроса, используя белый список. Другой вариант — преобразовать пути к файлам в абсолютные и убедиться, что они ссылаются на файлы в разрешенных каталогах.
Резюме
Это 10 основных проблем, которые, если вы не будете осторожны, могут привести к нарушению вашего PHP-приложения. Да, 10. Посчитай их … 1, 2, 3 … Что? Вы только насчитали 8? Хорошо, может быть 7. Ну, тогда это показывает, насколько легко тебя можно одурачить, и я даже не один из плохих парней!
Изображение через Fotolia