Этот вопрос десятилетиями беспокоил инженеров-программистов: насколько безопасна моя программа? Разработка современных веб-приложений развивается до такой степени, что можно создавать и запускать целый продукт или компанию, опираясь на полноценное программное обеспечение как услугу. Единственный интерфейс к вашему продукту — это пользовательский интерфейс, предоставляемый через браузер, мобильное приложение или данные, предоставляемые API вашего веб-сервиса. К сожалению, поскольку эти современные программные носители продолжают эволюционировать в более сложные платформы, так же как и области, в которых ваш продукт и ваши данные подвергаются потенциальным угрозам безопасности, криминальным вторжениям и краже данных.
В этом блоге мы рассмотрим частые каналы атак и использования PHP-приложений. Этот блог ни в коем случае не является официальным руководством по безопасности вашего приложения, и вы всегда должны консультироваться со своей командой экспертов по безопасности о наилучшей практике для вашей прикладной среды.
Общие Атаки
Для начала мы рассмотрим некоторые из наиболее распространенных атак, о которых вам следует знать. Почти все современные фреймворки, библиотеки и расширения имеют встроенные механизмы для исправления этих популярных методов атак, но, тем не менее, мы рассмотрим их. Эти атаки чрезвычайно просты в исполнении и очень легко предотвратить, но они очень вредны, если остаются открытыми для публики.
Межсайтовый скриптинг (XSS)
Все данные, которые вы предоставляете своим пользователям, не полностью размещены вами, вопреки распространенному мнению. Современные веб-приложения чрезвычайно динамичны и извлекают данные из различных источников. В некоторых случаях ваш сайт может предоставить пользователю возможность оставлять комментарии через форму. Внутри этой формы хакер может вставить тег <script>, указывающий на вредоносный скрипт на другом удаленном сервере.
Этот комментарий затем сохраняется в базе данных, снова извлекается для другого пользователя и отображается в веб-браузере этого пользователя. Поскольку атака является HTML, хак не отображается при визуализации в браузере. Однако, если вы используете команду view-source на странице, вы легко увидите встроенный Javascript, который был вставлен и выполнен в вашем браузере и в каждом браузере пользователей сайта. Потенциально, миллионы ваших клиентов могут быть скомпрометированы запуском неизвестного Javascript, который обслуживается вашим приложением, но указывает на другой удаленный файл, контролируемый хакерами!
Кроме того, хакер может разместить больше, чем просто тег <script>. XSS включает в себя <iframe>, <body> и даже <img> эксплойты. Как вы этого избегаете? Вы очищаете все данные, которые вы получаете от пользователей!
Обычные методы очистки включают strip_tags () , htmlspecialchars () и другие методы фильтрации данных .
SQL-инъекция
Этот эксплойт креативный и, честно говоря, смертельный для вашей базы данных. Представьте, например, что вы передаете информацию с одной страницы на другую через скрытые поля в форме.
В этом случае вы обращаетесь к $ _POST [‘user’], а значение равно 23 и $ _POST [‘password’]. Затем вы переходите к базе данных, чтобы выполнить SELECT из пользовательской таблицы, где user = 23. Эта конкретная атака переопределяет SQL и вставляет дополнительный оператор, так что ваш запрос возвращает true. Например, где вы обычно выполняете это:
SELECT user_id FROM user WHERE user_id = ‘23′ and password = ‘bla’
этот хакер может переопределить это, заставив вас выполнить это:
SELECT user_id FROM user WHERE user_id = ‘23′ and password = ‘bla’ OR ‘true’ = ‘true’
Вышеприведенный запрос может быть успешно выполнен и вернуть true, даже если пароль неверный, в результате чего ваш хакер получит доступ, только зная user_id и не зная пароля вообще!
Чтобы узнать, как избежать взлома базы данных, вы можете прокрутить вниз до раздела «База данных» (ниже).
Лучшие практики безопасности
Хорошо, мы рассмотрели несколько наиболее распространенных атак. Давайте углубимся в лучшие практики разработки программного обеспечения и как они могут помочь защитить вас от уязвимости к атакам.
Безопасность — это движущаяся цель. Не существует идеального способа защитить себя от бесконечных подвигов, которые потенциально могут существовать. Что делать в этом случае, чтобы избежать компрометации? Есть несколько основных рекомендаций, которые следует реализовать в вашей среде PHP.
Держите ваш PHP обновленным
Всегда держите свою версию PHP в актуальном состоянии. Я не могу подчеркнуть это достаточно. Вы, вероятно, будете шокированы тем количеством пользователей PHP, которые используют уязвимые версии PHP, начиная с PHP 4! Даже в рамках серии PHP 5 всегда будьте в курсе последней версии и имейте в виду, что группа PHP исключает поддержку и прекращает работу версии, независимо от того, кто ее запускает. Это означает, что ваша версия PHP может быть устаревшей и уязвимой.
Всегда поддерживайте SSL
Раньше было время, когда SSL использовался только при работе с финансовыми или медицинскими записями. Другими словами, SSL использовался, когда этого требовали федеральные регулирующие органы. Тем не менее, лучшие практики начинают диктовать, что SSL всегда должен быть включен в течение всего времени сеанса клиента. К сожалению, угроза безопасности стала настолько распространенной, что даже самые простые запросы могут оказаться под угрозой. По этой и другим причинам включение SSL во все времена стало обычной практикой в большинстве веб-приложений.
Проверяйте все, что вы собираете и отправляете вам
Вся информация, которая передается в вашу заявку, является подозрительной. Из этого правила нет исключений. Даже если вы получите эту информацию от стороннего API веб-службы, нет никакой гарантии, что их данные не будут заражены. Вы не можете поручиться за безопасность другой компании, поэтому, вероятно, лучше всего применить хорошую проверку данных на основе информации, полученной из внешнего мира.
Эта информация может быть в форме ввода от ваших пользователей, доступа партнеров к API вашего веб-сервиса или, возможно, даже локальных файлов, которые вы открываете с помощью PHP для анализа. Прежде чем какие-либо данные будут обработаны, сохранены в базе данных или возвращены вашим клиентам, вы должны всегда проверять их с помощью базовых проверок работоспособности.
Кроме того, имейте в виду, что заданные вами данные сеанса могут оказаться под угрозой. Например, когда вы устанавливаете значение cookie на стороне клиента, этим значением можно манипулировать; поэтому в следующий раз, когда вы получите к нему доступ, вам следует проверить эти данные. Вы, вероятно, не должны видеть конфиденциальную информацию в своих cookie-файлах, но на всякий случай также проверьте данные.
Посмотрите на функции filter_var () и filer_input () и посмотрите, как вы можете вписать их в ваш рабочий процесс санитарии. Настройте ваш php.ini для оптимальной безопасности. Ваш файл php.ini может содержать серьезные недостатки безопасности, если вы не настроили свою среду правильно. Я написал еще один блог на эту тему, который вы можете прочитать. В этом посте у меня есть раздел, который охватывает базовое введение в безопасность, а также другие основные декларации, о которых вы должны знать.
Следуйте надлежащим правилам сообщения об ошибках
Общее правило, когда дело доходит до сообщения об ошибках: сообщать обо всем в разработке, ничего не показывать в производстве.
Это означает, что, находясь в режиме разработки, вы хотите знать обо всех потенциальных проблемах с вашим PHP-приложением, включая уведомления, предупреждения и, конечно, ошибки. Однако в процессе производства вы никогда не хотите, чтобы информация об ошибках отображалась вашим посетителям. Вы не только избежите расстраивания своих клиентов, но и избежите показа защищенной информации, которая может быть использована против вас, если она попадет в чужие руки.
Файлы конфигурации — держите их в безопасности и скрытых
Все современные фреймворки и веб-приложения требуют конфигурационных файлов. Это файлы, которые содержат информацию о доступе, информацию о соединении, пароли, соединение с базой данных и переменные среды. Очевидно, что этот файл чрезвычайно чувствителен и никогда не должен быть взломан. Вам не нужны эти файлы в ваших общедоступных веб-каталогах. Конфигурационные файлы должны всегда находиться как минимум в одном каталоге над вашими общедоступными веб-папками, и доступ к ним должен осуществляться из самого приложения с помощью фронт-контроллера или платформы.
Фронт-контроллер метод — сохранить PHP-файлы частными
Такой подход возможен практически во всех современных PHP-фреймворках. Единственный файл, который должен быть открыт в вашей общедоступной корневой веб-папке, — это ваш фронт-контроллер или index.php. Затем ваш фронт-контроллер создает экземпляр вашего каркасного объекта, отправляет все запросы на внутренний маршрутизатор и включает необходимые файлы каркаса, переходя на один уровень вниз. Таким образом, у вас никогда не будет доступа к файлам ваших приложений в Интернете, и у вас будет только одна точка входа, которую вы можете заблокировать, чтобы сделать ее более безопасной.
Библиотеки абстракций базы данных — ваш друг
Если вы используете каркас, вы, вероятно, используете слой абстракции базы данных. В качестве альтернативы, по крайней мере, вы можете использовать MySQLi или PDO. Независимо от того, какой метод вы используете для взаимодействия с вашей базой данных, все данные должны быть обработаны перед вставкой в вашу базу данных. В частности, используя подготовленные операторы, вы гарантируете, что библиотеки баз данных выполняют всю утомительную работу по извлечению и удалению потенциально вредоносных данных, скрытых внутри ваших входных данных. Удалите ненужные расширения PHP. Вы не хотите иметь больше расширений, чем вам нужно. Выполните быстрый phpinfo () во время выполнения PHP, чтобы узнать, сколько расширений вы загрузили, и удалите все расширения, которые вам не нужны. Включая ненужные вам расширения, вы вводите потенциальные потери производительности и риски для безопасности.Чем больше переменных вы можете удалить из уравнения, тем меньше вам нужно беспокоиться. Как правило, это хорошая практика — не загружать больше расширений, чем необходимо.
Вывод
Этот список едва ли затрагивает вопросы безопасности PHP. Есть более сложные темы, включая правильные методы хеширования паролей и шифрования, правильное управление сеансами и файлами cookie, методы файлов и разрешений, настройки веб-сервера и брандмауэра и многое другое. Я надеюсь, что этот пост, по крайней мере, предоставит базовое введение в темы безопасности PHP как отправную точку в защите вашего приложения и данных ваших клиентов.
© xkcd.com
Заинтересованы в получении сквозной видимости вашего PHP-приложения? Проверьте бесплатную пробную версию сегодня !