Соображения безопасности, которые следует учитывать при разработке системы, аналогичной сеансу ASP.NET

Question

Какие соображения безопасности следует учитывать при разработке системы, аналогичной сеансу ASP.NET?

Редактировать: Некоторые следят за полученным вводом,

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

Я вижу, зашифрован ли токен и / илиподписал, что становится сложнее попытаться угадать действительный токен.Предполагая, что токены являются недолговечными, максимум 24 часа или, возможно, со скользящим истечением с некоторым ограничением общей продолжительности, подписывает ли токен какую-либо дополнительную защиту после рендеринга очень случайных уникальных токенов?

Я бы подумал об использовании чего-то вместестроки со значением 512 байт, сгенерированные RNGCryptoServiceProvider.

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

Answer 1

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

Давайте разберем это по типу токена:

• Случайный идентификатор токена

Любой может просто «угадать» один из них, но он быстр и прост в использовании. Поскольку сеанс обычно недолговечный, это, как правило, не является серьезной проблемой. Также отличное решение, потому что они имеют небольшой размер (22 байта в кодировке base64 или 32 байта в шестнадцатеричном формате)

Вы писали: «Я хотел бы рассмотреть возможность использования чего-либо в соответствии со значением 512 байт, генерируемым RNGCryptoServiceProvider.»

Да, хорошо, похоже, что 512-байтовый идентификатор был бы крутым; однако даже 128-битные значения (16 байт) имеют абсурдное количество возможностей (больше запросов, чем ваш сервер может обработать за год). Не делайте это своей основной защитой, вместо этого предполагайте, что идентификатор не является секретом.

• PKI Зашифрованные и подписанные данные

Это хорошо работает, чтобы «скрыть» информацию, текущую через транспорт. Тебе нужно? Это стоит значительных накладных расходов? Кроме того, в дополнение к накладным расходам на вычисления / верификацию приходится платить за объем передаваемых данных. Это более безопасно? возможно, но в конце концов украсть так же легко, как и случайный идентификатор.

Всегда предполагайте, что кто-то другой может получить идентификатор сеанса / токен

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

В мире веб-запросов есть две части идентифицирующей клиента информации, включенной в запрос. IP-адрес клиента и User-Agent. Проблема в том, что эти значения могут измениться за сеанс. Таким образом, подход заключается в том, чтобы либо повторно запрашивать подтверждение каждый раз, когда они изменяются, либо для каждого отдельного значения.

Да, я знаю, что User-Agent очень легко подделать, и IP-адрес клиента также может быть подделан; однако в конце дня вам стало сложнее атаковать. Это точка безопасности, потому что ничто не является абсолютно безопасным.

Дополнительные советы

• Для высокочувствительных данных вы должны быстро прекратить сеансы (<5 минут). </p>

• Очевидно, что SSL необходим по многим причинам

• SSL поддерживает «безопасные куки», которые никогда не записываются на диск и не сохраняются. Это может затруднить получение идентификатора сеанса.

• Циклическое переключение ключей может использоваться достаточно эффективно. Если вы генерируете новый сеансовый ключ при каждом посещении, как рекомендует Cris Lively, вам нужно сохранить N последних номеров идентификаторов сеансов. Поэтому, если N = 5, после 5 запросов мой исходный идентификатор сеанса больше не действителен.

• Учитесь у других, читайте и пользуйтесь своими существующими учетными записями на других крупных сайтах.

наконец-то ...

Я снова скажу, что сессии не очень хорошо масштабируются и их следует избегать во всех, кроме очень немногих местах.

ОБНОВЛЕНИЕ:

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

Генерация идентификатора из 16 байтов или более должна быть достаточной для эффективного устранения угадывающих идентификаторов сеанса атакующего. Предполагая, что это и использование безопасных файлов cookie SSL +, вы должны быть максимально безопасны. Почему?

SSL будет эффективно препятствовать получению ключа сеанса во время транзита. Таким образом, если у кого-то есть сеансовый ключ, который ему не принадлежит, то это потому, что он выполняет одну из двух вещей: A) он выполняет код на клиенте (может быть, в браузере) или B) он выполняет код на ваш сервер. Так что, в принципе, если они могут поставить под угрозу конечную точку, вы уже проиграли игру в области безопасности, и они вряд ли получат какую-либо дополнительную работу.

Если вы не используете SSL, у вас все равно нет безопасности. Простая атака «человек посередине» позволит злоумышленнику делать все, что я хочу, от имени клиента. Любая работа по обеспечению безопасности использования HTTP без SSL (или какой-либо другой формы безопасного согласованного ключа сеанса) - это просто притворство безопасности. Да, вы можете сделать это более трудным, но вы не можете сделать это безопасным.

Итак, в конце концов, просто доверьтесь SSL, чтобы защитить работу транспорта, и приступайте к жизни:)

Answer 2

1. Нужно ли это вообще.Вы не можете атаковать то, чего нет, и большое количество систем, использующих сеансы, не обязательно.
2. Каково значение атаки?(Если кто-то может видеть предпочтительную цветовую схему другого человека, мне все равно) Какое значение это может иметь в будущем?(Могу ли я завтра закончить тем же расширением того же кода выбора скина, чтобы он также работал с более конфиденциальными данными).
3. Я уже защищен от многих атак с помощью SSL?
4. Можно ли предсказать генерацию ключа?Нужно ли регулярно менять ключи?Как часто?Как мне это сделать?Как мне работать с внепоследовательными запросами (подлинный запрос для img1.png приходит после того, как запрос на img2.png изменил ключ).
5. Cookies или что-то еще?
6. Нужно ли мне«Выход», чтобы очистить состояние сервера, а также куки-файл клиента?
7. Где будет жить сессия «bag»?На веб-сервере или где-то еще.Как мне справиться с ситуацией с веб-фермерским хозяйством (если я не нуждаюсь сейчас, могу ли я?)
8. Могу ли я разделить некоторую информацию в состояние сеанса, а другую основать на аутентификации?
9. Могу ли я использовать код на стороне клиента для добавления ответа на запрос к обработке файлов cookie или я должен использовать среды no-js?
10. Могу ли я обнаруживать людей, пытающихся угадать идентификаторы?Как мне реагировать?
11. Как избежать повторного использования ключей (то есть моего «честного» назначения ключа, который использовался ранее) и / или избежать возникновения проблем?

Answer 3

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

Поэтому я бы рекомендовал некоторымшифрование ключа и время его истечения.

Вы можете сохранить ключ в файле cookie, в URL-адресе или в любом другом месте, в котором вы хотите.

Как ASP.net хранит идентификацию на клиентесторона

Answer 4

Принимая по одному за раз:

1. Каковы соображения безопасности при восстановлении обработки сеанса .Net:
   Обработка сеанса .Net предлагает очень ограниченную защиту для большинства ситуаций инет для других.Если цель состоит в том, чтобы предотвратить передачу данных в браузер, то это происходит.Однако, если цель состоит в том, чтобы гарантировать, что только авторизованный пользователь может использовать эти данные ... ну, это не так.Восстановление этого как есть, тривиально и приводит нас к другим вашим вопросам.

2. Действительно ли шифрование токена действительно обеспечивает безопасность?
   Нет. Это не так.Все, что вы отправляете в браузер, может быть взломано.Если эти данные могут быть перехвачены и воспроизведены, это не имеет значения.Однако существуют решения ...

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

---

Если бы мне пришлось перестроить обработку сеансов asp.net, я бы добавил одну вещь: случайно меняющееся значение, указывающее следующий принятый «токен запроса».Это должно быть как можно более непонятным.

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

Это гарантирует, что даже если поток данных между браузером и сервером был записан, он не может быть воспроизведен,Например:

1. Браузер отправляет первичный запрос на сервер.Сервер отвечает с идентификатором сеанса ABC и токеном запроса 1
2. Браузер делает второй запрос к серверу, передающему ABC, и 1. Сервер проверяет комбинацию, выполняет запрос и отвечает токеном 453.
3. Браузер занимает третье местозапрос к серверу, передающий ABC и 453. Сервер проверяет комбинацию, выполняет запрос и отвечает токеном 23
4. Плохой парень повторяет шаг 2, пропуская ABC и 1. Сервер видит недопустимый запрос, предупреждает владельца сайта и отвечает с помощьюошибка нарушения безопасности.

В этом случае ЕДИНСТВЕННЫЙ способ для плохих парней - это переслать новый запрос с последним полученным токеном.Однако, как только реальный браузер отправит новый запрос, он получит приятное уведомление о нарушении безопасности, и вы получите уведомление.

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

ОБНОВЛЕНИЕ

Один вопрос в комментариях касался одновременных запросов.Вообще говоря, браузер будет выдавать несколько запросов GET для таких артефактов, как CSS, изображения, Javascript и т. Д. Они не должны быть включены в тест безопасности.Однако каждый запрос POST, который браузер выполняет только один раз, должен запускать проверку и иметь новое значение, отправляемое обратно в браузер.