Фиксация сеанса

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

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

У Элис есть счет в банкеhttp://unsafe.example.com/

Мэллори намеревается украсть деньги Элис из ее банка.

У Элис есть разумный уровень доверия к Мэллори, и она будет посещать ссылки, которые Мэллори ей посылает.

Простой сценарий:

1. Мэллори определил, что http://unsafe.example.com/принимает любой идентификатор сеанса, принимает идентификаторы сеанса из строк запроса и не имеет проверки безопасности. http://unsafe.example.com/Таким образом, не является безопасным.
2. Мэллори отправляет Элис электронное письмо: «Эй, посмотри, в нашем банке появилась классная новая функция сводки по счету http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID». Мэллори пытается зафиксировать SID на I_WILL_KNOW_THE_SID.
3. Алиса заинтересовалась и зашла на сайт http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. Появляется обычный экран входа в систему, и Алиса входит в систему.
4. Мэллори посещает http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SIDаккаунт Элис и теперь имеет неограниченный доступ к нему.

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

Сценарий:

1. Мэллори посещает http://vulnerable.example.com/и проверяет, какой SID возвращается. Например, сервер может ответить: Set-Cookie: SID=0D6441FEA4496C2.
2. Теперь Мэллори может отправить Элис электронное письмо: «Ознакомьтесь с этой новой классной функцией в нашем банке http://vulnerable.example.com/?SID=0D6441FEA4496C2».
3. Алиса входит в систему с фиксированным идентификатором сеанса SID=0D6441FEA4496C2.
4. Мэллори посещает http://vulnerable.example.com/?SID=0D6441FEA4496C2аккаунт Элис и теперь имеет неограниченный доступ к нему.

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

Сценарий:

1. Веб-сайт www.example.comраздает поддомены ненадежным третьим лицам
2. Один из таких участников, Мэллори, который теперь контролирует evil.example.com, заманивает Элис на свой сайт
3. Посещение evil.example.comустанавливает сеансовый cookie-файл с доменом .example.comв браузере Алисы
4. При посещении Алисой www.example.comэтого сайта этот файл cookie будет отправлен вместе с запросом, и у Алисы будет сеанс, указанный в файле cookie Мэллори.
5. Если Алиса теперь войдет в систему, Мэллори сможет использовать ее учетную запись.

После завершения атаки Мэллори сможет получить доступ к www.example.comаккаунту Алисы.

Не обязательно, чтобы пользователь входил в систему для использования атак фиксации сеанса ^[1] и, хотя эти неаутентифицированные атаки не ограничиваются атаками на файлы cookie между поддоменами, последствия атак на поддомены актуальны для этих неаутентифицированных сценариев. Например, Mallory может предоставить URL со своего вредоносного сайта, фиксируя сеанс в неаутентифицированном сценарии, и использовать эти методы для эксплуатации своей цели. Это включает сценарии, использующие как неаутентифицированные сценарии (например, формы или регистрация), так и возможность скормить пользователю установленный сеанс, чтобы полностью обойти вход в систему.

Рассмотрим, например, что Мэллори может создать пользователя A1ice на www.example.com и войти в систему этого пользователя, чтобы захватить текущий действительный идентификатор сеанса. Затем Мэллори заманивает Алису в ловушку с URL-адресом из evil.example.com , который фиксирует этот сеансовый cookie в браузере Алисы (как описано выше) и перенаправляет на www.example.com для завершения определенной транзакции (или, по сути, более широкого использования). Таким образом, Мэллори может скрыть сеанс из их оригинального входа, соскребая данные и выполняя операции как «A1ice» на «www.example.com». Если Алиса была успешно обманута и сохранила свою кредитную карту в учетной записи, Мэллори может затем совершать покупки, используя эту карту.

Не рекомендуется использовать идентификаторы сеанса в URL (строка запроса, переменные GET) или переменные POST, поскольку они упрощают эту атаку — легко создавать ссылки или формы, которые устанавливают переменные GET/POST.

• SID становится известен другим людям, когда пользователи копируют и вставляют «интересные ссылки» из адресной строки в чаты, форумы, сообщества и т. д.
• SID хранится во многих местах (журнал истории браузера, журнал веб-сервера, журналы прокси-сервера, ...)

Примечание: Файлы cookie распределяются между вкладками и всплывающими окнами браузера. Если ваша система требует, чтобы был указан один и тот же домен (www.example.com/?code=site1 и www.example.com/?code=site2 ), файлы cookie могут конфликтовать между вкладками.

Может потребоваться отправить идентификатор сеанса на URL, чтобы обойти это ограничение. Если возможно, используйте site1.example.com или site2.example.com, чтобы не было конфликтов доменов в куки. Это может повлечь за собой расходы на дополнительные SSL-сертификаты.

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

Эту атаку можно в значительной степени избежать, изменив идентификатор сеанса при входе пользователей в систему. Если каждый запрос, относящийся к пользователю, требует, чтобы пользователь был аутентифицирован («вошел в систему») на сайте, злоумышленнику нужно будет знать идентификатор сеанса входа жертвы. Однако, когда жертва посещает ссылку с фиксированным идентификатором сеанса, ей нужно будет войти в свою учетную запись, чтобы сделать что-то «важное» от своего имени. В этот момент идентификатор сеанса изменится, и злоумышленник не сможет сделать ничего «важного» с анонимным идентификатором сеанса.

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

Этот метод также полезен против атак с подделкой межсайтовых запросов .

Идентификатор сеанса в большинстве современных систем по умолчанию хранится в HTTP-cookie , который имеет умеренный уровень безопасности, пока система сеанса игнорирует значения GET/POST. ^{[ необходима ссылка ]} Однако это решение уязвимо для подделки межсайтовых запросов и не соответствует требованию REST к отсутствию состояния .

При включении безопасности HTTPS некоторые системы позволяют приложениям получать идентификатор сеанса SSL/TLS . Использование идентификатора сеанса SSL/TLS очень безопасно, но многие языки веб-разработки не предоставляют надежную встроенную функциональность для этого.

Контрмера против фиксации сеанса — генерация нового идентификатора сеанса (SID) для каждого запроса. Если это сделать, то даже если злоумышленник может обмануть пользователя, заставив его принять известный SID, SID будет недействительным, когда злоумышленник попытается повторно использовать SID. Реализация такой системы проста, как показано ниже:

• Получить предыдущий идентификатор сеанса OLD_SIDиз HTTP-запроса.
• Если OLD_SIDзначение равно null, пусто или сеанс с SID= не OLD_SIDсуществует, создайте новый сеанс.
• Сгенерируйте новый идентификатор сеанса NEW_SIDс помощью безопасного генератора случайных чисел.
• Пусть сессия будет идентифицирована по SID= NEW_SID(а не по SID= OLD_SID)
• Передать новый SID клиенту.

Пример:

Если Мэллори успешно обманом заставит Алису посетить http://victim.example.com/?SID=I_KNOW_THE_SID, этот HTTP-запрос будет отправлен по адресу victim.example.com:

GET  /?SID=I_KNOW_THE_SID  HTTP / 1.1 Хост :  victim.example.com

victim.example.comпринимает SID=I_KNOW_THE_SID, что обычно было бы плохо. Однако, victim.example.comбезопасно, поскольку выполняет регенерацию сеанса. victim.example.comполучает следующий ответ:

HTTP / 1.1  200  OK Установить-Cookie :  SID=3134998145AB331F

Алиса теперь будет использовать SID=3134998145AB331Fто, что неизвестно Мэллори, и SID=I_KNOW_THE_SIDэто недействительно. Таким образом, Мэллори терпит неудачу в попытке фиксации сеанса.

К сожалению, восстановление сеанса не всегда возможно. Известно, что проблемы возникают при использовании стороннего программного обеспечения, такого как апплеты ActiveX или Java, а также при взаимодействии плагинов браузера с сервером. Стороннее программное обеспечение может вызывать выход из системы или сеанс может быть разделен на два отдельных сеанса.

Если реализация сеансов включает передачу SID через переменные GET или POST, то это также может сделать кнопку «Назад» в большинстве браузеров непригодной для использования, поскольку в этом случае пользователь будет использовать старый, недействительный идентификатор сеанса из предыдущего запроса.

Один из способов повышения безопасности — не принимать идентификаторы сеансов, которые не были сгенерированы сервером. Однако, как отмечено выше, это не предотвращает все атаки фиксации сеансов.

if  ( ! isset ( $_SESSION [ 'SERVER_GENERATED_SID' ]))  {  session_destroy ();  // Уничтожить все данные в сеансе } session_regenerate_id ();  // Создать новый идентификатор сеанса $_SESSION [ 'SERVER_GENERATED_SID' ]  =  true ;

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

if  ( logout )  {  session_destroy ();  // Уничтожить все данные в сеансе }

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

Сохраните переменную сеанса, содержащую временную метку последнего доступа, выполненного этим SID. Когда этот SID используется снова, сравните текущую временную метку с той, которая сохранена в сеансе. Если разница больше предопределенного числа, скажем, 5 минут, уничтожьте сеанс. В противном случае обновите переменную сеанса текущей временной меткой.

При посещении страницы большинство веб-браузеров устанавливают заголовок Referrer — страницу, содержащую ссылку, по которой вы перешли, чтобы попасть на эту страницу.

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

Например, http://vulnerable.example.com/можно использовать следующую проверку безопасности:

if  ( strpos ( $_SERVER [ 'HTTP_REFERER' ],  'http://vulnerable.example.com/' )  !==  0 )  {  session_destroy ();  // Уничтожить все данные в сеансе } session_regenerate_id ();  // Создать новый идентификатор сеанса

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

Поскольку все больше сетей начинают соответствовать RFC 3704 и другим методам защиты от спуфинга , IP-адрес становится более надежным идентификатором «того же источника». Таким образом, безопасность веб-сайта может быть улучшена путем проверки того, что исходный IP-адрес является постоянным на протяжении всего сеанса.

Это можно сделать следующим образом:

if  ( $_SERVER [ 'REMOTE_ADDR' ]  !=  $_SESSION [ 'PREV_REMOTEADDR' ])  {  session_destroy ();  // Уничтожить все данные в сеансе } session_regenerate_id ();  // Создать новый идентификатор сеанса $_SESSION [ 'PREV_REMOTEADDR' ]  =  $_SERVER [ 'REMOTE_ADDR' ];

Однако перед применением этого подхода следует учесть некоторые моменты.

• Несколько пользователей могут совместно использовать один IP-адрес. Нередко все здание совместно использует один IP-адрес с использованием NAT .
• У одного пользователя может быть несовместимый IP-адрес. Это справедливо для пользователей за прокси-серверами (например, клиентов AOL ). Это также справедливо для некоторых мобильных/роуминговых пользователей, а также для пользователей, которые находятся за балансировкой нагрузки интернет-подключений. Пользователи с включенными расширениями конфиденциальности IPv6 также могут изменить свои адреса конфиденциальности IPv6 в любое время.
• Он не будет надежно работать с клиентами с двойным стеком, поскольку запросы будут перемещаться между IPv4 и IPv6.
• Он не будет надежно работать с мобильными пользователями, поскольку мобильные пользователи также перемещаются между адресами.

Для некоторых сайтов дополнительная безопасность перевешивает недостаток удобства, а для других — нет.

Браузеры идентифицируют себя по заголовкам HTTP "User-Agent". Обычно этот заголовок не меняется во время использования; если бы это произошло, это было бы крайне подозрительно. Веб-приложение может использовать обнаружение User-Agent, чтобы помешать злоумышленникам украсть сеансы. Однако это легко обойти, так как злоумышленник может легко перехватить user-agent жертвы с помощью своего собственного сайта, а затем подделать его во время атаки. Эта предлагаемая система безопасности основана на безопасности через неизвестность .

if  ( $_SERVER [ 'HTTP_USER_AGENT' ]  !=  $_SESSION [ 'PREV_USERAGENT' ])  {  session_destroy ();  // Уничтожить все данные в сеансе } session_regenerate_id ();  // Создать новый идентификатор сеанса $_SESSION [ 'PREV_USERAGENT' ]  =  $_SERVER [ 'HTTP_USER_AGENT' ];

Однако перед применением этого подхода следует учесть некоторые моменты.

• Несколько пользователей могут иметь один и тот же User Agent браузера в интернет-кафе .
• У нескольких пользователей может быть один и тот же браузер по умолчанию (например, Internet Explorer 6 в Windows XP SP3 или мини-браузер в мобильном телефоне).

Но User Agent может законно измениться в некоторых случаях. Следующие примеры — те же пользователи.

• Смартфон, экран которого повернулся с момента последнего запроса
  • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
  • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2
• Режим совместимости с Internet Explorer:
  • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
  • Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
• Пользователь получает доступ к веб-сайту через прокси-сервер, распределенный по нескольким серверам, не все из которых обновлены до последней версии программного обеспечения прокси-сервера.
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (July 2019) (Learn how and when to remove this message)

Глубокая защита заключается в объединении нескольких контрмер. Идея проста: если одно препятствие преодолеть легко, то преодолеть несколько препятствий может быть очень сложно.

Стратегия глубокоэшелонированной обороны может включать:

• Включить HTTPS (для защиты от других проблем)
• Правильная конфигурация (не принимать внешние SID, устанавливать тайм-аут и т. д.)
• Выполнение session_regeneration, поддержка выхода из системы и т. д.

HTTP-рефереры не передаются с помощью SSL/TLS (HTTPS).

Следующий PHP-скрипт демонстрирует несколько таких контрмер, объединенных в систему глубокоэшелонированной защиты:

если  ( isset ( $_GET [ 'ВЫХОД' ])  ||  $_SERVER [ 'УДАЛЕННЫЙ_АДРЕС' ]  !==  $_SESSION [ 'ПРЕДЫДУЩИЙ_УДАЛЕННЫЙ_АДРЕС' ]  ||  $_SERVER [ 'HTTP_USER_AGENT' ]  !==  $_SESSION [ 'ПРЕДЫДУЩИЙ_USERAGENT' ])  {  session_destroy (); }session_regenerate_id ();  // Генерируем новый идентификатор сеанса$_SESSION [ 'PREV_USERAGENT' ]  =  $_SERVER [ 'HTTP_USER_AGENT' ]; $_SESSION [ 'PREV_REMOTEADDR' ]  =  $_SERVER [ 'REMOTE_ADDR' ];

Обратите внимание, что этот код проверяет текущий REMOTE_ADDR (IP-адрес пользователя) и User-agent по отношению к REMOTE_ADDR и User-agent предыдущего запроса. Это может быть неудобно для некоторых сайтов, как обсуждалось выше.

• Отравление сеанса
• Повышение привилегий

• Уголок безопасности: фиксация сеанса
• Уязвимость фиксации сеанса в веб-приложениях (PDF)
• Пример видео фиксации сеанса
• Классификация угроз Консорциума безопасности веб-приложений