Авторизация и аутентификация

Если приложение имеет различные типы доступа для различных типов пользователей, то есть когда речь идет об управлении доступом на основе ролей (Role Based Access Control, RBAC), необходимо определиться с ними на этапе разработки требований. Не следует менять их по мере разработки системы, так как это усложняет работу с ней. RBAC является частью авторизации (AuthZ).

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

СОВЕТ. Внедрите автоматизированный набор тестов, чтобы проверять соответствие реализации AuthZ. Автоматизация тестов позволит чаще проводить проверки AuthZ, чтобы убедиться в отсутствии случайных изменений.

Параметризированные запросы

При работе с базой данных приложение дает ей указание выполнить действия от его имени. Это может быть запрос на чтение, запись, обновление или удаление, но суть в том, что приложение обращается непосредственно к базе данных. Ни один человек или приложение не должны иметь возможность напрямую обращаться к вашей базе данных, кроме вашего приложения, вашей команды разработчиков программного обеспечения или вашего администратора базы данных. При атаке SQL или NoSQL злоумышленник пытается напрямую обратиться к базе данных, отправляя ей команды для выполнения нужных ему действий, а не запрограммированных инструкций. Такая атака называется инъекционной и является угрозой номер один по степени риска для любого веб-приложения (согласно Топ-10 OWASP, подробно описанному в главе 5).

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

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

Параметры URL

Злоумышленники, как и пользователи, имеют доступ к адресной строке в браузерах. Не помещайте переменные, которые имеют значение для вашего приложения, в параметры URL. Можно увеличить ID-номер, и, если приложение не было запрограммировано на такую ситуацию, пользователь увидит чужую учетную запись. Содержащиеся в параметрах URL-адреса конфиденциальные значения регистрируются, что также приводит к проблемам безопасности. Очень просто манипулировать значениями в параметрах URL, и оправдание «никто не должен был этого делать» не сработает для вашей команды реагирования на инциденты. Передавайте в параметрах URL только значения нулевой важности, например на каком языке пользователь хочет просматривать страницу. Никогда не передавайте ничего важного или конфиденциального.

Принцип наименьших привилегий

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

Несколько примеров реализации принципа наименьших привилегий:

Сервисная учетная запись, которая вызывает базу данных из приложения, должна иметь только права CRUD (CRUD – акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (англ. create), чтение (read), модификация (update), удаление (delete)), но никак не права владельца базы данных (DBO)).

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

Создание отдельной сервисной учетной записи для каждого используемого приложением API. Каждая из них должна иметь только те права, которые необходимы для выполняемых ею задач (например, только для команд «select» или «read», если предполагается, что она будет только возвращать данные, а не изменять их).

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

СОВЕТ. Реализацией принципа наименьших привилегий является использование во всех возможных случаях сервисной учетной записи с доступом только для чтения вместо учетной записи со всеми CRUD-правами.