Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Оригинал: https://www.kuoll.com/the-end-of-csrf/Судя по всему, это урезанная версия этой статьи.
Пишут, что внедрение поддержки SameSite неактуально, поскольку Google предлагает на замену ей Cookie Prefixes, поддержка которых уже реализована в Crome 49+ и Firefox 50+.
На удивление мало информации о Cookie Prefixes в интернетах. Надо будет проработать и, если разберусь досконально, напишу здесь. P.S. Добавил ссылку на оригинал оригинала:)
судя по тому, что расположено по вашей ссылке это ограничения на установку куки. т.е. грубо говоря защита от того, что кто-то на поддомене инжектнет в браузер куку на основной домен. https://tools.ietf.org/html/draft-west-cookie-prefixes-05 в Introduction об этом написано, как бы это не пересекающийся кейс с csrf
Это было бы странно, учитывая, что гугл — один из авторов драфта на фичу на ietf…
Так вот почему bundlestar так по-дурацки работал — вполне возможно, что они ставили этот strict и после покупки автоматически разлогинивали при возврате в магазин.
Проблема в том что защита от CSRF давно уже реализована в браузерах через хедер Access-Control-Allow-Origin.
Остаточная проблема в scrf это устаревшие браузеры, которые не поддерживают этот хедер. Новый флаг для кукисов ничем не поможет, т.к. в старых браузерах его и не появится.
Остаточная проблема в scrf это устаревшие браузеры, которые не поддерживают этот хедер. Новый флаг для кукисов ничем не поможет, т.к. в старых браузерах его и не появится.
Я думаю это главный претендент в номинации «самая бесполезная фича в браузерах».
Данная идея только понижает общий уровень безопасности.
Старые браузеры сразу становятся уязвимы.
Плюс защита от XSRF (классическая, с токенами) неплохо защищала еще и от XSS, значительно снижая возможный ущерб, а допустить XSS проще чем XSRF ибо больше точек отказа. Т.е. и здесь ухудшение безопасности.
Ради чего? «Ну это… так красивее».
Данная идея только понижает общий уровень безопасности.
Старые браузеры сразу становятся уязвимы.
Плюс защита от XSRF (классическая, с токенами) неплохо защищала еще и от XSS, значительно снижая возможный ущерб, а допустить XSS проще чем XSRF ибо больше точек отказа. Т.е. и здесь ухудшение безопасности.
Ради чего? «Ну это… так красивее».
Для старых браузеров придется поддерживать токены, к примеру. Как всегда с новыми фичами. Не совсем понял, как CSRF-токены спасали от XSS.
И что мы выиграем если будем все равно использовать токены?
В чем профит? Есть кейс где описанные в статье заголовки защитят, а токены бы не справились? Нет.
Токены ставить надо? Да. Иначе проблемы со старыми браузерами. А старые браузеры будут вечно. ИЕ6 еще изредка встречается, а тут такое.
В чем профит кроме «о! круто! новая фича!»?
В чем профит? Есть кейс где описанные в статье заголовки защитят, а токены бы не справились? Нет.
Токены ставить надо? Да. Иначе проблемы со старыми браузерами. А старые браузеры будут вечно. ИЕ6 еще изредка встречается, а тут такое.
В чем профит кроме «о! круто! новая фича!»?
все ошибаются, если у вас какое-то действие можно выполнить без токена то при такой защите это минизирует ушерб
Ну да, я где-то ниже писал, что если у вас много легаси и сделать по нормальному нельзя, то оно уместно, но… как можно ошибиться если контроллер данные из форм берет через отдельный метод/сервис/функцию, которая по умолчанию требует токена? Специально отключить проверку? Отстрелить ногу можно более изящно.
А если проверка пишется ДЛЯ КАЖДОЙ формы то это говнокод. WET должен стать DRY.
И костыли тут не спасут. Кроме случая когда легаси, и надо «пусть не безопасно, но хоть как-то» или «исправлять мы не будем, вроде и так работает, но если вдруг где-то пропустили, то будет страховочка».
А если проверка пишется ДЛЯ КАЖДОЙ формы то это говнокод. WET должен стать DRY.
И костыли тут не спасут. Кроме случая когда легаси, и надо «пусть не безопасно, но хоть как-то» или «исправлять мы не будем, вроде и так работает, но если вдруг где-то пропустили, то будет страховочка».
Один из вариантов XSS — это когда у вас на странице оказывается чужой JavaScript код (еще раз, напрямую на странице), и как следствие, получает прямой доступ к контексту страницы и DOM, вместе со всеми CSRF-токенами, и возможности их отправлять куда угодно, включая ваши endpoints (CORS, кстати, при этом тоже радостно все пропустит — потому что скрипт локальный и для браузера ничем не отличается от ваших собственных). Именно поэтому токенная защита от CSRF не имеет смысла при возможности проведения XSS (это, кстати, цитата в переводе с одной из презентаций на прошлонедельном DEFCON). Если я что-то не понял в вашем посте, прошу прокомментировать.
Да, конечно, токены не панацея от XSS.
Я говорю лишь о том, что есть кейсы в которых токены бы спасли, но их нет…
Например уязвим блог на том же домене что и атакуемая админка. Админка не уязвима.
Вы внедряете скрипт в блог, там-же форма атаки, и всё, привет.
Конечно XSS лечится не токенами, но токены часто могут помешать развить уязвимость и минимизировать ущерб. Но мы собственно не об этом.
Мой комментарий был о том, что данная фича не приносит ничего полезного, а только ухудшает ситуацию по сравнению с текущей.
Если мы используем оба способа одновременно — и токены и описанные заголовки, то это лишние сущности. Больше безопасности не будет, зато нам нужно сделать лишние телодвижения для этих заголовков.
Если же мы не используем токены, то… то безопасность ухудшается.
1) страдают старые браузеры
2) в некоторых случаях другие уязвимости могут привести к большему ущербу чем привели бы с токнами
Выигрыш? Выигрыш в том что «красивее».
Единственный случай когда это может несколько повысить безопасность — если у вас очень много легаси-кода который очень, очень WET (Write Everything Twice), токены обрабатываются не в едином месте а прописаны руками в сотнях и сотнях форм (причем как правило такие приложения идут с шаблонами и бизнеслогикой в перемешку), «высушить» и вообще очеловечить код не представляется возможным, но хочется увеличить безопасность на случай если где-то в этой мешанине кто-то пропустил токены, и окажется уязвимость. Но это довольно специфичный и редкий случай, и тулить его везде — контрпродуктивно.
Я говорю лишь о том, что есть кейсы в которых токены бы спасли, но их нет…
Например уязвим блог на том же домене что и атакуемая админка. Админка не уязвима.
Вы внедряете скрипт в блог, там-же форма атаки, и всё, привет.
Конечно XSS лечится не токенами, но токены часто могут помешать развить уязвимость и минимизировать ущерб. Но мы собственно не об этом.
Мой комментарий был о том, что данная фича не приносит ничего полезного, а только ухудшает ситуацию по сравнению с текущей.
Если мы используем оба способа одновременно — и токены и описанные заголовки, то это лишние сущности. Больше безопасности не будет, зато нам нужно сделать лишние телодвижения для этих заголовков.
Если же мы не используем токены, то… то безопасность ухудшается.
1) страдают старые браузеры
2) в некоторых случаях другие уязвимости могут привести к большему ущербу чем привели бы с токнами
Выигрыш? Выигрыш в том что «красивее».
Единственный случай когда это может несколько повысить безопасность — если у вас очень много легаси-кода который очень, очень WET (Write Everything Twice), токены обрабатываются не в едином месте а прописаны руками в сотнях и сотнях форм (причем как правило такие приложения идут с шаблонами и бизнеслогикой в перемешку), «высушить» и вообще очеловечить код не представляется возможным, но хочется увеличить безопасность на случай если где-то в этой мешанине кто-то пропустил токены, и окажется уязвимость. Но это довольно специфичный и редкий случай, и тулить его везде — контрпродуктивно.
Это же разные вещи, все равно что взломостойкость двери и сложность подбора отмычки к замку.
Для защиты от XSS можно использовать Content-Security-Policy. Запретить выполнение всего, что явно не подписано вами и пришли из неизвестного источника.
что бы использовать подобную защиту надо быть уверенным, что на вашем сайте нет XSS, уж лучше токены
На деле, основной вектор атаки CSRF это флеш и расширения браузера. Они позволяют обходить «клиентскую» защиту от сфабрикованных запросов с куками пользователя. Если кто-то серьёзно хочет защититься от csrf, «клиентские» меры никогда не будут достаточны.
Поддержу. Сам периодически пишу то парсеры, то какие-либо боты для своих нужд под определенные сайты. Когда нет ограничений на запросы, CSRF — лишь маленькая неприятность и один доп. запрос на чтение токена.
Самый лучший метод, который я встречал — запутывание и шифрование. Например, комментарии на YouTube. По быстрому я так и не смог разобраться, как их отправить «самому» и просто эмулировал клик по кнопке, который кстати тоже обычным .click() не заработает :)
Самый лучший метод, который я встречал — запутывание и шифрование. Например, комментарии на YouTube. По быстрому я так и не смог разобраться, как их отправить «самому» и просто эмулировал клик по кнопке, который кстати тоже обычным .click() не заработает :)
Чистые Anti-CSRF токены не предназначены для защиты от ботов которые знают актуальные имя/пароль пользователя или имеют аутентификационный токен/куку, т.е. в случае CSRF атаки сам сценарий атаки немного другой. А вот разработчики youtube скорее всего делали свою защиту с учетом как раз этого требования.
Когда-то давно делал защиту следующим образом:
- При логине генерирования токен, который сохранялся в сессии
- Пользователь редиректилкся на страницу https://y.site/TOKEN/main
- Все следующие запросы были по относительным линка
замечательная вещь. дождаться поддержки остальных браузеров и можно реализовывать подобно Amazon.
То есть сначала мы надеялись на браузеры (что они отправляют правильный referer). Потом этого оказалось недостаточно. Теперь нам опять предлагают надеяться на браузеры?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конец CSRF близок?