Запрос межсайтовой подделки (CSRF) — это атака, при которой браузер пользователя используется для выполнения нежелательных действий на доверенном сайте, для которого пользователь в настоящее время аутентифицирован. Этот тип атаки выполняется, когда пользователь выполняет какое-либо действие на вредоносном сайте. В большинстве случаев пользователей обманом заставляют переходить на эти вредоносные сайты. Это также известно как атака в один клик или сессионная езда.
Масштаб атаки CSRF зависит от уязвимостей, обнаруженных целевым приложением, и привилегий жертвы. Действия, инициированные злоумышленником, безусловно, будут иметь больший эффект, если жертва, выполняющая действия, находится на административном уровне, а не на низком уровне пользователя с меньшими привилегиями. Атаки CSRF используют тот факт, что веб-приложение полностью доверяет пользователю, как только оно может подтвердить, что пользователь действительно тот, за кого себя выдает. Успешная CSRF-атака может заставить пользователя выполнять действия по изменению состояния, такие как перевод средств, изменение пароля, покупка товара в Интернете и т. д.
Конкретные шаблоны защиты CSRF
Существует несколько способов предотвратить атаки CSRF.
- Шаблон токена синхронизатора
- Шаблон двойной отправки файлов cookie
- Файл cookie того же сайта
В этом сообщении блога мы рассмотрим шаблон токена синхронизатора и поймем, как мы можем использовать его в качестве защиты от атак CSRF.
Шаблон токена синхронизатора
В Synchronizer Token Pattern криптографически безопасный случайный токен будет сгенерирован при создании пользовательского сеанса. Этот токен называется токеном CSRF и сопоставляется с текущим сеансом пользователя. Токен CSRF уникален для каждого сеанса пользователя. Этот токен CSRF добавляется в скрытое поле формы, если эта форма выполняет операцию изменения состояния. Этот токен CSRF будет отправлен на сервер при отправке формы вместе с другими параметрами. Затем сервер проверит полученный токен CSRF с текущим пользовательским сеансом, и, если он действителен, будет выполнена требуемая операция изменения состояния.
С помощью этого метода разработчики могут предотвращать CSRF-атаки на свои сайты. Даже если злоумышленник перехватит запрос, он не сможет воссоздать весь сценарий отправки формы, поскольку у него нет токена CSRF. Даже если у злоумышленника есть файл cookie сеанса, он не может запросить токен CSRF, поскольку межсайтовые запросы не разрешены по умолчанию.
Образец демонстрационного приложения
Ниже приведены примеры кода приложения, созданного для демонстрации использования Syncronizer Token Patter. Это приложение построено с использованием node.js.
Это приложение имеет следующую страницу входа:
Пользователю необходимо ввести имя пользователя и пароль для входа в систему. Для демонстрационных целей использовалась жесткая аутентификация (имя пользователя: admin, пароль: admin).
Когда пользователь регистрируется, учетные данные пользователя проверяются на правильность. Если они правильные, идентификатор сеанса создается и добавляется в файл cookie. Токен CSRF также создается одновременно с идентификатором сеанса. И идентификатор сеанса, и токен CSRF сохраняются в памяти в этом приложении. В реальном приложении вы бы сохранили их в защищенной базе данных. Маршрут «/authenticate» следующего файла содержит код на стороне сервера, необходимый для выполнения этой задачи.
Как только пользователь аутентифицируется как действительный пользователь, он перенаправляется на страницу, содержащую страницу для пожертвований (образец формы, созданный для демонстрационных целей). Когда эта страница загружается, на сервер отправляется запрос ajax, и для этого сеанса приобретается токен CSRF. Маршрут «/get-csrf-token» кода выше вызывается для получения токена CSRF. Затем создается скрытое поле с этим токеном CSRF.
Ниже приведен пример кода формы для пожертвования.
В приведенной выше форме, когда форма отправляется через действие, токен CSRF также отправляется отдельно с другими параметрами. Затем на стороне сервера проверяются и сеанс, и токен CSRF. Только если они допустимы, выполняется требуемое действие по изменению состояния. В этом примере, когда они действительны, во внешнем интерфейсе отображается сообщение об успешном завершении.
Полная реализация находится по следующей ссылке:
https://github.com/rushan-silva/synchronizer-token-pattern
Надеюсь, вы поняли основную идею Synchronizer Token Pattern и расскажете о Double Submit Cookie Pattern в следующем посте блога.
