Насколько безопасен Ticket.UserData в User.Identity в asp.net - PullRequest
Новая
       9

Насколько безопасен Ticket.UserData в User.Identity в asp.net

4 голосов
/ 19 февраля 2009

Мой веб-сайт использует аутентификацию форм ASP.NET, и я вставляю информацию, специфичную для пользователя, в часть UserData билета / cookie аутентификации. Так как UserData находится внутри билета аутентификации, он зашифрован так, что 

authCookie.Value = FormsAuthentication.Encrypt(newTicket);

Теперь я не слишком беспокоюсь о том, что данные будут скомпрометированы в данный момент, поскольку они зашифрованы. но я заметил, что данные доступны в незашифрованном виде, как это 

FormsIdentity fid = User.Identity as FormsIdentity;
string plainTextUserData = fid.Ticket.UserData;

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

Стоит ли мне беспокоиться об этом?

Редактировать 1:

Причина, по которой я хочу это сделать, заключается в том, что я могу прекратить использовать сеансы и просто использовать файлы cookie и Ticket.UserData

Редактировать 2:

Данные в Ticket.UserData не меняются. постоянный после входа пользователя в систему.

Ответы [ 3 ]

5 голосов
/ 19 февраля 2009

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

@ jorsh1, основываясь на вашей рекомендации @Portman, Ticket.UserData не место для хранения изменяющихся данных. Вы не хотите заново создавать билет аутентификации при переходе с одной страницы на другую.

Либо используйте данные сеанса с службой сеансов или Sql Server . Если вы не хотите, чтобы данные в сеансе были небольшими и не чувствительными, используйте cookie. (*)

Канонический пример MS с UserData - хранить такие вещи, как список ролей, чтобы вы могли сказать что-то вроде «Думаю ли я, что этот пользователь - администратор», но если это что-то вроде роли администратора, вы, вероятно, нажмете базы данных, чтобы проверить, прежде чем вы неявно доверяете тому, что находится в куки.

string plainTextUserData = fid.Ticket.UserData;

Это работает внутри вашего приложения только потому, что Asp.Net уже расшифровал билет для вас. Однако, если вы хотите установить данные IIRC, вам необходимо заново создать и снова подключить cookie проверки подлинности форм. 

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
    currentTicket.Version + 1,
    currentUser.UserName,
    now,
    now.Add(formsAuthentication.Timeout),
    false,
    "new user data string",
    FormsAuthentication.FormsCookiePath);

string hash = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new HttpCookie(
    FormsAuthentication.FormsCookieName,
    hash);

Response.Cookies.Add(cookie);

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

* Я не сторонник хранения вещей в сессии. Обычно есть другой способ сохранить эти данные.

[править] Для чего я использую сессию:

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

Таким образом, мы не выставляем в cookie ничего деликатного и не полагаемся на сеанс. Мы также установили агрессивное восстановление сессий. В сочетании с небольшим объемом данных, хранящихся в сеансе, сеансы не доставляют нам проблем, и, поскольку только 1 фрагмент кода знает, что находится в сеансе, мы можем легко его реорганизовать.

Для чего-либо еще сессии являются злом. Я предпочитаю поддерживать viewstate на странице, которая нуждается в этом, или просто сохранять временное состояние в базе данных.

2 голосов
/ 19 февраля 2009

Это так же безопасно, как билет аутентификации. Поскольку вы используете его для той же цели, не беспокойтесь об этом.

1 голос
/ 19 февраля 2009

Вы вероятно не нужно беспокоиться.

Если данные являются конфиденциальными (например, номер социального страхования в США), вам, вероятно, следует избегать отправки их с билетом FormsAuth, даже если он зашифрован, потому что злодеи всегда вызывают новые атаки.

Однако я должен спросить: вы уже можете хранить идентификатор для каждого тикета (имя пользователя), так почему бы вам не сохранить все остальные данные в базе данных?

...