Полезно ли вообще использовать шифрование идентификатора сеанса (или другого значения аутентификации) в cookie?

Question

В веб-разработке, когда состояние сеанса включено, идентификатор сеанса сохраняется в cookie (в режиме без cookie вместо него будет использоваться строка запроса). В asp.net идентификатор сессии шифруется автоматически. В Интернете есть множество тем, касающихся того, как вы должны шифровать куки, включая идентификатор сессии. Я понимаю, почему вы хотите зашифровать личную информацию, такую ​​как DOB, но любая личная информация не должна храниться в cookie-файлах. Так что для других значений cookie, таких как идентификатор сеанса, какова цель шифрования? Это добавляет безопасность вообще? независимо от того, как вы его защитите, он будет отправлен обратно на сервер для расшифровки.

Будь конкретнее,

Для аутентификации

1. отключить сеанс, я больше не хочу иметь дело с временем ожидания сеанса
2. сохранить какое-либо значение идентификатора в куки,
3. на стороне сервера проверьте, существует ли значение идентификатора и соответствует ли оно аутентификации пользователя.
4. Позволяет файлу истечь после окончания сеанса браузера, таким образом.

против

Механизм аутентификации формы Asp.net (я полагаю, он использует сеанс или идентификатор сессии)

последний предлагает лучшую безопасность?

Answer 1

Атаки в сеансах, такие как Session Hijacking, стремятся получить действительный идентификатор сеанса. Если вы сейчас зашифруете идентификатор сеанса, злоумышленники просто будут стремиться получить зашифрованный идентификатор сеанса, и у вас не будет никакого преимущества. Поэтому шифрование идентификатора сеанса бесполезно. Помните, что идентификатор сеанса - это просто случайное значение, которое используется для идентификации сеанса. Злоумышленникам не нужно знать, имеет ли это случайное значение какое-то конкретное значение; им просто нужно знать это случайное значение.

Если вы хотите защитить сеанс, используйте HTTPS для шифрования всей HTTP-связи через SSL и устанавливайте куки только с флагами

• secure , чтобы разрешить отправку куки только через HTTPS и
• HttpOnly , чтобы запретить локальный доступ через JavaScript.

Answer 2

Я думаю, что «вы всегда должны шифровать свои данные» относится к использованию SSL в ваших соединениях с использованием надлежащим образом подписанного сертификата. Это зашифрует всю связь между клиентом и сервером.

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

Answer 3

Это задокументировано на сайте OWASP

Через web.config в элементе system.web/httpCookies

<httpCookies httpOnlyCookies="true" …> 

или программно

C# Code:
HttpCookie myCookie = new HttpCookie("myCookie");
myCookie.HttpOnly = true;
Response.AppendCookie(myCookie);

Answer 4

Данные, отправленные по протоколу SSL (HTTPS), полностью зашифрованы, включая заголовки (и, следовательно, файлы cookie), только тот хост, на который вы отправляете запрос, не шифруется. Это также означает, что запрос GET зашифрован (остальная часть URL). Несмотря на то, что злоумышленник может заставить клиента отвечать по HTTP, настоятельно рекомендуется использовать в файле cookie флаг «Secure», который предписывает использование HTTPS для отправки файлов cookie.

Атрибут Secure не имеет связанных значений. Скорее, наличие имен атрибутов указывает, что задано безопасное поведение. Атрибут Secure предназначен для ограничения связи cookie-файлов с зашифрованной передачей, позволяя браузерам использовать cookie-файлы только через безопасные / зашифрованные соединения. Естественно, веб-серверы должны устанавливать безопасные куки-файлы через безопасные / зашифрованные соединения, чтобы информация куки-файлов не передавалась таким образом, чтобы при первом отправлении в веб-браузер можно было подслушивать.

Answer 5

Шифрование случайных вещей ни к чему не приведет ...