В чем уязвимость наличия Jsessionid только по первому запросу - PullRequest
3 голосов
/ 18 января 2011

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

Но мы обнаружили, что URL первого запроса всегда имеет jsessionid, когда куки включены, а в URL следующего запроса НЕТ jsessionid.1003 *

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

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

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

спасибо J

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

Ответы [ 3 ]

7 голосов
/ 18 января 2011

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

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

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

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

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

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

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

Есть несколько хороших дополнительныхинформация на сайте OWASP

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

2 голосов
/ 18 января 2011

сделал управление сеансами на основе файлов cookie, чтобы предотвратить «атаку перехвата сеанса»

Что мешает украсть печенье?

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

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

0 голосов
/ 18 января 2011

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

...