аутентификация, кука и паническая атака

Обычно «ключ аутентификации», а это скорее всего просто access token или id сессии, делают короткоживущим, так что защита от угона в теории должна быть.

и передавать его нужно в URL

Так уже давно не делают. Да и раньше с этим боролись.

в url передавать категорически ничего не надо

Чем это плохая идея? Для этого по сути куки и нужны.
По поводу безопасности не использовать http.

а вообще, почитай про csrf

Верно. Можно воспринимать это как рестфул апи. Но используется лишь гет и пост, где гет только чтение, а пост: добавление, изменение, удаление. Смело куку гоняем всегда и везде, а на изменяющие действия лепим CSRF токен.

рад что ты заверил ;)

Ды я для ТСа развернул.

Чем это плохая идея?

У меня тот же вопрос

Тем, что один чел другому скинет ссылку с кукой и...

И совершенно нормальная практика передавать куку в заголовках. Плюс как сказали выше — https вместо http и даже заголовки будут шифрованы, собсно и кука в них тоже.

совершенно нормальная практика

да. так все и сделано. но ребята утверждают что есть некая атака связанная именно с кукой. я лично проблем не знаю связанных с кукой ни со стороны frontend (он чужие не прочитает), ни со стороны backend, поэтому спрашиваю тут.

передавая на backend login и пароль. в ответ backend возвращает для frontend в куке ключ аутентификации с которым работают остальные функции backend

А зачем тогда нужен ключ, если можно просто передавать логин/пароль в каждом запросе по http basic auth?

якобы существует некая атака против куки

Смотря что из себя представляет фронтенд. Если это браузер, то есть ненулевая вероятность, что эти куки сопрут, например через xss.

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

А зачем тогда нужен ключ, если можно просто передавать логин/пароль в каждом запросе по http basic auth?

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

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

Ну и ещё преимущество токенов, что для авторизации пользователя бекэнду совсем необязательно, к примеру, лезть в базу или обращаться к auth-серверу. Необходимые права можно инкапсулировать в сам токен - типа jwt.

Только если MITM при незащищенном соединении. Других вариантов не вижу.

Необходимые права можно инкапсулировать в сам токен - типа jwt.

Можно, вот только если они меняются есть период времени до протухания токена когда эти права не соответствуют действительности

Не знаю, как там с URL, а для Cookie имеет смысл подумыть о включении флагов HttpOnly и secure, если такая возможность есть.

но ребята утверждают что есть некая атака связанная именно с кукой

Попроси их текстом описать атаку. Возможно, они что-то там слышали, но толком не поняли. Когда будут формулировать текст, как раз эти приблизительные знания и структурируются.

есть период времени до протухания токена когда эти права не соответствуют действительности

Да, при этом подходе есть такая проблема, с отзывом токена. Но что мешает, если клиент с бэком по апи общается, отправить клиенту, давай обновляй токен. И ещё есть мнение, что клёво рулить токенами (access и refresh) на стороне бэка, а клиенту отдавать только access. Правда в этом случае пропадает красота решения.

В URL ни в коем случае на передавай что-то критичное так как: 1)URL не маскируется в адресной строке браузера 2)URL пишется в историю браузера. 3)По умолчанию многие балансировщики логгируют URL. Тут многие говорят про https, но у тебя самого может быть балансировщик с терминацией https. В таком случае даже доступа к его логам на чтение злоумышленнику хватит чтобы скомпроментировать твоих полльзователей.

По поводу флагов: secure - однозначно поставь. HttpOnly - только в том случае, если твой фронт не работает с печеньками из ява-скрипта.

Знакомые твои наверное имеют ввиду https://www.owasp.org/index.php/Clickjacking или https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

ХЗ чего их побуждает так воевать с печеньками. Скорее всего что то из серии «слушал звон да не знаю где он».

От себя рекомендую: Обязательно ознакомиться с https://www.owasp.org/index.php/OWASP_Secure_Headers_Project и пременить. Обсервотория мозиллы в помощь: https://observatory.mozilla.org Желательно ознакомиться с https://content-security-policy.com/ , причем не полениться выставить API для того, чтобы браузер тебе сообщал когда твоих пользователей пытаются XSS-сить (подробности см. ссылку) и организовать логгирование и мониторинг этих событий.

Данный комплекс мер гарантированно существенно снизит твои риски, связанные с использованием печенек. Если совсем уж риски большие или совсем уж хочется знакомым нос утереть, то озаботься Web Application Firewall-ом. Отсеивает сканирования ботов и скрипткидисов на ура. Усложняет жизнь проффи. Не является панацеей и не отменят потребности в написании безопасных web-приложений.

Не плохо хотя бы бегло ознакомиться с https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Вот неплохое руководство по защите REST API https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Вот длинный талмуд как ломать веб-приложения https://www.owasp.org/index.php/OWASP_Testing_Project

Как можно скинуть ссылку с кукой?

Вот если хранить токен в URL, то да - дырень, ибо копипаста ссылки (или даже просто скриншот, где видна строка адреса) и у юзера угоняют аккаунт.

Об токене речь и была. Не докапывайся к словам. Мы там друг друга поняли, а это главное. Ты кстати что там с трактором решил?

Буду пробовать хорошо учиться и поступать на второй год магистратуры. Пока по имеющейся информации это вроде как возможно даже при том как я сюда приехал (полгода дают достаточно ECT для перехода, потому что у меня выбраны все возможные для этого семестра предметы). У меня есть один очень социально активный одногруппник из Индии, который всё и всех знает, через него прощупываю почву.

Без опыта работы меня вряд ли возьмут на работу по специальности, я думаю.

обновляй токен

Тут есть проблема. На примере. Браузер, запрашивающий в двух вкладках один и тот же адрес, может получить во вкладке 1 тело ответа «предназначенное» для вкладки 2. То же самое и для аякса. Нет гарантии в очередности запрос-ответ.

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

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

Да, куки могут протухать, после окончания сессии, установленного срока или отсутствии какой-либо активности. Да, их тоже лочат, выше я объяснил почему это плохо, но их содержимое не обновляют на каждый чих, ибо окна, вкладки и аяксы.

А я вот наискал возможность скибнуть в Италию через миграцию бизнеса. Причем на вменяемых условиях в итоге. Образования у меня нет вообще. Так что это единственный для меня путь. Ну, это если все получится. Денег надо много по первости на такой финт, а дело как-то не особо клеится, вроде вертишься, а оно высоту не набирает, благо хоть пузом не чередит и то хорошо.

Желаю удачи :-)

Ну я совсем нищеброд. И бизнесом никогда не занимался. Так что мне только по учёбе или работе светит боюсь.

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

Тут есть проблема. Браузер, запрашивающий в двух вкладках один и тот же адрес...

У меня перед глазами пример SPA, клиент мессенджера, при открытии новой вкладки, предыдущая деактивируется. И клиент телеги по-моему так же себя ведёт.

Токен можно в localStorage хранить, хотя есть разные мнения на этот счет.

Это припарки. Даже в контексте одной вкладки может быть отправлено с десяток запросов на бекенд. И все они встанут в очередь если будет залочено.

Не суть где мы его храним, суть что оно будет втуплять если лочишь или глючить если не лочишь и меняеш часто куки.