In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
что значит decrypt cookies, я грешным делом думал, что
C> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>что значит decrypt cookies, я грешным делом думал, что C>
C>> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>>что значит decrypt cookies, я грешным делом думал, что C>>
C>>просто индефикатор, а тут получается зашифрованы пользовательские данные?
S>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
плохо,зачем было вообще это тащить на клиент?
P.S. интересно, а обратное действие тоже возможно (по имени пользователя на основе имеющийся cookie сгенерировать новый .ASPXAUTH)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[3]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, sunshine, Вы писали:
S>>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
C>плохо,зачем было вообще это тащить на клиент?
Непонятно — как иначе сделать авторизацию, если честно.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[4]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Непонятно — как иначе сделать авторизацию, если честно. C>просто хранить session_id
ID сессии хранится в другой куке.
[quote]The value is encrypted using the machine key (located in the server's machine.config or web.config file) so looking at the cookie on the client won't really provide you any information.[/quote]
Прошёл по твоей ссылке, товарищ ничего не написал — ни как взломали, ни что достали.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[6]: Cookies from ASP.NET servers can be cracked
Здравствуйте, Aen Sidhe, Вы писали:
AS>Прошёл по твоей ссылке, товарищ ничего не написал — ни как взломали, ни что достали.
согласен, но от этого не легче,
оказывается в asp.net 3.5sp1 / asp.net 4 есть возможность просмотреть web.config (пусть и зашифрованный), я так понял это как-то связано с роутингом. сообщение от scottgu взлом dnn
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[5]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Непонятно — как иначе сделать авторизацию, если честно. C>просто хранить session_id
Накладные расходы в режиме фермы представляешь?
Re[6]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Непонятно — как иначе сделать авторизацию, если честно. C>>просто хранить session_id
G>Накладные расходы в режиме фермы представляешь?
хранение одного ключа?
Re[7]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>просто хранить session_id
G>>Накладные расходы в режиме фермы представляешь? C>хранение одного ключа?
Синхронизация этого ключа.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[7]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>просто хранить session_id
G>>Накладные расходы в режиме фермы представляешь? C>хранение одного ключа?
Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.
В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server.
В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети.
Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии.
inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием).
Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия.
C> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>что значит decrypt cookies, я грешным делом думал, что C>
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, cadet354, Вы писали:
C>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>просто хранить session_id
G>>>Накладные расходы в режиме фермы представляешь? C>>хранение одного ключа?
AS>Синхронизация этого ключа.
в смысле синхронизация?
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
G>>>>Накладные расходы в режиме фермы представляешь? C>>>хранение одного ключа?
AS>>Синхронизация этого ключа. C>в смысле синхронизация?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, cadet354, Вы писали:
C>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>просто хранить session_id
G>>>Накладные расходы в режиме фермы представляешь? C>>хранение одного ключа?
G>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей. G>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
все хорошо в теории, только вот на практике оказалось хреново (причем как я понял таже проблема есть и у Оракла и т.д.) G>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети.
рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии.
в любом случае это происходит если ссесия храниться не в инпрок. G>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия.
для обычной куки можно делать аналогично.
на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе, получили потенциальную дыру в безопасности, которая сейчас получила реальное воплощение. (причем до фермы в 10 компов дай бог 1% приложений доходят, стаковерфлоу и до этого пока не дошел).
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, cadet354, Вы писали:
C>>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>>просто хранить session_id
G>>>>Накладные расходы в режиме фермы представляешь? C>>>хранение одного ключа?
G>>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей. G>>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию. C>все хорошо в теории, только вот на практике оказалось хреново (причем как я понял таже проблема есть и у Оракла и т.д.)
Что ты имеешь ввиду?
G>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска
А причем тут чтение с диска?
G>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>в любом случае это происходит если ссесия храниться не в инпрок. G>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>для обычной куки можно делать аналогично.
Какой обычной куки? Причем тут обычная кука?
C>на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе
на какой практике? На моей практике за 3 года ни одного обращения к session
C>получили потенциальную дыру в безопасности
Ну да, а с сессией проблем нету
Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да?
C>стаковерфлоу
Он кстати использует куки, а не сессию.
Re[10]: Cookies from ASP.NET servers can be cracked
G>Что ты имеешь ввиду?
Oracle Application Server http://www.pentestit.com/2010/06/08/poet-padding-oracle-exploit-tool/
G>>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>А причем тут чтение с диска?
сравнение скорости, что это не так много
G>>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>>в любом случае это происходит если ссесия храниться не в инпрок. G>>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>>для обычной куки можно делать аналогично. G>Какой обычной куки? Причем тут обычная кука?
а что ты считаешь авторизационной кукой?
C>>на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе G>на какой практике? На моей практике за 3 года ни одного обращения к session
да, я забыл, практика у всех разная C>>получили потенциальную дыру в безопасности G>Ну да, а с сессией проблем нету G>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да?
зачем? httponly для всех кук работает C>>стаковерфлоу G>Он кстати использует куки, а не сессию.
откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[11]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
G>>>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>>>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>>А причем тут чтение с диска? C>сравнение скорости, что это не так много
Скорости чего? А причем тут чтение с диска?
G>>>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>>>в любом случае это происходит если ссесия храниться не в инпрок. G>>>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>>>для обычной куки можно делать аналогично. G>>Какой обычной куки? Причем тут обычная кука? C>а что ты считаешь авторизационной кукой?
"А почему вы отвечаете вопросом на вопрос?"
Мы сейчас говорим об аутентификации, а не о куках вообще.
C>>>получили потенциальную дыру в безопасности G>>Ну да, а с сессией проблем нету G>>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да? C>зачем? httponly для всех кук работает а причем тут HTTP only?
C>>>стаковерфлоу G>>Он кстати использует куки, а не сессию. C>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь.
А причем тут пользовательская информация? я про аутентификацию говорю
Re[12]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Скорости чего? А причем тут чтение с диска?
для сравнения, что раундрип до сервера с ссесией это быстро.
C>>>>получили потенциальную дыру в безопасности G>>>Ну да, а с сессией проблем нету G>>>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да? C>>зачем? httponly для всех кук работает G> а причем тут HTTP only?
эт я сморозил, признаю, non-persistent это называется, HTTP only спасает от другого вида атак.
C>>>>стаковерфлоу G>>>Он кстати использует куки, а не сессию. C>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь. G>А причем тут пользовательская информация? я про аутентификацию говорю
еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора)
Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[13]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Скорости чего? А причем тут чтение с диска? C>для сравнения, что раундрип до сервера с ссесией это быстро.
Быстро по сравнению с чем? Откуда ты чтение с диска взял? В аутентификационной куке передается вся необходимая информация, дополнительно никуда обращаться не надо.
C>>>>>стаковерфлоу G>>>>Он кстати использует куки, а не сессию. C>>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь. G>>А причем тут пользовательская информация? я про аутентификацию говорю C>еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора) C>
C>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
C>я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время.
Время расшифровывания не зависит от того какие данные хранятся.
а причем тут HTTP only?