CSRF-уязвимости все еще актуальны

[hMartin]

На Хабре в 2013 была CSRF уязвимость, регулярка проверки реферера была немного кривая и смотрела только вхождение habrahabr.ru/, я зарегал домен ~ hhabrahabr.ru и продемонстрировал поддержке как можно крутить карму :)

Еще у Мейлру была аналогичная проблема, у них на главной странице было/есть закрытое апи, определяющее залогиненность пользователя по кукам, там тоже был косяк в регулярке и можно было чекать на своем хосте залогинен ли посетитель в мире/мылору и его ФИО. Сдал тогда проблему их пиарщику, не в курсе, починили ли.

[w9w]

«В результате часть DOM HTML страницы будет отправлена на ресурс атакующего. Высока вероятность того, что если атакующий правильно внедрит такой HTML, тогда то, что придет на сайт атакующего, будет содержать CSRF-токен.»
А не проще встроить скрипт js сниффера на страницу и прислать полный исходный код себе в логи? Часто получаю логины, пароли, api токены и куки (которые на httponly) из исходника. Например ">

[everythingIsPossible]

Подскажите, это опечатка и в скобках должно быть «которые не httponly» или http-only куки тоже может кто-то сниффером утянуть?

[SanSYS]

Пару недель назад как раз столкнулся с возможностью писать любой html, но не <script ))
Так что не всегда можно внетрить именно скрипт

[mayorovp]

«Можно только смириться» — не совсем точный термин. На самом деле есть способы «спрятать» токен даже от скрипта выполняющегося на той же странице — «всего-то» и нужно заранее спрятать все глобальные объекты и их методы в локальных переменных замыкания, и токен засунуть туда же, а скрипт в котором все это содержится — удалить из DOM.

Проблема в том, что при наличии XSS злоумышленнику уже не нужна CSRF-атака :-)

[interprise]

А есть 100% (кроме xss, тут уже ничего не поможет) защита, кроме генерации токена каждый запрос?

[devalone]

токены в хедере вроде Authorization?

[interprise]

да, пожалуй, тоже отличный подход. Есть минусы?

[devalone]

Я не представляю, как сделать серверный рендеринг страниц, зависящих от пользователя, вроде списка моих комментариев, например, но оно вроде и не надо особо.

[demimurych]

Исходный посыл о том что во всем виноваты Cookies (особенности протокола http) как бы слегка передергивание. Виноваты программисты которые не понимают (не знают) как правильно программировать сервисы где бы атакующий не мог использовать подобный вектор атаки.

И делать заявления сродни «не используйте cokkie для сессий», это тоже самое что говорить — «не используйте лопату для капания ям — так вы точно не стукните ей себя по ноге». Вместо того чтобы объяснить и научить как пользоваться лопатой.

[johnfound]

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

[maxfox]

Судя по табличке в конце, проблемой является XSS, а не CSRF. Доступ к поддомену — это довольно специфический случай (ну, мне так кажется), остается XSS и HTML injection. Остальное решается токенами, готовые реализации которых есть, наверное, для всех порядочных фреймворков.
Так что, по сути, доклад про опасность XSS… Ну и довольно странный наезд на cookies — а какие есть альтернативы использованию cookies, при этом устойчивые к XSS? Если какие-то варианты и вправду существуют, интересно было бы послушать.
Но мне кажется, проблему стоит искать в архитекутуре веб-платформы, позволяющей исполнение любого js, который удастся подпихнуть браузеру. Правда, тут уже поздно что-либо менять…

[SanSYS]

Про поддомены — не так уж и специфично для мира в целом, достаточно найти cname на незанятую территорию ))
Вот оч простой пример — hackerone.com/reports/114134
А вот утилиты в помощь для поиска github.com/guelfoweb/knock, michenriksen.com/blog/subdomain-takeover-detection-with-aquatone

[DimNS]

Наиболее кардинальный и работающий вариант защититься от CSRF-атак — это избавиться от куков и использовать header с токенами.

О, я как раз так и делаю, всё общение с сервером выполняется через API, при каждом запросе подставляется токен, который хранится в локальных хранилищах браузера (используется либа localForage), я правильно понимаю, что я молодец?

Почему намекнули про кардинальное решение, но не описали его поподробнее?

[y4ppieflu]

Но у localstorage нет httponly, т.е. при налчии XSS, токен легко украсть. Как по мне, куки для хранения сессионного идентификатора надежнее. С CSRF лучше бороться другими методами.

[DimNS]

Ммм не знал, спасибо.

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

А в принципе, раз в localstorage есть проблемы, тогда получается что если хранить токен в куках, а можно его с помощью либы github.com/js-cookie/js-cookie вытаскивать и отправлять в header, в таком виде всё гуд? Или я тут напридумывал непонятно что?

[mayorovp]

Проблема тут очень простая. Идентификатор сессии или токен отправляется либо самим браузером, либо скриптом — третьего не дано.

В первом случае он подвержен CSRF, во втором — краже через XSS.

[vintage]

Третее: и браузером, и скриптом, каждый свой токен.

[mayorovp]

Тогда первый токен подвержен CSRF, а второй угоняется через XSS :-)

[SanSYS]

По существу норм доклад, но некоторые вещи явно не были раскрыты
Если вам хочется познакомиться с основами, при чём на реальных примерах, а не просто абстракциях, рекомендую книгу Питера Яворски leanpub.com/white-hat-hacking-ru
Перевод так се, так что лучше в оригинале
А вообще всем веб-разработчикам следует прочесть её