Siemba обяви автоматизирано тестване за несигурна директна референция към обект (IDOR) като част от своята функционалност за тестване на сигурността на API. Тя тества REST, GraphQL и SOAP API за класовете уязвимости, за които има най-голяма вероятност да разкрият клиентски данни.

Колекция от API с 200 крайни точки (endpoints) може да бъде тествана за IDOR за по-малко от час. Същото покритие обикновено отнема дни или седмици на специалист по сигурността, работещ точка по точка, и произвежда писмен доклад дни след това. Siemba компресира както тестването, така и отчитането в единно непрекъснато изпълнение спрямо реално внедреното API, без да е необходим изходен код.

Какво е IDOR и защо е от значение?

IDOR е грешка в оторизацията. Уязвимата крайна точка не успява да провери дали идентификаторът, предоставен от заявителя, му принадлежи, така че промяната на едно число или идентификатор в заявката може да е достатъчна за преглед или промяна на чужди данни. OWASP го класифицира като счупена оторизация на ниво обект (BOLA) и го нарежда на първо място в OWASP API Security Top 10.

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

„Повечето уязвимости в API не са екзотични“, каза Сандхя Прашант, главен директор по сигурността в Siemba. „Те представляват сесия на един потребител, четяща данните на друг потребител, защото никой не е проверил. Това е IDOR и той генерира огромен дял от пробивите в реалния свят. Не са необходими речиси никакви разсъждения на ниво изходен код, за да бъде открит, а само дисциплина да се тества систематично всяка крайна точка срещу него. Това е точно такъв вид работа, която автоматизацията трябва да прави непрекъснато, така че екипите по сигурност да могат да насочат вниманието си към това, за което автоматизацията не може да прави изводи: верижни потоци и граници на привилегии.“

Как Siemba тества за IDOR?

Тестването започва от дефиницията на API, която екипът вече поддържа, предоставена като OpenAPI или Swagger файл, Postman колекция или URL адрес на колекция. Клиентът предоставя набор от идентификатори, а автентифицираните сесии се управляват от платформата. Siemba записва и runs резултатните тестови сценарии във всяка крайна точка, носеща параметър, подобен на ID.

Всеки резултат се оценява чрез прочитане на действителния отговор от API, а не чрез съвпадение на сигнатура или код за състояние. Код 200, носещ празен резултат или обща страница за грешка, не се отчита като преминат тест. Това е разликата между потвърдено констатирано нарушение и обема от шум, който прави автоматизираното тестване на оторизацията трудно за доверяване, и е причината всяко намерено нарушение, върнато от Siemba, да пристига вече описано със стъпки за възпроизвеждане, вместо да чака на опашка за фаза на отчитане.

Всеки протокол се тества според собствената му спецификация. REST крайните точки се тестват индивидуално за параметри в пътя, заявката (query), заглавните части (header) и тялото (body). GraphQL схемите се разрешават чрез анализ на интроспекция, след което се тестват за излагане на схемата, дълбочина на заявката и злоупотреба с групиране (batching), претоварване с псевдоними и оторизация на ниво поле. SOAP операциите се парсират от WSDL и се тестват за инжектиране на външни XML единици (XXE), обвиване на подписи (signature wrapping), манипулация на SOAPAction и неправилна конфигурация на WS-Security.

Какво покрива автоматизацията и какво не

Потвърдените констатации се картографират автоматично към девет от десетте категории на OWASP API Security Top 10. Десетата — счупена оторизация на ниво функция — заедно с верижни пътища на атака и нюансирано тестване на границите на привилегиите, се покрива от сертифицираните пентестери на Siemba, работещи от същата платформа. Затова ангажиментът, воден от експерти, започва от известна базова линия, вместо да започва разузнаване от нулата, което влага повече от бюджета за тестване в работата, която само човек може да извърши.

Практическата разлика е в покритието и непрекъснатостта. Специалистът по тестване, притиснат от времето, взема извадки от крайни точки. Автоматизацията тества всички тях, във всеки параметър, подобен на ID, на всяка позиция. А еднократното тестване сертифицира дадено API в деня на изпълнението си, оставяйки всяка крайна точка, внедрена след това, непреведена до следващия тест. Непрекъснатото тестване затваря този прозорец.

Създаден за работа в производствена среда

Клиентите контролират темпото на тестване чрез четири предварителни настройки за ограничаване (throttle) — от скрит режим (stealth mode), подходящ за работните часове, до турбо режим за специализирани прозорци за тестване, с независим контрол върху заявките в секунда, едновременните тестови случаи и таймаута на заявката. Прозорците за замразяване до 30 дни позволяват на екипите автоматично да паузират тестването около производствени замразявания, пикови търговски периоди или критични релизи, без да е необходим ръчен тикет.

Заедно тези контроли означават, че тестването за IDOR се извършва спрямо производствената среда, където данните и логиката на оторизация са реални, а не спрямо тестова (staging) среда, която се е разминала с нея.