НАЙ-ДОБРИТЕ ПРАКТИКИ ЗА СИГУРНОСТ НА API 2023
Въведение
API са критични за успеха на бизнеса. Фокусът трябва да бъде да се гарантира тяхната надеждност и сигурност. Мнозинството от респондентите в проучване на Salt Security от 2021 г. казаха, че са забавили стартирането на приложение поради API защита опасения.
Топ 10 на риска за сигурността на API
1. Недостатъчно регистриране и наблюдение
Когато нападател се опита да влезе в система, той генерира нередовен трафик. Те използват метод за грубо принуждаване на вашето удостоверяване срещу вашите входове.
2. Неправилно управление на активи
API обикновено имат повече крайни точки от традиционните уеб приложения. Правилната и актуална документация е от решаващо значение. За да избегнете остарели API версии и изложени хостове трябва да управлявате хостове и дадени версии на API. Трябва да опитате да намалите крайните точки на дебъгера.
3. Инжектиране
Уязвимости на инжектиране като инжектиране на SQL или команди възникват, когато ненадеждни данни се изпращат директно към интерпретатор като част от заявка или изявление. В резултат на това нападателите могат да подмамят интерпретатора да изпълни неволни изрази или да получи достъп до данни без съответното разрешение.
4. Неправилна конфигурация на сигурността
Лошите конфигурации за сигурност често се дължат на несигурни конфигурации по подразбиране.
- Непълни ad hoc конфигурации
- Отворете облачно хранилище
- Неправилно конфигурирани HTTP заглавки
- Ненужно активирани HTTP методи
- Споделяне на ресурси от различни източници
- Извеждане на подробни съобщения за грешка, съдържащи значение за сигурността информация
5. Масово задание
Масово присвояване се случва, когато обвързването на клиента към модели на данни без правилно филтриране на свойства води до масово картографиране. Нападателите могат да променят свойствата на обекта, като ги познаят.
6. Разрешение на функционално ниво
Оторизацията на нарушено функционално ниво може да се случи, когато има сложни правила за контрол на достъпа с различни йерархии, групи и роли. Неясното разделение между администраторските и потребителските функции води до слабости в оторизацията. Нападателите могат да получат достъп до ресурси или административни функции на други потребители.
7. Нарушено удостоверяване на потребителя
Механизмите за удостоверяване често позволяват на атакуващите да компрометират токени за удостоверяване или да използват грешки при внедряването, за да се представят временно или постоянно за други потребители.
8. Прекомерно излагане на данни
Що се отнася до общото използване на API, разработчиците са склонни да разкриват всички атрибути на обекта. Разработчиците могат да разкриват атрибути на обекти, ако не вземат под внимание поверителността. Прекомерното излагане на данни може да бъде причинено от разчитането на клиентската страна да филтрира данните, преди да се покажат на потребителя.
9. Липса на ресурси и ограничаване на скоростта
Клиентът или потребителят могат да бъдат заявени. Липсата на ограничение на ресурсите и скоростта не само може да повлияе на производителността на API сървъра и да доведе до атаки за отказ на услуга, но също така оставя възможност за слабости при удостоверяването.
10. Разрешение на ниво обект
API са склонни да разкриват крайни точки, които обработват идентификатори на обекти, създавайки голяма повърхност за атака в контрола на достъпа. Проверките за оторизация на ниво обект трябва да включват функционалност, която осъществява достъп до източник на данни чрез въвеждане от потребителя.
Как да защитите SOAP API
SOAP е спецификация на протокол, който комуникира с уеб страници. Това е индустриален стандарт на W3C, XML формат. SOAP прилага предаване на съобщения със състояние. SOAP се интегрира с WS-Security протоколи. SOAP може да гарантира целостта и поверителността на обработените транзакции с повече криптиране. Използвайки XML, SOAP е най-подробният стил на API.
SOAP е спецификация на протокол, който комуникира с уеб страници. Това е индустриален стандарт на W3C, XML формат. SOAP прилага предаване на съобщения със състояние. SOAP се интегрира с WS-Security протоколи. SOAP може да гарантира целостта и поверителността на обработените транзакции с повече криптиране. Използвайки XML, SOAP е най-подробният стил на API.
Как да защитите Rest API
REST е стил на API архитектура. REST е прост интерфейс за прехвърляне на информация. При изпращане на данни няма етап на преобразуване. Изпратената информация в оригинален вид има благоприятен ефект върху натоварването на клиента. Данните са във формат JSON или XML.
Архитектурни изисквания на RESTful:
- Да не съдържа състояние (без състояние)
- Кеширане.
- Общ интерфейс: Това позволява последователно, независимо от приложението взаимодействие с уеб сървъра.
В REST цялата комуникация използва HTTP методи: GET, POST, PUT, PATCH и DELETE. REST се използва като API за управление на CRUD (Създаване, четене, актуализиране и изтриване). Инсталирайте взаимодействие с ресурси в леки мащабируеми услуги. Ресурсът обикновено е обект на модел на данни.
Създаването на защитени RESTful API също така налага определени стандартни изисквания:
- Използване на HTTPS протокол: крипто операцията гарантира целостта на предадените данни.
- Rate-limits: Необходимо е да се провери натоварването на API. Премахване на заявки в случай на претоварване
- Удостоверяване: Идентификация на потребител / приложение / устройство.
- Дневник за проверка: Записване на действия чрез създаване на запис в регистрационния файл.
- Контрол на правата за достъп: Определяне на правата за достъп за работа с ресурси.
- Достъп до бизнес логиката на приложението.
По дизайн REST API не пази никакви записи. Има ограничение за достъп през локални крайни точки. При работа с REST архитектура. Обичайно е да се разграничават две нива на сигурност:
- Първо ниво – получаване на достъп до API
- Второ ниво – получаване на достъп до приложението
Как да защитим API
За да гарантират сигурността на API, организациите трябва да обърнат голямо внимание на следните области.
- Контрол на достъпа
- API защита
- Защита срещу заплахи
Моделът на API Gateway
Най-добрата практика за сигурност е да прехвърлите отговорностите за сигурност на API шлюз. API шлюзът се намира между API бекенда и потребителите. Той ще прихваща всички заявки от потребителите и ще управлява аспектите на сигурността.
Разработчиците на API могат да се съсредоточат върху функциите на API на бизнес логиката. API шлюзът управлява сигурността и контрола на достъпа.
API контрол на достъпа
Контролът на достъпа до API се отнася до процеса на определяне кой има достъп до кои API. Каква функционалност на тези API се използва от други приложения.
заверка е за идентифициране на субекта, който иска достъп до API. Идентификацията е или проверка на това дали потребителят знае парола.
Основно удостоверяване
Този метод използва процес на HTTP удостоверяване. Потребителските идентификационни данни се кодират с помощта на алгоритъма base64. HTTP заглавката се прикачва при изпращане на заявка.
Основното удостоверяване не е достатъчно за защита на API срещу всички сложни атаки за сигурност. Поне двама души трябва да споделят потребителското име и паролата. Трета страна може да получи достъп до защитена услуга чрез достъп до идентификационните данни. OAuth адресира тези уязвимости.
OAuth Token
OAuth използва токен за достъп. Идентификационните данни не се споделят по директен начин. Този токен има цял живот. Това означава, че дори този токен не е вечен. Това намалява опасността от кражба. Токенът използва обхвати. Достъп до ресурси въз основа на роли, присвоени на потребителя. Следователно OAuth за защита на API е много по-безопасен от парола.
Базирано на OIDC удостоверяване
OIDC – OpenID Connect. Това удостоверяване е за проверка на самоличността на крайния потребител. Базира се на удостоверяване, извършено от сървър за оторизация. Той получава подробности за профила на потребителя, като използва подобен на REST механизъм.
API базирано на ключ удостоверяване
API ключът е низова стойност, предавана от клиентско приложение към APIM шлюза. Ключът на клиента запазва информация в базата данни на приложението. Сървърът ще провери самоличността на клиента. Когато потребител се регистрира, програмата генерира ключ.
Тази стратегия защитава срещу нежелан достъп. За да ограничите броя на API заявките. API ключът има няколко начина, включително като параметър на заявка, в заглавката на заявката и като стойност на бисквитка.
Удостоверяване на базата на бисквитки
Метод за проверка на съдържанието на бисквитките запазва цялата информация за сесията. Потребителят инициира заявка за влизане. Той изпраща отговор, след като потребителят е влязъл. В заглавката на този отговор има поле Set-Cookies. Това поле съдържа информация за:
- името на полето за бисквитка
- стойността на полето за бисквитка
- колко време трае бисквитката
Следващият път, когато потребителят трябва да получи достъп до API. Той ще предаде стойността на запазеното Cookie поле JSESSIONID с ключа „Cookie“ в заглавката на заявката.
Удостоверяване на базата на токени
След това този токен се изпраща до сървъра в заглавката на заявката за оторизация. След като получи токена, сървърът го валидира. Самият сървър генерира токени за нови потребители. Ключът, за разлика от токените, може да позволи достъп само до извиквания на API без възможност за получаване на данните на потребителя.
JSON уеб токени (JWT)
Механизъм за удостоверяване, базиран на използването на специален тип токен. Това е JSON структура от данни. Токен от този тип има заглавка, съдържаща обща информация. Тялото съдържа полезен товар (потребителски идентификатор, група, данни) и криптографски подпис.
Този подход е оптималният начин за ограничаване на достъпа до REST API. Това е един от най-сигурните механизми за изпращане на данни между две страни.
J.W.T. е основната техника за контрол на достъпа за създаденото приложение. Услугата не разчита на ресурси на трети страни. Токените са лесни за използване, имат удобен формат за описание на данните.
Използването на HTTPS протокола в комбинация с криптографски подпис осигурява високо ниво на сигурност.
Когато защитавате уеб услуга, контролът на входа заслужава специално внимание. Трябва да се уверите, че всички данни, с които ще работи приложението, отговарят на стандарта API.
Общността на разработчиците е създала някои препоръки при валидиране на входните данни:
- За извършване на валидиране на данни както от страна на клиента, така и от страна на сървъра
- За да поставите списъци с разрешени сървъри, трябва да използвате вградените функции
- Винаги е необходимо да проверявате вида на съдържанието, размера и дължината на заявката
- Използвайте параметризирани заявки вместо ръчни заявки към базата данни в задната част
- За да се възползвате от списъците с разрешени сървъри
- За поддържане на регистрационни файлове за грешки и наблюдение за опити за размиване на въведените данни
Упълномощаване
Целта на оторизацията е да се определят нивата на достъп.
Базиран на XACML контрол на достъпа
XACML е базиран на XML, декларативен език за политики за контрол на достъпа, базиран на XML. Може да предостави стандартизиран начин за валидиране на заявки за оторизация. Той определя правилата за контрол на достъпа.
Отваряне на агент за политики OPA
OPA е двигател с отворен код с общо предназначение. OPA ще уточни политика като код и прости API, за да разтовари процеса на вземане на решения. Решенията за политика се генерират чрез оценка на входа на заявката и спрямо данни. Тези политически решения ще определят кои потребители имат достъп до ресурси.
Speedle+
Speedle+ е проект с отворен код за справяне с изискванията за контрол на достъпа. Екстернализиране на логиката за контрол на достъпа към машина за правила, използвайки механизъм за контрол на достъпа.
ограничаване на скоростта
Разрешаването на неограничен достъп до API не е добра практика. Най-доброто решение е да имате механизъм за ограничаване на скоростта.
Ограничаването на скоростта за защита на API ще бъде полезно по следните начини:
- Предотвратяване на DDoS атаки - Предотвратяване на нападателите от наводняване на мрежа с толкова много трафик.
- Въведете планове за използване на API - Това ще бъде от полза при монетизиране на API.
- Налагайте политики за справедливо използване – Никой не може да консумира всички разпределени ресурси или честотна лента.
- Предотвратете прекомерното използване на системата - с правилно ограничаване на скоростта. Възможно е да защитите API и бекенда от внезапна прекомерна употреба и пикове на заявките.
Заключение
Приложните програмни интерфейси (API) вече са от съществено значение в съвременния интернет и разработването на цифрови приложения. Приложенията, услугите и софтуерните платформи могат да ги използват за организиране на взаимодействия. REST интерфейсите представляват над 80% от всички публични и частни API. Прочетете статията ни относно КАКВО Е API, за да разберете по-добре значителните разлики между REST и SOAP API.