Контроль доступа
В этом разделе мы описываем:
Эскалацию привилегий.
Уязвимости контроля доступа.
Как предотвращать уязвимости контроля доступа.
Лабораторные работы
Если вы знакомы с базовыми концепциями уязвимостей контроля доступа и хотите попрактиковаться в их эксплуатации на реалистичных, преднамеренно уязвимых целях, вы можете перейти к лабораторным работам по ссылке ниже.
Что такое контроль доступа?
Контроль доступа — это применение ограничений к тому, кто имеет право выполнять действия или получать доступ к ресурсам. В контексте веб-приложений контроль доступа зависит от аутентификации и управления сессией:
Аутентификация подтверждает, что пользователь — это именно тот, за кого себя выдает.
Управление сессией определяет, какие последующие HTTP-запросы выполняет тот же пользователь.
Контроль доступа определяет, разрешено ли пользователю выполнять действие, которое он пытается совершить.
Нарушения контроля доступа распространены и часто представляют критическую уязвимость безопасности. Проектирование и управление контролем доступа — это сложная и динамичная задача, в которой бизнес, организационные и юридические ограничения воплощаются в технической реализации. Решения по проектированию контроля доступа принимаются людьми, поэтому вероятность ошибок высока.
Вертикальные механизмы контроля доступа
Вертикальные механизмы контроля доступа — это механизмы, ограничивающие доступ к чувствительной функциональности для определенных типов пользователей. При вертикальном контроле доступа разные типы пользователей имеют доступ к разным функциям приложения. Например, администратор может изменять или удалять любую учетную запись пользователя, тогда как обычный пользователь не имеет доступа к этим действиям. Вертикальные механизмы контроля доступа призваны обеспечивать бизнес-политики, такие как разделение обязанностей и наименьшие привилегии.
Горизонтальные механизмы контроля доступа
Горизонтальные механизмы контроля доступа — это механизмы, ограничивающие доступ к ресурсам для конкретных пользователей. При горизонтальном контроле доступа разные пользователи имеют доступ к подмножеству ресурсов одного типа. Например, банковское приложение позволяет пользователю просматривать транзакции и совершать платежи со своих собственных счетов, но не со счетов других пользователей.
Контекстно-зависимые механизмы контроля доступа
Контекстно-зависимые механизмы контроля доступа ограничивают доступ к функциональности и ресурсам на основе состояния приложения или взаимодействия пользователя с ним.
Контекстно-зависимые механизмы контроля доступа предотвращают выполнение пользователем действий в неправильном порядке. Например, розничный веб-сайт может запрещать пользователям изменять содержимое корзины после того, как они произвели оплату.
Примеры нарушений контроля доступа
Уязвимости нарушения контроля доступа возникают, когда пользователь может получать доступ к ресурсам или выполнять действия, которые ему не должны быть доступны.
Вертикальная эскалация привилегий
Если пользователь может получить доступ к функциональности, к которой ему не разрешен доступ, это является вертикальной эскалацией привилегий. Например, если обычный пользователь может получить доступ к странице администратора, где он может удалять учетные записи пользователей, то это вертикальная эскалация привилегий.
Незащищённая функциональность
В самом простом случае вертикальная эскалация привилегий возникает, когда приложение не применяет никакой защиты к чувствительной функциональности. Например, административные функции могут быть доступны со страницы приветствия администратора, но не отображаться на странице приветствия обычного пользователя. Однако пользователь может получить доступ к административным функциям, перейдя по соответствующему административному URL.
Например, веб-сайт может размещать чувствительную функциональность по следующему URL:
Этот URL может быть доступен любому пользователю, а не только административным пользователям, у которых есть ссылка на функциональность в пользовательском интерфейсе. В некоторых случаях административный URL может быть раскрыт в других местах, например в файле robots.txt:
Даже если URL нигде не раскрыт, атакующий может использовать список слов для перебора и нахождения чувствительной функциональности.
В некоторых случаях чувствительная функциональность скрывается путем присвоения ей менее предсказуемого URL. Это пример так называемой «безопасности через сокрытие». Однако скрытие чувствительной функциональности не обеспечивает эффективного контроля доступа, поскольку пользователи могут обнаружить скрытый URL несколькими способами.
Представьте приложение, которое размещает административные функции по следующему URL:
Этот URL может быть не напрямую угадываемым для атакующего. Однако приложение все же может утекать этот URL пользователям. URL может быть раскрыт в JavaScript, который конструирует пользовательский интерфейс на основе роли пользователя:
Этот скрипт добавляет ссылку в интерфейс пользователя, если он является администратором. Однако сам скрипт, содержащий URL, виден всем пользователям независимо от их роли.
Методы контроля доступа на основе параметров
Некоторые приложения определяют права доступа или роль пользователя при входе, а затем сохраняют эту информацию в контролируемом пользователем месте. Это может быть:
Скрытое поле.
Cookie.
Параметр строки запроса.
Приложение принимает решения о контроле доступа на основе переданного значения. Например:
Этот подход небезопасен, поскольку пользователь может изменить значение и получить доступ к функциональности, на которую у него нет полномочий, например к административным функциям.
Нарушение контроля доступа из-за неверной конфигурации платформы
Некоторые приложения реализуют контроль доступа на уровне платформы. Они делают это, ограничивая доступ к определенным URL и HTTP-методам на основе роли пользователя. Например, приложение может настроить правило следующим образом:
Это правило запрещает доступ к методу POST на URL /admin/deleteUser для пользователей из группы managers. В такой ситуации может пойти не так многое, что приведет к обходу контроля доступа.
Некоторые фреймворки приложений поддерживают различные нестандартные HTTP-заголовки, которые можно использовать для переопределения URL в исходном запросе, такие как X-Original-URL и X-Rewrite-URL. Если веб-сайт использует строгие фронтенд-контроли для ограничения доступа на основе URL, но приложение позволяет переопределять URL через заголовок запроса, то может оказаться возможным обойти контроль доступа, используя такой запрос:
Альтернативная атака связана с HTTP-методом, используемым в запросе. Описанные выше фронтенд-контроли ограничивают доступ на основе URL и HTTP-метода. Некоторые веб-сайты допускают разные HTTP-методы при выполнении действия. Если атакующий может использовать метод GET (или другой) для выполнения действий на ограниченном URL, он может обойти контроль доступа, реализованный на уровне платформы.
Нарушение контроля доступа из-за расхождений при сопоставлении URL
Веб-сайты могут различаться по строгости сопоставления пути входящего запроса с определенной конечной точкой. Например, они могут быть нечувствительны к регистру, поэтому запрос к /ADMIN/DELETEUSER все равно может быть сопоставлен с конечной точкой /admin/deleteUser. Если механизм контроля доступа реализован некорректно, он может считать это двумя разными конечными точками и в результате не применить корректные ограничения. Аналогичные расхождения могут возникать, если разработчики, использующие фреймворк Spring, включили опцию useSuffixPatternMatch. Это позволяет путям с произвольным расширением файла сопоставляться с эквивалентной конечной точкой без расширения файла. Другими словами, запрос к /admin/deleteUser.anything все равно будет соответствовать шаблону /admin/deleteUser. До Spring 5.3 эта опция включена по умолчанию.
В других системах вы можете столкнуться с различиями в том, считаются ли /admin/deleteUser и /admin/deleteUser/ разными конечными точками. В этом случае вы можете обойти контроль доступа, добавив завершающий слэш к пути.
Горизонтальная эскалация привилегий
Горизонтальная эскалация привилегий происходит, если пользователь получает доступ к ресурсам, принадлежащим другому пользователю такого же типа, вместо своих собственных ресурсов. Например, если сотрудник может получить доступ к записям других сотрудников, а не только к своим, то это горизонтальная эскалация привилегий.
Атаки горизонтальной эскалации привилегий могут использовать методы эксплуатации, схожие с вертикальной эскалацией. Например, пользователь может получить доступ к своей странице аккаунта по следующему URL:
Если атакующий изменит значение параметра id на идентификатор другого пользователя, он может получить доступ к странице аккаунта этого пользователя и к связанным с ней данным и функциям.
В некоторых приложениях эксплуатируемый параметр не имеет предсказуемого значения. Например, вместо инкрементного числа приложение может использовать глобальные уникальные идентификаторы (GUID) для идентификации пользователей. Это может помешать атакующему угадывать или предсказывать идентификатор другого пользователя. Однако GUID других пользователей могут раскрыться в других местах приложения, где упоминаются пользователи, например в пользовательских сообщениях или отзывах.
В некоторых случаях приложение действительно обнаруживает, что пользователю не разрешен доступ к ресурсу, и возвращает редирект на страницу входа. Однако ответ, содержащий редирект, может все еще включать некоторые конфиденциальные данные, принадлежащие целевому пользователю, поэтому атака все равно может быть успешной.
Горизонтальная эскалация в вертикальную
Часто горизонтальную эскалацию привилегий можно превратить в вертикальную, скомпрометировав более привилегированного пользователя. Например, горизонтальная эскалация может позволить атакующему сбросить или перехватить пароль другого пользователя. Если атакующий нацелится на администратора приложения и скомпрометирует его аккаунт, он сможет получить административный доступ и таким образом выполнить вертикальную эскалацию привилегий.
Атакующий может получить доступ к странице аккаунта другого пользователя, используя технику подмены параметров, уже описанную для горизонтальной эскалации привилегий:
Если целевой пользователь — администратор приложения, то атакующий получит доступ к административной странице аккаунта. Эта страница может раскрывать пароль администратора или предоставлять возможность его изменить, либо давать прямой доступ к привилегированной функциональности.
Небезопасные прямые ссылки на объекты
Небезопасные прямые ссылки на объекты (IDOR) — это подкатегория уязвимостей контроля доступа. IDOR возникают, если приложение использует введенные пользователем данные для прямого доступа к объектам, и атакующий может изменить ввод, чтобы получить несанкционированный доступ. Популярность они получили благодаря включению в OWASP 2007 Top Ten. Это лишь один из множества примеров ошибок реализации, которые могут дать возможность обходить контроль доступа.
Уязвимости контроля доступа в многошаговых процессах
Многие веб-сайты реализуют важные функции через серию шагов. Это типично, когда:
Необходимо собрать разнообразные входные данные или варианты.
Пользователю нужно просмотреть и подтвердить сведения перед выполнением действия.
Например, административная функция обновления данных пользователя может включать следующие шаги:
Загрузить форму, содержащую сведения о конкретном пользователе.
Отправить изменения.
Просмотреть изменения и подтвердить.
Иногда веб-сайт уделяет серьезное внимание контролю доступа на некоторых из этих шагов, но игнорирует другие. Представьте веб-сайт, где контроль доступа корректно применяется к первому и второму шагам, но не к третьему. Веб-сайт предполагает, что пользователь попадет к шагу 3 только после того, как он уже прошел первые шаги, которые правильно контролируются. Атакующий может получить несанкционированный доступ к функции, пропустив первые два шага и отправив напрямую запрос для третьего шага с требуемыми параметрами.
Контроль доступа на основе Referer
Некоторые веб-сайты основывают контроль доступа на заголовке Referer, переданном в HTTP-запросе. Заголовок Referer может добавляться браузерами в запросы, чтобы указать, какая страница инициировала запрос.
Например, приложение строго применяет контроль доступа к основной административной странице по адресу /admin, но для подстраниц, таких как /admin/deleteUser, проверяет только заголовок Referer. Если Referer содержит основной URL /admin, то запрос разрешается.
В этом случае заголовок Referer полностью контролируется атакующим. Это означает, можно подделывать прямые запросы к чувствительным подстраницам, указывая требуемый заголовок Referer, и получать несанкционированный доступ.
Контроль доступа на основе местоположения
Некоторые веб-сайты применяют контроль доступа на основе географического местоположения пользователя. Это может применяться, например, к банковским приложениям или медиа-сервисам, где действуют законодательные или бизнес-ограничения. Такой контроль доступа часто можно обойти с помощью веб-прокси, VPN или манипуляций с клиентскими механизмами геолокации.
Как предотвращать уязвимости контроля доступа
Уязвимости контроля доступа можно предотвращать, применяя многослойную защиту и следующие принципы:
Никогда не полагайтесь только на сокрытие для контроля доступа.
Если ресурс не предназначен для публичного доступа, по умолчанию запрещайте доступ.
Где возможно, используйте единый механизм контроля доступа на уровне всего приложения.
На уровне кода сделайте обязательным для разработчиков явное объявление разрешенного доступа для каждого ресурса и по умолчанию запрещайте доступ.
Тщательно проводите аудит и тестируйте механизмы контроля доступа, чтобы убедиться, что они работают как задумано.
Last updated