Топ 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 може лесно да бъде прихванат и реконструиран от хакери. Разгледайте този основен пример, който използва отворен Bearer Token в „частен“ API. От друга страна, може да съществува публична документация за нещо, което е предназначено изключително за лична употреба. Разкритата информация може да се използва от черни шапки не само за четене, но и за манипулиране на характеристиките на обекта. Считайте се за хакер, докато търсите потенциални слаби места във вашата защита. Разрешете само на тези с подходящи права достъп до това, което е върнато. За да минимизирате уязвимостта, ограничете пакета за отговор на API. Респондентите не трябва да добавят никакви връзки, които не са абсолютно задължителни.
Популяризиран API:
Неправилно управление на активи
Освен че повишават продуктивността на разработчиците, текущите версии и документация са от съществено значение за вашата собствена безопасност. Подгответе се за въвеждането на нови версии и отхвърлянето на старите API много по-рано. Използвайте по-нови API, вместо да позволявате на по-старите да останат в употреба. Спецификация на API може да се използва като основен източник на истина за документация.
Инжектиране
Приложните програмни интерфейси (API) са уязвими за инжектиране, но също и приложенията за разработчици на трети страни. Зловреден код може да се използва за изтриване на данни или кражба на поверителна информация, като пароли и номера на кредитни карти. Най-важният урок, който трябва да извлечете от това, е да не зависи от настройките по подразбиране. Вашето управление или доставчик на шлюз трябва да може да задоволи вашите уникални нужди от приложения. Съобщенията за грешка не трябва да включват чувствителна информация. За да се предотврати изтичането на данни за самоличност извън системата, в токените трябва да се използват двойни псевдоними. Това гарантира, че никой клиент не може да работи заедно, за да идентифицира потребител.
Недостатъчно регистриране и наблюдение
Когато има атака, екипите се нуждаят от добре обмислена стратегия за реакция. Разработчиците ще продължат да експлоатират уязвимостите, без да бъдат хванати, ако не е налице надеждна система за регистриране и наблюдение, което ще увеличи загубите и ще навреди на възприятието на обществото за компанията. Приемете стриктно наблюдение на API и стратегия за тестване на крайна точка на производство. Тестерите с бели шапки, които откриват уязвимости на ранен етап, трябва да бъдат възнаградени със схема за награди. Дневникът може да бъде подобрен чрез включване на самоличността на потребителя в API транзакции. Уверете се, че всички слоеве на вашата API архитектура са одитирани чрез използване на данни от Access Token.
Заключение
Архитектите на платформи могат да оборудват системите си така, че да са една крачка пред нападателите, като следват установени критерии за уязвимост. Тъй като API могат да осигурят достъп до лична идентифицируема информация (PII), поддържането на сигурността на такива услуги е от решаващо значение както за стабилността на компанията, така и за съответствието със законодателство като GDPR. Никога не изпращайте OAuth токени директно през API, без да използвате API Gateway и подхода Phantom Token.
Популяризиран API:
