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. А у них он живет на сервере полчаса и поэтому его можно использовать в течение этого промежутка времени из любого другого окна.

Сабина

[Sabina]

Вот еще картинки загадочные..
http://www.cs.nyu.edu/artg/research/ibm/ibm_slides/sld018.htm

Это они о чем интересно в "Session Key reused"?

Cабина

[Sabina]

Вот еще картинки загадочные..
http://www.cs.nyu.edu/artg/research/ibm/ibm_slides/sld019.htm

Это они о чем интересно в "Session Key reused"?

Cабина

[A. Fig Lee]

Sabina,
Вы путаете 2 разные session - SSL session нигде не светится и для юзера прозрачна.
HTTP Session, которую обычно хранят или в куки или в хидден вариаблес или в УРЛ - не имеет к ней отножения.

HTTP session - ага, можно скопировать, если не куки в другой компьютер - да собственно и куки можно.

[Слiн]

Может им надо сразу дезактивировать этот session key если окно закрылось, не важно с или без log out.

Еще бы был способ "им" разузнать, что бравузерное окошко закрылось, то наступил бы всеобщий коммунизьм

[Sabina]

Еще бы был способ "им" разузнать, что бравузерное окошко закрылось, то наступил бы всеобщий коммунизьм

То есть окончательный ответ "Это именно так, потому что так должно быть" ?

Сабина

[IA72]

Я все-таки еще раз повторю, для ясности.
Тот session key, который вы видите в браузере, к шифрованию не имеет отношения. Ключ для шифрования генерируется внутрях сервера, более того, https вообще ничем от http не отличается, так как все шифрование делается на уровне ssl (а поверх него идет обычный http)
А служит этот ключик для сохранения http сессии (не ssl), то бишь для того же, для чего часто используются куки. Что касается вообще не хранить сессию, то это часто невозможно - при хардверной кластеризации к примеру (когда все идет на свитч с hardware encryption, который раскидывает дальше по серверам в зависимости от загрузки) вообще тогда работать не будет, ибо никто не гарантирует что при каждом обращении браузера ему дадут один и тот же сервер.

[Слiн]

То есть окончательный ответ "Это именно так, потому что так должно быть" ?

Видимо, да.

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

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

[yocto]

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

Всё-таки, насколько я понял, вся путаница из-за названия. Если бы эта переменная называлась sessionId, то никаких вопросов бы не возникло, так?
Как мне кажетсся, та часть Web-application, которая отвечает за сохранение HTTP сессии (для stateless протокола, кстати) генерирует этот ключ, чтобы все прочие запросы от данного authenticated клиента считались принадлежащими ему же без повторной authentication.

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

[Strannik223]

В данном случае https используется только для шифрования пароля который клиент отдает серверу в процессе логина. На этом секурити заканчивается
Сервер отдает клиенту sessionID, что бы потом идентифицировать его при всех последующих запросах.
В большинстве случаем обходяться этим
Если надо шифровать трафик, то прийдеться из https не вылазить вообще, что даже при умеренных нагрузках вынуждает ставить dedicated https device

[Sabina]

Сервер отдает клиенту sessionID, что бы потом идентифицировать его при всех последующих запросах.

То есть этот session key - он и есть session ID по идее? Или по крайней мере нечто ему эквивалентное...

Я правильно поняла, что вы тоже согласны с тем, что это нормально? Имеется в виду это нормально, что УРЛ с этим session key можно скопировать в другое окно и сервер беспрепятственно позволит продолжать там свою сессию ..

Сабина