Меры противодействия перехвату сеанса в ASP.NET

Я хочу принять меры для предотвращения/смягчения захвата сеанса. Таким образом, я хочу знать варианты либо из встроенных ASP.NET, либо из пользовательских компонентов.

Обратите внимание, что перехват сеанса относится к Forms Auth session и Session State.

Мой ASP.NET постоянно использует HTTPS для всех страниц. Но возможно, что сеанс может быть скомпрометирован после того, как идентификатор файла cookie сеанса каким-либо образом будет получен третьей стороной, например. с жесткого диска пользователя, атаки с использованием межсайтовых сценариев и атаки «человек посередине»

В частности, я обеспокоен перехватом идентификатора сеанса, потому что https все время используется для моих проектов.

Ниже приведены ссылки, которые я просмотрел, написанные несколько лет назад:

Предотвращение попыток перехвата сеанса, Джефф Просис Информацию о недостатках см. в разделе "Предостережения".

Я не могу найти много соответствующей информации или отличной от Джеффа информации в Интернете.


security asp.net webforms session-hijacking form-authentication
person Pingpong    schedule 20.05.2014    source источник
comment
См. Считаете ли вы репликацию сеанса угрозой безопасности?   -  person SilverlightFox    schedule 21.05.2014

Ответы (1)


arrow_upward
0
arrow_downward

Вот несколько предложений:

  1. Посолите свой sessionId. Это гарантирует, что у вас есть уникальные идентификаторы сеанса, хотя я почти уверен, что идентификаторы сеанса ASP.NET по умолчанию достаточно уникальны для ваших целей; однако для дополнительной безопасности вы можете использовать что-то, что либо вы можете контролировать, либо самоидентифицируется. Например, вы можете использовать GUID в качестве соли, которую вы можете контролировать, обновляя по своему усмотрению.
  2. Отслеживайте SessionId и IP-адрес пользователя ваших пользователей как пару в объекте словаря. Это позволит вам сопоставить идентификаторы сеанса с IP-адресом и выявить любой перехват сеанса, который происходит за пределами локальной сети пользователя. Очевидно, не без недостатков, так как не имеет большого значения, заражен ли компьютер или маршрутизатор пользователя, но это, по крайней мере, затруднит выполнение злоумышленником своей задачи.

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

person Byrdman    schedule 02.07.2014
comment
Что помешает злому третьему лицу использовать тот же идентификатор сеанса, упомянутый в вашем первом пункте? Он по-прежнему действителен, вы только что сменили поколение. Как вы упомянули, второй пункт имеет недостаток при изменении IP-адреса (мобильные пользователи в роуминге) и когда люди обмениваются адресами (прокси-серверы Google). - person sisve; 02.07.2014