Перечень рекомендаций по защите API с пояснениями
Cледует избегать использования «базовой аутентификации» и использовать любые другие стандартные методы аутентификации, например OAuth, JWT и т. д.
Базовая аутентификация – это простой метод аутентификации пользователя путем передачи учетных данных пользователя в виде обычного текста по сети. Этот метод по своей сути небезопасен, и его следует избегать, когда это возможно.
Существует несколько причин, по которым следует избегать базовой аутентификации и заменять ее более безопасными методами аутентификации:
-
Отсутствие конфиденциальности: базовая аутентификация передает учетные данные пользователя (имя пользователя и пароль) в виде обычного текста по сети. Это означает, что любой, кто перехватывает трафик, может легко считать учетные данные и получить доступ к учетной записи пользователя.
-
Отсутствие целостности: базовая аутентификация не обеспечивает какого-либо механизма, гарантирующего, что передаваемые данные не были подделаны или изменены при передаче. Это означает, что злоумышленник может изменить трафик, чтобы получить доступ к учетной записи пользователя или выполнить другие вредоносные действия.
-
Недостаточная надежность аутентификации: базовая аутентификация полагается исключительно на учетные данные пользователя для их аутентификации. Это означает, что если злоумышленнику удастся получить учетные данные пользователя (например, с помощью фишинга или социальной инженерии), он сможет легко получить доступ к учетной записи пользователя.
-
Нет поддержки многофакторной аутентификации: базовая аутентификация не поддерживает многофакторную аутентификацию (MFA), которая является важным элементом безопасности и обеспечивает дополнительный уровень защиты от несанкционированного доступа.
И наоборот, другие методы аутентификации, такие как OAuth, OpenID Connect и SAML, предоставляют более безопасные и надежные методы аутентификации. Эти методы обычно используют зашифрованные протоколы для защиты учетных данных пользователя, предоставляют механизмы проверки целостности данных и поддерживают MFA. В результате они гораздо более безопасны и надежны, чем базовая аутентификация, и их следует использовать всегда, когда это возможно.
Используйте стандартные механизмы аутентификации для создания токенов, хранения учетных данных и аутентификации пользователей
Вот несколько примеров устоявшихся механизмов аутентификации, которые вы можете использовать вместо того, чтобы изобретать велосипед:
-
OAuth: OAuth – это широко используемый открытый стандарт авторизации, который позволяет пользователям предоставлять сторонним приложениям доступ к своим ресурсам, не передавая свои учетные данные. Он обычно используется веб-службами и API, чтобы пользователи могли входить в систему, используя свои учетные записи в социальных сетях или другие сторонние учетные записи.
-
OpenID Connect: OpenID Connect – это протокол аутентификации, созданный на основе OAuth 2.0, который позволяет пользователям проходить аутентификацию на нескольких веб-сайтах и в приложениях, используя один набор учетных данных. Он обычно используется для единого входа (SSO) на нескольких веб-сайтах и в приложениях.
-
SAML: Security Assertion Markup Language (SAML, язык разметки декларации безопасности) – это стандарт на основе XML для обмена данными аутентификации и авторизации между сторонами. Он обычно используется для единого входа в нескольких доменах или организациях.
-
Алгоритмы хеширования паролей: алгоритмы хеширования паролей, такие как
bcryptиscrypt, широко используются для безопасного хранения и защиты паролей пользователей. Эти алгоритмы гарантируют, что даже если злоумышленник получит доступ к базе данных паролей, он не сможет легко восстановить пароли. -
Двухфакторная аутентификация (2FA): 2FA – это механизм аутентификации, который требует от пользователей предоставления двух форм идентификации для доступа к своим учетным записям. Обычно это включает в себя что-то, что знает пользователь (например, пароль) и что-то, что у него есть (например, мобильное устройство или ключ безопасности). Многие сервисы и приложения теперь предлагают 2FA в качестве дополнительной меры безопасности.
Используйте максимальное число неудачных попыток ('Max Retry') и функционал, осуществляющий блокировку, при определённом числе неудачных входов в систему
Максимальное число неудачных попыток и блокировка часто используются в механизмах входа в систему для повышения безопасности и предотвращения атак методом «грубой силой»
Максимальное число неудачных попыток: Функционал «максимальное число неудачных попыток» ограничивает количество попыток входа в систему, которые пользователь может сделать в течение определенного периода времени. После определенного количества неудачных попыток входа в систему блокируется учетная запись пользователя на определенный период времени, обычно на несколько минут или часов. Это помогает предотвратить атаки методом «грубой силой», когда злоумышленник пытается угадать пароль пользователя, предпринимая повторные попытки входа в систему. Ограничивая количество попыток, система может замедлить или предотвратить такие атаки.
Блокировка: Функционал «блокировки» предполагает блокировку IP-адресов или учетных записей пользователей, у которых превышено максимальное количество неудачных попыток входа в систему в течение определенного периода времени. Заблокированным IP-адресам или учетным записям пользователей запрещается дальнейший вход в систему в течение определенного периода времени, обычно нескольких минут или часов. Это помогает предотвратить атаки методом «грубой силой», а также обеспечивает механизм, предотвращающий повторные попытки злоумышленников получить доступ к учетной записи или системе.
Шифрование конфиденциальных данных важно для их защиты от несанкционированного доступа, кражи и использования
Шифрование – это процесс преобразования простых текстовых данных в зашифрованный текст, который может быть расшифрован только тем, у кого есть ключ дешифрования. Это затрудняет злоумышленникам доступ к конфиденциальным данным, даже если они могут их перехватить или получить к ним несанкционированный доступ.
Для шифрования конфиденциальных данных вы можете использовать такие алгоритмы шифрования, как AES или RSA, а также надежную систему управления ключами, обеспечивающую безопасное хранение и управление ключами. Кроме того, вы можете реализовать другие меры безопасности, такие как контроль доступа, брандмауэры и системы обнаружения хакерских атак, для дальнейшей защиты конфиденциальных данных.
Используйте такой «JWT секретный ключ» ('JWT Secret'), который усложнит его подбор атакой методом «грубой силой» (полным перебором)
Позаботьтесь о хорошем секретный ключе для JWT для защиты от внесения злонамеренных изменений в токен (подделки токена), а также для предотвращения атак методом «грубой силы»
Надёжный секретный ключ должен генерироваться случайным образом, быть длинным и сложным, храниться в надежном месте и периодически меняться.
Не извлекайте алгоритм из заголовка запроса, используйте бэкенд
Извлечение алгоритма из заголовка JWT токена может представлять угрозу безопасности, поскольку злоумышленник может изменить алгоритм и потенциально получить несанкционированный доступ. Поэтому рекомендуется проверять алгоритм, используя бэкенд, а не извлекать его из заголовка. Это поможет гарантировать, что алгоритм, используемый для подписи и проверки токена, безопасен и не был подделан.
Срок действия токена должен быть выбран в соответствии с требованиями к системе и не превышать объективно необходимый срок, чтобы уменьшить окно уязвимости системы, ограничить последствия кражи токенов и повысить общую безопасность
Установка короткого срока действия токена (TTL, RTTL) важна в целях безопасности, поскольку уменьшает окно уязвимости, ограничивает влияние кражи токена и повышает общую безопасность. Однако срок действия должен быть сбалансирован с удобством использования, поскольку слишком короткий срок может доставить неудобства пользователям и снизить производительность.
Избегайте хранения конфиденциальных данных в полезной нагрузке JWT
Хранение конфиденциальных данных в полезной нагрузке JWT токена может увеличить риск утечки данных и других ситуаций, связанных с нарушением безопасности. Если злоумышленник сможет раздобыть или подделать токен, он потенциально может получить доступ к конфиденциальным данным, хранящимся в полезных данных.
Избегайте хранения больших полезных нагрузок в JWT токенах
Небольшая полезная нагрузка может снизить накладные расходы при передаче по сети, повысить скорость обработки и снизить риск атак, направленных на перегрузку системы.
Ограничивайте число запросов (ограничение пропускной способности, throttling), чтобы избежать DDoS атак / атакой методом «грубой силой»
Ограничивайте число запросов (ограничение пропускной способности, throttling), чтобы избежать DDoS атак / атакой методом «грубой силой»
Ограничение числа запросов посредством регулирования пропускной способности важно для предотвращения DDoS-атак и атак методом «грубой силой». DDoS-атаки перегружают сервер слишком большим количеством запросов, в то время как атаки методом «грубой силы» пытаются угадать учетные данные пользователя посредством нескольких попыток входа в систему.
Регулировка пропускной способности ограничивает количество запросов, которые могут быть отправлены в течение определенного периода времени, что усложняет злоумышленникам проведение атак такого типа. Это может защитить систему от перегрузки и предотвратить несанкционированный доступ злоумышленников.
Используйте HTTPS на стороне сервера и безопасные алгоритмы шифрования
Убедитесь, что ваш API сервер использует HTTPS вместо HTTP. HTTPS – это безопасный протокол, который шифрует данные при передаче, что затрудняет перехват и чтение конфиденциальной информации злоумышленниками. Чтобы реализовать HTTPS, вам необходимо получить сертификат SSL/TLS и настроить сервер на использование HTTPS.
HTTPS использует шифры для шифрования данных при передаче. Важно выбирать безопасные шифры, устойчивые к атакам и обеспечивающие надежное шифрование. Примерами чаще всего используемых безопасных шифров для обмена ключами являются AES, ChaCha20 и ECDHE. Обязательно отключите слабые и устаревшие алгоритмы шифрования, такие как RC4 и TLS 1.0/1.1, которые уязвимы для атак.
Используйте заголовок HSTS с SSL, чтобы избежать атак SSL Strip
SSL Strip – это тип атаки, когда злоумышленник перехватывает трафик между клиентом и сервером, который должен быть защищен с помощью SSL/TLS-шифрования, и понижает уровень соединения до простого текстового (незашифрованного) HTTP-соединения. Этот тип атаки может остаться незамеченным пользователем, поскольку злоумышленник может перенаправить пользователя на похожий веб-сайт, который также использует HTTP вместо HTTPS.
При SSL Strip атаке злоумышленник является «человеком посередине» (MITM) между клиентом и сервером. Когда клиент инициирует соединение с сервером, злоумышленник перехватывает SSL/TLS трафик и удаляет или заменяет HTTPS ссылки HTTP ссылками. Это может заставить пользователя думать, что он использует безопасное соединение, хотя на самом деле это не так. Затем злоумышленник может отслеживать и манипулировать данными, передаваемыми между клиентом и сервером.
HSTS заголовок – это заголовок безопасности, который указывает браузерам получать доступ к сайту только через HTTPS. Этот заголовок используется для предотвращения SSL Strip атак. Рекомендуется использовать заголовок HSTS с SSL.
Отключите вывод содержимого каталогов
Вывод содержимого каталогов – это функция веб-серверов, которая позволяет пользователям просматривать содержимое каталога на сервере. По умолчанию на веб-серверах часто включен вывод содержимого каталогов, а это означает, что любой, у кого есть доступ к серверу, может видеть все файлы и каталоги в данной папке.
Отключение вывода содержимого каталогов важно для безопасности API, поскольку оно не позволяет злоумышленникам получить доступ к конфиденциальным файлам и каталогам на сервере. Если вывод содержимого каталогов включен и злоумышленник получает доступ к серверу, он может легко просмотреть и загрузить любые файлы, которые не защищены должным образом. Отключив вывод содержимого каталогов, вы можете гарантировать, что только авторизованные пользователи смогут получить доступ к файлам и каталогам на сервере.
Приватные API должны быть доступны только для «безопасного» списка IP-адресов
Приватные API должны быть доступны только с IP-адресов, включенных в «безопасный» список, чтобы гарантировать, что только авторизованные пользователи или системы могут получить доступ к API. Предоставляя доступ только с определенных IP-адресов, вы можете предотвратить несанкционированный доступ из внешних сетей или злоумышленников. Это может помочь защитить конфиденциальные данные и предотвратить такие атаки, как DDoS или атаки методом «грубой силой». Кроме того, предоставление доступа только IP-адресам из «безопасного» списка может помочь обеспечить надежность и производительность API, предотвращая чрезмерный трафик из неавторизованных источников.
Проверяйте 'redirect_uri' на стороне сервера чтобы предотвратить Open Redirect атаки
В OAuth redirect_uri – это параметр, указывающий URI (унифицированный идентификатор ресурса), на который сервер авторизации должен перенаправить пользователя после завершения аутентификации. Redirect_uri часто используется в потоке OAuth для возврата кода авторизации или токена доступа клиентскому приложению.
Важно проверять redirect_uri на стороне сервера, чтобы предотвратить такие атаки, как Open Redirect атаки. При Open Redirect атаке злоумышленник может изменить параметр redirect_uri, чтобы перенаправить пользователя на вредоносный веб-сайт. Проверив redirect_uri на стороне сервера, вы можете убедиться, что URI перенаправления является правильным и авторизованным URI для клиентского приложения.
Проверка redirect_uri на стороне сервера также может предотвратить другие типы атак, такие как фишинговые атаки или атаки с подделкой межсайтовых запросов (CSRF). Проверив, что redirect_uri соответствует заранее определенному списку авторизованных URI, вы можете гарантировать, что пользователь будет перенаправлен на сайт, которому можно доверять, после завершения аутентификации.
Не используйте 'response_type=token', а вместо него применяйте поток с кодом подтверждения
В OAuth response_type=token – это метод получения токена доступа непосредственно из конечной точки авторизации без использования кода авторизации. Этот метод известен как Implicit Grant Flow (поток неявного доступа).
Однако рекомендуется избегать использования response_type=token и вместо этого использовать Authorization Code Grant Flow (поток с кодом подтверждения), при котором клиент обменивает код авторизации на токен доступа. Это связано с тем, что поток неявного доступа может быть менее безопасным, чем поток с кодом подтверждения.
Причина этого в том, что токен доступа возвращается непосредственно клиенту во фрагменте URL-адреса URI, который используется для редиректа. Это означает, что токен доступа может быть перехвачен или обнаружен в истории браузера или журналах сервера. Напротив, в потоке с кодом подтверждения токен доступа возвращается клиенту только после того, как клиент обменял код авторизации на токен, используя безопасную связь между серверами.
Таким образом, используя поток с кодом подтверждения вместо потока неявного доступа, вы можете защитить токен доступа от обнаружения или перехвата злоумышленниками.
Используйте параметр 'state' для предотвращения CSRF атак
В OAuth параметр state используется в качестве меры безопасности для предотвращения CSRF атак (подделка межсайтовых запросов). CSRF атаки возникают, когда вредоносный веб-сайт или сценарий отправляет запрос на настоящий веб-сайт от имени пользователя, который на момент отправки уже авторизирован на нём.
Чтобы предотвратить CSRF атаки, используется параметр state для хранения уникального значения, которое генерируется клиентским приложением перед инициированием запроса на авторизацию. Это значение добавляется в запрос авторизации, а затем проверяется сервером авторизации, когда пользователь перенаправляется обратно в клиентское приложение. Если значение state в ответе на авторизацию совпадает со значением state, отправленным клиентским приложением, авторизация считается действительной, и токен доступа возвращается клиенту.
Используя параметр state, вы можете предотвратить перехват или изменение запроса на авторизацию злоумышленниками при передаче, поскольку уникальное значение state известно только клиентскому приложению и серверу авторизации. Это может обеспечить целостность и безопасность OAuth потока и защитить от CSRF атак.
У вас должен быть «набор запрашиваемых у пользователя разрешений на доступ к данным» (scope) по умолчанию и необходимо проверять его для каждого приложения
У вас должен быть scope по умолчанию и необходимо проверять его для каждого приложения
В OAuth scopes используются для определения набора разрешений и уровней доступа, которые предоставляются клиентским приложениям при доступе к защищенным ресурсам от имени пользователя.
Лучшей практикой является использование scope по умолчанию, а также проверка его для каждого приложения, поскольку это помогает гарантировать, что клиентские приложения имеют доступ только к тем ресурсам, которые им необходимы, и что пользователи предоставляют только необходимые разрешения каждому приложению.
Scope по умолчанию – это набор разрешений, которые предоставляются всем клиентским приложениям по умолчанию, если иное не указано пользователем. Имея scope по умолчанию, вы можете гарантировать, что ко всем приложениям применяются одинаковые базовые параметры безопасности и контроля доступа.
Помимо наличия scope по умолчанию, также рекомендуется проверять scope для каждого приложения. Это означает, что когда пользователь предоставляет доступ к приложению, сервер должен проверить, является ли запрошенный scope допустимым и подходящим для этого приложения. Это может помочь предотвратить запрос вредоносными приложениями чрезмерных разрешений или несанкционированный доступ к пользовательским данным.
Имея scope по умолчанию и проверяя scope для каждого приложения, вы можете гарантировать, что OAuth поток безопасен и что клиентские приложения получают доступ только к тем ресурсам и разрешениям, которые им необходимы.
Проверьте для всех ли конечных точек с доступом только для аутентифицированных пользователей выполняется процесс аутентификации, чтобы избежать нарушения процесса аутентификации
Проверьте для всех ли конечных точек с доступом только для аутентифицированных пользователей выполняется процесс аутентификации, чтобы избежать нарушения процесса аутентификации
Выявляя и исправляя нарушененные процессы аутентификации, API может предотвратить такие атаки, как методом «грубой силы», подстановки учетных данных, перехвата сеанса и другие атаки, связанные с аутентификацией. Это поможет обеспечить безопасность системы и защиту конфиденциальных данных.
Избегайте использования идентификатора пользователя в URL-адресах ресурсов, например, users/242/orders
Избегайте использования идентификатора пользователя в URL-адресах ресурсов, например,
users/242/orders
Следует избегать использования собственного идентификатора пользователя. Используйте /me/orders вместо /user/654321/orders. Это поможет избежать риска раскрытия личного идентификатора пользователя, который может быть использован для дальнейших атак.
Используйте UUID вместо целых чисел с автоматическим инкрементом. UUID глобально уникальны и не являются последовательными. Их также сложнее угадать, чем последовательные целые числа
Использование UUID вместо автоинкрементных идентификаторов не позволяет злоумышленникам угадывать или перебирать идентификаторы ресурсов. UUID генерируются случайным образом и содержат 128 бит энтропии, поэтому злоумышленникам практически невозможно их угадать. Напротив, значения автоинкрементных идентификаторов можно легко предсказать или вычислить, что позволяет злоумышленникам получить доступ или манипулировать ресурсами, к которым у них не должно быть доступа. Кроме того, использование UUID может помочь предотвратить утечку информации, скрывая порядок создания ресурсов или доступа к ним.
Отключите парсинг поступающих извне XML сущностей, если вы парсите XML, чтобы избежать XXE атак
Если XML парсер уязвим для XXE атак, злоумышленник может использовать эту уязвимость для чтения файлов на сервере, выполнения SSRF атак и многого другого. Это может привести к раскрытию конфиденциальной информации, отказу в обслуживании и другим атакам.
XXE атака (XML External Entity, инъекция внешних сущностей XML) – это тип атаки, нацеленной на приложения, которые анализируют XML, поступающие из ненадежных источников. В ходе этой атаки злоумышленник внедряет вредоносное XML данные. Они могут содержать внешние объекты, которые злоумышленник может использовать для получения конфиденциальных данных, выполнения удаленного кода или запуска атак типа «отказ в обслуживании». XXE атаки можно предотвратить, отключив обработку внешних сущностей или проверив и очистив входные данные XML перед их анализом.
Отключите расширения, позволяющие обрабатывать поступающие извне сущности, если вы используете XML, YML или любой другой язык
Отключите расширения, позволяющие обрабатывать поступающие извне сущности, если вы используете XML, YML или любой другой язык
Отключение расширений, позволяющих обрабатывать поступающие извне сущности, важно при использовании XML, YAML или любого другого языка, который разрешает сущности, поскольку это помогает предотвратить XXE атаки (XML External Entity, инъекция внешних сущностей XML) или внедрение YAML тегов. В ходе этих атак злоумышленник обычно вставляет во входные данные какой-то собственный код для выполнения атак на приложение. Отключив расширение для работы с сущностями, входными данными нельзя манипулировать таким образом, что снижает риск этих атак.
Используйте CDN для загрузки файлов
Использование Content Delivery Network (CDN, сети доставки содержимого) для загрузки файлов может сделать API более безопасным, разгружая трафик загрузки файлов с API сервера и снижая риск DDoS-атак.
Избегайте ситуаций, когда часть HTTP запросов не может быть обработана из-за большого объёма данных, перенеся тяжелые HTTP операции в фоновые или асинхронные задачи
Невозможность обработки HTTP запросов – распространенная проблема в веб-приложениях. Она возникает, когда приложение не может обрабатывать входящие HTTP-запросы из-за большого количества запросов или большого объёма данных. Это может привести к тому, что приложение перестанет отвечать на запросы и произойдёт сбой сервера. Этого можно избежать, переместив тяжелые HTTP операции в фоновые или асинхронные задачи. Вы можете использовать очередь сообщений для постановки запросов в очередь и обработки их в фоновом режиме. Это позволит приложению продолжать обработку других запросов, пока тяжелые операции выполняются в фоновом режиме.
Убедитесь, что режим отладки отключён на продакшене
Режим отладки – это функционал, который помогает разработчикам отлаживать свой код. Он не предназначен для использования в продакшене. Он может раскрыть конфиденциальную информацию о приложении и сервере, на котором работает. Обязательно отключите режим отладки в продакшене.
Используйте Non-Executable Stacks, чтобы не дать злоумышленникам выполнить код на вашем сервере
Под стеком обычно понимают стеку вызовов или стек выполнения. Это структура данных, используемая компьютерной программой для управления и отслеживания последовательности вызовов функций, локальных переменных и других связанных данных во время выполнения программы.
Non-Executable Stack (неисполняемый стек) — это механизм обеспечения защиты, который предотвращает выполнение вредоносного кода, не давая выполняться памяти стека как код. Это помогает предотвратить такие атаки, как атаки на переполнение буфера, когда злоумышленник пытается перезаписать адрес возврата в стеке, чтобы перенаправить программу на выполнение вредоносного кода. Используя Non-Executable Stacks, программа может хранить стек отдельно от исполняемого кода и помогать предотвращать атаки такого типа.
Используйте HTTP-метод, соответствующий осуществляемой операции: GET (для чтения), POST (для создания), PUT/PATCH (для замены/обновления) и DELETE (для удаления записи) и отвечайте кодом 405 Method Not Allowed, если какой-то метод нельзя использовать для запрошенного ресурса.
Проверяйте заголовок
Content-typeв запросе, чтобы предотвратить XSS-атаки
Проверка заголовка Content-Type в запросе может повысить безопасность API, гарантируя, что данные запроса имеют ожидаемый формат, и снижая риск атак, таких как инъекционная атака или межсайтовый скриптинг (XSS).
Проверяйте вводимые пользователем данные, чтобы избежать распространенных уязвимостей
Вводимые пользователем данные являются распространенным источником уязвимостей в веб-приложениях. Это связано с тем, что вводимые пользователем данные часто не проверяются, не очищаются и не экранируются должным образом перед использованием в веб-приложении. Это может позволить злоумышленнику манипулировать входными данными и выполнить вредоносный код или вызвать неожиданное поведение приложения.
Используйте стандартный заголовок
Authorizationдля отправки токенов вместо пользовательских заголовков или параметров в запросе/его теле
Отправлять токены в параметрах запроса или его теле обычно не рекомендуется, поскольку эти параметры могут регистрироваться или кэшироваться различными системами, включая веб-серверы, прокси-серверы и шлюзы. Это потенциально может привести к раскрытию конфиденциальных данных, включая токены аутентификации.
Кроме того, отправка токенов в параметрах запроса или его теле может сделать их более уязвимыми для атак с подделкой межсайтовых запросов (CSRF). При CSRF атаке злоумышленник может обманом заставить пользователя отправить запрос, включающий его токен аутентификации, который злоумышленник затем может использовать, чтобы выдать себя за пользователя и получить доступ к его учетной записи.
Напротив, использование заголовка Authorization для отправки токенов гарантирует, что токены не регистрируются и не кэшируются промежуточными системами, а также может защитить от CSRF атак, позволяя серверу проверить токен перед обработкой запроса.
Используйте шифрование на стороне сервера, а не шифрование на стороне клиента
Использовать шифрование на стороне клиента не рекомендуется, поскольку кодовую базу на стороне клиента можно легко воссоздать путём ревёрс-инжиниринга, что может привести к раскрытию алгоритмов шифрования.
Используйте API шлюз для кэширования, правил, ограничивающих число запросов к ресурсу за определённый период времени и т. д.
Используйте шлюз API для кэширования, правил, ограничивающих число запросов к ресурсу за определённый период времени и других функций обеспечения защиты приложения
API шлюз может сделать ваши API более безопасным, предоставляя централизованную точку контроля для управления и защиты API трафика. Ниже приведено несколько способов, с помощью которых API шлюз может улучшить безопасность API:
-
Аутентификация и авторизация: API шлюзы могут осуществлять аутентификацию и авторизацию пользователей, снижая нагрузку на отдельные API и улучшая согласованность во всей организации. Сюда могут входить такие технические решения, как проверка JWT, OAuth и другие механизмы аутентификации.
-
Фильтрация трафика и ограничение числа запросов: API шлюз может обеспечивать фильтрацию трафика и ограничение числа запросов для защиты API от DDoS-атак, атак методом «грубой силой» и других типов злоумышленного использования.
-
Шифрование и дешифрование: API шлюз может выполнять шифрование и дешифрование конфиденциальных данных для защиты от утечки и кражи данных.
-
Логирование и мониторинг: API шлюз может обеспечить централизованное логирование и мониторинг трафика API, помогая выявлять угрозы нарушения безопасности и другие проблемы и реагировать на них.
-
Интеграция с средствами обеспечения безопасности: API шлюз можно интегрировать с такими средствами обеспечения безопасности, как WAF, SIEM и другими инструментами, чтобы обеспечить дополнительные уровни защиты.
Отправляйте заголовок
X-Content-Type-Options: nosniff
Вам следует отправить заголовок X-Content-Type-Options: nosniff, чтобы предотвратить атаки, связаные с анализом MIME типа в вашем веб-приложении. Этот заголовок сообщает браузеру не переопределять тип содержимого ответа, даже если он не является ожидаемым типом. Например, если злоумышленнику удастся загрузить HTML-файл с замаскированным расширением, например .jpg, сервер всё равно может отправить правильный заголовок Content-type для HTML-файла. Однако некоторые браузеры могут игнорировать этот заголовок и пытаться «проанализировать» Content-type на основе фактического содержимого файла, что приводит к потенциальной атаке с использованием межсайтового скриптинга (XSS).
Отправляя заголовок X-Content-Type-Options: nosniff, вы указываете браузеру всегда доверять предоставленному Content-type и не пытаться анализировать тип контента. Это помогает снизить риск того, что злоумышленники воспользуются несоответствием типов контента для доставки вредоносного содержимого ничего не подозревающим пользователям.
Отправляйте заголовок
X-Frame-Options: Deny
Заголовок X-Frame-Options предотвращает возможность отображения страницы в iframe, что обычно используется при кликджекинг атаках. Установив для этого заголовка значение Deny, вы указываете браузеру не отображать страницу ни в каком iframe. Это помогает предотвратить внедрение страницы в веб-сайт злоумышленника и снижает риск атак с использованием кликджекинга.
Отправляйте заголовок
Content-Security-Policy: default-src 'none'
Отправка заголовка Content-Security-Policy: default-src 'none' – это передовой метод обеспечения безопасности, который помогает предотвратить атаки с использованием межсайтового скриптинга (XSS). Этот заголовок сообщает браузеру, что он не должен разрешать загрузку каких-либо ресурсов из внешних источников, таких как скрипты, таблицы стилей или изображения. Он разрешает только ресурсы, которые явно внесены в белый список в заголовке CSP, например скрипты или таблицы стилей, размещенные в вашем собственном домене. Это может помочь предотвратить внедрение злоумышленниками кода на ваши веб-страницы с помощью XSS-атак, поскольку браузер не будет выполнять какие-либо скрипты или загружать какие-либо ресурсы, которые явно не разрешены политикой CSP.
Удалите заголовки, которые могут облегчить идентификацию сервера (например,
x-powered-byи т. д.), из HTTP-запроса
Эти заголовки можно помочь идентификацировать веб-сервер и его версию. Такая информация может быть использована злоумышленниками для выявления уязвимостей веб-сервера и их вредноносной эксплуатации.
Всегда принудительно задавайте заголовок
Content-Typeдля соответствующего MIME типа
Важно принудительно задавать Content-Type для безопасности API, поскольку это гарантирует, что клиент и сервер обмениваются передаваемыми данными во взаимно согласованном формате. Это может предотвратить такие атаки, как подмена или внедрение контента, когда злоумышленник пытается обманом заставить сервер обработать вредоносный контент, маскируя его другим типом. Принудительно задавая определенный формат Content-Type сервер может проверить, что получаемые им данные являются неподдельными и безопасными для обработки. Кроме того, принудительное указание Content-Type может помочь предотвратить определенные типы ошибок синтаксического анализа, которыми могут воспользоваться злоумышленники.
Избегайте передачи в ответе конфиденциальных данных (учетных данных, аутентификационных токенов и т. д.)
Возвращайте только те данные, которые необходимы для работы клиента
Возврат только тех данных, которые необходимы для работы клиента, является важной передовой практикой для безопасности API. Это связано с тем, что ограничение объема возвращаемых данных уменьшает объем раскрываемой конфиденциальной информации. Возвращая только необходимые данные, вы можете предотвратить уязвимость системы безопасности, такие как утечка данных, инъекционные атаки и другие типы атак, которые основаны на раскрытии слишком большого количества информации. Кроме того, уменьшение объема возвращаемых данных может повысить производительность вашего API за счет сокращения объема данных, которые необходимо обрабатывать и передавать.
Возвращайте правильный код состояния в соответствии с тем как закончилось выполнение операции, например,
200 OK400 Bad Request401 Unauthorized405 Method Not Allowed... и т. д.
Возврат правильного кода состояния в соответствии с тем как закончилось выполнение операции важен для безопасности API, поскольку позволяет клиенту понять результат своего запроса и предпринять соответствующие действия. Например, если сервер возвращает код состояния 401 Unauthorized клиент понимает, что его учетные данные для аутентификации неверны, и может предложить пользователю повторно ввести свои данные для входа. Напротив, если сервер возвращает код состояния 200 OK, даже если запрос не выполнен, клиент может не осознавать наличие проблемы и потенциально может выполнить вредоносные действия или отобразить неверные данные. Выдача правильных кодов состояния может помочь предотвратить возникновение уязвимостей в системе безопасности и повысить общую надежность и удобство использования API.
Проверяйте программную архитектуру и реализацию с помощью unit/интеграционных тестов
Unit и интеграционное тестирование может помочь выявить уязвимости в коде и архитектуре API, такие как ошибки при проверке вводимых данных, недостатки аутентификации и авторизации, а также другие проблемы, связанные с безопасностью. Выполняя комплексное тестирование, разработчики могут гарантировать, что API работает должным образом и что он защищен от распространенных атак, таких как инъекционные атаки, межсайтовый скриптинг и других средств эксплуатации уязвимостей. Надлежащее тестирование также может помочь выявить и устранить узкие места в производительности, улучшить масштабируемость и надежность, а также обеспечить общее качество API.
Используйте сode review (рецензирование кода, обзор кода, ревизия кода) и не полагайтесь только на себя
Используйте сode review и не полагайтесь только на себя
Наличие хорошего процесса рецензирования кода позволяет другим членам команды просматривать код и выявлять потенциальные проблемы безопасности или уязвимости. В процессе рецензирования кода они проверяют код, чтобы убедиться, что он соответствует передовым практикам и является безопасным. Не полагайтесь только на себя; разработчик, написавший код, не должен быть единственным, кто несет ответственность за его разрешение на выливку в продакшен. Это помогает выявить потенциальные ошибки или упущения до развертывания кода, снижая риск брешей в системе безопасности или других проблем.
Постоянно осуществляйте анализ безопасности вашего кода
Непрерывный анализ безопасности помогает выявлять и устранять уязвимости, связанные с безопасностью в кодовой базе до того, как ими смогут воспользоваться злоумышленники. Он предполагает использование автоматизированных инструментов и ручных методов для сканирования кода на наличие потенциальных слабых мест, таких как небезопасные методы кодирования, ошибки конфигурации и устаревшие зависимости. Выявляя и устраняя уязвимости на ранних этапах цикла разработки, можно значительно снизить риск брешей в системе безопасности или потери данных, улучшая общий уровень безопасности системы.
Проверьте свои зависимости на наличие известных уязвимостей и постоянно обновляйте их
Уязвимости в сторонних библиотеках и компонентах могут быть использованы злоумышленниками для получения доступа к вашей системе или данным. Эти уязвимости могут возникнуть из-за устаревших или небезопасных зависимостей, которые не были обновлены последними патчами для устранения ошибок защиты.
Регулярно проверяя уязвимости и обновляя зависимости, вы можете гарантировать, что ваш API не подвержен известным угрозам, связанным с нарушением безопасности. Это можно сделать с помощью автоматизированных инструментов или сервисов, которые сканируют вашу кодовую базу и предоставляют отчеты о любых уязвимостях, обнаруженных в ваших зависимостях. Своевременно устраняя эти уязвимости, вы можете снизить риск компрометации вашего API злоумышленниками.
Разработайте механизм для отката версии, развёрнутой на продакшене
Иногда развертывание новой версии API может привести к неожиданным ошибкам или проблемам, которые не были обнаружены во время тестирования. В таких случаях откат к предыдущей версии API может помочь смягчить последствия проблемы и восстановить работоспособность сервиса. Хорошо продуманное решение по откату может помочь сократить время пребывания в нерабочем состоянии и свести к минимуму влияние на пользователей.
Используйте централизованный доступ (логин) для всех сервисов и компонентов
Использование централизованного входа (логина) для всех сервисов и компонентов важно по нескольким причинам:
- Централизованный вход в систему позволяет вам управлять аутентификацией и авторизацией в одном месте, снижая риск возникновения брешей в системе безопасности или несогласованности между различными сервисами.
- Централизованный вход в систему обеспечивают единую точку входа, что позволяет вам легче контролировать доступ и отслеживать активность.
- Централизованный вход в систему упрощает применение политик безопасности для различных сервисов и компонентов, гарантируя, что только авторизованные пользователи смогут получить доступ к конфиденциальным данным или выполнить определенные действия.
Чтобы использовать централизованный вход в систему, вам необходимо настроить систему единого входа (SSO), которая позволит пользователям пройти аутентификацию один раз, а затем получать доступ к различным сервисам без необходимости повторного предоставления учетных данных. Это можно сделать с помощью таких протоколов, как OAuth или SAML, которые обеспечивают безопасную аутентификацию и авторизацию в различных приложениях и сервисах. После настройки вы можете использовать инструменты централизованного ведения логов, такие как стек ELK, Splunk или Graylog, для сбора логов из различных сервисов и компонентов и анализа их в одном месте. Это позволяет быстро выявлять угрозы безопасности или аномалии и реагировать на них.
Используйте агентов для отслеживания всех запросов, ответов и ошибок
Использование агентов для мониторинга всех запросов, ответов и ошибок позволяет отслеживать и обнаруживать любую аномальную активность или потенциальные атаки в режиме реального времени. Эти агенты можно настроить для отслеживания таких показателей, как время отклика, частота ошибок и характерные особенности использования приложения, что может помочь выявить любые аномалии, которые могут указывать на атаку. Отслеживание всех запросов и ответов, позволяет агентам вести сквозное наблюдение над поведением API, что может помочь выявить любые потенциальные уязвимости или слабые места в системе безопасности. Кроме того, агенты можно использовать для регистрации и анализа всех данных, проходящих через API, что может быть полезно для целей отладки и аудита.
Чтобы использовать агенты для мониторинга, вместе с API можно развернуть специальное решение для мониторинга. Это решение можно настроить для сбора данных из всех запросов и ответов, а также для анализа данных на предмет любых аномалий или проблем. Агенты могут быть реализованы с использованием различных инструментов и технологий мониторинга, таких как агенты для мониторинга производительности приложений (APM), мониторинга логов и мониторинга сети. Агенты должны быть настроены так, чтобы передавали оповещения членам команды службы безопасности в режиме реального времени при обнаружении какой-либо подозрительной активности, что позволит принять немедленные меры.
Используйте оповещения, отравляемые через SMS, Slack, электронную почту, Kibana, Cloudwatch и т. д.
Использование оповещений, отравляемые через различные каналы связи, таких как SMS, Slack, электронная почта, Kibana, Cloudwatch и т. д., может помочь вам быстро реагировать на любые проблемы или аномалии в вашей системе. Эти оповещения можно настроить так, чтобы они уведомляли вас в режиме реального времени о возникновении определенного события или условия, что позволяет вам принимать упреждающие меры для предотвращения времени пребывания в неработоспособном состоянии, потери данных или нарушений безопасности. Кроме того, оповещения могут предоставить ценную информацию о производительности системы и поведении пользователей, позволяя вам принимать обоснованные решения, касающиеся разработки и реализации вашего API.
Убедитесь, что вы не пишите в лог никакие конфиденциальные данные
Убедитесь, что вы не пишите в лог какие-либо конфиденциальные данные, такие как пароли, номера кредитных карт или личную информацию. Это связано с тем, что логи с конфиденциальными данными момогут попасть в руки злоумышленников, что позволит им получить несанкционированный доступ к вашей системе или данным. Кроме того, регистрация конфиденциальных данных может нарушать законы и нормативные требования о конфиденциальности данных и вас могут привлечь к юридической ответственности.
Используйте IDS и/или IPS системы для обнаружения и блокирования атак
Системы обнаружения вторжений (Intrusion detection systems, IDS) и системы предотвращения вторжений (Intrusion prevention systems, IPS) могут использоваться для обнаружения и блокирования атак. Эти системы можно настроить для мониторинга всего входящего и исходящего трафика и обнаружения любой подозрительной активности. Если обнаружена какая-либо подозрительная активность, системы можно настроить на блокировку трафика, предотвращая успешность атаки. IDS и IPS системы могут быть реализованы с использованием различных инструментов и технологий, таких как системы обнаружения вторжений в сеть (Network intrusion detection systems, NIDS), системы обнаружения вторжений на основе хоста (Host-based intrusion detection systems, HIDS) и системы предотвращения вторжений в сеть (Network intrusion prevention systems, NIPS). Эти системы можно развернуть вместе с API и настроить для мониторинга всего входящего и исходящего трафика. Системы можно настроить так, чтобы они в режиме реального времени оповещали членов команды службы безопасности при обнаружении какой-либо подозрительной активности, что позволяет принять немедленные меры.