IDOR: най-простият дефект, който и през 2026 г. превзема API

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

Какво е IDOR

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

Каноничният пример:

GET /api/v2/invoices/1007   → вашата фактура     (200 OK)
GET /api/v2/invoices/1006   → чужда              (200 OK)  ← IDOR
GET /api/v2/invoices/1005   → чужда              (200 OK)
...

Показаният отговор разкрива защитена фактура на друг потребител. Това доказва неефективен контрол на достъпа за тази операция, но не разкрива дали вътрешна проверка липсва, е грешна или е заобиколена. Удостоверена заявка също може да е злонамерена и да се вижда в подходяща одитна телеметрия.

Защо е проблем на 2026, а не на 2006 г.

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

• Архитектури с API на първо място. Всяко мобилно приложение и SPA говори с API със стотици крайни точки, обхващащи обекти. Това са стотици места, на които да бъде забравена една проверка за собственост.
• Сигурност, налагана от интерфейса. Уеб интерфейсът никога не ви показва бутона за достъп до чужд запис, затова екипите допускат, че е безопасно. API-то не се интересува от вашия интерфейс.
• Микроуслуги. Услугата, която притежава данните, често се доверява, че шлюз по-нагоре вече е извършил оторизацията. Понякога не е. Всяка услуга трябва сама да налага собствеността.

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

Защо скенерите го пропускат, а тестерите не

Автоматизираният скенер се затруднява с IDOR, защото преценката изисква контекст: той трябва да използва две удостоверени сесии на различни потребители, да знае кой обект на кого принадлежи и да разпознае, че потребител A, който чете обекта на потребител B, е погрешно. Това е смислова преценка за вашия модел на данните. Човешкият тестер създава два акаунта и просто опитва — което е точно причината IDOR да е основна констатация в ръчното тестване и сляпо петно за инструментите.

Как да го предотвратите още при проектирането

Принципът е всяка защитена операция с обект да бъде разрешена според приложимите права на заявителя преди разкриване или промяна. Изберете контрол, който покрива алтернативните пътища и разрешеното споделяне. Практически варианти са:

Налагайте правата преди разкриване или промяна. Ограничена заявка към базата е полезен вариант; извличане на метаданни и последваща проверка също може да е валидно, ако преди нея не се разкриват защитени данни и не възникват неразрешени ефекти. Отчетете споделянето, делегирането и правата за операцията, вместо да приемате съвпадението на собственика за цялата политика. Покрийте всеки защитен път. Налагайте политиката в доверен слой, който не може да бъде заобиколен чрез друг поддържан вход. Услуга или общ data-access слой е полезен вариант; задължителен gateway също може да участва във валиден дизайн.
• Предпочитайте неотгатваеми идентификатори — но не разчитайте на тях. UUID повишават летвата, но „труден за отгатване“ не е „оторизиран“. Те са защита в дълбочина, не самият контрол.
• Добавете тестове за оторизация на ниво обект в CI. За всяка чувствителна крайна точка — тест, че потребител A не може да прочете обекта на потребител B. Евтино за написване и улавя регресиите завинаги.
• Журналирайте и известявайте за провалени проверки за собственост. Скок на отказани заявки между обекти означава нападател, който изброява. Направете го видимо.

Изводът

IDOR се въвежда лесно, когато правата за обекти са неявни или се прилагат непоследователно. Откриването и експлоатацията зависят от контекста, идентификаторите и достижимите операции. Прилагайте политиката по всеки съответен път и я проверявайте спрямо очакваните резултати.

Как всъщност го намираме в един ангажимент

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

Тестването изисква описание на очакваните права. Хората често установяват контекста, а конфигурирани инструменти и регресионни тестове могат да автоматизират сравненията при известни резултати и контролирани идентичности. Общ неавтентикиран скенер трудно осигурява сам специфичната политика на приложението.

Къде се крие IDOR отвъд очевидния идентификатор

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

Последователен, UUID, косвен: защо „неотгатваем“ не е „оторизиран“

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

• Последователните идентификатори (/orders/1004) разкриват обем и са тривиални за обхождане. IDOR и рискът от изброяване съвпадат.
• UUID / ULID повишават цената на сляпото отгатване, но идентификаторите изтичат постоянно — заглавки с препращащ адрес, споделени връзки, журнали, автоматично допълване, заявки за поддръжка, мобилни кешове и предходни отговори, които вграждат идентификаторите на съседите. Изтекъл UUID без проверка за собственост е пълно компрометиране.
• Картите с косвени препратки могат да осигурят допълнителна граница: сървърът свързва препратка за конкретната сесия (item-1, item-2) с обект, до който потребителят има право на достъп. Препратка от една сесия не трябва да работи в друга. Основната корекция остава сървърната проверка на правата за всеки обект и действие. Тя трябва да се прилага и при тази схема, а може да бъде реализирана и чрез ограничени заявки или общ слой за оторизация без такава карта.

Правилото, което трябва да се усвои: притежаването на идентификатор не е доказателство за право. Всяко извличане на обект трябва да изведе отново „може ли този принципал да действа върху този обект?“ от сесията, никога от стойността в заявката.

Опасните съседи: масово присвояване и оторизация на ниво функция

IDOR рядко пътува сам. Два родствени дефекта превръщат надничането само за четене в завладяване на акаунт.

Mass assignment е API6 в OWASP API Security Top 10 от 2019 г. В изданието от 2023 г. попада в API3, Broken Object Property Level Authorization. Заявител с право да обновява обект трябва да бъде ограничен и до свойствата, които може да променя:

PATCH /api/v1/users/{self}
{ "displayName": "ново име", "role": "admin", "accountId": 9001 }

Полетата role и accountId никога не са били във формуляра, но ако моделът ги свърже, потребителят повишава собствените си права или премества записа си в друга клиентска организация. Поправя се с изрични DTO обекти със списък на разрешените полета — свързвайте само полета, които извикващият има право да задава, и разрешавайте полетата, носещи собственост (клиентска организация, собственик, роля), от страна на сървъра.

Нарушената оторизация на ниво функция (BFLA, API5) е вертикалният братовчед на IDOR на ниво обект. Тук проверката за обекта може да премине, но операцията не е охранявана според роля: обикновен потребител достига административна операция или маршрут само за администратори просто като го извика. Тествайте и двете оси при всяка крайна точка — „може ли да достигна обект на друга клиентска организация?“ (BOLA) и „може ли да извикам действие извън правата на моята роля?“ (BFLA) — защото един ресурс е безопасен само когато и обектът, и функцията са оторизирани за този принципал.

RBAC, ABAC, ReBAC: къде всъщност живее проверката за собственост

IDOR по същество е въпрос, на който вашият модел на оторизация трябва да отговори по време на заявката. Моделът, който избирате, решава колко естествено излиза този отговор.

RBAC свързва права с роли. Обща роля като customer сама не определя кои поръчки са достъпни; роли с обхват по ресурс и допълнителни условия могат да осигурят този контекст. Оценявайте действителния модел, вместо да приемате името му за доказателство за защита или пропуск.
• ABAC оценява атрибути (resource.ownerId == subject.id, resource.tenant == subject.tenant) и е мястото, където предикатът за собственост принадлежи при повечето CRUD API.
• ReBAC моделира връзките като граф („член ли е субектът на екипа, който притежава документа?“) и пасва на споделянето, йерархиите и делегирането, където собствеността е преносима.

Където и да живее логиката, централизирайте я. Един единствен, задължителен слой за оторизация — механизъм за политики, междинен слой или функция за решение, която всеки път за достъп до данни трябва да извика — превъзхожда проверките във всеки обработчик, които една разсеяна заявка за сливане ще прескочи. Избутайте предиката и в слоя на данните: ограничавайте всяка заявка по собственик и клиентска организация (WHERE tenant_id = :session_tenant), така че липсваща проверка да отказва достъп по подразбиране с празен резултат, а не отворено с чужд ред.

Тестване с матрица на оторизацията и разпознаване на експлоатацията в журналите

Можете да полуавтоматизирате търсенето на IDOR безопасно, без скенер с автоматизирана експлоатация. Изградете матрица на оторизацията: уловете каталога от заявки за потребител A, после възпроизведете всяка заявка с данните за достъп на потребител B (и с неудостоверена сесия) срещу препратките към обектите на A. Всеки 2xx там, където сте очаквали 403/404, е кандидат за констатация. Това е детерминирано, ограничено до известни крайни точки и стойности на препратките, и избягва сляпото изброяване срещу данни от продукционната среда — дръжте го в тестова среда с предварително създадени акаунти.

за всяка (сесия S, заявка R в договорения каталог):
    повторете R към контролирани обекти според очакваните права
    проверете защитените данни и доказаните промени
    отбележете неочакван достъп или ефекти; проучете различните статуси