Состояние веб-аутентификации - Сессия против Cookie?

Каков наилучший способ проверки подлинности и отслеживания состояния проверки подлинности пользователя от страницы к странице? Кто-то говорит состояние сеанса, кто-то - куки?

Могу ли я просто использовать переменную сеанса, которая имеет идентификатор пользователя, и после аутентификации установить пользовательский класс пользователя, который имеет информацию о пользователе. Затем на каждой странице проверьте, что переменная сеанса все еще активна, и получите доступ к основным данным пользователя из объекта User?

Какие-нибудь мысли? Есть хорошие примеры?

Вы смотрели на использование встроенной проверки подлинности форм aspnet? Он использует куки-файлы, но достаточно надежен в плане безопасности и облегчит большую работу.
Chris Van Opstal 10.12.2008 16:06:55
Это хорошо, но мне нужно проверить еще несколько фактов о пользователе из базы данных. Это может сделать это?
Bill 10.12.2008 22:14:58
да, вы можете хранить все что угодно в данных профиля пользователя. если вы не знаете, как создать свою собственную пользовательскую систему, я буду делать это только в том случае, если последствия для безопасности будут низкими
Shawn 10.03.2009 15:43:56
5 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

16
22.01.2009 14:44:12
это неправильно, потому что куки могут быть украдены, а сессия может быть украдена (поскольку это часто реализуется как абстракция над обычными куки)
lubos hasko 22.01.2009 11:04:21
Это не имеет смысла, потому что вы захватываете сеанс, украдя куки. Так что это одна и та же проблема, несмотря ни на что.
Todd Berman 10.11.2011 07:17:41
Я просто где-то читаю, что вы можете использовать комбинацию обоих.
fuddin 15.01.2013 18:04:36
Ни один человек не может украсть сеанс или его данные, поскольку они хранятся на сервере. Вы можете угнать это.
ColacX 6.10.2015 12:10:50

Я не знаю, ЛУЧШИЙ ли это способ сделать это, но нас устраивает то, как мы это делаем.

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

В некоторых приложениях мы объединяем это с использованием файлов cookie, чтобы непрерывно продлевать сеанс.

1
10.12.2008 16:06:07

Проблема с предпочтением сеансов перед файлами cookie для «безопасности» заключается в том, что сеансы ИСПОЛЬЗУЮ файлы cookie для идентификации пользователя, поэтому любая проблема с файлами cookie присутствует в сеансах.

При использовании Sessions следует помнить о локальности данных. Если вы планируете масштабировать до нескольких веб-серверов в любой момент, вы должны быть очень осторожны при хранении больших объемов данных в объектах сеанса.

Поскольку вы используете .NET, вам, в основном, придется написать свой собственный поставщик хранилища сеансов, чтобы справиться с этим, поскольку InProc не будет масштабироваться выше 1 сервера, поставщик БД - просто плохая идея (весь смысл в том, чтобы ИЗБЕГАТЬ чтения БД здесь при масштабировании, а не добавлять больше), и StateServer имеет много проблем с пропускной способностью. (В прошлом я использовал поставщика хранилища сессий memcached с некоторым успехом для борьбы с этой проблемой).

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

25
10.12.2008 16:17:37
Вы можете проводить сессии без файлов cookie на любой платформе. .NET предлагает это тоже самое.
Esteban Araya 10.07.2010 14:21:04
Как AppFabric распределенный кеш для хранения сессий?
Greg Bacchus 3.11.2011 02:27:29
@esteban Сессии без cookie помещают идентификатор сессии в URL. Я оставляю на ваше усмотрение, является ли это более / менее / столь же небезопасным, как использование cookie.
msgmash.com 9.03.2012 10:15:06

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

0
11.12.2008 01:06:04

Сеансы печенья ...

-3
10.03.2009 15:43:02