Zabezpečení příchozích webhooků pro více tenantů pomocí ověření podpisu

Zabezpečení příchozích webhooků pro více tenantů pomocí ověření podpisu.

Architektonický přehled příchozího ověřování

Provozování white-label platformy CPaaS vyžaduje zabezpečení koncových bodů před zfalšovanými požadavky HTTP POST. Routing pro více tenantů zavádí složité okrajové případy, kdy příchozí payload SMS generovaný mobilem může cílit na nesprávný podúčet. Aby se eliminovaly neoprávněné injekce, naše brána podepisuje každé odeslání webhooku pomocí podpisu HMAC-SHA256 vypočítaného nad surovým tělem požadavku v kombinaci s tajnou solí jedinečnou pro daného tenanta. Pracovník pro příjem vaší platformy musí spočítat tento kryptografický hash lokálně a porovnat jej s příchozí hlavičkou HTTP.

Kontrola kryptografické hlavičky a správa tajemství

Každé příchozí doručení obsahuje specializovanou autorizační hlavičku obsahující kryptografický digest a časové razítko. Vaše potrubí pro příjem musí tento token extrahovat a potvrdit, že stáří požadavku spadá do úzkého tolerančního okna, obvykle pěti minut, aby se zabránilo útokům přehráním. Tajemství jsou dynamicky zřízena, když tenenti dokončí zřizování JIT prostřednictvím našeho API platformy. Protože udržujeme přísný model předplacení, aktivní zůstatek je povinný; účty klesající pod předplacenou hranici 20 USD spouštějí automatické pozastavení doručení.

Zpracování analýzy payloadu a normalizace E.164

Jakmile je ověření podpisu úspěšné, váš pracovník analyzuje JSON payload k extrakci čísel odesílatelů, směrovacích tokenů cíle a textu zprávy. Všechna čísla podléhají přísné normalizaci E.164 před vstupem do fronty zpracování. Pokud tenant zpracovává vysokokapacitní kampaně, které se blíží stálé rychlosti spotřeby 1 000 USD/měsíc, náš systém zahájí měkkou recenzi poblíž 1 000 USD/měsíc k ověření legitimity provozu a optimalizaci parametrů routování. Během této fáze řídicí panely telemetrie sledují latenci webhooku a míru potvrzení HTTP 200.

Zmírnění útoků přehráním a driftu hodin

Latence sítě a drobné odchylky hodin serveru mohou způsobit tření při ověřování, pokud nejsou správně spravovány. Implementace klouzavé mezipaměti nonce zajišťuje, že identické podpisy webhooku nelze zlomyslně přenést znovu. Pokud váš koncový bod vrátí stavový kód mimo 2xx kvůli dočasnému zámku databáze, platforma zařadí bezpečné opakování do fronty. Je zásadní, aby vaši pracovníci zpracovávali tato opakování idempotentně, aby se zabránilo duplicitnímu zpracování DLR a chybám v hlavní knize.

Řešení problémů se selhanými podpisy a audity hlavní knihy

Pokud ověření podpisu selže, zkontrolujte surové hlavičky HTTP a potvrďte, že mezilehlé proxy nemění mezery v těle požadavku. Správci mohou křížově odkazovat na neúspěšné pokusy o doručení v auditech platformy. Pro hloubkovou finanční a systémovou analýzu se podívejte na tyto zdroje: opakování příchozího webhooku · Druhé příchozí číslo: předání schránky bez smíšených vláken · Uchovávání auditních protokolů: co mohou kupující exportovat a dokázat.

Začněte s IOSOR

POST-něte podepsanou příchozí událost se tajemstvím nájemce B na konec nájemce A. Kontrola musí odmítnout. Otočte tajemství jednoho nájemce a dokažte, že padá jen jeho webhook. Exportujte selhání podpisu proti id nájemce. Je to HMAC na nájemce, ne izolace seznamu STOP a ne debit okna replay.

Shrnutí IOSOR

Jedna URL webhook není jedno tajemství.

Dělejte: ověřte HMAC proti nájemci, který vlastní DID. Nedělejte: sdílet jeden podpisový klíč mezi podúčty ani brát nepodepsané MO jako interní.