Почему доступ пользователей подвержен атакам?

An application’s mechanism for handling user access only as strong as the weakest of these components.

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

Механизм защиты, используемый веб-приложениями, состоит из следующих пунктов:

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

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

Большинство веб-приложений обрабатывают доступ пользователей с помощью трех взаимосвязанных механизмов безопасности:

1. Аутентификация
2. Управление сессией
3. Контроль доступа

Аутентификация

Аутентификация - это способ доказать, кем мы себя называем. Логически это самая основная зависимость в работе пользователя с приложением. Важность аутентификации может быть очевидна с той точки зрения, что без аутентификации каждый рассматривается как анонимный, что является минимально возможным уровнем доверия. Его также называют authn. Большинство современных веб-приложений используют обычную систему аутентификации, в которой мы должны отправить имя пользователя или наш почтовый идентификатор и пароль, которые приложение проверяет на действительность, но в настоящее время некоторые приложения используют дополнительные задачи для входа, такие как OTP, или используют смарт-карты. и различные другие факторы. В дополнение к этой функции входа в систему аутентификация также использует ряд функций, таких как регистрация, восстановление учетной записи и изменение пароля.

Общие уязвимости:

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

Пример:

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

Обеспечение аутентификации:

• Используйте надежные учетные данные.
• Храните учетные данные в секрете.
• Правильно проверьте учетные данные.
• Используйте капчу.

Управление сессией

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

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

Общие уязвимости:

1. Слабость в генерации токенов сеанса: токены предсказуемы из-за слабости в генерации токенов сеанса.
2. Слабость в обработке токенов сеанса: иногда токены отображаются в URL-адресе или журналах, к которым может получить доступ злоумышленник.

Пример:

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

Обеспечение безопасности управления сеансом:

1. Создавайте сильные токены
2. Защищайте токены на протяжении всего их жизненного цикла

Контроль доступа

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

Общие уязвимости:

1. Вертикальное повышение привилегий: когда пользователи с более низкими привилегиями могут получить доступ к ресурсам пользователей с более высокими привилегиями.
2. Горизонтальное повышение привилегий: когда пользователь получает доступ к ресурсам другого пользователя, который имеет те же привилегии, что и злоумышленник.
3. Эксплуатация бизнес-логики: когда из-за какой-либо ошибки в приложении злоумышленник может получить доступ к ключевым ресурсам приложения.

Пример:

Предположим, что в запросе есть параметр UID, чем из-за слабого контроля доступа, если злоумышленник пытается заполнить анонимный идентификатор, он получает доступ как другой пользователь, например, вводя 124 вместо 123

 https://insecure-website.com/customer_account?uid=123

Обеспечение контроля доступа:

1. По умолчанию запретить доступ к функциям.
2. Не просто скрывайте функции.
3. Реализуйте многоуровневую модель привилегий.

Насколько они взаимозависимы?

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

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

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