- Типичные ошибки при защите сайтов от CSRF-атак
- Список ошибок:
- ERROR CSRF token mismatch #2719
- Comments
- StormYudi commented Nov 16, 2020 •
- DomiiBunn commented Nov 16, 2020
- StormYudi commented Nov 17, 2020
- DomiiBunn commented Nov 17, 2020
- StormYudi commented Nov 17, 2020
- DomiiBunn commented Nov 17, 2020
- StormYudi commented Nov 17, 2020
- mistermodcreator commented Nov 17, 2020 •
- YajTPG commented Nov 18, 2020
- alexevladgabriel commented Nov 18, 2020
- StormYudi commented Nov 20, 2020
- ajarmoszuk commented Dec 15, 2020
- ajarmoszuk commented Dec 15, 2020
- Techwolf12 commented Dec 23, 2020
- fabm3n commented Jan 12, 2021
- Dungeonseeker commented Feb 2, 2021
- eupedroosouza commented Sep 19, 2021
- SovernT13 commented Nov 21, 2021
- jordi00113 commented Nov 21, 2021 •
- Software-Noob commented Nov 21, 2021
Типичные ошибки при защите сайтов от CSRF-атак
В настоящее время в сфере обеспечения безопасности веб-сайтов и приложений возникла очень интересная ситуация: с одной стороны, некоторые разработчики уделяют особое внимание безопасности, с другой, они напрочь забывают о некоторых видах атак и не считают ошибки, позволяющие выполнить данные атаки, уязвимостями. Например, к такой категории можно отнести CSRF (Сross Site Request Forgery). Эта атака позволяет производить различные действия на уязвимом сайте от имени авторизованного пользователя. Если вы не слышали о таком, то я рекомендую прочитать соответствующую статью в Википедии, чтобы иметь общее представление об этом виде атак. Основная часть статьи предназначена тем, кто обеспокоен правильной защитой своих сайтов от CSRF.
Замечание 1: если подходить формально, то CSRF является атакой, а не уязвимостью, как и XSS. Уязвимостью является неправильная обработка входных данных, а CSRF это использует.
Замечание 2: если какие-то ошибки показались вам очевидными и не заслуживающими упоминания, то я рад за вас. Однако данный материал основан на реальных уязвимостях крупных сайтов, а каждый пункт показывает ошибку какой-либо команды разработчиков, обернувшуюся дырой в безопасности.
Список ошибок:
1) Полностью отсутствует защита от CSRF.
По своему опыту могу сказать, что в настоящее время это — самая распространенная ошибка. Ее можно встретить как на малопосещаемых блогах, так и на крупных проектах. Единственная уважительная причина не использовать защиту от данного вида атак — сайт не хранит никакие пользовательские данные, а вы не используете панель администратора для редактирования материалов.
2) Защищены не все запросы.
Я бы поставил эту ошибку на второе место по распространенности. На многих сайтах, где реализована какая-либо защита от CSRF, можно найти уязвимые запросы. Например, если вы воспользуетесь поиском Хабра habrahabr.ru/search/?q=CSRF, то увидите значительное количество статей, повествующих о найденных уязвимостях на тех сервисах, где есть защита.
Вы должны защищать абсолютно все запросы, которые изменяют что-либо на сайте. Вы добавили токен в форму смены адреса электронной почты, и злоумышленник не сможет завладеть аккаунтом вашего пользователя, изменив от его имени почту, а затем и пароль? Здорово. Вот только такая мера бесполезна, если можно просто отправить запрос на перевод денег с аккаунта жертвы на кошелек атакующего, минуя вашу защиту.
Удобство обеспечения безопасности — одна из причин использовать только метод POST для запросов, изменяющих данные пользователя. Если вы следуете этому совету, то необходимо просто убедиться, что все POST-запросы содержат надежный и правильный токен. Об этом речь пойдет ниже.
3) Использование для защиты от CSRF чего-либо, кроме токенов.
Казалось бы, очень удобно использовать HTTP referer (https://ru.wikipedia.org/wiki/HTTP_referer) для защиты от атак. Если в этом заголовке не страницы с вашего домена, то запрос был подделан. Но не все так радужно. У небольшой части пользователей HTTP referer может быть пуст по разным причинам. Кроме того, он может быть подделан с использованием старых версий Flash, что подставляет под удар тех, кто очень долго ничего не обновлял на своем компьютере.
Как насчет использования капчи? Я слышал достаточно большое количество вопросов от разработчиков о возможности их использования для защиты от атаки. Мой однозначный ответ — нет. Во-первых, вы явно не будете заставлять пользователя вводить капчу на каждый чих: это приведет к ошибке № 2. Во-вторых, далеко не все способы реализации капч обеспечат вас должной защитой, которую злоумышленник не сможет обойти. Поскольку эта тема является весьма спорной и актуальной, в дальнейшем я посвящу ей отдельную статью.
Для защиты от CSRF вы должны использовать анти-CSRF токены и только их. Лишь они обеспечивают должную защиту ваших сайтов. В общих чертах о механизме токенов рассказано в Википедии:
Другим распространённым способом защиты является механизм, при котором с каждой сессией пользователя ассоциируется дополнительный секретный ключ, предназначенный для выполнения запросов. Пользователь посылает этот ключ среди параметров каждого запроса, и перед выполнением каких-либо действий сервер проверяет этот ключ. Преимуществом данного механизма, по сравнению с проверкой Referer, является гарантированная защита от атак данного типа. Недостатками же являются: требования возможности организации пользовательских сессий и динамической генерации HTML-кода активных страниц сайта.
4) Отсутствие проверки анти-CSRF токена при обработке запроса.
Подобную ошибку я встречал на сайтах весьма серьезных компаний, чья безопасность должна быть на высоте.
В самом запросе токен есть, а при его обработке он не проверяется. Можно вставить в это поле любую строку, запрос все равно будет корректно обработан. Комментировать тут особенно нечего, надо только указать, что применение функции isset() php.net/manual/ru/function.isset.php для проверки токена совершенно недопустимо.
5) Частичная проверка анти-CSRF токена.
Данную ошибку я встретил сразу на нескольких крупных сайтах рунета в разных вариациях. Например, один из сайтов использовал токены вида «Имя_пользователя.Текущее_время.Длинное_случайное_число». При этом проверялось только соответствие имени пользователя в токене и логина того, от чьего имени был отправлен запрос. Это немного усложняет атаку, но не делает ее невозможной.
6) Возможность использовать один токен для разных пользователей.
Данную ошибку я встретил один раз, но на достаточно крупном сайте, так что считаю необходимым упомянуть ее. Злоумышленник мог зарегистрировать новый аккаунт на сайте, скопировать токен из исходного кода страницы и использовать его для CSRF. Не допускайте такой ошибки, так как она полностью уничтожает все плюсы токенов на вашем сайте.
7) Недостаточная длина токена.
Ваш токен должен быть настолько длинным, чтобы злоумышленник потратил на его подбор как минимум столько же времени, сколько и на подбор пароля пользователя. Я встречал токены из 2 символов, они не сильно помогут, если кто-то очень сильно захочет осуществить CSRF-атаку.
8) Предсказумые токены.
При разработке алгоритма генерации токена обязательно используйте случайные данные в токене (совет актуален, если вы разрабатываете всю систему с нуля. В случае использования фреймворка или CMS вы должны полагаться на их разработчиков). Поверьте, токен вида «md5(user_id)» — очень плохая идея.
9) Отсутствие токенов в админ-панели или системе для сотрудников техподдержки.
Даже если весь доступный вашим пользователям сайт защищен от CSRF, то не стоит забывать про панель администратора. В одной известной в узких кругах биллинг-системе было много CSRF именно в панели администратора (хотя они были и в публичной части системы, но это не так важно). И любой, кто знал структуру запросов, мог использовать CSRF-атаку на сотрудника техподдержки и получить доступ к данным всех клиентов компании, использующей данную биллинг-систему. Единственная проблема — необходимо узнать структуру запросов: для этого можно использовать социальную инженерию, скачать копию в открытых источниках или просто взломать менее защищенный сайт, использующий такую же систему.
10) Передача токенов в открытом виде, особенно в GET-запросах.
На нескольких сайтах я видел ситуации, когда токены пользователей передавались в открытом виде: если токен содержится в адресе страницы, то пользователь может скопировать ссылку целиком и разместить ее где-нибудь, даже не подозревая об опасности. Вам не нужно сильно беспокоиться о скрытой передаче токенов только тогда, когда они одноразовые, а пользователь может случайно раскрыть только использованный токен. Однако это все равно не очень хорошо, так как сигнализирует о некоторых проблемах с архитектурой приложения: например, вы используете GET, а не POST для запросов, изменяющих пользовательские данные.
Наличие этих ошибок даже на крупных и серьезных сайтах показывает, что проблема защиты от CSRF-атак стоит достаточно остро. Безусловно, этот список не является исчерпывающим. Я уверен, что можно найти еще несколько ошибок и способов их эксплуатации. Однако если вы проверите свои сайты на наличие проблем, описанных в этой статье, и исправите их, то значительно повысите защищенность проекта.
Источник
ERROR CSRF token mismatch #2719
Comments
StormYudi commented Nov 16, 2020 •
Background:
- Panel or Daemon: Panel
- Version of Panel/Daemon: 1.1.1
- Server’s OS: CentOS 7
- Your Computer’s OS & Browser: Safari 14.0.1
Describe
I’ve installed the latest 1.1.1 version panel in my CentOS 7 server, after the setup, I was trying to login in the panel, and then I’ve got an error with message CSRF token mismatch, http code 419.
The login form with X-CSRF-Token header is empty, I think something is wrong, is that a bug?
The text was updated successfully, but these errors were encountered:
DomiiBunn commented Nov 16, 2020
Most likley your php version is out of date. Try asking for help here 1st https://discord.gg/PN6eYsBY if that’s the solution close the issue please ^.^
StormYudi commented Nov 17, 2020
Most likley your php version is out of date. Try asking for help here 1st https://discord.gg/PN6eYsBY if that’s the solution close the issue please ^.^
Thanks for your help, But I am using PHP7.4 with Mysql 5.7 🙁
DomiiBunn commented Nov 17, 2020
Panel logs would be usefull tail -n 100 /var/www/pterodactyl/storage/logs/laravel-$(date +%F).log | nc bin.ptdl.co 99
StormYudi commented Nov 17, 2020
There is no logs 🙁 the file is empty, I will try to reinstall the panel in ubuntu, thanks
DomiiBunn commented Nov 17, 2020
There has to be a log if you get an error ^.^ try to go to the panel again and than run the log command
StormYudi commented Nov 17, 2020
I checked it again and it was really not there 🙁
[root@localhost ptero.rainyun.com]# tail -n 100 /www/wwwroot/ptero.rainyun.com/storage/logs/laravel-$(date +%F).log | nc bin.ptdl.co 99
tail: cannot open ‘/www/wwwroot/ptero.rainyun.com/storage/logs/laravel-2020-11-17.log’ for reading: No such file or directory
mistermodcreator commented Nov 17, 2020 •
I got the same Error and the log is the following:
Probably this can help?
YajTPG commented Nov 18, 2020
Usually clearing Cookies fixes that error. (Atleast for me)
alexevladgabriel commented Nov 18, 2020
Are you using a ssl configuration with http:// connection?
Do you have generated ssl for that domain?
StormYudi commented Nov 20, 2020
@alexevladgabriel I am not using https at that time.
I simply reinstall the OS and reinstall the panel again, it works now, thank you all.
ajarmoszuk commented Dec 15, 2020
This is unfortunately still an issue, running PHP 7.4.13. Not sure what is happening but there is no information to suggest any issues. Nothing is to be found in the logs.
ajarmoszuk commented Dec 15, 2020
Site is running on HTTPS.
Techwolf12 commented Dec 23, 2020
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
fabm3n commented Jan 12, 2021
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
This would not change anything because the default value is already false: https://github.com/pterodactyl/panel/blob/develop/config/session.php#L163
Dungeonseeker commented Feb 2, 2021
Same issue here on Ubuntu Server 20.10 running Apache & PHP 7.14
#0 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(358): Swift_Transport_AbstractSmtpTransport->assertResponseCode #1 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(147): Swift_Transport_AbstractSmtpTransport->readGreeting #2 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/SendmailTransport.php(50): Swift_Transport_AbstractSmtpTransport->start #3 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Mailer.php(65): Swift_Transport_SendmailTransport->start #4 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php(521): Swift_Mailer->send #5 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php(288): Illuminate\Mail\Mailer->sendSwiftMessage #6 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/Channels/MailChannel.php(65): Illuminate\Mail\Mailer->send #7 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/NotificationSender.php(146): Illuminate\Notifications\Channels\MailChannel->send #8 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/NotificationSender.php(105): Illuminate\Notifications\NotificationSender->sendToNotifiable #9 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Support/Traits/Localizable.php(19): Illuminate\Notifications\NotificationSender->Illuminate\Notifications\
eupedroosouza commented Sep 19, 2021
Sem SSL aqui. Ele falha ao criar um cookie «XSRF-TOKEN» porque deseja definir como seguro e os cookies não https não podem ser definidos como seguros.
Consertar isso:
This worked for me, thanks!
SovernT13 commented Nov 21, 2021
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
This also worked for me. I was using a custom installer script though.
jordi00113 commented Nov 21, 2021 •
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
Worked for me. I used https first instead of http.
This setting was not changed back when going through the installer
Software-Noob commented Nov 21, 2021
We don’t offer any installers. If you have an issue with such, contact the author of it directly. The fix is above should someone stumble upon this in the future.
The value depends on what protocol scheme you choose during installation, and also, our support bot in Discord can respond to this issue.
Источник
