Помещает данные в безопасные cookie?
Я использую asp.net mvc 2.0, и я задаюсь вопросом, как безопасный это должно поместить информацию в cookie?
Как я вставил свой cookie билет аутентификации форм, который шифруется так, я могу поместить информацию, которая могла быть уязвимой там?
string encryptedTicket = FormsAuthentication.Encrypt(authTicket)
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Как я не храню пароль или что-либо как этот, но я хочу сохранить UserId, потому что в настоящее время каждый раз пользователь выполняет запрос на мой сайт, я должен сделать запрос и получить тот пользовательский Идентификатор пользователя, так как каждая таблица в моем дб требует, чтобы Вы использовали идентификатор пользователя для возвращения правильной строки.
Таким образом, они начинают складывать быстро, таким образом, у меня скорее есть он что, если пользователь аутентифицируется однажды затем вот именно, пока они не должны повторно аутентифицироваться снова. Если я сохранил бы этот идентификатор пользователя, я мог бы сохранить столько запросов к базе данных.
Все же я не хочу это плавающий вокруг в открытом тексте как потенциал, кто-то мог использовать его, чтобы попытаться вытащить строку из базы данных, когда они действительно не должны быть.
Покажите, насколько хороший является это шифрование той Аутентификацией использование?
13 ответов
Наряду с шифрованием файлов cookie следует также реализовать ротационный токен для предотвращения атак повторного воспроизведения.
Идея состоит в том, что зашифрованный файл cookie содержит некоторое значение, которое можно сравнить с известным значением на сервере. Если данные совпадают, то запрос завершается успешно. Если данные не совпадают, вы испытываете атаку повторного воспроизведения и вам необходимо прервать сеанс.
ОБНОВЛЕНИЕ
В одном из комментариев спрашивалось, хочу ли я сохранить значение в cookie. Ответ положительный. ВЕСЬ cookie должен быть зашифрован, что можно сделать автоматически с помощью HttpModule. В зашифрованном файле cookie находится любая ваша обычная информация + изменяющийся токен.
На каждом ответном посте проверьте жетон. Если он действителен, разрешите транзакцию, создайте новый случайный токен, сохраните в файле cookie и отправьте его обратно в браузер. Опять же, в зашифрованном виде.
В результате ваш файл cookie защищен (вы используете 3DES?), И у любого злоумышленника будет чрезвычайно ограниченное окно возможностей даже для попытки повторной атаки. Если жетон не прошел проверку, можно просто поднять тревогу и принять соответствующие меры.
Все, что требуется на стороне сервера, - это отслеживать пользователя и его текущий токен. Обычно это намного меньше, чем необходимость искать такие мелочи, как имя пользователя, при каждой загрузке страницы.
ОБНОВЛЕНИЕ 2
Я пытался понять, лучше это или хуже, чем сохранение изменяющегося значения в сеансе. Я пришел к выводу, что хранение изменяющегося значения в сеансе на веб-сервере абсолютно ничего не делает для предотвращения атак повторного воспроизведения и, следовательно, менее безопасно, чем размещение этого значения в файле cookie.
Рассмотрим этот сценарий. Браузер делает запрос. Сервер смотрит на идентификатор сеанса и извлекает объекты сеанса, затем выполняется работа, и ответ отправляется обратно в браузер. Тем временем BlackHat Bob записал транзакцию.
Боб затем отправляет точно такой же запрос (включая идентификатор сеанса) на сервер. На данный момент у сервера нет абсолютно никакого способа узнать, что это запрос от злоумышленника. Вы не можете использовать IP, поскольку они могут измениться из-за использования прокси, вы не можете использовать отпечатки пальцев браузера, поскольку вся эта информация была бы записана при первоначальном обмене. Кроме того, учитывая, что сеансы обычно продолжаются не менее 30 минут, а иногда и намного дольше, у злоумышленника есть довольно большое окно для работы.
Итак, несмотря ни на что, чтобы предотвратить повторное воспроизведение, вы должны отправлять изменяющийся токен в браузер после каждого запроса.
Теперь остается вопрос о том, следует ли также хранить такие значения, как идентификатор пользователя, в зашифрованном файле cookie или хранить его на стороне сервера в переменной сеанса. С сеансом у вас есть проблемы, такие как более высокая память и использование процессора, а также потенциальные проблемы с балансировкой нагрузки и т. Д. С куки-файлами у вас есть некоторый объем данных, который меньше 4 КБ, и, при правильном выполнении, в диапазоне 1 КБ или меньше, который добавляется на каждый запрос. Я предполагаю, что все будет сводиться к тому, предпочтете ли вы добавить больше / более крупные серверы и внутреннее сетевое оборудование для обработки запросов (сеанс) или заплатить за немного больший интернет-канал (cookie).
Нет. С помощью атаки оракула заполнения было показано, что получение зашифрованных данных (CBC) может быть опасным из-за утечки ошибок.
Я определенно не эксперт в области криптографии, но недавно я видел демонстрацию, в которой зашифрованное состояние представления было расшифровано с помощью этой атаки.
В идеальном мире с идеальным шифром это не было бы проблемой. К сожалению, в реальном мире нет ничего идеального, и идеального шифра никогда не будет. Безопасность - это решение этих угроз реального мира. Криптографические системы всегда уязвимы для атак, будь то тривиальная атака (перебором) или недостаток в самом примитиве. Более того, наиболее вероятно, что вы нарушите реализацию примитива, распространенные ошибки включают неслучайный или нулевой IV, управление ключами и неправильный режим блочного шифра.
Короче говоря, это грубое злоупотребление криптографией. Эту проблему лучше всего решить, избегая ее вместе с использованием переменной сессии. Вот почему существуют сессии, весь смысл в том, чтобы связать браузер с данными состояния, хранящимися на сервере.
edit: Шифрование cookies привело к ASP.NET oracle padding attack. Этого следовало бы избежать, используя криптографический нонсенс. Как я уже сказал, это грубое злоупотребление криптографией.
Как вы уже сказали, хорошей практикой для хранения любых данных в cookies является шифрование данных. Шифровать перед помещением в cookie и расшифровывать после прочтения.
В примере с хранением идентификатора пользователя, выберите что-то, что вряд ли будет использовано против вашей системы. Для идентификатора пользователя используйте guid, а не увеличивающееся целое число, которое является PK в таблице базы данных. Guid будет нелегко изменить, чтобы успешно угадать другого пользователя во время атаки на вашу систему.
Как только пользователь будет идентифицирован или аутентифицирован, перейдите к сохранению объекта пользователя или свойств ключа в Session.
Первое, что нужно решить, - это безопасность используемых соединений. Если это не так, предположим, что cookie или что-либо еще между вами и клиентом будет перехвачено.
Файл cookie может быть помехой, если он находится на клиентской машине. Просмотрите кражу файлов cookie, подделку межсайтовых запросов, проблему сбитого с толку депутата.
Шифрование достаточно хорошее, это не слабое звено.
Слабым звеном является то, что значение cookie может быть перехвачено, и кто-то другой может выдать себя за пользователя.
Итак, информация в куки-файлах достаточно безопасна, но вы не можете защитить сам куки.
Ограничения файлов cookie: размер, возможность отключения и угроза безопасности (вмешательство). Конечно, если вы зашифруете cookie, это может снизить производительность. Session и Viewstate были бы хорошей альтернативой. Если вы хотите, чтобы он хранился на стороне клиента, лучше использовать viewstate. Вы можете зашифровать строку с идентификатором пользователя и сохранить в viewstate. Сеанс был бы лучшим вариантом. Если ваши обращения к базе данных медленные, рассмотрите возможность кеширования
HttpCookie c;
c.Secure = true;
Очевидно, что это работает только при передаче данных через SSL, но этот параметр указывает браузеру не отправлять cookie, если соединение не SSL, тем самым предотвращая перехват с помощью атак "человек посередине". Если вы не используете защищенное соединение, данные в cookie будут полностью видны любому, кто пассивно прослушивает соединение. Это, кстати, не так маловероятно, как можно подумать, учитывая популярность общественного Wi-Fi.
Чтобы обеспечить надлежащую защиту файлов cookie аутентификации, убедитесь, что вы указали безопасную схему шифрования / хеширования (обычно в файле web.config), установив machineKey validation = "SHA1" (я использую SHA1, но при желании вы можете заменить его другим провайдером). Затем убедитесь, что в ваших формах auth установлен атрибут protection = "All" , чтобы файл cookie был как хешированным, так и зашифрованным. Неотказуемость и безопасность данных - все в одном :)
ASP.NET будет обрабатывать шифрование / дешифрование [РЕДАКТИРОВАТЬ: только cookie аутентификации! ] файл cookie для вас, хотя для пользовательских файлов cookie вы можете использовать метод FormsAuthentication.Encrypt (...), поэтому просто убедитесь, что вы не отправляете UserId через другие средства открытого текста, такие как строка запроса.
Использование, которое вы рассматриваете, является точной целью возможности хранения информации в Forms Auth Ticket.
Шифрование значения userid в cookie только предотвращает возможность того, что пользователь узнает, что это за значение. Оно не
- предотвращает воспроизведение cookie (используйте SSL, чтобы предотвращения перехвата злоумышленником куки жертвы)
- предотвращения фальсификации (злоумышленник все еще может вслепую перевернуть биты в закодированном файле cookie с вероятность того, что он расшифрует его до действительного пользователя, используйте HMAC для предотвращения этого)
- полностью предотвратить получение пользователем расшифрованного значения (пользователь может перебором получить значение вне очереди, используйте сильный ключ шифрования, чтобы сделать успех менее вероятным)
Шифрование cookie также создает проблему управления ключами. Например, когда вы меняете ключ шифрования, вы должны убедиться, что "живые" сеансы со старым ключом не будут немедленно завершены. Вы подумали об управлении ключом шифрования, верно? Что произойдет, если администраторы уйдут? Он скомпрометирован? И т. д.
Позволяет ли ваша архитектура (балансировщики нагрузки, распределение серверов, ...) использовать объекты сессий на стороне сервера для отслеживания этой информации? Если нет, привяжите userid к объекту сессии и оставьте "чувствительные" данные на сервере - пользователю нужно иметь только cookie сессии.
Объект сеанса, вероятно, был бы намного проще и безопаснее для решения вашей проблемы.
Для вашего очень конкретного сценария (идентификатор пользователя) краткий ответ: НЕТ !
Чтобы получить длинный ответ, представьте себе этот гипотетический сценарий:
- Вы переходите на stackoverflow.com;
- Заполняете свое имя пользователя / пароль и отправляете форму;
- Сервер отправляет вам файл cookie, содержащий ваш идентификатор пользователя, который будет использоваться для вашей идентификации при следующих запросах;
- Поскольку ваше соединение НЕ было безопасным (HTTPS), злоумышленник обнюхал его и перехватил cookie.
- Плохой парень получает доступ к вашей учетной записи, потому что сервер не сохранил, скажем, ваш IP-адрес, и, таким образом, не может отличить вашу машину от машины плохого парня.
По-прежнему в этом сценарии представьте, что сервер сохранил ваш IP-адрес, но вы находитесь в корпоративной локальной сети, а ваш внешний IP-адрес такой же, как у других 100 машин. Представьте, что кто-то, имеющий доступ к одной из этих машин, скопировал ваш файл cookie. Вы уже поняли? : -)
Мой совет: поместите конфиденциальную информацию в HTTP-сеанс .
ОБНОВЛЕНИЕ: наличие сеанса подразумевает использование cookie (или, по крайней мере, уродливого URL-адреса), что возвращает нас к той же самой проблеме: его можно захватить. Единственный способ избежать этого - добавить сквозное шифрование: HTTP + SSL = HTTPS . А если кто-то скажет: «О, но файлов cookie / сеансов должно быть достаточно, чтобы отпугнуть большинство людей», посмотрите Firesheep .
Это нормально (неплохо, но не неправильно ) с точки зрения безопасности. Однако с точки зрения производительности этого следует избегать.
Все файлы cookie передаются от клиента к серверу при каждом запросе. В наши дни у большинства пользователей могут быть быстрые широкополосные соединения, но эти соединения асимметричны - пропускная способность восходящего потока, используемая для передачи данных cookie, часто все еще очень ограничена. Если вы поместите слишком много информации в файлы cookie, это может сделать ваш сайт вялым, даже если ваш веб-сервер работает с избытком мощности. Это также может увеличить ваш счет за пропускную способность. Это моменты, которые не будут обнаружены в вашем тестировании, что, скорее всего, происходит в вашей корпоративной сети, где восходящая пропускная способность от клиента к серверу достаточна.
Лучший (общий) подход - просто сохранить отдельный токен в cookie, который вы используете в качестве ключа для поиска информации в базе данных. Вызовы базы данных также относительно медленны (по сравнению с наличием информации в памяти или в запросе), но поиск первичного ключа, подобный этому, неплох, и все же лучше, чем отправлять данные, потенциально, на четверть пути по всему миру каждый раз. запрос. Это также лучше для безопасности, потому что это сохраняет данные за пределами машины пользователя и по сети в максимально возможной степени. Этот токен не должен быть чем-то вроде идентификатора пользователя из вашего вопроса, а скорее чем-то более недолговечным - ключом, используемым для индексации и скрытия более крупных блоков данных, из которых ваш идентификатор пользователя, возможно, является одной из частей.
Для вашего идентификатора пользователя, который, вероятно, представляет собой только одно целое число, а также других небольших и важных данных, храните их в памяти на веб-сервере. Поместите это в сеанс.