Нужно ли сверять токен в БД?

Токен тоже.
Какая разница куда ты (пост формы, экшн формы, срц фрейма) распихиваешь параметры?
Токен всеравно будет где-то в контексте запроса.

Да хоть полуразовый.
А токен это (само|недо|пере)произвольный текст?

Не надо ничего шаманить на стороне приложения кроме реферера.
Все остальное шаманицца в конфиге сервера: корс + фреймопшнс (ну ладно, можно и это впилить в приложение ради бомжей селящихся на шаредах)

Кстати, что мне помешает написать проверку реферера и для подгрузки списка пользаков?
(для меня это две строки кода в экшне, а в новой версии я впилю это сразу в базовую форму)
Социальная инженерия сразу обсерится, т.к. придется мазанную форму сначала бросить просто в админку, затем заставить кликнуть на список пользаков, а потом уже что-то делать с пользаком ))

Ну и чтоб ты понимал (ну вдруг ты не понял о чем я): http://www[dot]deep-cms[dot]ru/api/sourc[dot][dot][dot]est[dot]html#312-348
Проверка там идет в два этапа:

1) проверяет только домен
2) проверяет путь от корня сайта, где правила проверки можно задавать и регуляркой

Вызывается оно в экшне удаления пользака, например, типа так:

-----
Шта? Репозиторий?

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

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

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

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

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

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

Однако в этой вот дискуссии я повторю в сотый раз -- реферер, это все что нужно, т.к. он проще, а эффективность у него такая-же как и у токена.

-----
Шта? Репозиторий?

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

Плюс, при наличии XSS уязвимости, твой реферер легко подменится каким нибудь курлом и сессайди будет на руках для осуществления успешного запроса.
Да, понимаю что это другая проблема. Но получается что защита от CSRF на реферерах не самодостаточна - ещё один минус в копилку реферера...

И да, не всегда хакер имея sessid на руках захочет это сделать своими руками.
Что бы например не попасть в лог или тупо не упереться на ограниченное пользование по IP. Поэтому даже если увели sessid, не факт что проблемы будут создавать своими руками посему даже в таком случае CSRF имеет место быть.

Как то так

(Отредактировано автором: 24 Ноября, 2015 - 22:46:23)

Кстати, а як ты определишь что тебя запросили с ифрейма, а? ))
В твоем варианте вообще не надо кликать.
Значит жертву уже поимели по полной программе -- получен непосредственный доступ к ПК.
Мы тут уже никакими припарками не поможем.
Причем тут курлы-шмурлы?
Опустим, не пугай ежа.
Лучше покажи как ты, проведя XSS, с помощью жс получишь куки чужого домена ))
Значит там был митм, т.к. через XSS куки чужого домена не увести.

Из пустого в порожнее.

-----
Шта? Репозиторий?

А зачем мне это определять? Ты же когда срц у айфрейма указываешь пишешь адрес, а токен не знаешь, поэтому и выясню отдавать тебе форму или нет)

Угу, потому что бесполезно

Если правильно понял вопрос, то достаточно поставить картинку в DOM а её сорц указать на свой сервер + document.cookie

Сори, мне пора) Если что пиши, думаю к завтрашнему вечерку отпишусь
(Добавление)

Забыл прокомментить
это вполне может быть инет клуб или другое общаковое заведение

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

Различие одно: не пришёл токен - это гарантированно ошибка. Не пришёл реферер - это допустимое поведение клиента. Убить реферер - просто. Поэтому от CSRF используют токены. Что, конечно, не мешает при желании проверять и реферер. Но его может штатно не быть.

-----
PostgreSQL DBA

Нет же. Ну ок, у тебя тоже один раз кликнуть надо для получения токена.
Куку чужого домена браузер не отправит на левый сорц.
На своем сайте ты имеешь доступ только к своим кукам.
Или тролль в гостях у жертвы, или жертва потеряла смарт, или...
От этого уже не спасет ни мой реферер, ни твой токен.
И токен тоже.
Это смотря в каком контексте рассматривать.
Убить === подменить.

-----
Шта? Репозиторий?

Да.


В любом. Отсутствие реферера - допустимое поведение клиента. RFC 2616


Нет. Убить === отключить его передачу (во всяком случае для этого запроса)
подменить === убедить клиента реферер передать, но другой

-----
PostgreSQL DBA

Кликнуть куда? Что мешает при не валидном запросе не подставлять токен никуда?

Ну да. Видимо я тебя неверно понял. Я вообще то говорил про XSS уязвимость на сайте жертвы а не на левом сайте и то только если нет httponly или есть но браузер допотопный

Сегодня очень много общественных мест где есть выход в интернет и машины в таких местах зачастую общие. Те же инет клубы.

(Отредактировано автором: 25 Ноября, 2015 - 19:36:08)

Но и отсутствие токена -- допустимое поведение клиента.
(Добавление)
Как он будет невалидным если ты запрос из ифрейма никак не отличишь от обычного.
Я вообще-то в самом-самом начале говорил что хсс это совсем другой вопрос.
ССЗБ.

-----
Шта? Репозиторий?

У каждого решения проблемы есть не только недостатки, но и стоимость решения. Если стоимость двух разных решений сопоставима, а недостатков у какой-то меньше - ее и нужно выбирать.

Токен тут имеет преимущество. При нормальной архитектуре кода (которая никак не связана с тем - нужен нам токен или нет) внедрение токена не сложнее проверки referer.
Но при этом мы не отсеиваем людей, у которых по каким-то причинам пустой referer.
Т.е. стоимость реализации сопоставима, но недостатков меньше.

Если у вас говнокод, в который вы просто не можете адекватно изменить, что бы добавить поддержку токенов... ну referer пойдет.

-----
self-banned

А не нужно отличать, нет валидного токена в запросе - нет валидного токена в ответе
все просто

Так никто не спорит Только защищаться от CSRF с помощью защиты от XSS немного странно : )))

Как раз-таки категоричное нет. Нет токена или токен неверен - недопустимая ошибка поведения клиента, при этом, не противоречащая каким-либо RFC. Запрошенное действие не выполнять, открыть вновь форму с соответствующим сообщением пользователю мол "попробуйте ещё раз".

-----
PostgreSQL DBA

Но ведь где-то должен выдаваться первичный валидный токен, иначе ты не отследишь токеновый след ))
Не пори чушь. Каким боком реферер спасает от XSS?
С таким подходом у нас разговора не выйдет.
Ты тред с самого начала осилил хотябы?
(Добавление)
Надо определиться что есть "клиент" -- программа-браузер или тело, тыкающее кнопы.
И загенерить токен, да? Иначе будет как у teddy -- токена нет? ПНХ! Иди получай в момент авторизации или я хз где, но в единственном месте.

-----
Шта? Репозиторий?