V tomto článku by som chcel ozrejmiť, ako fungujú internetové platby cez i-banking. Prednedávnom som niektoré platobné systémy implementoval a preddávnom ma veľmi zaujímalo, ako asi tieto platby fungujú (a preto sa s vami, o mnou nadobudnuté informácie, delím). Na príklade budem opisovať komunikáciu medzi aplikáciou e-shopu a aplikáciou internetbankingu.
Opisovaná situácia: zákazník si na e-shope vyberie tovar, potvrdí objednávku a chce zaplatiť cez i-banking svojej banky.
Priebeh platby
Po objednávke musí zákazník zvoliť, aký druh platby použije na zaplatenie, pretože aj keď majú slovenské banky (aspoň tie, s ktorými mám skúsenosť) veľmi podobné protokoly na platby, nie sú rovnaké a napríklad Tatra banka má dokonca 2 druhy platieb (TatraPay a CardPay). E-shop následne má všetky informácie, aby vygeneroval payment request (na obrázku krok 1). V payment requeste je okrem iného uvedená suma, identifikácia obchodníka (e-shopu), identifikátor platby (variabilný symbol, niekedy aj špecifický symbol a konštantný symbol) a návratová url na stránku obchodníka. Payment request bude zaslaný banke prostredníctvom zákazníkovho browsra - teda potenciálne nebezpečným kanálom. Preto treba dodatočne zabezpečiť integritu a autenticitu dát uvedených v payment requeste.
Používaným spôsobom zabezpečenia payment requestu je podpis prenášaných dát. Podpísané musia byť všetky dôležité atribúty uvedené vyššie. Tieto sú skombinované do základu podpisu, z ktorého sa spraví hash. Hash sa následne zakryptuje symetrickou šifrou (používanými sú DES a 3DES) kľúčom, ktorý je známy iba obchodníkovi a banke (kľúče samozrejme rozdeľuje banka a každému obchodníkovi by mala prideliť iný kľúč), a vypadne podpis. Podpis je pridaný ako ďaľší atribút payment requestu.
E-shop teda má už kompletné údaje o payment requeste. Väčšinou sú to dvojice názov-hodnota, ktoré sa podľa špecifikácie príslušného protokolu zapracujú do HTML formu alebo URL a zobrazené v zákazníkovom prehliadači. Zákazníkov browser potom opustí obchodníkov web odoslaním payment requestu na server banky (podľa typu platby GET alebo POST HTTP requestom) (na obrázku kroky 2,3).
Banka následne autentifikuje zákazníka (prihlasovacími údajmi do i-bankingu, grid kartou, "kalkulačkou"...) a ten môže potvrdiť platbu (na obrázku krok 4). Ešte pred potvrdením platby ale musí banka samozrejme overiť digitálny podpis payment requestu a ten aj validovať (či sú správne zadané údaje etc.). Po potvrdení platby banka spracuje transakciu a vygeneruje payment response, ktorý obsahuje minimálne identifikátor platby (variabilný symbol) a výsledok transakcie. Prirodzene aj payment response je chránený digitálnym podpisom, ktorý sa spravidla generuje rovnakým postupom ako v payment requeste. Výsledky platby môžu byť OK (transakcia prebehla/prebehne), fail (transakcia neprebehne) a pri niektorých typoch e-platieb tiež timeout (platba zatiaľ neprebehla). Keď už banka vygenerovala payment response, zákazníkov browser je s payment response-om presmerovaný naspäť na stránku obchodníka (na obrázku kroky 5,6) (stránka obchodníka, kam má byť zákazník presmerovaný po spracovaní transakcie, bola uvedená v payment requeste - väčšinou sa používa HTTP GET).
Obchodník musí overiť podpis a validnosť payment response-u a ak sa to podarí, môže spracovať výsledok platby (na obrázku krok 7). Najprv musí spárovať platbu, ktorej sa payment response týkal, s objednávkou, ktorú zákazník odoslal. Na toto slúži identifikátor platby. Ďalej môže pokračovať v spracúvaní objednávky.
Zabezpečenie
Ako ste možno postihli, o celé zabezpečenie doteraz opísaného protokolu sa starajú podpisy správ vymieňaných medzi bankou a obchodníkom. Potencionálnemu útočníkovi (zákazník) by teda stačilo vedieť vygenerovať želaný payment response a dobre ho podpísať, aby mohol obchodníka presvedčiť o tom, že za objednané produkt(y) už zaplatil. Preto je veľmi dôležité zabezpečenie tajného symetrického kľúča, ktorý nesmie uniknúť ani z banky, ani od obchodníka.
Toto môže byť celkom riskantné, preto banky obchodníkovi väčšinou posielajú zabezpečeným mailom sumáre platieb realizovaných cez i-banking. Obchodník tak môže zistiť, ktorá objednávka v skutočnosti zaplatená nebola.
Záverom
Opisoval som spoločné vlastnosti fungovania internetových platieb. Samozrejme, že niesú všetky rovnaké. Niektoré protokoly môžu mať podporu na session dáta obchodníka, niektoré používajú okrem variabilného symbolu aj ďaľšie vlastnosti na identifikáciu platby, niektoré majú podporu na zadanie jazyka zobrazeného i-bankingového systému v payment requeste a podobne.
uhm, nechcem byt zly, ale napriklad system cardpay patri zrovna k tym najhorsim vobec.
kazdopadne, to co si opisoval je platba u 3rd party, skutocne zaujimave je to priamo na strane 1st autentifikacnej autority, akou je napriklad verisign, ci virtualterminal saferpay. to su najvyssie autorizacne a autentifikacne autority, ktore maju mimo ine avs, qsa a samozrejme rozsirene protokoly overenia (vsetko konci na gigi). u nas neexistuje ani 3d security (a vlastne card pay nepozna ziadnu security) aj napriek tomu, ze jej 1st autoritou je verisign. velka skoda, ze banka nezobrala achex (firstdata) ktory robi nielen 3d u visa ale aj u mc a dokonca background check pri amex. viac o posielanych datach je mozne najst tu
kazdopadne ja som sa s cardpay stretol pred rokom ci tak nejako a viem, ze posielal spatne email, v ktorom boli nejake info o statuse objednavky. bolo to velmi zaujimave, lebo behom chvilky (ak clovek poznal system) a vedel kde ma prijimatel email, mohol utocnik potvrdzovat platby (co som ako POC aj urobil). neviem ci zlepsili tento system, ale od banky, ktora ma xss a csrf snad vsade by som to ani necakal.
kazdopadne je to fajn clanok, snad to niekomu pomoze s nasadzovanim lokalnych platobnych systemov do praxe
------------------------------
http://blog.synopsi.com
No vzhladom k tomu, ze som podpisal zmluvu o mlcanlivosti (so zamestnavatelom), musim si este preverit, co vsetko mozem publikovat a co nie. Kazdopadne, prave robim na 3-D Secure a pokracovani autentifikovanej platby na Payment server. Rozmyslal som o tom, ze by som napisal aj clanok o 3-D Secure a tychto veciach, ale ako som povedal, musim sa najprv dohodnut o tom, co mozem a co nemozem zverejnit.
==
Správnemu programátorovi stačí pivo a google.
neviem co vsetko mozes zverejnit ty, ale ja prakticky vsetko :) 3d secure (neviem z akej strany ho poznas) ma svoje muchy a ze je ich dost. napriklad dost lahko sa da obist. robil som o tom dva reporty priamo pre achex (part of firstdata) presnejsie pre western union, ktory je najdolezitejsim klientom systemu. ono je tam toho dost vela, mozno to raz zaradim k dalsim clankom o bankovych systemoch. taktiez su zaujimave info ohladom vnutornych kontrolnych systemoch hlavne pre japonsky jcb a diners, ktore funguju malinko rozdielnejsie od beznych kartovych systemov.
pockam si na to co napises a potom uvidim ci to napisem aj ja inde, alebo ta len doplnim. som rad, ze aspon niekto sa zaujima (pracuje) s tymito systemami u nas, uz som ani nedufal :)
------------------------------
http://blog.synopsi.com
welmi zaujimawy clanok . . .
niekoho ako wy hladam
a poprawde ma zaujima celkowo tento system platenia :)
Ak chces, aby ta tu niekto bral vazne, tak nepouziway thaketo pitchowiny. Na pisomny prejav odporucam slovencinu.
==
A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
Ako myslis dakujem za radu
Btw, o ktorej verzii CardPay si hovoril? Pretoze tieto veci sa celkom casto update-uju.
==
Správnemu programátorovi stačí pivo a google.