БЕЗОПАСНОСТЬ WEB-ПРИЛОЖЕНИЙ НА PHP

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

Валидация входящих данных

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

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

Защита от XSS атак

Межсайтовый скриптинг (Cross Site Scripting - XSS) позволяет злоумышленнику включать свой HTML код в вашу станицу. Наиболее уязвимы для такого вида атак являются приложения, где происходит динамическое формирование страниц. Суть атаки — выйти за пределы HTML тега, через специальные символы, и далее внедрять свой код. Защита от этого вида атак сводится к фильтрованию данных отосланных пользователем.

Рассмотрим код уязвимой станицы, отображенный на рисунке 1:

Рисунок 1. Форма ввода, подверженная атакам XSS

Злоумышленнику достаточно сформировать URL следующего вида:

http://www.server.com/index.php?username="><script>alert(document.cookie)</script>

и страница будет уже содержать следующий код:

Рисунок 2. Демонстрация уязвимости

Данный код не причиняет вреда, а лишь демонстрирует уязвимость XSS, отображая cookie. Следует помнить, что код может быть другим, более опасным.

Чтобы обезопасить себя от такого вида атак, следует отфильтровать значение, передаваемое через параметр username, например, при помощи регулярных выражений:

Рисунок 3. Проверка данных с помощью регулярного выражения

Следует проверять все переменные получаемые от пользователя — GET, POST, COOKIE. Во все из них без труда можно встроить зловредный код. Особое внимание следует уделять паролям, так как в них не принято вводить ограничения на символы.

PHP обладает несколькими функциями, позволяющими значительно облегчить задачу защиты web-приложений. Одной из таких функций является htmlspecialchars() которая гарантирует, что любой введенный пользователем код (php, javascript и т.д.) будет отображен, но выполняться не будет.

Защита от CSRF атак

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

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

В качестве предотвращения подобного рода атак, используйте только POST запросы к процессам, предназначенным для изменения информации в базе данных. Не используйте $_REQUEST. Пользуйтесь $_GET-ом для обработки GET параметров, и $_POST для извлечения POST параметров.

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

Предотвращение SQL инъекций

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

Для выполнения запросов к базе данных следует использовать PDO. Благодаря параметризированным запросам и подготовленным выражениям, вы можете свести на нет угрозу SQL инъекций.

Давайте рассмотрим следующий пример:

Рисунок 4. Проверка данных с помощью PDO

В коде, представленном выше, мы отправляем запрос в метод prepare(), включая именные параметры: :name и :age. Таким образом, запрос пре-компилируется для дальнейшей подстановки данных. При вызове метода execute(), запрос полностью формируется и выполняется. Если вы пользуетесь подобной техникой, то все попытки злоумышленника осуществить SQL инъекцию будут сведены к нулю.

Обработка ошибок

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

На публичном сервере вам необходимо отключить такие опции, как display_errors и display_start_up_errors, а вот такие опции как error_reporting и log_errors, должны быть активны, чтоб все ошибки, возникшие у пользователей, записывались в логи.

Также вы можете использовать “set_error_handler” для определения своего собственного обработчика ошибок. Однако тут могут возникнуть ограничения, ведь собственный обработчик уступает родному PHP механизму. Ошибки E_CORE_ERROR, E_STRICT или E_COMPILER_ERROR не смогут быть отловлены в том же файле, где и определённый обработчик. Более того, ошибки, которые могут возникнуть в самом обработчике также не смогут быть отловлены.

Для более элегантного способа отлавливания исключений, потенциально опасный код нужно помещать в блок try/catch. Все собственные исключения должны быть объектами классов или подклассов Exception. Если исключения и были выброшены, то в блоке try/catch их можно обработать.

Защита подключаемых файлов

Часто в PHP скриптах происходит подгрузка других файлов, таких как подключение к базе и многих других. Некоторые разработчики дают таким файлам расширение .inc. Такие файлы по умолчанию PHP не парсит. Если обратиться к ним по адресу напрямую, пользователь сможет увидеть текст данного файла. Если же хакеру удастся получить доступ к файлу хранящиму данные подключение к базе, то в последствии он может получить доступ ко всем данным вашего приложения. Так что всегда используйте расширение .php для подгружаемых файлов и храните их там, куда нет прямого пользовательского доступа.

Список литературы:

1. 8 Practices to Secure Your Web App [Электронный ресурс] – URL: https://www.sitepoint.com/8-practices-to-secure-your-web-app/ (дата обращения: 13.06.2017)