Viltots maksājuma paziņojums: kā pārbaudīt webhook izcelsmi pirms pasūtījuma izpildes

Maksājuma paziņojums nedrīkst sākt pasūtījuma izpildi tikai tāpēc, ka tā saturs izskatās ticams. Vispirms jāveic webhook paraksta pārbaude atbilstoši konkrētā piegādātāja protokolam, saglabājot pārbaudei vajadzīgo sākotnējo saturu un pārbaudot piegādes aktualitāti. Pēc tam jānoskaidro, vai notikums attiecas uz pareizo vidi, kontu un pasūtījumu un vai tas tiešām atļauj paredzēto darbību. Dublikātu novēršana ir vēl atsevišķa kontrole. Derīgs identifikators vai vēl neredzēts notikums nepierāda autentisku izcelsmi.

Kur uzņēmums sāk uzticēties ārējam paziņojumam

Sāciet pārbaudi ar biznesa darbību, ne tehnisku bibliotēku sarakstu. Kas sistēmā notiek, kad pienāk paziņojums? Var tikt atzīmēta apmaksa, rezervēta prece, piešķirta piekļuve vai izveidots uzdevums noliktavai. Atrodiet pirmo vietu, kur ārējā ievade var izraisīt šādas sekas.

Lūdziet izstrādātājam parādīt, kāda pārbaude izpildās pirms šīs vietas. Atbilde “mēs saņemam tikai maksājumu sistēmas datus” nav pietiekama. Publiski sasniedzams adreses ceļš nav pats par sevi sūtītāja identitātes apliecinājums. Vajadzīgs pārbaudāms mehānisms un skaidrs noraidījuma ceļš.

Iedomāsimies, ka sistēma no ienākoša teksta nolasa pasūtījuma numuru un statusu, pēc tam nodod pasūtījumu noliktavai. Ja uzticamības pārbaude paredzēta tikai vēlāk, biznesa darbība jau var būt sākusies. Tas ir ilustratīvs projektēšanas risks, ne apgalvojums par kāda konkrēta uzņēmuma ievainojamību.

Pārbaudes mērķis ir pierādīt secību: vispirms uzticams notikums, pēc tam atļauta darbība. OWASP transakciju autorizācijas vadlīnijas uzsver servera puses kontroli un gala pārbaudi pirms izpildes. Integrācijas pasūtītājam tas nozīmē prasīt pierādījumu, ka kritisko pārbaudi nevar apiet ar citu ievades ceļu.

Webhook paraksta pārbaude un idempotence risina dažādus jautājumus

Paraksta pārbaude konkrētā protokola ietvaros sasaista saņemto saturu ar uzticamo parakstīšanas mehānismu. Tā nav vispārīga garantija, ka pasūtījumu drīkst izpildīt. Arī autentisks notikums var attiekties uz citu vidi vai darbību, kurai jūsu sistēmai nevajadzētu reaģēt.

Idempotences kontrole nosaka, vai konkrētās darbības sekas jau ir radušās. Tā nevar aizstāt izcelsmes pārbaudi: ļaunprātīgs pieprasījums var saturēt iepriekš neredzētu identifikatoru. Savukārt autentiskuma pārbaude viena pati nenovērš atkārtotu izpildi. Detalizēts dublikātu novēršanas modelis aplūkots rakstā par idempotenci integrācijās.

Prasībās šīm kontrolēm norādiet atsevišķus sagaidāmos rezultātus. Ja tests rāda, ka atkārtots notikums nerada otru pasūtījumu, tas vēl nepierāda viltota notikuma noraidīšanu. Ja viltots paraksts tiek noraidīts, vēl jāpārbauda, vai jau apstrādāts derīgs notikums nerada tās pašas sekas vēlreiz.

Neizmantojiet statusu “pārbaudīts” bez paskaidrojuma. Tam jānorāda, vai pārbaudīta izcelsme, satura shēma, biznesa nosacījumi vai izpildes vēsture. Vienā vispārīgā lauciņā apvienotas pārbaudes apgrūtina gan kļūmju diagnostiku, gan drošības pieņemšanu.

Kāpēc vajadzīgs sākotnējais pieprasījuma saturs

Stripe piemērā validācijai izmanto sākotnējo pieprasījuma saturu jeb raw body, galveni Stripe-Signature un konkrētā saņemšanas punkta noslēpumu. Stripe kļūdu diagnostikas dokumentācija brīdina, ka JSON pārveidošana, atstarpju maiņa vai cita satura pārserializācija var izjaukt paraksta pārbaudi. Semantiski līdzīgs JSON nav obligāti tie paši pārbaudāmie baiti.

Tāpēc integrācijas izstrādātājam jāizseko pieprasījums no saņemšanas līdz validācijai. Kurā brīdī ietvars pārveido saturu? Vai starpnieks to pārraksta? Vai pārbaude saņem sākotnējo datu plūsmu vai vēlāk no objekta izveidotu tekstu? Šos jautājumus var pārbaudīt testa vidē, neizpaužot produkcijas noslēpumus.

Sākotnējā satura saglabāšana pārbaudei nenozīmē pienākumu bez termiņa glabāt visus maksājumu datus parastos žurnālos. Nosakiet, kas vajadzīgs diagnostikai, kur šie dati atrodas un kam tie pieejami. Ikdienas novērošanai bieži lietderīgāks ir droši atlasīts tehnisks kopsavilkums, ne pilns personas un maksājuma informācijas izraksts.

Ja paraksta pārbaude neizdodas, neatrisiniet to, izslēdzot validāciju. Vispirms nodaliet iespējamās neatbilstības: saturs ir mainīts, izmantota nepareiza konfigurācija vai nav saņemta gaidītā galvene. Pārbaudiet šos variantus kontrolētā vidē. Kļūdas pazušana pēc pārbaudes atslēgšanas nav integrācijas labojums.

Noslēpums, vide un laiks jāsaista ar konkrēto saņemšanas punktu

Noslēpumu izvēlei jābūt uzticamai konfigurācijai. Ienākošais pieprasījums nedrīkst patvaļīgi norādīt failu vai adresi, no kurienes paņemt pārbaudes materiālu. Ja integrācija apkalpo vairākus kontus, paredziet ierobežotu un pārbaudāmu atbilstību starp saņemšanas punktu un atļauto kontu.

Stripe dokumentācijā norādīts, ka lokālās CLI pārsūtīšanas un vadības panelī reģistrētā saņemšanas punkta noslēpumi atšķiras. Vienāds prefikss nepierāda vienādu vērtību. Šī atšķirība ir biežs diagnostikas jautājums, bet tā nav iemesls izdrukāt noslēpumus koplietojamā konsolē vai pievienot tos atbalsta pieteikumam.

Stripe webhook vadlīnijas apraksta parakstītu laika zīmogu, piegādes svaiguma pārbaudi un noslēpumu rotāciju. Atkārtotai piegādei tiek izveidots jauns paraksts un laika zīmogs. Tātad jānošķir notikuma sākotnējais laiks no konkrētās piegādes autentifikācijas datiem.

Konkrēto pieļaujamo laika logu izvēlieties pēc piegādātāja dokumentācijas un integrācijas darbības apstākļiem. Universālu robežu visām maksājumu sistēmām izmantot nedrīkst. Pieņemšanas pārbaudē iekļaujiet arī servera pulksteņa neatbilstības gadījumu, lai komanda zinātu, kā tas izskatās un kurš par to saņem brīdinājumu.

Noslēpumu maiņai sagatavojiet pārbaudāmu secību: kur tiek atjaunota konfigurācija, kā pārliecinās par jaunā materiāla izmantošanu un kad vecais vairs nav pieņemams. Ja piegādātājs paredz pārejas periodu, tā robežas jākontrolē. Ja pastāv aizdomas par kompromitēšanu, parasta plānotas rotācijas procedūra var nebūt pietiekama; nepieciešams incidenta izvērtējums.

Pēc autentiskuma pārbaudes vēl paliek biznesa lēmums

Definējiet, kuri notikumi vispār drīkst sākt pasūtījuma izpildi. Nepietiek, ka nosaukumā ir vārds “maksājums”. Piegādātāja notikumu nozīme jāsasaista ar uzņēmuma pasūtījuma stāvokļiem. Testa vides notikums nedrīkst palaist reālu izsniegšanu, un cita konta maksājums nedrīkst apstiprināt jūsu pasūtījumu.

Pārbaudiet pasūtījuma saikni, sagaidāmo summu un valūtu, kā arī paša pasūtījuma pašreizējo stāvokli. Šie ir sistēmas prasībās nosakāmi biznesa nosacījumi, ne paraksta algoritma uzdevums. Ja pasūtījums jau atcelts vai mainīts, autentisks vecāks paziņojums nav atļauja ignorēt jauno situāciju.

Ja nepieciešams atsevišķi nolasīt aktuālo maksājuma objektu no piegādātāja, arī šis solis jāveido ar uzticamu konta konfigurāciju un skaidru kļūmes ceļu. Neveiksmīgu nolasīšanu nedrīkst traktēt kā apstiprinājumu. Nezināms stāvoklis paliek nezināms, līdz ir iegūts pietiekams pamatojums darbībai.

Uzņēmuma atbildīgajam jāspēj paskaidrot lēmumu vienā teikumā: konkrētā pasūtījuma izpildi atļāva šis pārbaudītais notikums un šie izpildītie nosacījumi. Ja pamatojums ir tikai “pienāca paziņojums”, prasības vēl nav pietiekami precīzas.

Darba rinda nedrīkst kļūt par uzticības apiešanas ceļu

Ieteicams atdalīt saņemšanu un pārbaudi no ilgākas pasūtījuma apstrādes. Taču rindā ievietotajam darbam jāsaglabā saikne ar pārbaudīto notikumu. Patvaļīgs neapstrādāts pieprasījums nedrīkst kļūt par uzticamu izpildes uzdevumu tikai tāpēc, ka tas nonācis iekšējā rindā.

Noskaidrojiet, kas drīkst rindā rakstīt un mainīt uzdevumus. Ja cits sistēmas ceļš var izveidot to pašu izpildes komandu bez pārbaudes, korekts webhook saņēmējs vēl neaizsargā visu procesu. Pārbaudi ārējā ieejas punktā papildiniet ar gala kontroli pie biznesa darbības.

Saņemšanas apstiprinājumu plānojiet tā, lai tas nenozīmētu nepamatotu biznesa panākumu. Ja verificētu notikumu nav izdevies noturīgi saglabāt apstrādei, vajag dokumentētu rīcību. Savukārt pasūtījuma izpildes kļūme jāatšķir no paša paziņojuma saņemšanas kļūmes. Pretējā gadījumā atbalsta komanda nevarēs izvēlēties pareizo atkopšanas soli.

Stripe dokumentācija paredz atkārtotas piegādes un negarantē notikumu secību. Tāpēc integrācijas tests nevar aprobežoties ar vienu ideāli pienākušu paziņojumu. Pārbaudiet, kā saglabājas konkrētās darbības pamatojums arī tad, ja notikumi pienāk citādā secībā, nekā rāda vienkāršā demonstrācija.

Pieņemšanas tests: viltots, mainīts, novecojis un derīgs notikums

Šī ir sintētiskas testa vides matrica. Tā nav norāde veikt eksperimentus svešā vai produkcijas maksājumu sistēmā. Izmantojiet testa kontu, īpaši tam paredzētu pārbaudes materiālu un darbības, kas nevar izraisīt īstu preces izsniegšanu.

Katram testam saglabājiet ievades identitāti, konfigurācijas versiju, rezultātu un pierādījumu par biznesa blakusefektiem. Tikai atbildes kods ne vienmēr parāda, vai darbība jau nav notikusi citā sistēmā. Rezultātu salīdziniet arī ar pasūtījuma un darba rindas stāvokli.

Negatīvajam testam jābūt apzināti mainītam vienā būtiskā aspektā. Citādi būs grūti saprast, vai sistēma noraidīja notikumu paraksta, formāta vai pilnīgi cita iemesla dēļ. Derīgais kontroles piemērs palīdz pārliecināties, ka drošības pārbaude nav vienkārši aizliegusi visu plūsmu.

Ko darīt, ja pārbaude sāk noraidīt īstus paziņojumus

Pārbaudes pierādījums nav tikai ekrānattēls

Pieņemšanas rezultātam piesaistiet to programmas un konfigurācijas versiju, ar kuru tests izpildīts. Ja pēc tam mainās saņēmēja ceļš vai datu apstrādes starpnieks, agrākais sekmīgais piemērs vēl nepierāda jaunās konfigurācijas darbību. Vajag zināt, kuras pārbaudes atkārtot un kurš pieņem lēmumu par izmaiņu nodošanu produkcijai.

Prasiet arī paskaidrojumu par pārbaudes robežu. Vai notikums izgāja cauri tam pašam maršrutam, ko izmantos reālā integrācija, vai tika ievadīts tieši iekšējā funkcijā? Abi testi var būt noderīgi, taču tie pierāda atšķirīgas lietas. Iekšējas funkcijas tests neparāda, ko pieprasījuma saturam izdara ārējais saņemšanas slānis.

Pārbaudiet noraidījuma pierādījuma saturu. Tajā jāvar atšķirt apzināti nederīgu parakstu no testa, kas vispār nesasniedza validāciju. Ja saņēmējs nebija pieejams, biznesa darbība arī nenotika, bet tas nav sekmīgs paraksta drošības tests. Negatīvajam rezultātam vajag atbilstošu cēloni un novērojumu, ne tikai tukšu pasūtījumu sarakstu.

Pēc testa atgrieziet vidi paredzētajā stāvoklī. Īslaicīgs diagnostikas režīms nedrīkst palikt kā alternatīvs pieņemšanas ceļš. Tāpat atsevišķi nosauciet sintētiskos testa notikumus, lai tos nevar sajaukt ar pierādījumiem par klienta maksājumu. Atbildīgajam jāzina, kurš rezultāts ir tests un kurš ir īsta darbība.

Nosakiet atbildību par drošu atkopšanu

Saglabājiet drošu apstāšanos: automātiska izpilde bez pietiekama pamatojuma nenotiek. Nosakiet, kurš pārbauda konfigurāciju un kurš biznesa pusē redz iestrēgušos pasūtījumus. Šie uzdevumi var būt saistīti, bet tiem nav vienādas piekļuves tiesības.

Diagnostikā salīdziniet zināmu testa piemēru ar pašreizējo saņemšanas ceļu. Pārbaudiet nesenas ietvara, starpnieka vai noslēpumu konfigurācijas izmaiņas. Žurnālos nošķiriet kļūdas kategoriju no sensitīvā satura. Nav vajadzības nosūtīt noslēpumu vai pilnu klienta maksājuma informāciju plašam atbalsta saņēmēju lokam.

Manuālai izpildei jābūt kontrolētam izņēmumam ar pārbaudītu pamatojumu. Poga “turpināt jebkurā gadījumā” nav kļūdu apstrāde. Atkopšanas plāns jāsaista ar manuālo rezerves procesu, saglabājot, kurš lēma un kādi dati lēmumu atbalstīja.

Atbalsta darbībās nošķiriet novērošanu no izpildes. Darbiniekam var būt nepieciešams redzēt noraidījuma kategoriju un pasūtījuma identitāti, bet ne mainīt uzticamo konfigurāciju. Savukārt konfigurācijas uzturētājam nevajag vienlaikus klusējot apstiprināt visus iestrēgušos pasūtījumus. Šo pienākumu robežas nosakiet atbilstoši uzņēmuma riskam un komandas iespējām.

Atkopšanas uzdevumā uzskaitiet vēl nepabeigtās darbības un to pamatojumu. Neizmantojiet vispārīgu norādi atkārtot visus paziņojumus, ja nav skaidrs, kuri jau radījuši sekas. Pirms turpināšanas jāsalīdzina sistēmu faktiskie stāvokļi. Neskaidru gadījumu atstājiet pārbaudei, nevis automātiski pielīdziniet neizpildītam darījumam.

Par sekmīgu atjaunošanu spriediet pēc paredzētā procesa darbības un saglabātās kontroles. Brīdinājumu pazušana vien nav pietiekama. Ja kļūdu skaits samazinājies tāpēc, ka paziņojumi vairs netiek reģistrēti vai tiek pieņemti bez pārbaudes, risks nav atrisināts. Pārbaudes rezultātā jāredz gan pareiza pieņemšana, gan paredzēta noraidīšana.

Prasiet pierādījumu pirms automātiskas izpildes

Integrācijas nodošanā palūdziet parādīt derīgu testa notikumu un tā mērķtiecīgi bojātos variantus. Jums nav jāievieš kriptogrāfija pašam, bet jāredz, ka kļūdainie gadījumi neizraisa pasūtījuma izpildi un derīgais ceļš paliek funkcionāls.

Biznesa procesu automatizācijas pārbaudei norādiet maksājumu pakalpojuma sniedzēju un notikumu, pēc kura sākas izpilde. Nesūtiet noslēpumus. Sākuma jautājums ir konkrēts: kas pierāda, ka tieši šim paziņojumam drīkst uzticēties un tieši šo pasūtījumu drīkst izpildīt?