Изолация между клиентски организации: когато достъпът зависи от HTTP хедър

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

Как идентификаторът излиза извън доверения контекст

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

След това backend-for-frontend (BFF) може да извика услуги за поръчки, цени и наличности. При всяка защитена операция трябва да има проверима връзка между заявителя, избраната организация и разрешеното действие. Тя може да се предава чрез подписано твърдение, служебен токен с ограничен получател или удостоверен канал с изрично разрешено делегиране.

Скок 1  browser  ->  BFF
        Authorization: Bearer <session token>
        (няма хедър за наемател; наемателят е изведен от токена)

Скок 2  BFF  ->  order-sourcing service
        X-Tenant-Id:     1001        <- прочетен от сесията, сега низ
        X-User-Id:       4471
        X-Tenant-Schema: tenant_1001

Скок 3  order-sourcing  ->  inventory / pricing
        X-Tenant-Id:     1001        <- копиран дословно от скок 2
        X-Tenant-Schema: tenant_1001

Самият формат на хедъра не доказва уязвимост. В тази примерна верига копирането на хедъри без проверим механизъм на доверие би попречило на получаващата услуга да различи разрешения избор от неподкрепено твърдение на заявителя.

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

Когато никой не отговаря за проверката

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

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

Проверката за отделен обект също може да е недостатъчна. Поръчката действително може да принадлежи на организация 1002, но заявителят от организация 1001 да няма право да действа в нея. Сравняването на обекта с подадената организация не заменя проверката на правата на заявителя.

Четене на данните на друга клиентска организация

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

Базовата заявка на легитимния клиент:

POST /sourcing/v2/orders/search HTTP/1.1
Host: orders.internal.example.test
Authorization: Bearer <valid session for a user in tenant 1001>
X-Tenant-Id: 1001
X-User-Id: 4471
X-Tenant-Schema: tenant_1001
Content-Type: application/json

{"status":"OPEN","limit":25}

HTTP/1.1 200 OK    -> 25 поръчки, всички принадлежащи на наемател 1001

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

X-Tenant-Id: 1002
X-User-Id: 4471
X-Tenant-Schema: tenant_1002

HTTP/1.1 200 OK    -> поръчки, принадлежащи на наемател 1002

Решаващият резултат са записи на друга организация в отговора, получени с данни за достъп без права за нея. Това потвърждава четенето през границата между организациите. Само по себе си то не разкрива всички вътрешни проверки или точното място на пропуска.

Отрицателните тестови случаи дават и следните отговори:

X-Tenant-Id: 999999        (няма такъв наемател)  -> 200, празен набор резултати
X-Tenant-Id: not-a-number  (нечислов)             -> 200, празен набор резултати
X-Tenant-Id: 1002'         (добавена кавичка)     -> 200, празен набор резултати
X-Tenant-Id: (хедър отсъства)                     -> 200, празен набор резултати

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

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

Опитът за запис с непотвърдено въздействие

Опит за запис към същата услуга използва контекста на друга организация и невалидна дата. Документираният отговор е грешка при валидацията. Той не установява нито успешно премината проверка на правата, нито неразрешен запис.

POST /sourcing/v2/orders HTTP/1.1
Authorization: Bearer <valid session for a user in tenant 1001>
X-Tenant-Id: 1002
X-User-Id: 4471
X-Tenant-Schema: tenant_1002
Content-Type: application/json

{"sku":"AX-9","qty":5,"requestedDate":"31/02/2026"}

HTTP/1.1 422 Unprocessable Entity
{"errors":[{"field":"requestedDate","message":"invalid date format"}]}

Грешка при валидацията не доказва нито че операцията към друга организация е безопасно блокирана, нито че има заобикаляне на контрола на достъпа. Установете реалния ред на изпълнение и след това тествайте отново с иначе валидна заявка в рамките на договорения обхват и ограниченията за безопасност. Описвайте запис към друга организация като потвърден само когато доказателствата показват неразрешена промяна на състоянието или равностойна проверка, извършена с разрешение. Ако последваща валидна заявка не е тествана, посочете въздействието от записа като непотвърдено.

Въздействието от записа в тази статия е непотвърдено. Документираният пример не съдържа последваща заявка с валидни данни или доказателство за неразрешена промяна. Потвърденото четене остава отделна констатация.

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

• Проучете реалния ред на изпълнение. Подробностите за грешката могат да насочат прегледа, но грешка за поле не доказва премината проверка на правата. Използвайте код или журнали, когато са налични, без да извеждате невидими стъпки само от статуса.
• Повторете безопасно с валидни данни. В рамките на договорения обхват използвайте контролирани данни и проверете резултата. Сам по себе си отговор 2xx не доказва неразрешена промяна.
• Оценете ефекта и правата. Проверете дали е извършено защитено действие и дали заявителят има право да го предизвика. Страничен ефект при отговор за грешка не е автоматично нарушение на достъпа: важни са естеството на ефекта и правата за него.

Идентичността, която токенът не удостоверява

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

POST /api/checkout/order HTTP/1.1
Authorization: Bearer <token for user 7781, tenant 1001>
Content-Type: application/json

{
  "userId": "7782",
  "cartId": "c-9f12",
  "paymentMethodId": "pm-4411"
}

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

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

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

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

Съществуването също е информация

В същата програма е описан административен API с различни отговори за известен ресурс на друга организация, несъществуващ идентификатор и невалиден вход:

GET /api/admin/accounts/1001-A4F2   -> 403  (съществува, не е ваш)
GET /api/admin/accounts/1001-A4F3   -> 404  (не съществува)
GET /api/admin/accounts/not-an-id   -> 400  (неправилно оформен)

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

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

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

Контрол на достъпа преди защитеното действие

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

Довереният контекст може да идва от проверени данни за достъп, сървърна справка за правата или изрично делегиране между услуги. Изберете механизма според архитектурата и документирайте кой има право да задава съответния контекст. Подписаното твърдение също изисква подходящи проверки на издателя, получателя, валидността и правата.

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

Как да тествате изолацията между организации

Използвайте поне две контролирани организации и роли, които представят договорения модел на права. Администраторите и обикновените потребители са добра отправна точка; добавете делегирани, помощни и специализирани роли, когато са приложими.

Подгответе контролирани тестови данни и запишете очакваните права за всеки клас обекти. Разделете четенето от записването. Правилно филтриран списък не доказва нищо окончателно за крайна точка за промяна.

обект: поръчка 1001-A4F2 (наемател 1001)

принципал              GET    PATCH   DELETE
t1001 admin            allow  allow   allow
t1001 user (собственик) allow  allow   deny
t1001 user (друг)      deny   deny    deny
t1002 admin            deny   deny    deny
t1002 user             deny   deny    deny

Договорете матрицата на покритието преди тестването. Проверете включените в обхвата комбинации и посочете изрично пропуските. Включете администратори от друга организация и обикновени потребители: правата в една организация не трябва неявно да стават права в друга.

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

Не класифицирайте резултат само по статус кода. Отговор 400, 409, 422 или 500 нито потвърждава, нито опровергава заобикаляне на контрола на достъпа. Когато е възможно, установете реалния ред на изпълнение, след което повторете безопасно с иначе валидни данни и проверете защитения ефект. За предходния пример за запис няма документирана последваща заявка с валидни данни, затова въздействието остава непотвърдено.

Какво да изисквате от доставчика

Купувачът може да поиска конкретни доказателства и без достъп до реализацията. Започнете с тези три въпроса.

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

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

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