Как защититься от кражи cookie не используя мета информацию (ip, etc..) и js?

Question

[bonav76690]

Если кто-то залез в браузер к пользователю и скопировал его куки себе - пиши пропало? Обязательно использовать js, локалсторедж и прочие браузерные приблуды? Чисто протоколом http и бакендом никак?
Какой есть алгоритм защиты, используя php?

Comments

[FanatPHP]

Тебе задали вопрос, что имеется в виду под "кто-то залез в браузер". Или ты на него ответишь, или вопрос будет удаён, как невнятный

[bonav76690]

FanatPHP, ты неадекват?

[FanatPHP]

Понятно

[bonav76690]

FanatPHP, дед иди на свежий воздух выйди подыши

Answer 1

[nokimaro]

Что подразумевается под "залез в браузер" ?
Если у злоумышленника полный доступ к компьютеру/браузеру, то помимо cookies точно так же можно достать данные localstorage и любых других "приблуд". И в принципе можно просто отправлять запросы из браузера как легитимный юзер, тут вы бессильны.

Если речь про воровство cookies через XSS, то есть флаг HttpOnly который предотвратит доступ к cookies через JS
https://owasp.org/www-community/HttpOnly

Против MITM-аттак, используйте HTTPS + HSTS.

Как доп защита, использовать GeoIP-базы, как делают соц. сети или почтовики, собирая данные об авторизации пользователя и выявляя аномальные входы (другая страна, другой город).

Comments

[bonav76690]

Отбросим всякие браузерные локалстореджы и тд, используется для авторизации пользователя только http протокол и атакуемая область только http. Допустим человек по середине перехватил запрос с куками, сохранил себе, как защититься от такого не используя мета инфу о пользователе (user agent, ip и тд)?

[Михаил]

CSRF

[bonav76690]

rasschitai, и как они помогут?

[FanatPHP]

HTTPS

[nokimaro]

bonav76690, использовать TLS (https) с HSTS чтобы предотвратить MiTM атаки.
Если возможна MitM атака, то атакующий может подделать на 100% любые запросы пользователя, любые секретные заголовки и тд и использовать тот же ip что и пользователь, раз они в одной сети.

[bonav76690]

nokimaro, ладно, злой украл только куки не юзая митм, хочу абстрагироваться от всех косвенностей. Допустим ему куки отправила тупая девушка друга, которая смогла увести куки. Как защититься всеравно?

[FanatPHP]

никак
но до него все равно не дойдёт.

[nokimaro]

bonav76690, ну если только средствами бэкенда, то привязать куку к сигнатуре браузера. К user agent, accept и тд. То есть нужно будет не только украсть куку, а вставить и использовать её в точно таком же браузере, в такой же версии OS и тд.
Подводные камни - при обновлении браузера, обновится user agent у легитимного пользователя.

[FanatPHP]

nokimaro, не нужно увлекаться фантазиями. Ни своими, ни чужими.
Старайся, чтобы твой ответ был осмысленным и, желательно, подкреплялся твоим собственным практическим опытом. А не представлял собой фантазии, единственная цель которых - желание удовлетворить бессвязный каприз автора вопроса.

[Михаил]

bonav76690, как доп. мера, в обще нужен комплекс...
- куки авторизации, должны быть не явными и меняться с интервалом (возможно с добавлением каких то солей, IP, UA, GEO, с первыми двумя есть ряд проблем)
- защита пост запросов, теми же CSRF токенами (тоже с солью можно и ограничение по времени жизни, лучше уникальный)
- проверка откуда пришел
- и т.д.

[nokimaro]

FanatPHP, мой ответ вполне осмысленный и не рекомендует ничего фантастического
HttpOnly против XSS, HTTPS против MiTM, аналитика авторизации по geo-ip.
всё остальное уже флуд в комментах

Answer 2

[Vladislav]

Сессии, как аналог их нельзя украсть.

Comments

[bonav76690]

Сессии на куках держутся, PHPSESSID та же самая кука

[Vladislav]

bonav76690, используй постоянно: session_regenerate_id(false)
и у тебя всегда будет уникальный id сессии.

[bonav76690]

а какая разница? пусть она генерится новая при каждом запросе, так когда ее будут доставать из браузера она всеравно будет актуальной!

[Vladislav]

bonav76690, тогда в вашем случае, ни как. если парсить каждый раз куки. и еще есть доступ к ПК...
если доступа к пк нет, то только бд. Не знаю что у вас там за сверх засекреченные данные уже такие

[bonav76690]

Владислав, это теоретический эксперимент

Answer 3

[Dimonchik]

если сервер богатый или учебный - websocket

но в целом проблемы нет от слова совсем:

перепутать одинаковые данные невозможно