https - showing session key in URL?

Sabina · Post by **Sabina** » 02 Feb 2004 19:24

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

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

Cабина

Sabina · Post by **Sabina** » 02 Feb 2004 19:24

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

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

Cабина

A. Fig Lee · Post by **A. Fig Lee** » 02 Feb 2004 19:40

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

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

Слiн · Post by **Слiн** » 02 Feb 2004 19:54

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

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

Sabina · Post by **Sabina** » 02 Feb 2004 20:08

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

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

Сабина

IA72 · Post by **IA72** » 02 Feb 2004 20:15

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

Слiн · Post by **Слiн** » 02 Feb 2004 20:24

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

Видимо, да.

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

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

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

yocto · Post by **yocto** » 02 Feb 2004 20:35

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

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

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

Strannik223 · Post by **Strannik223** » 05 Feb 2004 05:45

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

Sabina · Post by **Sabina** » 05 Feb 2004 05:55

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

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

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

Сабина

Strannik223 · Post by **Strannik223** » 05 Feb 2004 06:39

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

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

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

Сабина

Да, я думаю просто неудачное название переменной сбивающее с толку

Да, а в чем проблема-то? Security? Но украсть сессию проще подслушав трафик, чем украсть n-циферный id из урл. Тем более что но по времени ограничен
Хотя его действительно, чаще в куку засовывают