НАЈДОБРИ ПРАКТИКИ ЗА БЕЗБЕДНОСТ API 2023 година
Вовед
API се клучни за успехот на бизнисот. Фокусот мора да биде да се обезбеди нивната сигурност и безбедност. Мнозинството од испитаниците на истражувањето за безбедност на сол во 2021 година рекоа дека го одложиле лансирањето на апликацијата поради Безбедност на API грижи.
Топ 10 безбедносни ризици на API
1. Недоволно евидентирање и следење
Кога напаѓачот се обидува да влезе во системот, тие создаваат неправилен сообраќај. Тие користат метод на брутално принудување на вашата автентикација против вашите влезови.
2. Неправилно управување со средства
API-ите имаат тенденција да имаат повеќе крајни точки од традиционалните веб-апликации. Правилната и ажурирана документација е од клучно значење. За да се избегне застарена API верзии и изложени хостови треба да управувате со домаќините и дадените верзии на API. Треба да се обидете да ги намалите крајните точки на дебагерот.
3. Инјекција
Ранливости на инјектирање како што се SQL или командни инјекции се појавуваат кога недоверливите податоци се испраќаат директно до преведувач како дел од барање или изјава. Како резултат на тоа, напаѓачите можат да го измамат толкувачот да изврши ненамерни изјави или да пристапи до податоци без соодветна дозвола.
4. Погрешна конфигурација на безбедноста
Слабите безбедносни конфигурации често се должат на несигурни стандардни конфигурации.
- Нецелосни ад хок конфигурации
- Отворете складирање облак
- Погрешно конфигурирани заглавија на 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.
Како да обезбедите API за одмор
REST е стил на API архитектура. REST е едноставен интерфејс за пренос на информации. При испраќање податоци, нема фаза на конверзија. Информациите испратени во оригинална форма имаат корисен ефект врз оптоварувањето на клиентот. Податоците се во JSON или XML формати.
РЕЦЕТНИ архитектонски барања:
- Да не содржи држава (без државјанство)
- Кеширање.
- Заеднички интерфејс: Ова овозможува конзистентна, независна од апликацијата интеракција со веб-серверот.
Во REST, целата комуникација користи HTTP методи: GET, POST, PUT, PATCH и DELETE. REST се користи како управување со API за CRUD (Креирај, читај, ажурирај и бриши). Инсталирајте интеракција со ресурси во лесни скалабилни услуги. Ресурсот обично е објект на податочен модел.
Создавањето на безбедни RESTful API, исто така, наметнува одредени стандардни барања:
- Користење на протоколот HTTPS: крипто операцијата обезбедува интегритет на пренесените податоци.
- Ограничувања на стапка: Неопходно е да се провери оптоварувањето на API. Отфрлање на барањата во случај на преоптоварување
- Автентикација: Идентификација на корисник / апликација / уред.
- Ревизорски дневник: Снимајте дејства со креирање запис во датотеката за евиденција.
- Контрола на правата за пристап: Определување права на пристап за работа со ресурси.
- Пристап до деловната логика на апликацијата.
Според дизајнот REST API не чува никакви записи. Постои ограничување за пристап преку локални крајни точки. При работа со REST архитектурата. Вообичаено е да се разликуваат две нивоа на безбедност:
- Првото ниво - добивање пристап до API
- Второто ниво - добивање пристап до апликацијата
Како да обезбедите API
За да се обезбеди безбедност на API, организациите треба да обрнат големо внимание на следните области.
- Контрола на пристап
- API заштита
- Заштита на закани
Шема на портата API
Најдобрата безбедносна практика е да се претоварат безбедносните одговорности на портата на API. Портата API се наоѓа помеѓу задниот дел на API и потрошувачите. Ќе ги пресретне сите барања на потрошувачите и ќе управува со безбедносните аспекти.
Програмерите на API можат да се фокусираат на функциите на деловната логика API. Портата API управува со безбедноста и контролата на пристапот.
Контрола на пристап до API
Контролата за пристап на API се однесува на процесот на одредување кој има пристап до кои API. Која функционалност на тие API се користат од други апликации.
Проверка е за идентификување на ентитетот кој бара пристап до API. Идентификацијата е или потврдување дали корисникот знае лозинка.
Основна автентикација
Овој метод користи процес за автентикација на HTTP. Корисничките ингеренции се кодирани со користење на алгоритмот base64. Заглавието на HTTP се прикачува кога се испраќа барање.
Основната автентикација не е доволна за заштита на API од сите сложени безбедносни напади. Најмалку две лица треба да ги споделат корисничкото име и лозинката. Трето лице може да пристапи до обезбедена услуга со пристап до ингеренциите. OAuth се справува со овие пропусти.
Токен OAuth
Оаут користи токен за пристап. Ингеренциите не се споделуваат на директен начин. Овој токен има цел живот. Ова значи дека дури и тој токен не е вечен. Ова ја намалува заканата од кражба. Токенот користи опсег. Пристап до ресурси врз основа на улогите доделени на корисникот. Оттука, OAuth за обезбедување на API е многу побезбеден од лозинката.
Автентикација базирана на OIDC
OIDC – OpenID Connect. Оваа автентикација е за да се потврди идентитетот на крајниот корисник. Се заснова на автентикацијата што ја врши серверот за овластување. Добива детали за профилот за корисникот користејќи го механизмот сличен на REST.
Автентикација базирана на клуч на API
Клучот API е вредност на низата што ја пренесува клиентската апликација до портата APIM. Клучот на клиентот зачувува информации во базата на податоци на апликацијата. Серверот ќе го потврди идентитетот на клиентот. Кога корисникот се регистрира, програмата генерира клуч.
Оваа стратегија се брани од несакан пристап. За ограничување на бројот на барања за API. Клучот API има неколку начини, вклучително и како параметар за барање, во заглавието на барањето и како вредност на колачето.
Автентикација базирана на колачиња
Начинот на проверка на содржината на колачињата ги задржува сите информации за сесијата. Корисникот иницира барање за најава. Испраќа одговор откако корисникот ќе се најави. Во заглавието на овој одговор има поле Постави-колачиња. Ова поле содржи информации за:
- името на полето за колачиња
- вредноста на полето за колачиња
- колку долго трае колачето
Следниот пат кога корисникот ќе треба да пристапи до API. Тој ќе ја пренесе вредноста на зачуваното поле за колачиња JSESSIONID со клучот „Cookie“ во заглавието на барањето.
Автентикација базирана на токени
Овој токен потоа се испраќа до серверот во заглавието на барањето за авторизација. По добивањето на токенот, серверот го потврдува. Самиот сервер генерира токени за нови корисници. Клучот, за разлика од токените, може да дозволи пристап само до повиците на API без можност за добивање на податоците на корисникот.
JSON веб-токени (JWT)
Механизам за автентикација базиран на употреба на посебен вид токен. Тоа е JSON податочна структура. Токен од овој тип има заглавие што содржи општи информации. Телото содржи носивост (кориснички ID, група, податоци) и криптографски потпис.
Овој пристап е оптимален начин за ограничување на пристапот REST API. Тој е еден од најбезбедните механизми за испраќање податоци помеѓу две страни.
Џ.В.Т. е примарна техника за контрола на пристап за креираната апликација. Услугата не се потпира на ресурси од трети страни. Токените се едноставни за употреба, имаат пригоден формат за опис на податоци.
Употребата на протоколот 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.
