Osiguravanje dolaznih webhookova za više zakupaca putem provjere potpisa

Osiguravanje dolaznih webhookova za više zakupaca putem provjere potpisa.

Arhitektonski pregled dolazne provjere

Prilikom upravljanja CPaaS platformom s bijelom oznakom, zaštita vaših krajnjih točaka od lažiranih HTTP POST zahtjeva je od vitalne važnosti. Usmjeravanje za više zakupaca uvodi složene rubne slučajeve gdje dolazni SMS korisni teret podrijetlom s mobilnog uređaja može ciljati krivi podračun. Kako bi se uklonila neovlaštena ubacivanja, naš pristupnik potpisuje svako slanje webhooka pomoću HMAC-SHA256 potpisa izračunatog nad sirovim tijelom zahtjeva u kombinaciji s tajnom soli jedinstvenom za tog zakupca. Radnik za unos vaše platforme mora lokalno izračunati ovaj kriptografski sažetak.

Inspekcija kriptografskog zaglavlja i upravljanje tajnama

Svaka dolazna isporuka sadrži specijalizirano zaglavlje autorizacije koje obuhvaća kriptografski sažetak i vremensku oznaku. Vaš cjevovod unosa mora izdvojiti ovaj token i potvrditi da je starost zahtjeva unutar uskog prozora tolerancije, obično pet minuta, kako bi se spriječili napadi ponovnim slanjem. Tajne se dinamički dodjeljuju kada zakupci dovrše JIT provizioniranje putem API-ja naše platforme. Budući da održavamo strogi model unaprijed plaćanja, aktivni saldo je obavezan; računi koji padnu ispod granice unaprijed plaćenog iznosa od 20 USD pokreću automatsku obustavu isporuke.

Rukovanje parsiranjem korisnog tereta i E.164 normalizacijom

Jednom kada provjera potpisa uspije, vaš radnik parsira JSON korisni teret kako bi izvukao brojeve pošiljatelja, tokene usmjeravanja odredišta i tekst poruke. Svi brojevi prolaze kroz strogu E.164 normalizaciju prije ulaska u red čekanja za obradu. Ako zakupac upravlja kampanjama visokog volumena koje se približavaju stabilnoj brzini potrošnje od 1000 USD mjesečno, naš sustav pokreće blagu recenziju blizu 1000 USD mjesečno kako bi potvrdio legitimitet prometa i optimizirao parametre usmjeravanja. Tijekom ove faze nadzorne ploče telemetrije prate kašnjenje webhooka i stope uspješnosti HTTP 200.

Ublažavanje napada ponovnim slanjem i pomaka sata

Kašnjenje mreže i manje diskrepancije sata poslužitelja mogu uzrokovati trenje provjere ako se njima ne upravlja ispravno. Implementacija predmemorije kliznog nonca osigurava da se identični potpisi webhooka ne mogu zlonamjerno ponovno prenositi. Ako vaša krajnja točka unosa vrati statusni kod koji nije 2xx zbog privremenog zaključavanja baze podataka, platforma stavlja u red siguran ponovni pokušaj. Osigurajte da vaši radnici obrađuju ove ponovne pokušaje idempotentno kako biste spriječili dupliciranje DLR obrade i dvostruko naplaćivanje u vašim knjigama podračuna.

Rješavanje problema neuspjelih potpisa i revizije glavne knjige

Ako provjera potpisa ne uspije, pregledajte sirova HTTP zaglavlja i potvrdite da posredni poslužitelji ne mijenjaju razmake u tijelu zahtjeva. Administratori mogu usporediti neuspjele pokušaje isporuke u revizijskim zapisnicima platforme. Za dubinsku financijsku i sistemsku analizu, pogledajte ove resurse: ponavljanja dolaznog webhooka · Drugi dolazni broj: primopredaja pretinca bez miješanih niti · Zadržavanje revizijskih zapisnika: što kupci mogu izvesti i dokazati.

Započnite s IOSOR-om

POST-ajte potpisani dolazni događaj tajnom najmoprimca B na kraj najmoprimca A. Provjera mora odbiti. Zakrenite tajnu jednog najmoprimca i dokažite da pada samo njegov webhook. Izvezite pad potpisa naspram id-a najmoprimca. To je HMAC po najmoprimcu, ne izolacija popisa STOP i ne debit prozora replay.

Sažetak IOSOR

Jedan URL webhooka nije jedna tajna.

Radite: provjerite HMAC prema najmoprimcu koji ima DID. Ne radite: dijeliti jedan ključ potpisa među podračunima niti primati nepotpisani MO kao unutarnji.