Состояние сеанса

ASP.NET --- Основы ASP.NET --- Состояние сеанса

Состояние сеанса (session state) — это самая сложная технология для управления состояниями. Она позволяет сохранять информацию на одной странице и затем получать к ней доступ с другой страницы, а также поддерживает объекты любого типа, включая специальные, создаваемые самим разработчиком типы данных. Лучше всего то, что состояние сеанса использует такой же основанный на коллекциях синтаксис, что и состояние представления. Единственное отличие связано с именем встроенного свойства страницы, которое в данном случае выглядит как Session.

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

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

Архитектура сеанса

Управление сеансом не является частью HTTP-стандарта. Поэтому для отслеживания информации сеанса и ее привязки к соответствующему ответу ASP.NET приходится выполнять дополнительную работу.

ASP.NET отслеживает каждый сеанс с помощью уникального 120-битового идентификатора. Для генерации этого значения ASP.NET использует патентованный алгоритм, что, согласно статистике, обеспечивает гарантию того, что число будет уникальным и достаточно случайным для того, чтобы злоумышленник не смог воссоздать или угадать идентификатор сеанса, которым будет пользоваться данный клиент. Этот идентификатор является единственным фрагментом информации, который передается между вебсервером и клиентом.

Когда клиент предоставляет идентификатор сеанса, ASP.NET отыскивает соответствующий сеанс, извлекает с сервера состояний сериализированные данные, преобразует их в реальные объекты и помещает эти объекты в специальную коллекцию для того, чтобы к ним можно было получить доступ в коде. Весь этот процесс выполняется автоматически.

При каждом новом запросе ASP.NET генерирует новый идентификатор сеанса до тех пор, пока состояние сеанса не будет фактически использовано для сохранения какой-то информации. Такое поведение позволяет немного увеличить производительность. Коротко это можно объяснить так: зачем тратить время на сохранение идентификатора сеанса, если он не используется?

Когда ASP.NET обрабатывает HTTP-запрос, тот проходит через конвейер различных модулей, которые могут реагировать на события приложения. Одним из модулей в этой цепочке является SessionStateModule (который находится в пространстве имен System.Web.SessionState). Этот модуль генерирует идентификатор сеанса, извлекает из внешних поставщиков состояния данные сеанса и затем привязывает эти данные к контексту вызовов запроса. Он также сохраняет данные состояния сеанса, когда обработка страницы завершается.

Однако важно понимать, что модуль SessionStateModule фактически не хранит данные сеанса. Вместо этого состояние сеанса сохраняется во внешних компонентах, которые называются поставщиками состояния:

Состояние сеанса представляет собой еще один пример сменной архитектуры ASP.NET. Поставщиком состояния может быть любой класс, который реализует интерфейс IHttpSessionState, а это значит, что способ работы состояния сеанса можно настроить, просто создав (или купив) новый .NET-компонент. ASP.NET включает три готовых поставщика состояния, которые позволяют сохранять информацию внутри процесса, в отдельной службе и в базе данных SQL Server.

Чтобы механизм состояния сеанса работал, клиент вместе с каждым запросом должен предоставлять соответствующий идентификатор сеанса. Финальным фрагментом данной головоломки является способ отслеживания этого идентификатора сеанса от одного запроса к другому. Это можно делать двумя способами:

• С применением cookie-наборов. В этом случае идентификатор сеанса передается в специальном cookie-наборе (по имени ASP.NET_SessionId), который ASP.NET создает автоматически, когда используется коллекция сеанса. Он применяется по умолчанию и соответствует способу из более ранних версий ASP.

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

Использование состояния сеанса

Взаимодействовать с состоянием сеанса можно с помощью класса System.Web.SessionState.HttpSessionState, который на веб-странице ASP.NET доступен в виде встроенного объекта Session. Синтаксис для добавления элементов в эту коллекцию и их извлечения выглядит практически так же, как и синтаксис, который используется для добавления элементов в состояние представления страницы.

Например, вот как сохранить объект DataSet в памяти сеанса:

Session["ProductsDataSet"] = dsProducts;

После этого его можно извлечь с помощью соответствующей операции преобразования:

dsProducts = (DataSet)Session["ProductsDataSet"];

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

• Если пользователь закрывает и заново запускает браузер.

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

• Если сеанс завершается из-за отсутствия активности со стороны пользователя. По умолчанию сеанс автоматически завершается после 20 минут простоя.

• Если программист завершает сеанс вызовом метода Session.Abandon().

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

Вдобавок данные состояния сеанса также будут утеряны и в случае повторного создания домена приложения. Этот процесс происходит автоматически при обновлении веб-приложения либо изменении конфигурационных параметров. Домен приложения также может создаваться заново через определенные промежутки времени для поддержания приложения в нормальном работоспособном состоянии. Если такое поведение приводит к возникновению проблем, данные состояния сеанса можно хранить вне процесса. В таком случае они не потеряются даже в результате завершения домена приложения.

В таблице ниже перечислены основные методы и свойства класса HttpSessionState:

Конфигурирование состояния сеанса

Сконфигурировать состояние сеанса можно с помощью элемента <sessionState> в файле web.config. Ниже показаны все доступные параметры настройки, которые можно применять:

<?xml version="1.0"?>
<configuration>  
   <system.web>    
       <sessionState mode="Off|InProc|StateServer|SQLServer|Custom" 
             stateConnectionString="tcpip=127.0.0.1:2549" stateNetworkTimeout="10"      
             sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"       
             sqlCommandTimeout="30" allowCustomSqlDatabase="false"       
             useHostingIdentity="true|false"       
             compressionEnabled="true|false"       
             cookieless="UseCookies" cookieName="ASP.NET_SessionId"       
             regenerateExpiredSessionId="true|false"       
             timeout="20"      
             customProvider=""    
       />  
   </system.web>
</configuration>

Атрибуты сеанса подробно описаны в последующих разделах.

Mode

Параметр настройки состояния сеанса Mode позволяет указать, какой поставщик состояния сеанса должен использоваться для хранения данных состояния сеанса между запросами. Допустимые значения перечислены ниже:

Off

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

InProc

Установка значения InProc напоминает подход, который использовался для хранения состояния сеанса в классической версии ASP. Это значение указывает ASP.NET хранить информацию в текущем домене приложения, что обеспечивает наилучшую производительность, но наименьший срок хранения: если вы перезапустите сервер, данные состояния будут утеряны.

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

Еще одна причина, по которой установка значения InProc может быть нежелательной, состоит в том, что она приводит к получению более "хрупких" сеансов. В ASP.NET домены приложений создаются заново в ответ на различные действия, включая изменения конфигурационных настроек, обновления страниц, а также достижение определенных пороговых значений (независимо от того, произошла ошибка или нет). Если вы обнаружите, что домен приложения часто перезапускается, что приводит к преждевременному завершению сеансов, можете воспользоваться одним из более надежных поставщиков состояния сеанса.

StateServer

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

Выбрав режим StateServer, обязательно следует указать значение для параметра stateConnectionString. Эта строка сообщает TCP/IP-адрес компьютера, на котором запускается служба StateServer, и номер его порта (который определяется ASP.NET и который обычно изменять не нужно), что позволяет обслуживать службу StateServer на другом компьютере. Если не изменить значение этого параметра, использоваться будет локальный сервер (с адресом 127.0.0.1).

Разумеется, эта служба должна быть запущена, чтобы приложение могло с ней взаимодействовать. Проще всего это сделать с помощью консоли управления Microsoft (Microsoft Management Console). Выберите в меню Start (Пуск) пункт Programs --> Administrative Tools --> Computer Management (Все программы --> Администрирование --> Управление компьютером) или же откройте окно панели управления, щелкните на значке Administrative Tools (Администрирование), а затем на значке Computer Management (Управление компьютером). В появившемся диалоговом окне Computer Management (Управление компьютером) разверните узел Services and Applications (Службы и приложения) и щелкните на элементе Services (Службы). В правой части окна появится список служб: отыщите в нем службу по имени ASP.NET State Service:

Отыскав службу в списке, вы можете вручную запустить или остановить ее с помощью щелчка правой кнопкой мыши. Обычно имеет смысл сконфигурировать ОС Windows так, чтобы эта служба запускалась автоматически. Для этого щелкните на имени службы правой кнопкой мыши, в появившемся контекстном меню выберите пункт Properties (Свойства). После этого в списке Startup Type (Тип запуска) выберите значение Automatic (Автоматически), как показано на рисунке ниже. Далее щелкните на кнопке Start (Запустить), чтобы запустить эту службу немедленно.

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

SQLServer

Это значение заставляет ASP.NET использовать для хранения информации о сеансе базу данных SQL Server, применяя параметры, определенные в атрибуте sqlConnectionString. Такой способ управления состоянием является наиболее удобным, но пока что самым медленным. Чтобы его можно было использовать, на сервере должна быть установлена система SQL Server.

Установка значения для атрибута sqlConnectionString выполняется по схеме, подобной той, что применяется для получения доступа к данным ADO.NET. В целом это подразумевает указание источника данных (адреса сервера), имени пользователя и пароля, если только не используется интегрированная система безопасности SQL.

Вдобавок также должны быть установлены специальные хранимые процедуры и временные базы данных сеансов. Эти хранимые процедуры будут отвечать за сохранение и извлечение данных сеанса. В состав ASP.NET входит утилита командной строки, позволяющая выполнять эту задачу автоматически. Называется она aspnet_regsql.exe и находится в каталоге c:\Windows\Microsoft.NET\Framework\[Версия].

Удобнее всего запускать ее в окне командной строки Visual Studio (выберите в меню Start (Пуск) пункт Programs --> Microsoft Visual Studio 2012 --> Visual Studio Tools --> Visual Studio 2012 Command Prompt. Затем можно сразу же вводить команду aspnet_regsql.exe независимо от того, в каком каталоге она открыта.

Утилита aspnet_regsql.exe может применяться для решения нескольких связанных с базами данных задач. Чтобы использовать ее для создания базы данных с хранилищем сеансов, нужно указать параметр -ssadd. Кроме того, параметр -S позволяет указать имя сервера базы данных, а параметр -Е — что для подключения к этой базе данных должна использоваться учетная запись текущего пользователя Windows.

Ниже показана команда, которая создает базу данных для хранения данных сеанса на текущем компьютере, используя для нее стандартное имя ASPState:

aspnet_regsql.exe -S localhost -E -ssadd

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

После создания базы данных состояния сеанса необходимо указать ASP.NET ее использовать, внеся соответствующие изменения в раздел <sessionState> файла web.config. Если для хранения информации о состоянии сеанса была создана база данных ASPState (это принято по умолчанию), тогда предоставлять ее имя в разделе <sessionState> не нужно. Вместо этого следует указать место размещения сервера и тип аутентификации, который ASP.NET должна применять для подключения к этому серверу:

<sessionState mode="SQLServer"    
    sqlConnectionString="data source=localhost;Integrated Security=SSPI" ... />

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

Для удаления базы данных ASPState используйте параметр -ssremove.

Обычно при управлении состоянием с помощью SQL Server по-прежнему действует стандартный параметр тайм-аута состояния сеанса. Причина в том, что утилита aspnet_regsql.exe также создает для SQL Server новое задание по имени ASPState_Job_DeleteExpiredSessions. До тех пор, пока работает служба SQLServerAgent, это задание будет выполняться каждую минуту.

Кроме того, при каждом перезапуске сервера SQL Server, независимо от значения тайм-аута сеанса, будут удаляться таблицы данных состояния. Дело в том, что таблицы информации о состоянии создаются в базе данных tempdb, которая является всего лишь временным хранилищем. Если такое поведение не подходит, можно указать утилите aspnet_regsql.exe установить в базе данных ASPState постоянные таблицы данных состояния. Для этого понадобится использовать параметр -sstype p (где p означает "persisted" (постоянный)). Ниже показана модифицированная версия предыдущей команды:

aspnet_regsql.exe -S localhost -Е -ssadd -sstype p

Теперь записи сеанса будут оставаться в базе данных даже в случае перезапуска SQL Server.

И, наконец, последний вариант: утилиту aspnet_regsql.exe также можно применять для создания таблиц данных состояния в какой-то другой базе данных (отличной от ASPState). Для этого применяется параметр -sstype c (где c означает "custom" (специальный)) и указывается имя базы данных в параметре -d:

aspnet_regsql.exe -S localhost -E -ssadd -sstype с -d MyCustomStateDb

При таком подходе таблицы данных сеанса будут сразу же созданы как постоянные, так что содержащиеся в них записи будут оставаться даже после перезапуска SQL Server.

В случае использования специальной базы данных также потребуется выполнить две конфигурационные настройки в разделе <sessionState> файла web.сonfig. Во-первых, необходимо установить атрибут allowCustomSqlDatabase в true. Во-вторых, понадобится добавить в строку соединения параметр InitialCatalog с именем используемой базы данных. Ниже показан должным образом настроенный элемент <sessionState>:

<sessionState Mode="SQLServer" allowCustomSqlDatabase="true"        
    sqlConnectionString="data source=localhost;Integrated Security=SSPI; Initial Catalog=MyCustomStateDb" ... />

В случае выбора режима SQLServer также можно устанавливать значение для необязательного атрибута sqlCommandTimeout, который задает максимальное количество секунд на ожидание ответа от базы данных перед отменой запроса. По умолчанию значение равно 30 секундам.

Custom

Выбор специального (Custom) режима требует указания используемого поставщика хранилища данных о состоянии сеанса с помощью атрибута customProvider. В атрибуте customProvider может быть задано как имя класса, являющегося частью веб-приложения и хранящегося в каталоге App_Code, так и имя класса, входящего в состав скомпилированной сборки и хранящегося в каталоге Bin или в глобальном кэше сборок (GAC).

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

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

Сжатие

В ASP.NET доступно средство сжатия, которое позволяет сократить размер сериализируемых данных сеанса. Если установить атрибут enableCompression в true, данные сеанса перед отправкой за пределы процесса будут сжиматься (с использованием класса System.IO.Compression.GZipStream). Параметр enableCompression действует только при использовании внепроцессного хранилища состояния сеанса, поскольку только в такой ситуации данные сериализируются.

Для сжатия и восстановления данных сеанса веб-сервер должен выполнять дополнительную работу. Однако обычно это никакой проблемы не представляет, т.к. сжатие применяется лишь в тех сценариях, когда веб-серверы имеют массу лишнего времени ЦП, но ограничены по каким-то другим показателям. Сжатие данных состояния сеанса имеет смысл в описанных двух ключевых ситуациях:

• При сохранении больших объемов данных состояния сеанса в памяти. Память вебсервера является очень ценным ресурсом. В идеале состояние сеанса применяется для сохранения относительно небольших фрагментов информации, а для остальных требующих более длительного хранения и больших по объему данных применяется база данных. Но если это не так и внепроцессный сервер состояния требует огромных объемов памяти, сжатие может оказаться подходящим решением.

• При сохранении данных состояния сеанса данных на другом компьютере. В некоторых веб-приложениях с высокой степенью масштабируемости состояние сеанса сохраняется за пределами процесса (обычно в базе данных SQL Server) или на отдельном компьютере. Из-за этого среда ASP.NET должна передавать информацию сеанса туда и обратно через сетевое соединение. Очевидно, что при таком проектном решении показатели производительности будут значительно ниже, чем при сохранении состояния сеанса на компьютере веб-сервера. Однако для некоторых веб-приложений, с высоким трафиком и большими потребностями в плане сохранения данных состояния сеанса это решение все равно может быть лучшим компромиссом.

В первом случае сжатие позволяет жертвовать ресурсами ЦП во имя экономии памяти веб-сервера, а во втором — ради сокращения нагрузки на сетевое соединение. Степень сжатия существенно варьируется в зависимости от типа данных, но во время тестирования клиентам Microsoft удавалось достигать сокращения размеров данных на 30-60% , что гарантирует значительный выигрыш в производительности.

Cookieless

Параметр Cookieless может быть установлен в любое из значений перечисления HttpCookieMode. С помощью атрибута cookieName можно указать имя, используемое для cookie-набора. Если оно не указано, для имени cookie-набора принимается значение по умолчанию, которое выглядит как ASP.NET_SessionId.

Ниже приведен пример принудительного применения режима без поддержки cookie-наборов (что удобно для целей тестирования):

<sessionState cookieless="UseUri" ... />

В режиме без поддержки cookie-наборов идентификатор сеанса будет автоматически вставляться в URL-адрес. Получив запрос, ASP.NET будет удалять идентификатор, извлекать коллекцию сеанса и направлять запрос в соответствующий каталог. Измененный URL-адрес показан ниже:

http://localhost:2549/(S(4j3z52ayktdsfzy0exy41hl5))/Page1.aspx

Поскольку идентификатор сеанса вставляется в текущий URL-адрес, все относительные ссылки также автоматически получают этот идентификатор сеанса. Другими словами, если пользователь на текущий момент находится на странице Page1.aspx и щелкает на относительной ссылке, указывающей на страницу Page2.aspx, эта относительная ссылка будет включать текущий идентификатор сеанса как часть URL-адреса. То же самое произойдет и если вызвать метод Response.Redirect() с относительным URL-адресом.

Единственное реальное ограничение режима без поддержки cookie-наборов состоит в том, что с ним нельзя применять абсолютные ссылки, потому что они не будут содержать идентификатора сеанса. Например, выполнение следующего оператора приведет к утрате пользователем всей информации о сеансе:

Response.Redirect("http://localhost/WebApplication/Page2.aspx");

По умолчанию ASP.NET допускает повторное использование идентификатора сеанса. Например, если делается запрос и строка запроса содержит просроченный сеанс, ASP.NET создает новый сеанс и использует этот же идентификатор сеанса. Проблема в том, что идентификатор сеанса может случайно появиться в каком-то публичном месте, например, на странице результатов в поисковой службе. Это может привести к тому, что множество пользователей получат доступ к серверу с одним и тем же идентификатором сеанса и затем присоединятся к одному и тому же сеансу с теми же самыми разделяемыми данными.

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

Единственный недостаток такого подхода состоит в том, что он подразумевает утерю всех данных состояния представления и формы на текущей странице, т.к. для обеспечения нового идентификатора сеанса ASP.NET выполняет переадресацию браузера.

Чтобы выяснить, используется ли в текущий момент сеанс без cookie-наборов, необходимо проверить свойство IsCookieless объекта Session.

Timeout

Еще одним важным параметром настройки состояния сеанса в файле web.config является Timeout. Он указывает количество минут, в течение которых ASP.NET будет находиться в режиме ожидания (не получая запрос), прежде чем завершит сеанс:

<sessionState timeout="20" ... />

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

Значение параметра Timeout можно также изменять в коде. Например, если известно, что сеанс содержит чрезвычайно большое количество информации, время хранения сеанса лучше ограничить. Для этого можно отобразить пользователю соответствующее предупредительное сообщение и затем просто изменить значение свойства Timeout. Следующая строка кода ограничивает время тайм-аута до 10 минут:

Session.Timeout = 10;

Обеспечение безопасности состояния сеанса

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

Существует несколько подходов, позволяющих обойти эту проблему. Наиболее распространенный из них — воспользоваться специальным модулем сеанса, выполняющим проверку на наличие изменений в IP-адресе клиента. Однако единственным действительно безопасным подходом является разрешение доступа к cookie-наборам сеанса только из тех разделов веб-сайта, где используется SSL-шифрование. В таком случае cookie-набор сеанса шифруется и, следовательно, становится бесполезным на других компьютерах.

Если решено воспользоваться этим подходом, также имеет смысл пометить cookie-набор как безопасный, чтобы он пересылался только через SSL-соединения. Это не позволит пользователям изменять URL-адрес с https:// на http:// и, следовательно, пересылать cookie-набор без SSL-шифрования. Ниже показан необходимый код:

Request.Cookies["ASP.NET_SessionId"].Secure = true;

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

При использовании сеансов без cookie-наборов существует еще одна потенциальная угроза нарушения системы безопасности. Даже если идентификатор сеанса зашифрован, применив прием социальной инженерии, сообразительный пользователь может вынудить другого пользователя подключиться к определенному сеансу. Все, что злоумышленнику понадобится — это подсунуть другому пользователю URL-адрес с действительным идентификатором сеанса. Щелкнув на ссылке, этот пользователь сразу же подключится к такому сеансу. Хотя с этого момента идентификатор сеанса будет защищаться, атакующему уже известно, какой идентификатор сеанса используется, поэтому он сможет позже взломать этот сеанс.

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