Захват сеанса под другим углом

Я работаю над набором инструментов для безопасного входа в систему/портала, общий код не содержит SQL-инъекций, XSS и т.д. У меня есть много возможностей для остановки захвата сеанса.

восстановить идентификатор сеанса для КАЖДОЙ страницы
Сравнить IP-адрес пользователя с IP-адресом при входе в систему
сравнить пользователя user_agent с агентом при входе в систему
имеют короткие сеансовые тайм-ауты

и т.д.

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

Представьте себе ситуацию, когда у вас есть 2 пользователя за брандмауэром, который делает SNAT/DNAT, так что обособленно от одного и того же IP-адреса. Они оба идентичные машины, поставляемые одним и тем же местом. Один подключается к сайту и входит в систему, а другой копирует файл cookie PHPSESSID и может просто украсть сеанс.

Это может показаться крайним примером, однако это очень похоже на мое место работы, все находятся за брандмауэром, поэтому он выглядит как тот же IP-адрес, и все машины управляются/предоставляются ИТ-командой, поэтому все они имеют ту же версию браузера, ОС и т.д.

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

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

Ответ 1

Принудительно использовать HTTPS.

Я думаю, вы имеете в виду пассивную атаку, когда пользователь в сети нюхает куки. Для этого вам не нужен HTTPS. Есть несколько вариантов, которые достаточны, когда стороны уверены, с кем они говорят (например, вы могли бы сначала обменять DH, и сервер зашифровал бы токен, который клиент будет использовать в следующем запросе...), но это не стоит того, чтобы сбить этот маршрут.

Если пользователь изначально вводит адрес не-https, активная атака по-прежнему возможна, но в этом случае вы ничего не можете сделать. В будущем вы можете предотвратить будущие атаки такого рода, как только пользователь установит одно безупречное соединение с вашим сайтом через строгая транспортная безопасность HTTP..

Ответ 2

Я написал основной портал входа в основную ветку военных США.

Я сделал все, что вы упомянули выше, плюс еще один шаг:

Вы сохранили файл cookie при первом входе в систему с солью SESSION? Затем зашифруйте все серверы, используя эту соль. Мошенники должны были бы знать о THAT cookie и STEAL IT, и это резко снижает подверженность захвату сеанса, поскольку они просто не локуются за него.

Кроме того, используйте JS и AJAX, чтобы определить, установлены ли они, и если они это сделают, храните флеш файл cookie вместе с другой солью. В этот момент вы можете более или менее предположить, что у вас есть довольно преданные злоумышленники, и там не намного больше вы можете сделать (например, отправлять ваши GPG-ключи пользователей для использования через javascript и заставлять их подписывать каждый бит данных, которые они отправляют вам).

Ответ 3

Не заново изобретайте wheal, встроенный обработчик сеанса для вашей платформы очень безопасен.

Существует несколько конфигураций для обработчика сеанса PHP. Используйте HTTPS, ни в коем случае нельзя передавать идентификатор сеанса через http "cookie_secure", это отличная функция, но страшное имя. Файлы cookie httponly упрощают xss, потому что javascript не может получить доступ к document.cookie. Use_only_cookies останавливает фиксацию сеанса, потому что злоумышленник не может влиять на это значение в другом домене (если у него нет xss, но это спорная точка).

Конфигурация PHP:

session.cookie_httponly=on
session.cookie_secure=on
session.use_only_cookies=on

Ответ 4

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

Вы должны посмотреть:

Понимание идентификатора подлинности Rails

Токены - хорошая идея.