Использование Токена против CSRF атак

окены (Token) обеспечивают дополнительный уровень безопасности при отправки форм залогинеными пользователями. После того как пользователь вошел на сайт Joomla (даже если он еще не залогинился), система присваивает ему уникальный идентификатор. По нему можно легко отличать посетителей друг от друга, отслеживать действия и переходы пользователя по сайту. Но тут возникает проблема связанная с безопасностью, а именно если идентификатор сессии пользователя попадет в руки злоумышленнику. Тогда последний сможет не зная логина и пароля, ходить по сайту под чужим именем и т.д. Атака подобного рода носит название CWE-352: Cross-Site Request Forgery (CSRF) - Подделка межсайтовых запросов. Разберемся как уберечь себя от подобной ситуации.

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

Joomla в своем арсенале имеет готовый способ защиты от CSRF-атак. Для этого нужно воспользоваться статическими встроенными классами JUtility, JRequest и JHTML.

Уникальный идентификатор пользователя (так же его иногда называют токеном, маркером, ИД-шником и прочее...) добавляется следующим образом:

где tokenValue - уникальное значение (нечто похожее на md5).

Реализовывается это в расширении следующим образом:

В примере идентификатор был передан как GET-параметр. Как известно, в адресе должны передаться только параметры для чтения страницы, что не свойственно для токена. Обычно он передается вместе формой в POST. Делается это следующим образом:

Для проверки воспользуемся методом JRequest:checkToken(). Он вернет булево значение — правильный, либо нет маркер. Ниже идет небольшой пример использования. Примерно так же проверяются формы в панели управления Joomla.

Примечание: функция jexit() - это наиболее верный способ моментальной остановки работы Joomla. Почему нельзя использовать die()?

По умолчанию, checkToken() проверяет данные из массива POST. Первым аргументом можно явно указать, где искать маркер.

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

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

Следующий листинг демонстрирует, как заново сгенерировать метку

Легко! Но нужно быть внимательным и чтобы не смешать различные маркеры, лучше генерировать его в самом начале работы компонента, тогда можно быть увереным в его уникальности.

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

}