Partner API Authorization Preizkusi za portale preprodajalcev AI API

Partner API za portale preprodajalcev mora domnevati, da je vsak ID objekta v zahtevi mogoče kopirati, uganiti, ponovno predvajati, zabeležiti z drugo integracijo ali prenesti prek napačnega orodja osebja. Glavna težava ni, ali so ID-ji strank neprozorni. Težava je v tem, ali vsako dejanje dokaže, da klicatelj, partnerski račun, ciljni najemnik, predmet, lastnina in stanje odobritve sodijo skupaj.

To je najbolj pomembno pri AI API portalu preprodajalcev, ker API običajno izpostavi zelo vplivne objekte nadzorne ravnine: nadaljnje stranke, navidezne API ključe, denarnice, kreditne prilagoditve, izvoze uporabe, destinacije webhook, uporabnike osebja in nujne zamrznitve. Eno samo manjkajoče preverjanje avtorizacije lahko eni stranki omogoči branje uporabe druge stranke, dovoli žetonu osebja, da premakne kredite med najemniki, ali dovoli žetonu avtomatizacije, da prekliče ključ, ki ga ne bi smel nikoli videti.

Dejstvo: OWASP API Security 2023 navaja raven pokvarjenega objekta Authorization kot API1 in raven lastnosti pokvarjenega predmeta Authorization kot API3. V praksi preverjanja na ravni objekta odgovarjajo na to, ali lahko ta klicatelj deluje na tem objektu? medtem ko preverjanja na ravni lastnosti odgovarjajo "ali lahko ta klicatelj nastavi ali prebere to polje?" Oboje je prvovrstna skrb za Partner API design.

Določite Authorization pogodbo pred pisanjem testov

Authorization testi so uporabni samo, če testirajo glede na izrecno pogodbo o pravilniku. Začnite z matriko, ki opisuje, kateri akter lahko izvede katero dejanje na katerem cilju in pod kakšnimi pogoji. Ne zanašajte se na imena končnih točk ali vloge uporabniškega vmesnika kot pravilnik.

Uporabna matrika ima te stolpce:

• Vrsta igralca: lastnik partnerja, skrbnik partnerja, finančni operater, operater podpore, žeton za avtomatizacijo, skrbnik stranke, uporabnik stranke samo za branje.
• Partnerski račun: račun preprodajalca ali agencije, ki ima v lasti razmerje s strankami na nižji stopnji.
• Ciljni najemnik: nižji račun stranke, ki se ustvari, zaračuna, pregleda, začasno ustavi ali izbriše.
• Vrsta predmeta: stranka, navidezni ključ, denarnica, vnos v knjigo, poročilo o uporabi, končna točka webhook, uporabnik osebja, profil cen, preslikava ponudnika.
• Dejanje: ustvarjanje, branje, seznam, posodobitev, preklic, polnjenje, vračilo, izvoz, zamrznitev, odmrznitev.
• Monetarni organ: ali dejanje spremeni stanje, kreditni limit, maržo, stanje poravnave, stanje računa ali omejitve porabe.
• Stanje odobritve: ali je zahteva predhodno odobrena, čaka na odobritev, dvojno odobrena, potekla ali samo v sili.

Na primer, operaterju podpore je morda dovoljeno, da si ogleda metapodatke zamaskiranega ključa stranke in zamrzne ključ med incidentom, ne more pa ustvariti kreditov, spremeniti kataloga cen, izvoziti celotne podatke o uporabi ali odmrzniti ključa brez odobritve. Finančni operater lahko ustvari kreditno prilagoditev za stranko, ki je v lasti istega partnerja, vendar samo v okviru konfiguriranega zneska in šele, ko obstaja zapis o odobritvi.

Priporočilo: zapišite matriko kot artefakt z različicami, nato pa naj se vsako ime avtorizacijskega preizkusa sklicuje na vrstico ali pravilo. Ko se pravilnik spremeni, mora diff prikazati spremembo pogodbe in preskusno spremembo.

Uporaba referenc na objekte, vezane na najemnika

Neprozorni ID-ji zmanjšajo tveganje oštevilčenja, vendar ne dokazujejo avtorizacije. ID navideznega ključa, ID denarnice, ID vnosa v knjigo, ID izvoza uporabe ali žeton kazalca mora biti razrešen znotraj pričakovane meje partnerja in najemnika.

Vzorec varnega iskanja je:

resolve object where
  object.id = request.object_id
  and object.partner_id = actor.partner_id
  and object.customer_id = request.customer_id
  and actor has action_scope for object_type/action
  and object.state allows action

Nevaren vzorec je:

object = find_by_id(request.object_id)
if actor.has_scope("keys:revoke"):
  revoke(object)

Druga različica dovoljuje posedovanje obsega, ne avtoritete nad ciljem. Ne uspe, ko veljaven žeton za partnerja A predloži ID ključa od partnerja B ali ko operater za stranko A predloži ID denarnice od stranke B.

Povezava najemnika mora zajemati več kot očitne predmete. Vključite žetone kurzorja za poročila o uporabi, ID-je izvoznih opravil, ID-je končnih točk webhooka, ID-je odobritev, ključe idempotence in ID-je prilagoditve glavne knjige. Ti predmeti se pogosto zdijo »notranji«, ravno zato postanejo šibke točke.

Izdelajte minimalno preskusno napravo za navzkrižne najemnike

Uporabite namerno majhno vpenjalo, ki olajša izražanje napačnega dostopa. Cilj ni velika količina podatkov. Cilj je jasna ločitev.

Partner P1
  Staff: p1_owner, p1_support, p1_finance
  Token: p1_full_token, p1_support_token, p1_finance_token
  Customer C1A
    Key K1A
    Wallet W1A
    Usage cursor U1A
    Ledger entry L1A
  Customer C1B
    Key K1B
    Wallet W1B
    Usage cursor U1B
    Ledger entry L1B

Partner P2
  Staff: p2_owner
  Token: p2_full_token
  Customer C2A
    Key K2A
    Wallet W2A
    Usage cursor U2A
    Ledger entry L2A

Ta napeljava vam omogoča testiranje dveh razredov napak. Prvič, dostop med strankami istega partnerja, kjer se klicatelj iz P1 poskuša dotakniti C1B, medtem ko deluje na C1A. Drugič, dostop med partnerji, kjer se žeton P1 poskuša dotakniti predmetov P2.

Priporočilo: zaženite isti sistem za javnega partnerja API in zaledje portala prodajalca. Omejitve uporabniškega vmesnika ne ščitijo neposrednih API odjemalcev, opravil v ozadju, razvijalskih orodij brskalnika ali ogroženih integracijskih žetonov.

Preizkus ravni objekta Authorization na vsaki končni točki z velikim vplivom

Za vsako končno točko, ki sprejme ID objekta, ustvarite vsaj en pozitiven test in več negativnih testov. Pozitivni testi dokazujejo, da je naprava veljavna. Negativni testi dokazujejo, da meja drži.

Ustvarjanje in iskanje strank

Ustvarjanje stranke je običajno videti neškodljivo, ker ciljni najemnik še ne obstaja. Še vedno potrebuje pooblastilo, ker lahko klicatelj poskuša ustvariti stranke pri drugem partnerju, dodeliti prepovedan cenovni profil ali nastaviti notranje metapodatke.

Preizkusni primeri:

• Lastnik partnerja lahko ustvari stranko pod istim partnerjem.
• Žeton za avtomatizacijo z obsegom zagotavljanja stranki lahko ustvari stranko pod istim partnerjem.
• Žeton samo za podporo ne more ustvariti stranke.
• Žeton P1 ne more ustvariti stranke z partner_id=P2.
• Žeton na ravni stranke ne more navesti sorodnih strank.

Ustvarjanje ključa, preklic in rotacija

Ključna dejanja življenjskega cikla imajo velik vpliv, ker omogočajo dostop do časa izvajanja in lahko prekinejo proizvodne delovne obremenitve. Nadzorne ravnine ponudnika običajno izpostavijo skrbniške objekte, kot so projekti, delovni prostori, storitveni računi, člani in ključi API prek API-jev. Niz prehoda ali preprodajalca mora enako skrbno ravnati s svojimi virtualnimi ključi.

Preizkusni primeri:

• Avtomatizacija P1 lahko ustvari K1A samo za C1A, če njegov žeton vključuje obseg pisanja ključev.
• Podpora P1 ne more ustvariti K1A, če je vloga podpore samo za branje za ključe.
• Podpora za P1 lahko zamrzne K1A le, če je na voljo zamrznitev v sili.
• Podpora za P1 ne more preklicati K1B, ko kontekst zahteve pravi C1A.
• P1 polnega žetona ne more preklicati K2A.
• Skrbnik stranke za C1A ne more zamenjati, razkriti ali preklicati K1B.

Za ekipe, ki izvajajo Partner API avtomatizacijo, pomemben preizkus ni samo "ali ta žeton omogoča pisanje ključev?" To je "ali ima ta žeton možnost pisanja ključev za tega partnerja, to stranko, ta ključ, to stanje in to operacijo?"

Popolnitve kredita in spremembe denarnice

Dejanja za premikanje denarja zahtevajo strožje preizkuse kot običajne posodobitve. Polnjenje kredita je lahko sintaktično pravilno in je še vedno nepooblaščeno, ker denarnica pripada drugemu najemniku, znesek presega pooblastilo, zapis odobritve cilja na drugo stranko ali pa je bil ključ idempotence prvič uporabljen za drugo operacijo.

Preizkusni primeri:

• P1 Finance lahko po odobritvi dopolni W1A v okviru svoje omejitve zneska.
• P1 finance ne more dopolniti W1B z odobritvijo, ustvarjeno za W1A.
• P1 finance ne more dopolniti W2A.
• Podpora P1 ne more napolniti nobene denarnice.
• Žeton za avtomatizacijo ne more spremeniti kreditne omejitve, razen če ima izrecno določen obseg premikanja denarja.
• Ponovno predvajan ključ idempotence ne more preusmeriti predhodnega polnjenja W1A na W1B.

Priporočilo: obravnavajte ključe idempotence kot obseg partnerja plus operacija plus ciljni najemnik plus normalizirano telo zahteve. Ponovni poskus bi moral biti varen, vendar ne bi smel postati kanal za trk med najemniki.

Poročila o uporabi in izvozni kazalci

Poročila o uporabi je enostavno premalo zaščititi, ker so samo za branje. V sistemih preprodajalcev lahko podatki o uporabi razkrijejo imena strank, delovne obremenitve, izbire modelov, stroške, identifikatorje končnih uporabnikov in komercialne marže. Cursor žetoni in izvozni ID-ji morajo biti prav tako vezani na najemnika.

Testni primeri:

• Skrbnik C1A lahko bere segmente uporabe C1A.
• Skrbnik C1A ne more brati uporabe C1B s spreminjanjem customer_id.
• Analitični žeton P1 samo za branje lahko izvozi uporabo za stranke P1 samo, če je prisoten obseg izvoza.
• Žeton P1 ne more nadaljevati izvoza uporabe P2 s kopiranim kazalcem.
• Kazalca, ustvarjenega za poročilo na ravni ključa, ni mogoče ponovno uporabiti za pridobitev uporabe celotnega najemnika, razen če je to izrecno dovoljeno.

Če portal razkrije AI API merjenje uporabe strank, preizkusite poglede povzetkov in izvoze, ki jih je mogoče prenesti. Izvozne poti pogosto obidejo isti krmilnik ali kodo pravilnika, ki jo uporabljajo interaktivne strani.

Preizkusite raven lastnosti Authorization na POPRAVKU in posodobite končne točke

Broken Object Property Level Authorization se prikaže, ko ima klicatelj dovoljenje za posodobitev predmeta, lahko pa tudi nastavi polja, ki morajo biti interna, privilegirana ali v lasti drugega poteka dela.

Za partnerske API-je občutljiva polja pogosto vključujejo:

• partner_id, customer_id in polja za nadrejeno lastništvo.
• provider_project_id, provider_workspace_id in zgornje ključne reference.
• pricing_catalog_version, margin_tier in preglasitve popustov.
• wallet_balance, credit_limit, settlement_status in stanje računa.
• fraud_status, risk_score in oznake skladnosti.
• role, scopes in zastavice za obhod odobritve.

Uporabljajte sezname dovoljenih, ne zavrnitvenih. Na primer, končna točka posodobitve profila stranke lahko dovoljuje display_name, billing_email in metadata.external_reference. Moral bi zavrniti ali prezreti margin_tier, credit_limit in provider_project_id, tudi če klicatelj lahko posodobi predmet stranke.

PATCH /partner/customers/C1A
{
  "display_name": "Acme Support Team",
  "margin_tier": "internal_zero_margin",
  "provider_project_id": "provider-project-owned-by-C1B"
}

Pričakovani rezultat mora biti determinističen. Prednostna napaka pri preverjanju, ki identificira nedovoljena polja, ne da bi razkrila občutljive notranje vrednosti. Ne sprejmite tiho privilegiranih polj in jih nato prezrite, razen če vaša API pogodba že dosledno uporablja ta vzorec.

Naredi zavrnitve brez naštevanja

Negativni testi bi morali preveriti statusne kode in obliko odgovora. Če žeton P1 zahteva K2A, odgovor ne sme razkriti, ali K2A obstaja pod drugim partnerjem.

Pogosto pravilo je:

• Uporabite 401, ko klicatelj ni preverjen.
• Uporabite 403, ko je klicatelj preverjen, vendar nima obsega dejanja v lastni meji.
• Uporabite 404 ali generični odgovor ni najdeno, ko je predmet zunaj klicateljeve meje in obstoj ne sme biti razkrit.

Natančna konvencija se lahko razlikuje, vendar mora biti vedenje dosledno. Telo zavrnitve bi se moralo izogibati sporočilom, kot je »ključ pripada drugi stranki« ali »denarnica obstaja pod partnerjem P2«. Te informacije so uporabne za napadalce in le redko uporabne za zakonite stranke.

Kompromis: splošne zavrnitve partnerskim razvijalcem otežijo odpravljanje napak. Rešite to z ID-ji zahtev, strukturiranimi revizijskimi dnevniki in podpornimi orodji, ne pa z uhajanjem obstoja med najemniki v javnih API napakah.

Zabeležite Authorization odločitev, neobčutljive obremenitve

Authorization testi bi morali tudi trditi, da zavrnitve ustvarijo koristne notranje dokaze. Potrebujete dovolj podrobnosti, da rekonstruirate, kaj se je zgodilo med incidentom, ne da bi shranili neobdelane pozive, skrivnosti ali nepotrebne podatke o strankah.

Polja dnevnika morajo vsebovati:

• request_id in ID korelacije sledi.
• actor_id, vrsta igralca, ID žetona in predloga vloge.
• partner_id od overjenega igralca.
• Zahtevan ciljni najemnik in razrešen ciljni najemnik, ko je razrešitev dovoljena.
• Vrsta predmeta in dejanje.
• Različica pravilnika in rezultat odločitve.
• Koda vzroka zavrnitve, kot je missing_scope, tenant_mismatch, approval_required ali field_not_allowed.

Ne beležite celotnih API ključev, skrivnosti ponudnika navzgor, pozivov, koristnih podatkov o neobdelani uporabi ali celotne izvozne vsebine. Za zavrnjene zahteve navzkrižnih najemnikov bodite previdni, da so notranji dnevniki nadzorovani z dostopom; javni odziv je lahko splošen, medtem ko ima varnostna ekipa še dovolj dokazov.

Avtomatizirajte pas v CI in uprizarjanju

Preizkusni snop bi se moral izvajati na treh mestih: testi enot za funkcije pravilnika, integracijski testi za API končne točke in uprizoritvene sonde proti razporejenemu zaledju portala prodajalca. Vsaka plast lovi različne napake.

Praktična struktura CI:

authz-tests/
  fixtures/
    partners.json
    customers.json
    roles.json
    tokens.json
  matrix/
    keys.yaml
    wallets.yaml
    usage_exports.yaml
    customers.yaml
  tests/
    test_keys_authz.ts
    test_wallet_authz.ts
    test_usage_authz.ts
    test_patch_allowlists.ts

Vsaka vrstica matrike mora definirati akterja, zahtevo, pričakovano odločitev in pričakovano vedenje brez naštevanja.

- name: p1_support_cannot_revoke_p2_key
  actor: p1_support_token
  method: POST
  path: /partner/customers/C2A/keys/K2A/revoke
  expected_status: 404
  expected_error_code: not_found
  expected_audit_reason: tenant_mismatch

Dodajte različice v slogu mutacije, ki zamenjajo en identifikator naenkrat: ID stranke, ID ključa, ID denarnice, ID odobritve, kazalec, ključ idempotence in ID končne točke webhook. Ti testi so zasnovani kot ponavljajoči se. Ponavljanje je sprejemljivo, če dokazuje, da ima vsak identifikator neodvisen obseg.

Operativni kontrolni seznam

Pred pošiljanjem končne točke partnerja API uporabite ta kontrolni seznam:

• Končna točka ima imenovano avtorizacijsko pravilo v matriki pravilnika.
• Vsako iskanje objekta vključuje mejne pogoje partnerja in najemnika.
• Vsaka končna točka seznama se filtrira glede na mejo akterja pred paginacijo.
• Vsak kazalec, ID izvoza, ID webhooka, ID odobritve in ključ idempotence so omejeni.
• Končne točke PATCH uporabljajo dovoljene sezname lastnosti glede na vlogo in dejanje.
• Dejanja premikanja denarja zahtevajo izrecno območje in stanje odobritve.
• Zamrznitev v sili je ločena od odmrznitve in kreditnega organa.
• Zavrnitve preprečujejo uhajanje informacij o obstoju med najemniki.
• Revizijski dnevniki beležijo odločitev o avtorizaciji in različico pravilnika.
• Enaki negativni testi se izvajajo na API in zalednih poteh portala.

Kompromisi za eksplicitno odločitev

Drobno zrnati daljnogledi zmanjšajo radij eksplozije, vendar povečajo zapletenost vkrcanja partnerja. Privzete predloge vlog pomagajo: lastnik, finance, podpora, analitika, avtomatizacija zagotavljanja in odziv v sili. Naj naprednejši partnerji prilagodijo te predloge, namesto da začnejo z neobdelanimi obsegi.

Strogi seznami dovoljenih lastnosti upočasnjujejo uvajanje funkcije, ker je za vsako novo polje, ki ga je mogoče urejati, potrebna sprememba pravilnika. To trenje je uporabno za zaračunavanje, cene, preslikavo ponudnikov in polja za upravljanje ključev. Za polja profila z nizkim tveganjem je postopek lahko lažji.

Tokovi odobritve zmanjšajo nenamerne ali zlonamerne spremembe kredita, vendar dodajo zakasnitev zakonitim operacijam podpore. Zamrzovanje v sili naj bo hitro, reverzibilno in ločeno. Ne dovolite, da isti žeton za nujne primere dodaja kredite, spreminja marže, izvozi uporabo in odmrzne račune.

Predvidevanje: portali preprodajalcev bodo še naprej izpostavljali več skrbniških dejanj prek partnerskih API-jev, ker stranke pričakujejo samopostrežno zagotavljanje, poročanje in avtomatizacijo. Sistemi, ki se dobro starajo, bodo tisti z avtorizacijskimi pogodbami in negativnimi testi, ne pa tisti, ki se zanašajo samo na poimenovanje poti, skrite kontrole uporabniškega vmesnika ali neprozorne ID-je.

Uporabni sklep

Zgradite avtorizacijski snop, preden partner API postane dovolj velik, da ima vsaka končna točka svojo izjemo. Začnite z dvema partnerjema, dvema strankama pod enim partnerjem, eno stranko pod drugim partnerjem in majhnim naborom žetonov. Nato preizkusite dejanja, ki vam lahko najbolj škodijo: ustvarjanje ključa, preklic ključa, polnitve kredita, izvozi uporabe, posodobitve denarnice, ponovna uporaba odobritve, ponovitev idempotence in polja PATCH.

Pogodbo je preprosto določiti: klicatelj mora imeti pravi obseg, pod pravim partnerjem, za pravega najemnika, predmet, lastnino, dejanje, znesek in stanje odobritve. Implementacijsko delo to zagotavlja na vseh končnih točkah, vključno z dolgočasnimi.

Sorodno branje

• idempotentni partner API avtomatizacija za zagotavljanje ključev in kreditov