Оригинальный адрес:API Security Best Practices
Оригинальный автор: Марк Мишон
Переводчик и корректор: HelloGitHub-Xiaoyu и HelloGitHub-Duck
Хотя API по существу использует их, но даже если пользователь API всего внутреннего персонала, он все еще может представить проблему безопасности. API Для решения проблем безопасности, в этой статье мы собрали серию наилучшей практики API, я надеюсь, что вы помните эти советы позже в защите безопасности API / веб-сервисов и защиты от вторжения, помогут вам.
1, используйте HTTPS
Сегодняшняя сеть Интернет больше не является прежней эпохой, и стандартный HTTP не может удовлетворить потребности веб-безопасности. В то время как основные поставщики браузеров начинают помечать URL-адреса, которые не используют уровень безопасности, ваш API может подумать о том, чтобы начать делать то же самое — используя HTTPS. HTTPS использует безопасность транспортного уровня (TLS) для шифрования передачи. Это означает, что HTTPS шифрует связь между клиентом и сервером. Для API HTTPS означает, что содержимое, отправляемое из API, защищено третьей стороной, но, что более важно, это означает, что учетные данные для доступа защищены.
2. Сертификация
Когда дело доходит до учетных данных, самый простой способ избежать случайного использования API — обеспечить надлежащую аутентификацию. Аутентификация определяет, можете ли вы получить доступ к API и как получить доступ к API.Даже бесплатный API, открытый для публики, теоретически должен рассмотреть возможность принятия стратегии аутентификации для обеспечения безопасности. С помощью аутентификации вы можете ограничить или удалить пользователей, злоупотребляющих вашим API, позволяя пользователям при необходимости сбросить свои учетные данные, сохраняя их в безопасности. Чтобы узнать больше об аутентификации API, вы можете прочитать«Три самых распространенных метода аутентификации».
3. Авторизация
Аналогичной функции аутентификации является авторизация. Разница между аутентификацией и авторизацией заключается в том, что аутентификация связана с тем, кто использует API, а авторизация касается того, к чему они могут получить доступ. Например, пользователям бесплатного плана может быть разрешен доступ только к части всех ваших API. Авторизация пользователя позволяет приложениям считывать данные своего профиля с социальных платформ, когда вы хотите интегрировать API-интерфейсы, такие как вход через социальные сети.
4. Безопасность конечных точек и ресурсов (авторизация на уровне объектов)
В общем, мы бы защищали конечные точки/конечные точки с помощью авторизации, но в долгосрочной перспективе нам необходимо защитить отдельные ресурсы. Безопасность отдельных ресурсов предотвращает доступ к данным из-за неправильно настроенной авторизации на уровне конечной точки. Кроме того, это означает, что сама конечная точка не ограничена типом пользователя, а скорее ресурс контролирует, кто может ее просматривать, а кто нет. (разрешения с точностью до URL)
5. Ограничение скорости
Когда дело доходит до безопасности, мы часто думаем о несанкционированном доступе. Конечно, то, как обрабатывать неправомерный доступ, также полезно для управления ресурсами. Ограничение скорости — это метод ограничения использования API. Он не только экономно защищает ресурсы, но и гарантирует, что сервер не будет перегружен определенным большим количеством запросов. Большинство методов ограничения скорости основаны на времени — обычно цикл выставления счетов устанавливается для обработки общего использования API, а «взрывные» методы используются для ограничения притока запросов. Если ты видишь429 Код состояния HTTP, указывая на то, что вы ограничены в скорости.
6. Проверьте и дезинфицируйте вход
Один из самых старых способов атаки веб-приложений является входным, а именно: то, как мы доступаем к данным, возможно, могут измениться, но необходимость проверки любого пользовательского ввода не изменилась. Валидация на стороне клиента помогает предотвратить ошибки и улучшить пользовательский опыт, но API также необходимо проверить перед выполнением операции на входе ввода и очистке (Sanitize) - стратегии очистки для удаления запроса вредоносного или недействительного кода. Проверка, необходимая для обеспечения соответствия данных об ожиданиях ресурсов, таких как: тип, форма, структура и даже пароли и другие факторы.
7. Раскрытие информации по запросу
Заманчиво использовать ярлыки для сопоставления моделей данных непосредственно с интерфейсами, но это не только приводит к длинным ответам, увеличивает использование полосы пропускания, но также предоставляет данные, к которым пользователям не нужен доступ. Например: а/userИнтерфейс должен возвращать информацию о пользователе. Может потребоваться только некоторая основная информация о пользователе без пароля/разрешений пользователя.
8. Настройка сообщений об ошибках
В дополнение к очистке входных данных для API необходимо также очистить информацию, сгенерированную из них. Сообщения об ошибках имеют решающее значение для понимания пользователями проблемы, но убедитесь, что конфиденциальные данные не утекли. Предоставление конечным пользователям подробной информации о внутренней структуре кода API облегчит действия злоумышленников, поэтому не забудьте настроить сообщения об ошибках, которые не только достаточно информативны, чтобы помочь пользователям в отладке, но и недостаточно информативны, чтобы сообщать о проблеме, раскрывающей внутреннюю работу и конфиденциальные данные приложения.
9. Не раскрывайте конфиденциальную информацию
Открытие API должно быть построено на защите конфиденциальных данных, следите за тем, чтобыJSON Web Tokenи раскрывать детали в кеше. Тело JWT (JSON Web Token) создает иллюзию безопасности, но на самом деле его легко расшифровать. Поэтому следует избегать JTW и кэшей, содержащих пользовательскую информацию, которую можно использовать для доступа к приложениям. Тот же совет относится и к URL-адресам: убедитесь, что строка запроса не раскрывает детали конфиденциальных данных.
10. Оцените зависимости
Мы не пишем код полностью сами во время разработки, и в большинстве случаев большая часть кода будет содержать библиотеки, промежуточное ПО и различные зависимости от внешних источников. Хотя в целом мы можем считать популярные пакеты проверенными в боевых условиях, даже это не означает, что эти зависимости полностью свободны от уязвимостей. Поэтому убедитесь, что вы оцениваете зависимости вашего API — хорошо ли они поддерживаются? Вы используете последнюю версию? В чем историческая проблема? Возможно, самое важное, о чем следует подумать, это: действительно ли вам нужна библиотека, чтобы делать то, что вы делаете?
11. Разрешить пользователям отслеживать и сбрасывать ключи аутентификации
Другим способом повышения безопасности API является разрешение пользователям сбросить свои учетные данные и использование монитора. Общая ошибка - не разрешать пользователям сбросить их ключ API. Если пользователь API случайно раскрывает свои ключи или вредоносные получают ключ, тогда проблема теперь напрямую повлияет на ваш API. Напротив, чтобы обеспечить безопасность, вы можете создать метод управления доступ к ним.
12. Сертификация в стандартизированных услугах
Мы видим, как гиганты API, такие как Google, Microsoft и Amazon, стандартизируют свои процессы авторизации и аутентификации API. С тем же успехом мы могли бы рассмотреть централизованный подход, например использование шлюза API или выделенной точки входа для обработки запросов аутентификации.
Следуйте рекомендациям стандартов OWASP
В дополнение к этим передовым практикам рассмотрите возможность принятияОткрытый проект безопасности веб-приложений(Открытый проект безопасности веб-приложений, сокращенно OWASP). Они предоставляют рекомендации для конкретных платформ, а также будущие рекомендации для конкретных API.API Безопасность Топ 10.除了在代码层面保护 API 之外，还需要确保正确配置服务器和基础设施，以避免未经授权的访问。
Переводчику есть что сказать: автор последнего абзаца этой статьи сделал свой продукт, поэтому переводчик его не переводит.Если есть более качественный перевод этой статьи, пожалуйста, оставьте сообщение для обмена ^^
Присоединяйтесь к серии HelloGitHub «Перевод и танец»Требовать:
-
Обычно читаю англоязычную информацию и статьи на GitHub, open source, программирование, программисты
-
Переводить или исправлять не менее 1 статьи в месяц
-
Перевод оригинальный и плавный
-
Понимание Markdown, правил типографики
Присоединяйтесь и дайте волю своим талантам! Делитесь отличными статьями с большим количеством людей.