в чем уязвимость наличия Jsessionid только по первому запросу

Недавно мы удалили jsessionid из URL-адреса, чтобы управлять сеансом на основе файлов cookie, чтобы предотвратить «атаку захвата сеанса».

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

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

Вопрос: есть ли какая-либо уязвимость в системе безопасности, открывающая jsessionid только при первом запросе?

Существует решение для удаления jsessionid из первого запроса, но я хотел проверить, действительно ли он уязвим для внесения изменений.

спасибо J

РЕДАКТИРОВАТЬ: я прояснил свои сомнения. Спасибо за ответы.


security jsessionid
person Jenga Blocks    schedule 18.01.2011    source источник

Ответы (3)


arrow_upward
9
arrow_downward

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

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

В идеале вы должны удалить JSESSIONID из URL-адреса во всех местах и ​​использовать только хранилище файлов cookie.

Кроме того, если вы хотите смягчить перехват сеанса, необходимо рассмотреть ряд других областей.

Вам необходимо использовать SSL на всех страницах, где передается идентификатор сеанса (это необходимо для снижения риска перехвата идентификатора сеанса при передаче (например, атаки Firesheep).

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

Кроме того, если возможно, файлы cookie сеанса должны использовать флаги httpOnly и secure, чтобы снизить риск их утечки по каналам с открытым текстом.

На сайте OWASP есть полезная дополнительная информация.

Кстати, если у вас есть дополнительные вопросы по безопасности, есть специальный сайт обмена стеками по адресу Security.stackexchange.com.

person Rory McCune    schedule 18.01.2011
comment
Да, мы улучшали общую безопасность, и спасибо за дополнительную информацию. - person Jenga Blocks; 19.01.2011

arrow_upward
2
arrow_downward

управление сеансом на основе файлов cookie для предотвращения «атаки захвата сеанса»

Что мешает краже файла cookie?

Управление сеансом — это работа на стороне сервера. Вам нужно, чтобы сервер проверил (на основе файла cookie), что пользователь должен войти в систему.

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

person m.edmondson    schedule 18.01.2011
comment
Я согласен, что куки можно украсть. Наше требование состояло в том, чтобы не раскрывать jsessionid по URL-адресу, это может быть не на 100% безопасно. Но наличие jsessionid у нашего первого URL-адреса запроса имеет какой-либо вредный эффект? Просьба уточнить - person Jenga Blocks; 18.01.2011
comment
Это не более вредно, чем использование файлов cookie — я бы серьезно усомнился в этих требованиях. - person m.edmondson; 18.01.2011
comment
Да, одинаково уязвимы. но мы обратимся к перехвату сеанса в следующем выпуске. повышение общей безопасности было нашей целью на данный момент. Хотя мой первоначальный пост немного вводил в заблуждение - person Jenga Blocks; 19.01.2011
comment
Нет, они не одинаково уязвимы. Наличие идентификатора сеанса в URL-адресе может быть проблемой, даже если сайт использует SSL. Злоумышленник может создать URL-адрес с предопределенным идентификатором сеанса и обмануть пользователя (путем сокращения URL-адреса в Твиттере и т. д.), чтобы он посетил этот URL-адрес. Теперь жертва получает сеанс, где идентификатор сеанса известен злоумышленнику. Также URL-адреса отслеживаются в истории браузера, прокси и т. д. Файлы cookie — нет. - person Erlend; 04.07.2011
comment
Но файлы cookie хранятся в браузере... на самом деле SSL также шифрует URL-адрес, поэтому я Я не уверен, что ваша точка зрения верна. Было бы удивительно, если бы приложение предоставило сеанс с любым идентификатором, предоставленным пользователем - обычно он генерируется сервером. - person m.edmondson; 04.07.2011
comment
@Erlend описывает фиксацию сеанса. Если ваше приложение принимает JSESSIONID в URL-адресе, и вы не выполняете никаких дополнительных проверок (например, проверки ip), то вы уязвимы. Спецификация Servlet 3.0 имеет ‹tracking-mode›COOKIE‹/tracking-mode›, чтобы убедиться, что JSESSIONID используется только как файл cookie. Спецификация даже рекомендует не разрешать использование JSESSIONID в URL-адресе. - person Patrick; 19.07.2011

arrow_upward
0
arrow_downward

Если кто-то завладеет идентификатором сеанса, то он в значительной степени захватит весь сеанс, см. Уязвимость >Предсказуемые идентификаторы сеансов.

person ismail    schedule 18.01.2011
comment
Вы имеете в виду, что наличие jsessionid в URL-адресе первого запроса по-прежнему делает приложение уязвимым? - person Jenga Blocks; 18.01.2011
comment
Судя по статье, да. - person ismail; 18.01.2011
comment
Спасибо . На самом деле я попробовал многопользовательский сценарий, в котором я вытащил jsessionid из URL-адреса первого запроса, и данные сеанса были доступны для нескольких пользователей с одним и тем же jsessionid. спасибо J - person Jenga Blocks; 19.01.2011