OWASP API Security Top 10 на практика

Разпространението на архитектури, в които API е основният интерфейс, промени начина, по който се проявяват слабостите. OWASP API Security Top 10 описва важните категории риск. В нашата работа няколко от тях се повтарят особено често сред сериозните констатации. Разглеждаме как изглеждат на практика.

Нарушена оторизация на ниво обект: основният риск

Познат като BOLA или IDOR, това е най-честият сериозен API дефект, който отчитаме. Крайна точка връща обект по идентификатор, проверява, че сте удостоверени, но никога не проверява, че обектът е ваш. Сменяте идентификатора, прочитате чужди данни. API-тата го влошават, защото всяко мобилно приложение и SPA говори със стотици крайни точки, обхващащи обекти — стотици места, на които да бъде забравена една проверка за собственост. Поправката е принцип: оторизирайте всеки достъп до обект спрямо извикващия, в услугата, която притежава данните.

Нарушено удостоверяване и оторизация на ниво свойство на обекта

API-тата излагат удостоверяването директно, така че слабостите са директно достижими: токени, които не изтичат, които не се отменят при изход, които изтичат в URL адреси. А масовото присвояване — при което клиент задава полета, които не би трябвало, като "role": "admin" — превръща обновяването на профил в повишаване на права. Използвайте списък с разрешени полета, които клиентът може да задава; никога не обвързвайте телата на заявките директно с обекти.

Неограничено изразходване на ресурси

Без лимити за страниране, ограничаване на честотата и контрол върху цената на заявките, една заявка може да принуди едно API да извърши огромна работа. Рутинно показваме единично извикване, което връща хиляди записи, или GraphQL заявка, която се разклонява в множество пълни сканирания на таблици. Ограничете размерите на страниците, сложете таван на дълбочината и цената на заявките и ограничавайте честотата според субекта.

Практическият извод

Не ви е нужно да запомняте всичките десет. Ако налагате оторизация на ниво обект навсякъде, обработвате токените правилно, използвате списък с разрешени записваеми полета и поставяте лимити върху използването на ресурси, сте затворили категориите зад повечето от сериозните API констатации, които виждаме. Тествайте ги изрично — това са точно проблемите, които скенерът, лишен от контекст с удостоверяване, обикновено пропуска.

Сенчести и забравени API

Не можете да обезопасите крайна точка, за която сте забравили, че съществува. Стари версии на API, останали работещи, след като v2 е излязла, недокументирани вътрешни крайни точки, маршрути за отстраняване на грешки и тестови хостове, изложени към интернет, са повтарящ се източник на сериозни констатации — обикновено защото поправките по оторизацията са попаднали в текущата версия, докато старата е останала онлайн и необновена. Опишете всяка версия и хост, които отговарят, изведете от употреба ненужното и се уверете, че обхватът на тестването ви включва крайните точки, които никой не се е сетил да спомене.

Документацията като контрол по сигурността

Точната, актуална спецификация на API не е просто удобство за разработчика — тя е контрол. Тя определя как изглежда „валидно“, което прави възможна строгата валидация по схема, и прави сенчестите крайни точки видими именно защото те отсъстват от нея. Екипите, които третират спецификацията като източник на истината, намират за далеч по-лесно да разсъждават за това какво излага техният API — и за далеч по-трудно да оставят стара версия тихо да отговаря на заявки.

Нарушена оторизация на ниво функция: различен проблем от BOLA

BOLA пита чий запис може да докоснете; нарушената оторизация на ниво функция (BFLA) пита коя операция изобщо може да извикате. Двете често се смесват, защото и двете завършват с неразрешено действие, но провалящият се контрол е различен. BOLA се проваля, когато обработчик се доверява на идентификатор на обект от заявката. BFLA се проваля, когато маршрут, който трябва да е запазен за привилегирована роля, е достижим от всеки, който може да го намери.

При BFLA често е защитено едно действие, но не и друго върху същия ресурс. Например крайна точка за четене може да има правилни проверки, докато изтриването, експортирането или промяната остават достъпни без необходимите права. В REST API тези операции често използват различни HTTP методи. Затова проверката за GET не означава автоматично, че PUT, PATCH и DELETE са защитени. Предвидимите имена на административни маршрути улесняват откриването на такива функции.

Подправяне на заявки от страна на сървъра в API сървърни части

API-тата са необичайно изложени на SSRF, защото изтеглянето на неща от името на клиента е нормална функция: регистриране на webhook, визуализация на връзки, внос на документ от URL, изтегляне на аватар и интеграции, които приемат адрес за обратно извикване. Когато сървърът извлича местоположение, което извикващият контролира, нападателят може да обърне заявката навътре, към облачни услуги за метаданни, вътрешни административни панели и бази данни, които се доверяват на мрежата, а не на извикващия.

Съвременните внедрявания го влошават. Контейнерните и облачните среди излагат чувствителни крайни точки върху локални за връзката и частни диапазони, а слепият SSRF все още изтича информация чрез разликите във времето за отговор, размера и статуса, дори когато не се връща тяло. Наивните списъци с блокирани адреси рутинно се преодоляват чрез пренасочвания, алтернативни кодирания на IP адреси и имена на хостове, които се разрешават до вътрешни адреси само в момента на заявката.

Небезопасно използване на API на трети страни

По-голямата част от Top 10 допуска, че нападателят е вашият клиент. Тази точка допуска, че нападателят е по-горе по веригата от вас. Когато услугата ви извиква партньор, доставчик на плащания или поток от данни, лесно е към този отговор да бъде разширено доверие, което никога не бихте дали на потребител. Компрометиран или просто небрежен доставчик по-горе по веригата може след това да ви подаде злонамерени пренасочвания, прекомерно големи полезни товари или данни, които попадат директно в приемник.

Слабите места са предвидими: сляпо следване на пренасочвания от доставчика, доверяване на TLS без проверка и разбор на отговорите от трети страни без ограниченията и валидацията, които прилагате към входящия трафик.

Къде да се налага: шлюз или услуга

API шлюзът е правилното място за груби, общи контроли: удостоверяване, прекратяване на TLS, глобални ограничения на честотата и оформяне на заявките. Той е погрешното място за вземане на окончателното решение за оторизация, защото шлюзът рядко знае кой обект се адресира и кой го притежава. Затова налагането само на шлюза се проваля точно там, където живеят BOLA и BFLA.

Трайният модел е защита в дълбочина: шлюзът филтрира очевидната злоупотреба и установява идентичността, а услугата взема решението за всяка заявка и всеки обект спрямо собствените си данни, така че вътрешен извикващ, който прескача шлюза, все пак получава отказ.