Врвни ранливости на OATH API
Врвни ранливости на OATH API: Вовед
Кога станува збор за експлоатирања, API се најдоброто место за почеток. API пристапот обично се состои од три дела. На клиентите им се издаваат токени од сервер за овластување, кој работи заедно со API. API добива токени за пристап од клиентот и применува правила за авторизација специфични за домен врз основа на нив.
Современите софтверски апликации се ранливи на различни опасности. Бидете во тек со најновите експлоатирања и безбедносни пропусти; Имањето репери за овие пропусти е од суштинско значење за да се обезбеди безбедност на апликацијата пред да се случи напад. Апликациите од трети страни се повеќе се потпираат на протоколот OAuth. Корисниците ќе имаат подобро целокупно корисничко искуство, како и побрзо најавување и авторизација, благодарение на оваа технологија. Можеби е побезбедно од конвенционалното овластување бидејќи корисниците не мора да ги откриваат своите ингеренции со апликацијата од трета страна за да пристапат до даден ресурс. Додека самиот протокол е безбеден и безбеден, начинот на кој е имплементиран може да ве остави отворени за напад.
При дизајнирање и хостирање на API-и, овој напис се фокусира на типичните пропусти на OAuth, како и на различни безбедносни ублажувања.
Овластување на ниво на скршен објект
Има огромна површина за напад доколку се прекрши овластувањето бидејќи API-те обезбедуваат пристап до објектите. Бидејќи ставките до кои се достапни API мора да бидат автентицирани, ова е неопходно. Спроведување на проверки за овластување на ниво на објект користејќи портал API. Треба да им се дозволи пристап само на оние со соодветни ингеренции за дозвола.
Скршена автентикација на корисникот
Неовластените токени се уште еден чест начин за напаѓачите да добијат пристап до API. Системите за автентикација може да бидат хакирани или клучот API може да биде погрешно изложен. Токените за автентикација може да бидат користени од хакери да се добие пристап. Проверете ги луѓето само ако може да им се верува и користете силни лозинки. Со OAuth, можете да отидете подалеку од обичните клучеви на API и да добиете пристап до вашите податоци. Секогаш треба да размислувате за тоа како ќе влезете и како ќе излезете од некое место. OAuth MTLS Sender Constrained Tokens може да се користат заедно со Mutual TLS за да се гарантира дека клиентите нема да се однесуваат лошо и да ги предаваат токените на неточната страна додека пристапуваат до други машини.
Промоција на API:
Прекумерна изложеност на податоци
Нема ограничувања за бројот на крајни точки што може да се објават. Најчесто, не сите функции се достапни за сите корисници. Со изложување на повеќе податоци отколку што е апсолутно неопходно, се ставате себеси и другите во опасност. Избегнувајте откривање на чувствителни информации додека не биде апсолутно неопходно. Програмерите може да одредат кој има пристап до што со користење на опсегот и приговорите на OAuth. Приговорите може да специфицираат до кои делови од податоците има пристап корисникот. Контролата на пристап може да се направи поедноставна и полесна за управување со користење на стандардна структура на сите API.
Недостаток на ресурси и ограничување на стапката
Црните шапки често користат напади со одбивање на услуга (DoS) како начин со брутална сила за да се совлада серверот и така да се намали неговото време на работа на нула. Без ограничувања на ресурсите што може да се повикаат, API е ранлив на ослабувачки напад. „Користејќи API портал или алатка за управување, може да поставите ограничувања за стапки за API. Треба да се вклучат филтрирање и страници, како и да се ограничат одговорите.
Погрешна конфигурација на безбедносниот систем
Различните упатства за безбедносна конфигурација се прилично сеопфатни, поради големата веројатност за погрешна безбедносна конфигурација. Голем број мали нешта може да ја загрозат безбедноста на вашата платформа. Можно е црните шапки со задни намени да откријат чувствителни информации испратени како одговор на погрешни прашања, како пример.
Масовна задача
Само затоа што крајната точка не е јавно дефинирана не значи дека програмерите не можат да ѝ пристапат. Тајниот API може лесно да биде пресретнат и обратно дизајниран од хакери. Погледнете го овој основен пример, кој користи отворен токен на носител во „приватен“ API. Од друга страна, јавната документација може да постои за нешто што е исклучиво наменето за лична употреба. Изложените информации може да се користат од црните капи не само за читање, туку и за манипулирање со карактеристиките на објектот. Сметајте се себеси за хакер додека барате потенцијални слаби точки во вашата одбрана. Дозволете пристап до она што е вратено само на оние со соодветни права. За да ја минимизирате ранливоста, ограничете го пакетот одговор на API. Испитаниците не треба да додаваат врски што не се апсолутно потребни.
Промовирано API:
Неправилно управување со средства
Покрај зголемувањето на продуктивноста на програмерите, тековните верзии и документацијата се неопходни за вашата безбедност. Подгответе се за воведување нови верзии и укинување на старите API далеку однапред. Користете понови API наместо да дозволите постарите да останат во употреба. Спецификација на API може да се користи како примарен извор на вистина за документација.
Инјектирање
API се ранливи на инјектирање, но исто така се и апликациите за програмери од трети страни. Злонамерниот код може да се користи за бришење податоци или кражба на доверливи информации, како што се лозинки и броеви на кредитни картички. Најважната лекција од ова е да не зависите од стандардните поставки. Вашиот менаџмент или добавувач на портал треба да може да ги задоволи вашите единствени потреби за апликација. Пораките за грешка не треба да вклучуваат чувствителни информации. За да се спречи протекување на податоците за идентитетот надвор од системот, треба да се користат парни псевдоними во токени. Ова осигурува дека ниту еден клиент не може да работи заедно за да идентификува корисник.
Недоволно евидентирање и следење
Кога навистина се случува напад, тимовите бараат добро осмислена стратегија за реакција. Програмерите ќе продолжат да ги искористуваат пропустите без да бидат фатени доколку не постои сигурен систем за евидентирање и следење, што ќе ги зголеми загубите и ќе ја оштети перцепцијата на јавноста за компанијата. Прифатете строга стратегија за следење на API и тестирање на крајната точка на производството. Тестерите на белата капа кои рано ќе пронајдат пропусти треба да бидат наградени со шема на награди. Трагата на дневникот може да се подобри со вклучување на идентитетот на корисникот во трансакциите на API. Осигурете се дека сите слоеви на вашата API архитектура се ревидирани со користење на податоци за токен за пристап.
Заклучок
Архитектите на платформата може да ги опремат своите системи да бидат еден чекор понапред од напаѓачите следејќи ги утврдените критериуми за ранливост. Бидејќи API-ите може да обезбедат пристап до информациите за лична идентификација (PII), одржувањето на безбедноста на таквите услуги е од клучно значење и за стабилноста на компанијата и за усогласеноста со законодавството како што е GDPR. Никогаш не испраќајте OAuth токени директно преку API без да користите API Gateway и Phantom Token Approach.
Промовирано API:
