Під час роботи з автентифікацією ASP.Net Forms я натрапив на файл cookie .ASPXAUTH. У мене є кілька запитань:
- Яке призначення цього файлу cookie?
- У якому місці знаходиться цей файл cookie?
що таке файли cookie ASPXAUTH?
Відповіді:
Файл cookie ASPXAUTH використовується для визначення автентифікації користувача.
Що стосується розташування файлів cookie, це залежить від вашого браузера. Якщо ви використовуєте Firefox, ви можете переглянути файл cookie, натиснувши Інструменти -> Параметри -> Конфіденційність. Потім прокрутіть вниз до домену та розгорніть його, щоб побачити файл cookie та його значення. Значення зашифровано за допомогою ключа машини (розташований у файлі machine.config або web.config сервера), тому перегляд файлу cookie на клієнті насправді не надасть вам ніякої інформації. Ви можете розшифрувати / переглянути значення на стороні сервера, використовуючи:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
де authTicketє ці поля:
Твердження "ASPXAUTH в основному використовується для підтримки стану сеансу ASP.NET" є неправильним. ASP.NET видає зовсім інший файл cookie, який називається ASP.NET_SessionId, для відстеження стану сеансу.
2
У Firefox v8.0 файли cookie можна знайти наступним чином: Інструменти -> Інформація про сторінку -> Безпека -> Переглянути файли cookie
—
Ентоні
На тій самій вкладці безпеки є кнопка "Перегляд збережених паролів", і на мій подив, я зміг побачити всі паролі як звичайний текст для різних веб-сайтів, які я переглядав за допомогою firefox. Хоча браузер повинен зберігати його у закодованому форматі на диску, і він просто відображається для довідки, декодуючи його, але ця опція насправді є загрозою безпеці, наскільки я можу подумати. Якщо будь-який хакер може використовувати той самий алгоритм і читати ці файли cookie за допомогою JavaScript, хоча витік цього алгоритму є віддаленою можливістю, оскільки він може включати також якийсь ключ, який відомий лише коду браузера.
—
RBT
Щоб отримати ім'я ключа, що використовується для зберігання ідентифікатора сесії asp.net у колекції файлів cookie запиту http, ось код C #: var aspNetSessionState = new System.Web.Configuration.SessionStateSection (); var aspNetSessionCookieName = aspNetSessionState.CookieName;
—
RBT
В
—
Кікенет,
Application_PostAuthenticateRequestна Request.IsAuthenticated вірно , але .ASPXAUTH НЕ значення в моїй HttpContext.Current.Request.Cookies. Я використовую sessionState.
Я створив проект MVC, запустіть його. Зареєструйте обліковий запис, а потім увійдіть. І огляньте файли cookie в інструменті chrome dev, там був Aspnet.ApplicationCookie. А потім додав один рядок у дії входу: FormsAuthentication.SetAuthCookie (model.Email, true); і знову ввійти та перевірити файли cookie в chrome dev tool цього разу, очевидно, це був ASPXAuth. То яка різниця в обох?
Фактично файл cookie .ASPXAUTH не точно повідомляє, коли користувач справді автентифікується. Коли користувач виходить із програми, файл cookie .ASPXAUTH видаляється з браузера. Однак, якщо ви повернетесь на сайт протягом короткого проміжку часу (із тимчасовим обмеженням cookie-файлу для автентифікації форми), та відредагуйте нові файли cookie ASP.NET_SessionId такими:
- змінити поле "ім'я" з "ASP.NET_SessionId" на ".ASPXAUTH"
- змінити "значення" з 24 char sessionID на старий рядок аутентифікації 448 char
Після оновлення ви зможете припустити особу автентифікованого користувача без повторної технічної повторної автентифікації. (знову припускаючи, що ви робите це протягом зазначеного тайм-ауту, що зберігається в зашифрованому рядку автентифікації .ASPXAUTH)
Хороший допис у блозі пояснює проблему більш докладно. Можливим рішенням є поєднання .ASPXAUTH із сеансом ASP.
Якщо взаємодія користувача з URL-адресою входу в HTML дозволила TSWPPserver встановити ідентифікацію користувача, віддалений сервер ПОВИНЕН сформувати файл cookie, який ідентифікує користувача та дозволяє автентифікацію сервера. Вміст файлу cookie ПОВИНЕН бути підписаним та зашифрованим. Конкретна реалізація цього файлу cookie, включаючи алгоритми підписання та шифрування, залежить від реалізації сервера TSWPP, оскільки для аналізу вмісту файлу cookie потрібен лише сервер. Якщо сервер реалізує файл cookie, тоді файл cookie ПОВИНЕН бути повернутий в корисному навантаженні HTTP із типом вмісту "application / x-msts-webfeed-login".