https - showing session key in URL?

[Sabina]

Есть приложение на сервлетах.
Также есть логин через https и после успешного окончания SSL транзакции, пользователь видит в URL-ах свой session key=xxxxxxxxxx

Если он скопирует URL и закроет окно, и потом откроет новое с этим самым URL, его пускают обратно в его сессию, то есть безо всяких паролей и проч.
Типа session key живет полчаса с момента выдачи.

Может я ошибаюсь, но мне кажется это не безопасно аттачить session key в УРЛу. Хотя всей механики https не знаю, может оно и ничего.

Скажите если ли какие-то веские причины по которым эти session key в https сессии присобачивают к УРЛу, а не хранят как session value, например?

Спасибо,
Сабина

[Sabina]

сорри дубль получился

[A. Fig Lee]

Есть приложение на сервлетах.
Также есть логин через https и после успешного окончания SSL транзакции, пользователь видит в URL-ах свой session key=xxxxxxxxxx

Если он скопирует URL и закроет окно, и потом откроет новое с этим самым URL, его пускают обратно в его сессию, то есть безо всяких паролей и проч.
Типа session key живет полчаса с момента выдачи.

Может я ошибаюсь, но мне кажется это не безопасно аттачить session key в УРЛу. Хотя всей механики https не знаю, может оно и ничего.

Скажите если ли какие-то веские причины по которым эти session key в https сессии присобачивают к УРЛу, а не хранят как session value, например?

Спасибо,
Сабина

Насколько я знаю/помню - стандартный паттерн во всяких апликейшн серверах -
сессион кey стараются хранить в куки, онако не у всех оно енейблед. Поетому сразу после создания сессии - когда она нью, сессия записывается в куки и в PATH_INFO. Здесь вы ее можете видеть - если посмотрите пропертис линков.
Следующий раз если на сервер придет сессия из куков, он забывает про PATH_INFO и пользуется только куками. Иначе - все время PATH_INFO и Вы будете видеть сессию в УРЛ. И здесь ноу вей ту превент копи УРЛа на другой компьютер анлес сам сервер еще и IP чекает - в реальной жизни - никто как правило IP не чакает. Если вопрос был почему сессия не в PATH_INFO, а в обычных параметрах строки - так тож делают, принципиальной разницы с PATH_INFO нет, только PATH_INFO легче хедлить.

[Sabina]

Насколько я знаю/помню - стандартный паттерн во всяких апликейшн серверах -
сессион кey стараются хранить в куки, онако не у всех оно енейблед. Поетому сразу после создания сессии - когда она нью, сессия записывается в куки и в PATH_INFO. Здесь вы ее можете видеть - если посмотрите пропертис линков.

Про session ID я согласна, что encodeURL ее к УРЛу аттачит, если cookie disabled. А вот зачем session key показывать? Можно же их хранить в session value...
Хотя опять-таки может в https свои методы, может там только session key является идентификатором сессии?

А если и есть возможность не показывать session key, то кто знает, может сервер его восстанавливает по session ID из УРЛа и опять пускает...

Со вчерашнего дня пытаюсь найти что-нибудь толковое по https но нигде именно этот момента не описывается. И главное хоть бы исходники этих страниц были....

Сабина

[Dedal]

Насколько я знаю/помню - стандартный паттерн во всяких апликейшн серверах -
сессион кey стараются хранить в куки, онако не у всех оно енейблед. Поетому сразу после создания сессии - когда она нью, сессия записывается в куки и в PATH_INFO. Здесь вы ее можете видеть - если посмотрите пропертис линков.

Про session ID я согласна, что encodeURL ее к УРЛу аттачит, если cookie disabled. А вот зачем session key показывать? Можно же их хранить в session value...
Хотя опять-таки может в https свои методы, может там только session key является идентификатором сессии?

А если и есть возможность не показывать session key, то кто знает, может сервер его восстанавливает по session ID из УРЛа и опять пускает...

Со вчерашнего дня пытаюсь найти что-нибудь толковое по https но нигде именно этот момента не описывается. И главное хоть бы исходники этих страниц были....

Сабина

Чей-то я не понял. Session Key -- это который симметричный ключ, используемый уже после стадии handshake? Браузер с сервером сами договариваются, генерят уникальный для этого сеанса ключ и им пользуются. Никогда не видел, чтобы он в урле сидел. Это точно именно ключ?

[Sabina]

Чей-то я не понял. Session Key -- это который симметричный ключ, используемый уже после стадии handshake? Браузер с сервером сами договариваются, генерят уникальный для этого сеанса ключ и им пользуются. Никогда не видел, чтобы он в урле сидел. Это точно именно ключ?

Вот именно, он самый (...?session key=xxxxxxx) там в УРЛе и сидит. Очень хочется узнать как его оттуда убрать. В простом сервлете, я бы sessionID показала, а key спрятала в value, а этот https кто его знает?

Сабина

[IA72]

Чей-то я не понял. Session Key -- это который симметричный ключ, используемый уже после стадии handshake? Браузер с сервером сами договариваются, генерят уникальный для этого сеанса ключ и им пользуются. Никогда не видел, чтобы он в урле сидел. Это точно именно ключ?

Вот именно, он самый (...?session key=xxxxxxx) там в УРЛе и сидит. Очень хочется узнать как его оттуда убрать. В простом сервлете, я бы sessionID показала, а key спрятала в value, а этот https кто его знает?

Сабина

Тот session key, который иногда пишут в url не имеет никакого отношения к шифровальным ключам. Просто уникальный номер сессии для ее сохранения на сервере какое-то время.

[PavelM]

Может я ошибаюсь, но мне кажется это не безопасно аттачить session key в УРЛу. Хотя всей механики https не знаю, может оно и ничего.

Поясните, пожалуйста, что именно небезопасно и в каком случае?
https ни чем не отличается в данном случае от http.

[yocto]

Я так понимаю, что session key в данном случае - просто какой-то уникальный (для данной сессии) идентификатор. Собственно, к протоколу https он, видимо, никакого отношения не имеет, поскольку генерируется приложением.
Проверить это можно просто переключившись с https на http, если есть такая возможность.
Видимо, смущает двусмысленность самого названия session key?

[Sabina]

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

Is it how it is suppose to work?

Cабина

[faw]

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

[faw]

PS - и это не зависит от того http или https

[yocto]

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

Это как раз говорит о том, что этот ключ был выдан самим приложением.
Потому как новое окно будет означать новый физический канал и новый encryption key. Стало быть, простое копирование ничего не даст. Если же работает, значит само приложение нормально принимает старый session key для другой (физически) сессии. Непорядок.

И вообще, я не очень уверен, что сам ключ шифрования, который выбирается на стадии https handshake, доступен приложению для манипуляции. По идее, он должен быть скрыт в недрах уровня tls.

[Sabina]

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

Спасибо за предложение проверить,
Сабина

[Sabina]

И вообще, я не очень уверен, что сам ключ шифрования, который выбирается на стадии https handshake, доступен приложению для манипуляции. По идее, он должен быть скрыт в недрах уровня tls.

Вот отсюда следует, что session key имеет смысл в связке с подписью и private key:

SA secure SSL session begins when a web browser submits a request for a secured web page. When this occurs the web server responds by sending the appropriate certificate/public key. After checking the signature on the certificate, the web browser generates a session key. The session key is encrypted using the public key and is sent back to the web server. The server uses the corresponding private key to decrypt the session key. Since the server and the browser both have the same session key, all information transferred between the web site and web browser is secured with the session key.

Тогда вопрос, а что же в том приложении сделано не так? Может им надо сразу дезактивировать этот session key если окно закрылось, не важно с или без log out. А у них он живет на сервере полчаса и поэтому его можно использовать в течение этого промежутка времени из любого другого окна.

Сабина