Авторизация и защита веб-ресурсов в ASP.NET | ASP.NET

10 Как реализовать меж-доменную идентификацию?

Всё это, конечно, хорошо. Пока работа осуществляется на одном браузере – всё отлично. А как быть с современными реалиями, когда у человека два мобильных телефона, один рабочий компьютер и несколько браузеров на нем, домашний компьютер, и ещё ноутбук?

Придется как-то решать вопрос с переносом ключей доменов между браузерами, устройствами. А ещё решить вопрос их правильной синхронизации.


Одним из механизмов решения данной задачи является вычисление различных ключей доменов на базе общего мастер-ключа без возможности обратного восстановления мастер-ключа по известному ключу домена.

Создав при помощи мастер-ключа M персональный ключ K для домена D на одном устройстве, пользователь сможет создать тот же самый ключ K для домена D и на любом другом при помощи всё того же мастер-ключа M и единого алгоритма. Точнее это сделает не пользователь, а его браузер.

Максимальное удобство для пользователя.

Но и максимальный риск

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

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

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

2 Алгоритм защиты токена при передаче

Исходный токен клиента передается крайне редко. Только при передаче незарегистрированного токена в момент создания сессии.

Токен считается незарегистрированным

, если он: создан на базе случайного (не зафиксированного) ключа; не был принят сервером после отправки ключа Change-To или Permanent. Подробнее см.


Браузер и сервер совместно вырабатывают пару случайных чисел, т.н. соль (Salt), при помощи которой хешируются младшие 128 бит токена. Оба обмениваются этими числами согласно протоколу. Подробнее см.

Таким образом, сервер сайта видит следующий токен:

где

$Hi(T_s)$

– старшие 128 бит,

$Lo(T_s)$

– младшие 128 бит исходного токена,

$cup$

– конкатенация строк. При этом исходный токен

$T_s$

должен быть уже известен серверу.

В идеале CSI-Salt должен меняться при каждом запросе браузера к серверу. Однако это может быть затратным требованием с точки зрения вычислительных ресурсов. Кроме того, это может «убить» возможность отправки параллельных запросов на сервер.Поэтому допускается, в целях оптимизации расчетов, сохранение неизменным значения CSI-Salt в разных запросах, но не дольше одного сеанса.

Это может быть ограничение по времени (смена CSI-Salt каждые 5 минут), либо реакция на интенсивность запросов (смена CSI-Salt через каждые 100 запросов), либо после каждой серии запросов (в момент паузы клиент-сервер), либо смешанный вариант. Здесь решение оставляется за разработчиками браузеров.

Слишком долгое удержание неизменным CSI-Salt ослабляет защиту передаваемого токена, позволяя злоумышленнику, при перехвате токена, воспользоваться им, пока легальный пользователь не выполнил Logout, и выполнить неавторизованный запрос от имени жертвы.

1 Защита ключевой информации от НСД

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

А вот способы защиты ключей от компрометации необходимо рассмотреть подробнее.

Ключи могут быть скомпрометированы путем:

Если допустить, что ключевая информация сохраняется на смарт-карте (мы рассматривали данный вариант в разделе

), то задача защиты ключевой информации перекладывается на плечи чипа. Правда появляется уязвимость к клавиатурным шпионам, которые могут перехватить вводимый PIN-код; ну и неудобность в использовании.

Помимо смарт-карт для защиты от прямого доступа к ключевой информации можно использовать симметричное шифрование. Но вопрос: какой ключ взять для шифрования?

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

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

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

Можно применить комбинированный вариант: шифрование ключом от браузера шифрование паролем пользователя от учетной записи ОС (если это позволяет API ОС). Причем ключ всегда генерируется «на лету». Тогда офлайновый брутфорс станет ещё затратнее.

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

Вы же предварительно сделаете резервную копию ключей (экспортируете ключи в файл). Если, конечно, уже не сделали этого ранее при распространении ключей на другие устройства.

3 Риски потери/компрометации ключей и их минимизация

А что если я потеряю мастер-ключ?

Такое может произойти, если вы поменяли пароль или переустановили ОС. Какие риски?

Ну вы не попадете на сайты, где были раньше. Потеряете историю покупок на интернет-магазинах, свои объявления на интернет-площадках, карму на форумах. Не беда.

Хотя, кто мешает сделать процедуру перерегистрации с новым токеном и подтверждением его через телефон, указанный в том же объявлении? Получается, что сайту необходимо делать форму перерегистрации токена (аналог «восстановления пароля»)? Где же обещанное отсутствие «всяких таких» форм?

На самом деле сайту, которому необходимо не просто идентифицировать посетителя, а ещё и знать кто это на самом деле, придется делать форму регистрации. Собственно, эта форма может использоваться для повторной регистрации. Вы указываете ровно те же данные, что и ранее (email, mobile).

Но всё-таки, лучше не терять мастер-ключ.

Как предотвратить потерю? Создавать резервную копию, защищать её паролем и хранить на отчуждаемых носителях. Так же, собственно, как это делается с ключами для bitcoin. В принципе, можно переводить мастер-ключи в печатный вид и сохранять на бумажке. Если на то пошло. А потом восстанавливать ручным вводом. Но это уже для совсем «параноиков», вроде меня.
А что если у меня угонят мастер-ключ?

Это уже серьезно. Хотя описываемые здесь рекомендации по хранению мастер-ключа (не входят в протокол) защищают их от прямого НСД, клавиатурных шпионов и троянов, тем не менее, риск компрометации мастер-ключа сохраняется. К сожалению, идеальной защиты не существует. Ключ может быть угнан прямо из памяти браузера через уязвимость движка javascript. Как пример. Или вы теряете мобильник…

Так какие риски угона мастер-ключа?

Существенные для получения сведений о вас и даже для совершения действий от вашего имени. Получение возможности злоумышленнику авторизовываться под вами и в режиме чтения получать доступ к закрытой информации. Тихо и незаметно. Или разом выкачать все ваши приватные видео из одноклассников. Вам неприятно. Любители котиков ликуют.

Здесь необходимо быстро перерегистрироваться с новым ключом на важных сайтах. И, если случилось страшное, регистрация вашего нового токена в БД поставщика услуг официальным способом, – единственный правильный вариант. Способов регистрации можно придумать множество: от бумажной фиксации в официальном письме, до заявки через службу техподдержки сайта с подтверждением личности приемлемыми способами. Но это только для серьезных сайтов, вроде онлайн-банка.

Способы минимизации рисков. Использование индивидуальных ключей для доменов (но это понижает мобильность учёток). Двухфакторная аутентификация по независимым каналам. Показ сайтом IP-адресов и устройств, откуда было подключение в последний раз, чтобы вы хотя бы вовремя заметили компрометацию.

1 Трекинг пользователя

Сайт, которому вы доверяете, может беззастенчиво сливать о вас информацию другим сайтам. В интернете существуют сайты-коллекторы, которые агрегируют такую информацию и продают её желающим. Яндекс-метрика, гугл-аналитика – редкий сайт обходится без них.

Чтобы два разных сайта могли определить, что работают с одним и тем же клиентом, применяются две техники:

  1. Выполнение одного сайта в контексте другого и взаимный обмен собственно сгенерированными идентификаторами пользователей (в качестве идентификатора может использоваться всё, что угодно из вашего профиля).
  2. Формирование отпечатка браузера по единому алгоритму (формирование уникального набора атрибутов браузера) и косвенная идентификация клиента по этому отпечатку.


В схеме 2 есть небольшой недостаток:

идентифицируется не пользователь

, а браузер. Но зачастую браузер == клиент.

Кажется, токен лучшим образом подходит к использованию в схеме № 2. Ведь если пользователь разрешил «запомнить» себя двум сайтам (действующим в паре), наш постоянный токен может выступить в роли такого «отпечатка», только уже не браузера, а самого пользователя. Проблема для сайтов здесь в том, что они получат разные токены.

Похожее:  Add Authentication to Your Vanilla JavaScript App in 20 Minutes | Okta Developer

Но ведь сайты могут попробовать применить ещё и схему № 1. Тогда получится следующее.

Сайт 1 получит от браузера код H1, а сайт 2, выполняемый в контексте сайта 1 – код H2. Кажется, теперь сайты могут сформировать пару (H1, H2) и даже передать это некому сайту-агрегатору.Пусть есть ещё один сайт 3, который работает в паре с сайтом 2, пытаясь вас отследить.

Сайт 3 получит от браузера токен H3, а сайт 2, выполняемый в контексте сайта 3 – токен H2′ != H2 (см. как формируется токены). Как результат, объединение полученных данных невозможно, т.к. у них нет пересекающихся частей.

Но это не значит, что сайты не смогут использовать для слежки fingerprint браузера. Здесь утверждается только то, что схема генерации токенов сама по себе достаточно надежна и защищает от трекинга.

Вариант защиты: выходить из сайтов, с которыми вы закончили работу. Браузер может делать это автоматически при закрытии вкладки.

5 Компрометация ключа для SSO

Пусть учетная запись пользователя на сервере аутентификации, поддерживающим SSO, компрометирована. Оценим возможные риски при нашей схеме аутентификации.

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

Компрометация одного ключа домена не ведет к автоматической компрометации всех остальных.

Большинство сайтов, где вы уже авторизовывались ранее при помощи SSO, наверняка сохранят в своей базе ваш токен с вашим профилем с сервера SSO. В нашей схеме, сайт просто будет подтягивать токен из БД и опознавать вас. Т.е. на таких сайтах сервер SSO уже не нужен – он выполнил свою функцию на этапе регистрации.

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

Не поможет злоумышленнику и попытка провести заново кросс-доменную аутентификацию: сайт должен блокировать попытки создания новой учетной записи со старым Id-пользователя SSO и новым токеном сайта. Либо попытки перезаписи токена пользователя для существующего Id в процессе SSO должны блокироваться.

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

Минимизация рисков при компрометации. Как ни странно, но это – сохранение сайтами токенов и профилей пользователей на своей стороне. Попытка злоумышленником провести кросс-доменную аутентификацию может вызвать конфликт между старым Id-пользователя и новым его токеном.

Максимальный риск: авторизация от вашего имени на других сайтах (где вы ещё не были). Доступ к данным вашего профиля. Совершение незаконных действий от вашего имени. А чтобы законный владелец не смог ничего вернуть, злоумышленник может поменять на сервере авторизации свой токен легальным способом. Этот риск, впрочем, совпадает с рисками, при использовании традиционных схем авторизации.

Способы защиты. Отказ от использования SSO (тем более, что предлагаемая схема и задумывалась как способ уйти от централизованных схем аутентификации). Использование нескольких SSO (не храните все яйца в одной корзине!).

Если SSO поддерживает двухфакторную аутентификацию с подтверждением личности по иным атрибутам (почта, телефон), то существует возможность восстановления контроля над учёткой сервера авторизации.

Авторизация и защита веб-ресурсов в asp.net

Предоставление каждому посетителю сайта уникальной учётной записи позволяет вам однозначно идентифицировать любого из них. Идентификация позволяет веб-сайту менять оформление и контент в зависимости от предпочтений и интересов посетителей.

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

Корпоративные сайты, расположенные в защищённых внутренних сетях предприятий, могут содержать страницы с отчётами, предназначенными только для руководителей или сотрудников определённых отделов. Рядовые сотрудники не должны иметь доступа к этим ресурсам.

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

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

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

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

Рассмотрим, как организована авторизация в популярном веб-фреймворке ASP.NET.

Как мы уже говорили, предоставление пользователям уникальных учётных записей позволяет идентифицировать их. Механизм «узнавания» сайтом зарегистрированных посетителей называется аутентификацией.

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

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

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

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

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

Использование аутентификации и авторизации для защиты сайта, построенного на основе технологий ASP.NET – основная тема этой статьи.

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

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

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

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

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

Однако в случае принадлежности пользователя к нескольким группам или ролям в системе должен быть предусмотрен механизм решения конфликтов прав. Например, пользователь блога может быть включён в две группы, одной из которых разрешено создавать посты, а другой – только просматривать. Какое право присваивать пользователю в итоге?

Большая часть систем оставляет в действии минимальные права либо предусматривает приоритет запретов над разрешениями. В таком случае наш гипотетический пользователь не будет иметь права писать в блог, так как ограничение полномочий будет преобладать над разрешением.

Хорошей практикой является разделение пользователей на группы по виду деятельности на сайте. Например, наш блог может иметь следующие группы пользователей: «Авторы», «Редакторы», «Модераторы» и т.д.

Альтернативный подход будет состоять в том, чтобы выделить группы «Создание статей», «Правка статей», «Удаление комментариев» и т. д. Такой подход будет обладать значительной гибкостью, но при этом придётся поддерживать на сайте большее количество различных групп.

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

При защите сайта на ASP.NET используются три направления разделения доступа:

Как веб-формы, так и роутинг в ASP.NET использует для защиты доступа web.config. Основа конфигурации для защиты доступа к ресурсам сайта выглядит примерно так:

Похожее:  Двухэтапная аутентификация — Справка

XML-элемент location определяет путь к защищаемому ресурсу: папке, странице или элементу роутинга. В данном примере он задаёт страницу adminhome.aspx. Можно защитить содержимое папки целиком, указав путь к ней. Если атрибут path отсутствует, настройки безопасности применяются к той папке, в которой находится файл web.config, со всеми её подпапками.

Элемент authorization определяет, кто имеет или не имеет доступа к защищаемому ресурсу. Права проверяются последовательно, начиная с первого и до тех пор, пока совпадение не будет найдено. Вложенный элемент allow задаёт разрешение, а deny – запрещение доступа к ресурсу для заданного пользователя или роли.

В нашем примере правило <allow admin role /> будет проверено первым. Если пользователь обладает ролью администратора, доступ ему будет предоставлен, и проверка условий на этом прекратится.

В противном случае проверка продолжится до следующего правила: <deny users=”*” />, которое лишит доступа к ресурсу всех пользователей. Таким образом, наш пример даёт доступ к файлу только администраторам. Всем остальным будет отказано в доступе.

Существует несколько специальных символов, обозначающих часто используемые группы. Мы уже видели символ «*», обозначающий всех пользователей.

Символ «?» обозначает анонимного (не успевшего зарегистрироваться) пользователя. Несколько групп или отдельных пользователей могут быть перечислены через запятую. Пользователи и роли могут смешиваться в одном правиле, например:

Разработка сайта согласно методологии MVC сосредотачивается не на файлах и папках, а на контроллерах и их действиях. Соответствующим образом меняется и защита. По умолчанию все действия всех контроллеров доступны всем пользователям, как и в случае с веб-формами. Вам доступны те же пользователи и роли, но файлов web.config больше нет.

Вместо этого вы применяете атрибут [Authorize] непосредственно к контроллерам и действиям. Например, если у вас есть контроллер, доступ к которому должны иметь только администраторы, вы можете добавить соответствующую роль в тэг. Учтите, что использование тэгов в [Authorize] означает неявный запрет доступа для всех пользователей, не перечисленных в них:

Для обозначения анонимов и всех пользователей доступны те же символы «?» и «*». Вы можете применять установки ко всему контроллеру или к отдельным действиям. При этом настройки действий будут иметь более высокий приоритет, чем настройки всего контроллера:

Если вы не укажете пользователей или ролей в атрибуте [Authorize], то доступ будет разрешён всем зарегистрированным пользователям.

В ASP.NET 4 был добавлен атрибут [AllowAnonymous], который позволил разрешить анонимному пользователю доступ к отдельным действиям защищённого контроллера.

Ограничив доступ к страницам и контроллерам, следующим шагом вы должны убедиться в том, что доступ к самому серверному коду осуществляется правильно. Некоторые объекты легко защитить, потому что к ним должны иметь доступ только пользователи с определённой ролью, и доступ этот – полный.

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

Например, не имеет смысла показывать ссылку на панель администрирования рядовым пользователям. Клиент, не имеющий отправленных заказов, не должен видеть кнопку трекинга. Даже если элемент не активен или ведёт на страницу авторизации, он может смутить простого пользователя и дать злоумышленнику пищу для размышления.

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

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

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

Всегда проверяйте, насколько безопасен код, обрабатывающий GET-запросы. Например, ваш веб-магазин имеет запрос для удаления заказа:

Теперь, представьте хакера, удаляющего все заказы перебором параметра order. Проверяется ли принадлежность заказа пользователю в соответствующем обработчике?

В другом случае отсутствие проверки в чём-то вроде:

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

Защита самих данных авторизации является отдельной задачей безопасности, хоть и близко соотносящейся с безопасностью доступа к ресурсам и коду. Во-первых, на безопасность механизма аутентификации влияет продолжительность сессии. В ASP.NET этот параметр задаётся в web.config следующим образом:

В этом примере время жизни сессии составит 30 минут. Атрибут slidingExpiration определяет, сбрасывает ли счётчик истечения сессии поступление запроса от пользователя. Если установить данному атрибуту значение false, пользователю придётся осуществлять вход каждые 30 минут, даже во время активной работы с сайтом.

Также необходимо учитывать возможность кражи сессии. Большинство веб-фреймворков хранят идентификатор сессии в маленьком кусочке текстовых данных, называемом кукой или печенькой (cookie), в браузере пользователя.

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

Существуют средства вроде FireSheep – расширения для браузера Firefox – позволяющие демонстрировать редактирование или подмену авторизационной куки.

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

Фреймворк ASP.NET позволяет усилить защиту сайта, установив атрибут формы входа на сайт requireSSL=”true”. Для ещё большей безопасности рекомендуется также применить тэг в конфигурации сайта.

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

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

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

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

Комбинация этих мер позволит вам создать безопасный и защищённый веб-сайт.

Система безопасности инстанта – защита форм регистрации и авторизации 3 493 просмотра — instantcms community

Версия 1

Мною написано несколько файлов, которые защищают формы авторизации и регистрации Инстанта как от брутфорс-атаки, так и от атаки по словарю. В настоящий момент скрипты проходят тестирование на моем демосайте

www.aviakis.net.ru.

Вот некоторые (но не все) характеристики:

1. Защита формы авторизации от перебора логина-пароля. При обнаружении перебора сперва делается предупреждение, а затем перебирающий блокируется.
2. Защита формы авторизации в админке с помощью дополнительного поля. Не исключает дополнительной защиты папки
/admin с помощью .htaccess. Такой .htaccess мною написан и лежит вместе с другими файлами в установочном дистрибутиве, хотя на демосайте его сейчас нет.
3. Защита форм регистрации. Не секрет, что многие наши ленивые юзеры норовят зарегится, например, под логином zz и паролем 11, а потом удивляются, почему от их имени на сайте происходят разные гадости. Я составила список из примерно 70 слов, которые при авторизации проверяются. Если система находит логин или пароль в этом списке, регистрации не происходит. При необходимости этот список легко дополнить.

Теперь о причинах, почему мой скрипт не может быть опубликован или выложен в открытый доступ. На нашем сайте в форуме появлялось сообщение (месяца два назад, наверное), о том, что какой-то человек захотел выяснить, насколько безопасен Инстант. Сам он в сайтостроении не особо продвинут, поэтому заплатил человеку сведующему, тот скачал движок Инстанта и исследовал его вдоль и поперек. После этого появилась статья в каком-то журнале о всех найденых дырах… Короче, кому хочется, эту старую тему сами ищите.

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

В настоящий момент установочный дистрибутив готов для версии 1.5.2. Мне надо еще немного времени, чтобы адаптировать его к 1.5.3. Собственно, для этого надо просто добавить папку languages со всеми файлами и в скриптах вместо вывода текста поставить языковые переменные. Мне так проще было писать скрипты.

Похожее:  Личный кабинет юридического лица ИФНС

Посмотреть скрипты в работе можно, как я сказала, на демосайте www.aviakis.net.ru. Если кому-то захочется поставить мой скрипт себе на сайт, пусть обращается в личку. Я ему отправлю письмо с подробным описанием и полными техническими характеристиками.

Буду благодарна тому, кто найдет тот или иной косяк в алгоритме для оперативного исправления.

Версия 2
Во второй версии модуль авторизации перезагружается автоматически по истечении времени. То самое юзабилити, за которое ратовал neart. Просили — получите! Чуточку изменила алгоритм защиты. Теперь учтена возможность подбора со сменой ip.

Что будет в Версии 3? Собираюсь адаптировать свои файлы к версии Инстанта 1.5.3. Кроме того, перепишу модуль авторизации по технологии ajax, чтобы формы авторизации подгружались в браузер тогда, когда это нужно.

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

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

Брутфорсте на здоровье)))

Светлана.

Схема на базе протокола srp

SRP — протокол парольной аутентификации, устойчивый к прослушиванию и MITM-атаке и не требующий третьей доверенной стороны. Имеет свой RFC2945. Есть производные от него стандарты для протоколов Telnet, TLS. Единственный из представленных, который проводит окончательную взаимную авторизацию обеих сторон. Хорошо описан как в Википедии, так и на Хабре пользователем @datacompboy.

Тем не менее, для генерации секретного ключа x протокол использует устаревшие подходы: (уже  не криптостойкую) функцию SHA-1 и  простую схему хеширования: x = hash(salt | hash(login | ‘:’ | pass). В свете современных тенденций к взлому паролей брутфорсом офлайн на специализированных ПЛИС или арендованных кластерах, данный подход должен быть улучшен, использованием scrypt.

Для реализации схемы нам понадобятся: большое простое число N, генератор g мультипликативной группы Z*N и параметр k = hash(N, g). В качестве g и N стороны используют числа, определенные в RFC-5054. Так, например, g = 2, а «мультипликативная группа» – это просто степени двойки; точнее их остатки по модулю N.

Процесс регистрации пользователя в системе:

  1. Клиент отправляет серверу свой login и свою 256-битную версию соли saltC.

  2. Сервер генерирует свою 256-битную версию соли saltS для пользователя login.

  3. Клиент формирует общую 256-битную соль: salt = saltC ^ saltS.

  4. Клиент вычисляет секретный 256-битный ключ x = scrypt(password, salt) от своего пароля

  5. Клиент вычисляет верификатор пароля V = gx (mod N).

  6. Клиент посылает на сервер пару (saltC, V).

  7. Сервер вычисляет общую соль salt аналогично клиенту в п. 3.

  8. Сервер хранит учетные данные пользователя в форме: login, salt, V.

Процесс авторизации пользователя в системе:

  1. Клиент формирует случайное 256-битное число a и вычисляет 2048-битное A = ga (mod N).

  2. Клиент делает запрос на сервер со своим login, и числом А.

  3. Сервер формирует случайное 256-битное число b и вычисляет 2048-битное B = (kv gb) (mod N).

  4. Сервер посылает клиенту пару (salt, B).

  5. Обе стороны вычисляют u = hash(A | B). В оригинальном RFC указано, что параметр u – 32-битное беззнаковое, получаемое от результата примененной хеш-функции hash(A | B).

  6. Пользователь вычисляет свой ключ x на основе пароля и соли, аналогично пп. 4 процесса регистрации.

  7. Пользователь вычисляет сессионный ключ K следующим образом: S = (B – kgx)a ux (mod N); K = hash(S).

  8. Сервер вычисляет сессионный ключ K следующим образом: S = (Avu)b (mod N); K = hash(S).

  9. Пользователь вычисляет M1 = hash( hash(N) ^ hash(g) | hash(login) | salt | A | B | K ) и отправляет на сервер.

  10. Сервер дождавшись от пользователя M1, проверяет его, производя аналогичные п. 9 вычисления.

  11. Сервер вычисляет M2 = hash( A | M1 | K ) и отправляет клиенту.

  12. Клиент проверяет M2 сервера. На этом этапе аутентификация считается завершенной.

В функции hash операция | означает конкатенацию аргументов. Если предполагается, что ключ K не будет использоваться в дальнейшем взаимодействии (например, для шифрования или аутентификации пакетов), то пп. 9-12 к исполнению обязательны. А если будет, то проверка излишняя, т.к. несогласованный ключ не позволит проводить корректное взаимодействие. Но я бы всё-таки оставил эти пункты обязательными.

Согласно спецификации, пользователь должен прервать аутентификацию, если получил B = 0 (mod N) или u = 0. (Полагаю, что B не должно быть также равно –kV, т.к. в этом случае клиент получит S = 0a ux (mod N) = 0).

Сервер должен прервать аутентификацию, если получил A = 0 (mod N). Клиент должен первым доказать, что получил тот же ключ K. Если клиенту это не удалось, сервер должен прервать аутентификацию, без своего доказательства K.

Подведём итоги

Параметр / Схема

1. Симметричная на базе HASH

2. На базе ECDSA

3. SRP-6a

Скорость

Проверка на сервере реализуется быстрее

Проверка подписи на стороне сервера в 2 раза медленнее клиента

Медленная, требует длинной арифметики и 4 пакета для завершения аутентификации

Технические сложности

Отсутствуют; может быть реализована на нативном js; работает достаточно быстро.

Отсутствует поддержка произвольной кривой в WebCryptoApi на клиенте

Уже никаких

Потенциальные уязвимости

Уязвима к компрометации БД и последующему контролю канала сервера; уязвима в процессе регистрации пользователя

Существуют классы уязвимых эллиптических кривых. Методики оценки безопасности кривых ещё не разработано. Вероятность, что выбрана «слабая» кривая, всегда остается.

Задача решения дискретного логарифма может быть решена теоретически; надежность базируется на сложности факторизации N; числа N, g, k известны всем.

Обратить особое внимание на

Случайное число k, генерируемое клиентом в процессе подписи, не должно использоваться дважды!

Числа A, B не должны быть равны 0 и 0, –vk соответственно.

Защита от пассивного MitM

да (но только не в момент регистрации)

да

да

Защита от активного MitM

да (только, если учетные данные не компрометированы)

да

да

Защита пароля при компрометации БД

да

да

да

Защита после компрометации БД и прослушивании канала

нет

да

да

Препятствие «легальному» доступу злоумышленника после компрометации БД

да

да

да

Взаимная аутентификация сторон

нет

нет

да

Защита от фишинга (попытка злоумышленника выдать себя за легальный сервер)

нет

нет

да

Требует наличие какого-либо доп. защищенного канала при регистрации клиента?

да

нет

нет

Защита слабых паролей в момент авторизации

нет

да

да

Защита от владельцев ЦОД

нет

нет

нет

Заключение

Несколько моих знакомых, которым я показал статью, задавали мне по сути один и тот же вопрос: «А в чем здесь главная фишка?»

Если смотреть с высока

И действительно, поверхностный обзор протокола оставляет о нем впечатление (особенно с точки зрения конечного пользователя), как об ещё одном (очередном?) парольном менеджере, встроенном в браузер.

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

Серверы кросс-доменной авторизации тоже решение «так себе». Те же яйца Тот же парольный менеджер, только сбоку «онлайн». Тут вы доверяете владельцу сервера, а не разработчику менеджера. Но сервер могут взломать (и не важно Google это, или Facebook – утечки происходят рано или поздно у всех). Сервер может быть недоступен (вдруг его DDOS-ят или там просто тех.работы – ЕСИА в пример) или заблокирован каким-либо органом. Да и вообще, такие серверы под маской SSO любят собирать о вас слишком много информации, и нередко становятся целью хакеров со всего мира. Вам это нужно?

К тому же, мне, например, не прельщает перспектива регистрироваться в хомячковых соц.сетях только затем, чтобы авторизоваться на очередной интернет-барахолке и разместить там объявление купи-продай. Тем более, что регистрация в таких соц.сетях, становится всё строже и строже. Раньше требовался лишь подтвержденный email, потом телефон. Сейчас в наглую требуют реальную фотографию. Не удивлюсь, если скоро от нас будут требовать сдать отпечатки пальцев и кровь на анализ. Вам точно это нужно?

Я хочу интернет-независимости. А вы? SSO – не делает на свободными.

Наконец, есть же во многих браузерах встроенная фишка «запомнить пароль». Правда эта фишка исчезает при первой же переустановке ОС. Да и с мобильностью тут неважно. Даже между браузерами в пределах одного устройства. Фактически проблема с хранением паролей и их синхронизацией отдана на откуп самому пользователю. Крутись как можешь, чувак.

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

Так всё-таки, неужели в предлагаемом протоколе нет ни какой особой фишки?

О вот нет главной фишки!

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector