Форум PHP

Здравствуйте.

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

Например переманить пользователя по ссылке и подсунуть в теле страницы фрейм, которому будут доступны и куки и сессионный идентификатор.

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

Так вот вопрос.

Как быть в этом случае? На каждую ссылку по уникальному токену будет слишком кучеряво. Достаточно одного на страницу.

Но если я открою несколько вкладок, в которых будет одна и та же страничка?
Тогда в сессию придется писать несколько токенов? Потому что если я заменю новый старым, то предполагается что работа происходит только в одной вкладке, а если не заменю, то будет сильно засоряться сессия.

Как оптимальнее всего поступить?

Вкладок в браузере? Или имеются в виду какие-то внутренние вкладки? Если в браузере вам хватит одной сессии - так как при открытии второй вкладки сервер уже будет "знать", что пользователь зарегистрировал сессию. Вам же будет достаточно проверить этот факт при помощи функции isset() или empty() - все-равно не избежать проверки состояния в сессии.

Нет, вкладки не при чем, это я рассуждал о сбособах защиты от CSRF уязвимостях.

Я авторизован на сайте (атакуемом), который авторизованным пользователям стартует сессию. Пока я владею идентификатором сессии - сайт везде мне дает зеленый свет.

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

Для того, чтобы пользователь мог оставаться залогиненым на своем любимом ресурсе, браузеры автоматически отправляют Cookie тому серверу, который их установил.

Сервер получает запрос, смотрит Cookie, убеждается в том, что сессия связанная с данными Cookie существует и выполняет действие от имени пользователя, связанного с этой сессией.

Таким образом, если из браузера пользователя отправить запрос, то вместе с ним отправятся и Cookie. И сервер будет думать, что имеет дело с залогиненым пользователем ресурса и действия выполнит от его имени. А заставить браузер отправить запрос можно и со сторонней страницы. И если сервер такие запросы будет обрабатывать так же, как и запросы со своих страниц — это и есть уязвимость.

Как с этим бороться?

Если Вы мне объясните как правильно обойти эту уязвимость, возможно вопрос вкладок отпадет.

P.S. Опа, запалился из разных аккаунтов :)

каким образом может появиться такой фрейм на сайте?)

Вопрос не в этом, а в том как защититься. Поможет ли один токен на сеанс? На вкладку? Или на каждую страницу свой токен генерить? Я не взломщик, поэтому не знаю как действует злоумышленник.

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

.

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

Видимо я чего-то недопонимаю. Надо попробовать повзламывать, от цэ дело будет))

Если взломщик может получить идентификатор сессии, то само собой разумеется, что он получит и токен. Мне кажется, все серьезней чем Вы думаете.

Мы это обсуждаем в контексте CSRF, верно? Тогда давайте разберемся что это такое - а это отправка запроса на атакуемый ресурс от лица якобы жертвы. Т.е. у нас есть форма отправки сообщения, содержащее для авторизованного пользователя (определяем по кукам) только поле text. Злоумышленник создает страницу, при заходе на которую отправляется запрос с заполненным полем text на атакуемый ресурс. Если при этом тот кто зашел на страницу злоумышленника авторизован на атакуемом ресурсе - то от его имени на нем (атакуемом ресурсе) разместиться сообщение злоумышленника. Для борьбы с этим существуют токены (ключи) - они генерируются сервером и вставляются в каждый важный (защищаемый) запрос. При выполнении действий сервер проверяет ключи и если они не совпадают - то действие считается совершенным не от имени пользователя и отменяется.

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

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

PS: еще не плохой и довольно надежный вариант проверять значение HTTP_REFERER. Но тут тоже есть моменты вроде: даже если мы проверяем HTTP_REFERER, то в купе с XSS на сайте можно опять получить CSRF. + Не все браузеры (особенно если это отдельно настроить) его заполняют и следовательно при пустом поле HTTP_REFERER мы вынуждены пропускать запросы, что опять открывает CSRF. Хотя стоит ли так париться ради 0,05% процента пользователей - я не уверен)

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

Но это Вы описали работу форм, а CSRF включает в себя намного больше.
Например на странице находится список аудиозаписей, напротив каждой из них есть кнопка удалить. Кнопка передает серверу запрос типа file/?mod=deleteAudio&idAudio=3251. Решением проблемы могла бы быть подмена общедоступного id, но бывает еще кнопка удалить весь альбом, которая не привязывается к какому либо id. Как таковой уязвимости и нет, так как самому приложению ничего не угрожает, но будет очень неприятно, потерять какие либо данные.

Что же получается, просто добавить токен в ссылку и дело в шляпе?
Не может же быть все так просто? :)

Для ссылок насколько я знаю токены обычно не используют, но по сути - разницы в данном случае особой быть не должно.