Skip to content

README-bg.md

Latest commit

 

History

History
100 lines (72 loc) · 11.3 KB

README-bg.md

File metadata and controls

100 lines (72 loc) · 11.3 KB

English | 繁中版 | 简中版 | العربية | Azərbaycan | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt

Контролен списък за сигурност на API

Контролен списък с най-важните контрамерки за сигурност при проектиране, тестване и пускане на вашето API.

Удостоверяване

  • Не използвайте Basic Auth. Използвайте стандартно удостоверяване ( например: JWT, OAuth).
  • Не преоткривайте нови начини за удостоверяване, генериране на токени, съхранение на пароли. Придържайте се към стандартите.
  • Използвайте Max Retry и jail функции по време на удостоверяване.
  • Използвайте криптиране на всички чувствителни данни.

JWT (JSON Web Token)

  • Използвайте произволен сложен ключ (JWT Secret), за да направите грубото форсиране на токена по- трудно.
  • Не извличайте алгоритъма от заглавката. Принудете алгоритъма в бекенда (HS256 or RS256).
  • Направете токена, така че да изтече (TTL, RTTL), за възможно най-кратко време.
  • Не съхранявайте чувствителни данни в JWT, те могат да бъдат декодирани лесно.
  • Избягвайте да съхранявате твърде много данни. JWT обикновено се споделя в заглавки, а те имат ограничение на размера.

Достъп

  • Задайте ограничение за броя на заявките в минута (Throttling, RPM-Limit), за да избегнете DDoS / Brute Force атаки.
  • Използвайте HTTPS, от страната на сървъра, с TLS 1.2+ и сигурни шифри, за да избегнете MITM (Man in the Middle атака).
  • Използвайте заглавката HSTS (HTTP Strict Transport Security) със SSL, за да избегнете SSL Strip атаки.
  • Изключете списъците с директории.
  • За частни API, разрешете достъп само от IP адреси/хостове в белия списък.

Упълномощаване

OAuth

  • Винаги проверявайте redirect_uri, от страната на сървъра, за да разрешите само URL адреси от белия списък.
  • Винаги се опитвайте да използвате еднократен код вместо токени (не използвайте response_type=token).
  • Използвайте параметъра state с произволен хеш, за да предотвратите CSRF в процеса на OAuth удостоверяване.
  • Определете обхват по подразбиране и проверете настройките за всяко приложение.

Заявка

  • Използвайте подходящият HTTP метод според операцията: GET (четене), POST (създаване), PUT/PATCH (замяна/актуализация) и DELETE (изтриване) и също отговорете с 405 Method Not Allowed ако заявеният метод не е подходящ за искания ресурс.
  • Валидирайте типа данни (content-type) в заглавката Accept (Content Negotiation), за да позволите само поддържани формати (например: application/xml, application/json и т.н.) и отговорете с 406 Not Acceptable, ако типът не се поддържа.
  • Валидирайте типа данни (content-type), които получавате (например: application/x-www-form-urlencoded, multipart/form-data, application/json и т.н.).
  • Валидирайте въведеното от потребителя, за да избегнете често срещани уязвимости (например: XSS, SQL-Injection, Remote Code Executionи т.н.).
  • Не споделяйте чувствителни данни (идентификационни данни, пароли, токени или API ключове) в URL адреса, вместо това използвайте стандартната заглавка Authorization.
  • Използвайте само криптиране от страна на сървъра.
  • Използвайте API шлюз за ​​да конфигурирате кеширане, ограничаване на заявките (например: Quota, Spike Arrest или Concurrent Rate Limit) и динамично внедряване на API.

Обработка

  • Проверете, дали всички крайни точки са защитени чрез удостоверяване, за да избегнете прекъсване на процеса на удостоверяване.
  • Идентификаторът на собствен ресурс на потребителя, трябва да се избягва. Използвайте /me/orders, вместо /user/654321/orders
  • Не използвайте автоматично нарастване за ID. Вместо това използвайте UUID.
  • Ако анализирате XML файлове, уверете се, че анализът на обект е изключен, за да избегнете XXE (XML external entity).
  • Ако анализирате XML, YAML или друг език с котви и препратки, уверете се, че разширяването на обекта е изключено, за да избегнете Billion Laughs/XML bomb чрез атака с експоненциално разширяване на обект.
  • Използвайте CDN за качване на файлове.
  • Ако имате работа с огромно количество данни, използвайте Workers и Queues, за да обработите колкото е възможно повече, във фонов режим, и да върнете отговор бързо, за да избегнете HTTP блокиране.
  • Не забравяйте да изключите режима DEBUG.
  • Използвайте неизпълними стекове, когато има такива.

Отговор

  • Изпратете заглавката X-Content-Type-Options: nosniff.
  • Изпратете заглавката X-Frame-Options: deny.
  • Изпратете заглавката Content-Security-Policy: default-src 'none'.
  • Премахнете заглавките, които биха могли да помогнат на атакуващ да провери вашия ресурс за уязвимости - X-Powered-By, Server, X-AspNet-Versionи т.н.
  • Фиксирайте content-type за вашия отговор. Ако изпращате отговор application/json, то тогава заявката трябва да бъде в application/json
  • Не изпращайте в отговорите чувствителни данни като идентификационни данни, пароли или токени.
  • Върнете правилния код на състоянието въз основа на резултатите от операцията. (например: 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed и т.н.).

Непрекъсната интеграция и непрекъсната доставка (CI & CD)

  • Одитирайте вашия дизайн и внедрете модулни/интеграционни тестове.
  • Използвайте процес за преглед на кода (Code Review). Не се самоодобрявайте (no Self-Approval).
  • Уверете се, че вашето приложение е сканирано с антивирусен софтуер, преди да бъде пуснато в производство, включително библиотеки и други зависимости.
  • Непрекъснато провеждайте тестове за сигурност (статичен/динамичен анализ) на вашия код.
  • Проверете вашите зависимости (както софтуер, така и операционна система) за известни уязвимости.
  • Проектирайте решение за бързо връщане към предишната версия.

Мониторинг

  • Използвайте централизирани входове за всички услуги и компоненти.
  • Използвайте агенти, за да наблюдавате целия трафик, грешки, заявки и отговори.
  • Използвайте известия за SMS, Slack, имейл, Telegram, Kibana, Cloudwatch и др.
  • Уверете се, че не регистрирате чувствителни данни като кредитни карти, пароли, ПИН кодове и др.
  • Използвайте IDS и/или IPS система за наблюдение на заявки и екземпляри на API.

Вижте също:

Принос

Чувствайте се свободни да допринесете, като отворите това хранилище, направите някои промени и изпратите Pull Requests. За всякакви въпроси, моля, пишете ни на team@shieldfy.io.