Vedroid & Mikas
Vedroid
Я только что заметил косяк в системе авторизации новой AR-игры – похоже на классический zero-day. Хочешь вместе разберемся, получится ли из этого хак или просто урок по защите?
Mikas
Окей, давай пройдёмся по процессу и посмотрим, где логика аутентификации сбоит. Я покажу, где слабые места, и мы набросаем исправление – без реальной эксплуатации, просто в теории.
Vedroid
Привет, начни с первичного обмена токенами. Большинство систем выдают JWT при входе, но если он хранится в локальном хранилище или куки без HttpOnly, у тебя уже есть уязвимость XSS. Потом проверь процесс обновления токена – если сервер принимает токен обновления с любого домена или по незащищенному HTTP, ты можешь просто воспроизвести его из украденной сессии. Поищи еще перенаправления в цикл; некоторые API перебрасывают на страницу авторизации при истечении срока действия токена, но если URL перенаправления не проверяется, злоумышленник может подсунуть поддельную ссылку, которая вернет пользователя на вредоносный хост с украденным токеном в параметрах запроса. Не забывай про отсутствие защиты от CSRF на эндпоинтах, изменяющих состояние; если ты используешь GET для сброса пароля, это тихий вектор атаки. Ну и наконец, если куки "помни меня" установлен как "secure", но без "SameSite=strict", межсайтовая вставка может перехватить его. Это наиболее распространенные уязвимости; исправление обычно сводится к ротации секретов, установке короткого срока жизни токенов, применению SameSite и переносу критических секретов в защищенные, HttpOnly куки.
Mikas
Отличный разбор, попадаешь во все стандартные подвохи. Просто помни про оптимальное решение: короткая жизнь JWT, ротация ключей, строгое SameSite, и refresh tokens только на серверном куки. Иначе XSS/CSRF превратится в настоящую брешь в безопасности. И если ты до сих пор используешь GET для сброса пароля, можешь сразу сдаваться.
Vedroid
Понял – короткие JWT, ротация ключей, SameSite strict, куки для обновления только на сервере. Никаких сбросов через GET, никаких открытых перенаправлений. Это должно удержать цикл под контролем. Если хочешь сделать еще надежнее, подумай о ротации секретов для каждого клиента и добавь белый список для источников запросов для критических операций. Держи трафик зашифрованным, всегда, и не забывай про строгие флаги для куки. Вот где настоящая золотая середина.
Mikas
Отличный чек-лист, но помни, даже если все флаги выставлены, хитрый XSS всё равно может вытащить куки, если ты хоть где-то используешь DOM API для этого. Вообще, лучше вообще не допускай токен на страницу, не давай клиенту его парсить. И ещё: белый список origin – это хорошо, но проверяй против реального referer, а не просто против заголовка, который можно подделать. Просто предупреждаю, иначе кто-нибудь, у кого окажется валидный refresh, сможет тебя обойти.
Vedroid
Да, вот как мы и собирались. Никаких токенов в DOM, никакого парсинга на стороне клиента, валидируй реальный Referer, а не подделанный заголовок. Оставляй обновление на серверном HttpOnly куки, меняй секреты, используй короткие JWT, и все будет в порядке. Если хочешь быть совсем уж педантичным, логируй каждую ошибку аутентификации и запускай многофакторную аутентификацию при повторных попытках. Держи все под контролем.