Как правильно передавать идентификатор сессии для бэкэнда?
От: vsb Казахстан  
Дата: 12.10.17 16:20
Оценка:
Фронтэнд на джаваскрипте (или в мобилке, не важно), для него есть REST-подобное API на бэкэнде, всякие GET /products/123. Имеются юзеры разных типов с разными правами. Для юзера сайт должен выглядеть обычным образом (логин/логаут). Соответственно с каждым запросом должен передаваться какой-то токен, из которого бэкэнд вытащит информацию о юзере и использует её для авторизации запроса.

Смысла в серверных сессиях я не вижу, поэтому пока использую простой вариант — в токене кодирую user id, ip address, issue time. Всё это дело защищаю HMac-ом.

Основной вопрос в том — как правильно передавать этот токен на бэкэнд, чтобы максимально защититься от всяких атак.

Пока у меня такие рассуждения:

Первая атака это подстановка img src="//bank.com/transfer?from=1&to=2&amount=3" на левом сайте. Соответственно браузер выдаст GET-запрос на bank.com/transfer с правильными куками. Соответственно все запросы, которые что-то могут менять, должны быть не на GET. Такую атаку провернуть крайне легко, я даже на RSDN могу любую картинку в пост вставить. Ну это в принципе просто здравый смысл. Хотя мне и идея того, что GET-запросы кто-то может слать от юзера без его ведома не нравится, но я не представляю, как от этого можно защититься. Проверять Referer на бэкэнде?

Вторая атака это форма form method=post action="//bank.com/transfer..." на левом сайте. Насколько я понимаю, по такой форме можно жамкнуть жаваскриптом, так что пользователь опять же сделает POST-запрос с правильными куками. Вот как от этого защититься — я совсем не понял. Ну опять же Referer проверять, но это как-то не совсем надёжно кажется.

Третья атака это если на моём сайте будет уязвимость и злоумышленник сможет выполнить у клиента произвольный жаваскрипт, пока он находится на сайте. Понятно, что он сможет вызывать любые методы API от его имени. Но ещё он может стащить его токен (сессию) и продолжать их вызывать. Защищаться тут можно двумя способами: во-первых на очень важные вещи просить ввод SMS-кода, во-вторых сделать токен недоступным для жаваскрипта, например HTTP-only кука.

Собственно всё это приводит к какой-то путанице, из которой я сделал один вывод — чтобы максимально защититься от всего, надо всё API полностью спрятать за каким-нибудь PUT-методом и передавать сессию по HTTP-only куке. PUT-запросы с третьего сайта сделать никак не получится, куку жаваскриптом вытащить тоже никак не получится.

Но так никто не делает, поэтому вопрос — что я понимаю не так?

CSRF городить не хочу, какой-то костыль с нетривиальной реализацией.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.