Ssl cetifikat i sigurnost naplate

Zelio bih preuzimati podatke kreditih kartica preko stranice poradi naplate usluga. Na netu sam pronasao par pruzatelja takvih usluga (ouroboros, webteh itd…).

Kako bi preuzimao podatke sa svoje domene, prvo trebam osigurati SSL certifikat, kako bi mogao sigurno traziti podatke kupaca koje oni trebaju kako bi naplatu i procesuirali. Ukoliko zakupim SSL certifikat, koliko jos tog treba treba odraditi sto se sigurnosti samog preuzimanja tice. Koliko je SSL sam po sebi sigurna stvar prilikom prihvacanja osjetljivih podataka?

Malo mi je cudno da ja trebam prihvacati podatke kupaca, jer na taj nacin mi oni uopce nisu potrebni, ili se pak varam?

Da li netko ima slicnih iskustava?

SSL je najsigurnije što trenutno postoji. Postoje različite vrste certifikata, ovisno o razini sigurnosti, točnije novčanoj garanciji koja stoji iza njih, pa te detalje o certifikatima prouči na stranicama prodavatelja.

No, to osigurava samo vezu između klijenta i tvog poslužitelja - nazovimo to “front end” zaštitom. Jednom kada podaci dođu do tebe, oni opet trebaju biti zaštićeni - “back end” zaštita. Ovdje ima par riječi o tome, gdje je u zadnjem postu ujedno i odgovor na tvoje pitanje zašto ti trebaš prihvaćati podatke kupaca:

http://www.webmajstori.net/forum/showthread.php?t=16450

Za dobru praksu vezanu uz back end prvo vidi ima li operater preko kojeg ćeš ići nekakav konkretan implementacijski priručnik.

SSL certifikat ti u osnovi nije nužan jer nisi ti taj koji preuzima podatke od klijenata već payment gateway pružatelja usluga, a oni već imaju svoj certifikat - tebi samo treba public i private key koji ćeš od njih dobiti. Doduše ako se baviš online trgovinom preporučam da i ti ponudiš SSL. Za podatke o kartici je nebitno, ali ćeš zaštititi ostale podatke koje klijenti razmjenjuju sa tvojom stranicom, poput imena i prezimena, adresa i sličnog - barem sam tako ja napravio. Ako imaš kakvo konkretno pitanje, pucaj.

Bio sam na linku, hvala malo mi je jasnije ovo o cemu pisem, ali evo nasamo sam sljedeci pasus,

Ovako stoji u dokumentaciji jednog od gateway posluzitelja:

Kod POST protokola trgovac prikuplja sve potrebne podatke za autorizaciju i šalje POST
zahtjev na stranicu
https://secure.ouroboros.hr/payment/pay.php
. Kako se prikupljanje
osjetljivih podataka obavlja na stranicama trgovca, trgovac je duzan na svojim stranicama
osigurati vlastiti SSL certifikat. Minimalni skup podataka se sastoji od sljedeih polja:

mch_code, amount, signature –
card_number – broj kreditne kartice
card_expmon, card_expyear – itd… itd…

Mislim da u se u ovom slucaju preko moje stranice preuzimaju podaci te automatski preusmjeravaju na gateway posluzitelja.

Guba mi je da kada odeš na tu stranicu s GET zahtjevom, kihne na null-pointeru. Ulijeva povjerenje, nema što. :slight_smile:

Pa, čisto tehnički gledano, ti možeš u svoju web-stranicu staviti FORM element s method=POST i action=https://secure.ouroboros.hr/payment/pay.php.

Pri tome moraš složiti obrazac tako da polja nazoveš ovako kako ti je rečeno. Svoj URL u action staviš za testiranje, da vidiš što se stvarno podnosi, a kada je sve debugirano, staviš njihov kako bi se post podnio njima.

Stvarno, u tom slučaju ti podaci tebe neće niti vidjeti - web-preglednik ih šiba direktno na gateway.

Možda je jedno od polja koje primaju i nekakav URL stranice na koju će preglednik biti preusmjeren nakon što oni obrade POST zahtjev. Moguće da će taj URL dobiti u query-stringu i kakve parametre koji označavaju uspješnost transakcije. Ako nije, onda će korisniku biti prikazana njihova stranica s obavijesti o plaćanju i eventualno u njoj link na tvoju stranicu.

Uoči, međutim, da ako je komunikacija prema tvome webu nesigurna, uljez može bilo kako falsificirati tu komunikaciju. Od toga da otme DNS upise i prikaže svoj web umjesto tvoga, ili da šalje “phishing” e-mail s lažnim linkom na svoj shop spravljen da izgleda kao tvoj, do toga da preotme onu stranicu koja prikazuje rezultate plaćanja i tamo nagovori korisnika da mu oda podatke do kojih nije mogao doći iz onog originalnog POST-a (npr. napiše da transakcija nije uspjela i pukne mu ponovo isti obrazac). SSL certifikat osigurava klijentu da za svaku stranicu s tvog weba zna da je autentična i tako spriječava tu rupu, ako je korisnik oprezan.

“Guba mi je da kada odeš na tu stranicu s GET zahtjevom, kihne na null-pointeru. Ulijeva povjerenje, nema što.” Na sto si mislio nisam te bas shvatio.

Na sto si mislio “ako je komunikacija prema tvome webu nesigurna”, da li si mislio ukoliko nije https ili nesto drugo…

A ovaj zadnji dio sto si napisao, “tako spriječava tu rupu, ako je korisnik oprezan” znaci da ako je korisnik recimo totalno neuk sto se tice sigurnosti ali zeli preko svoje kartice nesto posto poto kupiti moze zavrsiti naopako. U ovoj postavic stvari znaci puno toga ovisi o meni tj. puna odgovornost preuzimanja podataka od posjetitelja.

Znas li mozda koji servis jednostavno nudi ili nekakav api ili iframe da se uglavi u stranicu tako da ja nemam nista s preuzimanjem podataka kartice.

[quote=“tchibo”]Na sto si mislio nisam te bas shvatio.[/quote]Klikni na onaj link u svom prethodnom postu.

[quote=“tchibo”]Na sto si mislio “ako je komunikacija prema tvome webu nesigurna”, da li si mislio ukoliko nije https ili nesto drugo…[/quote]Da, mislio sam ako tvoj web nema https.

[quote=“tchibo”]A ovaj zadnji dio sto si napisao, “tako spriječava tu rupu, ako je korisnik oprezan” znaci da ako je korisnik recimo totalno neuk sto se tice sigurnosti ali zeli preko svoje kartice nesto posto poto kupiti moze zavrsiti naopako. [/quote]Ne. “Oprezan” znači da ako je korisnik upućen u upotrebu svog vlastitog web-preglednika i prati da li mu je address bar zelen (ili kako već web-preglednik indicira sigurnu vezu). Nije tvoj problem, niti tvoja odgovornost ako je korisnik neuk. Tvoja je odgovornost da korisniku koji zna koristiti svoje računalo osiguraš sve što je uobičajeno i prihvaćeno kao dobra poslovna praksa.

[quote=“tchibo”]U ovoj postavic stvari znaci puno toga ovisi o meni tj. puna odgovornost preuzimanja podataka od posjetitelja.[/quote]Pa ne. Kako sam ti gore opisao, čini mi se da kroz POST metodu podaci nikada ne moraju vidjeti tebe. Ali to ne znači da neki uljez ne bi mogao web-stranicu koja se pokazuje prije ili poslije same transakcije, a koja dolazi sa tvog servera, nekako iskoristiti da inicira napad na korisnika. Stoga je dobro da i ti zakupiš certifikat i za one stranice svog web-shopa koje se poslužuju s tvojeg servera također osiguraš korisnikovom web-pregledniku mehanizam provjere autentičnosti web-stranica.

[quote=“tchibo”]Znas li mozda koji servis jednostavno nudi ili nekakav api ili iframe da se uglavi u stranicu tako da ja nemam nista s preuzimanjem podataka kartice.[/quote]Opet ćeš imati isti problem. Problem je u logici stvari - u nekom trenutku korisnik kreće ili završava na tvom webu. Ako ne može biti siguran da je stvarno došao na tvoj web (umjesto na neki web koji je falsifikat tvoga), onda više niti u što ne može biti siguran.

Pričekaj ako se Riba pojavi, možda će ti on znati malo bolje pojasniti ovaj dio.

Dakle ne znam kako Ouroboros radi jer nisam niti proučavao alternative eToMiTreba od RBA. Oni imaju dvije izuzetno bitne prednosti: ne postoji nikakva naknada za “uključenje” servisa i drugo, ne postoji fiksna mjesečna naknada za korištenje istog (uzimaju mali postotak izvršene transakcije, mislim da je 0.5%). Ovisno o tome koliki priljev očekuješ mjesečno i koliko stalan ovo može ili ne mora biti bitna stavka.
Ovo da Ouroboros očekuje da ti prikupljaš podatke poput broja kreditne kartice mi se čini nevjerojatnim, jer kompletan rizik i sigurnost tih podataka prebacuju na tebe. Ne znam za tebe, ali to je obaveza koju osobno nisam spreman prihvatiti (čitaj: možeš li sa 100% sigurnošću garantirati svojim klijentima da ti podaci neće ni na koji način “iscuriti”). Kako ipak nemam iskustva iz prve ruke sa njihovom uslugom, dopuštam da je to zaista tako, no osobno se ne bih osjećao ugodno da plaćam nešto na taj način.
Kod eToMiTreba ti njihovom payment gateway preko SSL-a šalješ određen broj parametara, poput iznosa, ID-a transakcije i slično, no osjetljive podatke poput imena i prezimena, broja kartice i expiry datuma te CVV koda kupac sam upisuje izravno na njhove stranice - dakle ti s tim nemaš ništa. Štoviše, tražio sam od RBA ako je moguće uz svaku transakciju dobiti i podatak o imenu i prezimenu uplatitelja da mogu informaciju zbog dodatne sigurnosti usporediti sa svojim lokalnim podacima i na taj način dodatno osigurati da samo vlasnik kartice može plaćati unutar svojeg korisničkog računa, međutim ti podaci su potpuno sakriveni čak i od mene.
Od mana mogu navesti jedino:

  • kako se korisnik preusmjeri na RBA payment gateway koji nije dizajnom prilagođen tvojim stranicama a pritom ne izgleda posebno profesionalno, kod korisnika može izazvati sumnju.
  • upute za integraciju koje ti daju su prilično loše i nedorečene, ali ekipa brzo odgovara na upite i da se na koncu sve složiti
  • poslovni račun tvrtke mora biti u RBA

Upravo sam se sjetio dodatnog razloga zašto bi trebao imati SSL certifkat kod sebe. Naime, u slučaju eToMiTreba, nakon uspješne transakcije, payment gateway će korisnika preusmjeriti na željeni URL na tvojoj stranici. U slučaju da taj URL nije https, svaki pretraživač će korisniku izbaciti popup upozorenje da je preusmjeren sa sigurnog linka (jer gateway koristi https) na nezaštićeni. Iako ovo u tom trenutku ne predstavlja sigurnosnu opasnost većini korisnika neće biti ugodno to vidjeti. Korištenjem SSL certifikata možeš imati target URL koji je https i eliminirati taj problem.

Toga sam se i pribojavao, naime sto meni treba je api ili frame koji mogu uglaviti na stranice tako da kupac ne napusta moju domenu, tj. Da se cak i placanje vrsi na mojoj domeni sa njihovim backgroundom. Ta opcija od rba mi nije zanimljiva bas izrazloga koji si naveo. Negdje sam citao da webteh nudi ovako nesto ali cu jos provjeriti pa se javim. Ovo sto se ouroborosa tice se i meni cinilo malo “riskantno” s obzirom na moju potkovanost znanjem u ovom podrucju.

Pa čini se da niti u Ouroborosu ti ne skupljaš stvarno podakte. Ti poslužiš formu pregledniku, korisnik je popuni u svom pregledniku (lokalno, dakle) i kada stisne SUBMIT preglednik te podatke direktno pošalje na gateway zato što si u action atribut forme stavio onaj URL od gatewaya.

Ključno pitanje je što gateway pošalje pregledniku nakon što se forma obradi - da li prikazuje njihovu stranicu (s gatwayevog servera) ili pošalje pregledniku Location header preusmjeravajući ga natrag na tvoj web. Tebi je bolje ovo drugo zbog prilagodbe izgleda (korisnik uvijek dobiva stranice poslužene s tvog weba), ali je lošije zbog sigurnosti da ti netko ne “otme” proces kod preusmjeravanja natrag, od čega se osiguravaš pomoću SSL certifikata jer i svi podaci s tvog servera dolaze kriptirani, tj. uljez ne može presresti tvoju inicijalnu web-stranicu s formom i promijeniti URL koji si naveo kao URL stranice koja se otvara nakon završetka transakcije. Naravno, moguće je da se taj URL i specificira negdje u konfiguraciji Ouroboros servisa, pa uopće nikada ne putuje mrežom.

Da, kasnije sam razmišljao u krevetu prije spavanja i sigurno se radi o ovome što tsereg kaže. Dakle ti imaš lokalni obrazac ali target ti he njihov https URL. Mislim da i Ouroboros i Webteh i PayWay nude ovu mogućnost. U tom slučaju svakako moraš imati SSL jer na taj način nitko tko između klijentovog pretraživača i tvoje stranice “prisluškuje” promet (recimo public wireless!) neće moći doći do tih osjetljivih podataka.

Puno hvala obojici, mislim da smo sada dobili temu koja ce u svakom slucaju pomoci svima onima koji proces naplate zele obavljati na svojoj domeni ali se ne odvazaju isprobati bas poradi sigurnosnih razloga koje ste gore i navodili.

Mislim da je jos samo stavka za razmotriti koji SSL zakupiti tj. koje su razlike te na sto obratiti pozornost prilikom odabira od onih jeftinijih (Godaddy.com - 70€ ) pa do onih najjacih (Thawte - 500€, Verisign - do 1300€ ). Verisign nudi i skeniranje stranice u potrazi za sigurnosnim “rupama”. Moze biti da je dobar marketinski trik ali se ipak cini ok. Ali je svakako isplativije zakupiti nesto skuplji certifikat pa na stranicama postaviti Thawte logo nego Godaddy ili takvo nesto.

S tehničke strane i najjeftiniji i najskuplji certifikat rade identično i jednako su sigurni. Skuplji certifikati dolaze sa nekim bonusima i dodacima, kao extended validation, osiguranjem do određenog iznosa itd…
Ja bih išao na skuplji certifikat u dva slučaja:

  • očekuješ zaista iznimno velik broj posjeta i transakcija i bitna ti je pouzdanost u svakom trenutku
  • zanima te neka od ponuđenih ekstra mogućnosti (malo vjerojatno)

Moje je mišljenje da prosječni posjetitelj pojma nema što je to SSL a kamoli Thawte, Verisign, GeoTrust ili GoDaddy pa je plaćanje “branda” bacanje novca, osim ako to ne činiš iz vlastitog zadovoljstva.

I slažem se da je tema korisna, nadajmo se da će takvih biti više na WM kao i više onih koji sudjeluju u njima. :slight_smile:

Cijeli sustav PKI-a se temelji na jednom konceptu koji je u osnovi iskrivljen: lancu povjerenja. Onaj koji pristupa nekom dokumentu mora vjerovati onome koji izdaje certifikat koji je korišten u zaštiti. A taj koji izdaje certifikat je možda opet dobio svoj certifikat od nekog u lancu iznad njega, pa implicitno vjerujemo i onom iznad, o kojem možda ne znamo baš ništa. I tako sve do kuće koja izdaje vršni certifikat - root certification authority.

Dodatni problem je što popularni root certifikati dolaze predinstalirani na našim Windowsima ili s našim preglednicima. Od kuda možemo znati da je instalacijski paket došao do nas na pouzdan način i da ti certifikati nisu zapravo falsifikati? Možemo li vjerovati samim kućama i procesima koje one koriste u pripremi tih instalacijskih paketa? Koliko sve nepoznatih ljudi sudjeluje u toj priči?

Ovo su teorijska razmatranja, naravno, ali pokazuju ključni problem s tom infrastrukturom. Da ne ulazimo u detalje oko povlačenja certifikata i pravovremene propagacije te informacije…

Poanta je slijedeća: bit, temelj sigurnosti u ovom procesu je povjerenje. Trgovački gledano, najbolje je kupiti certifikat od onog certifikacijskog autoriteta koji uvažava najveće povjerenje u industriji i među krajnjim potrošačima.


Drugi aspekt PKI-a je sigurnost tzv. autentifikacijskih poslužitelja. Njih pogone certifikacijski autoriteti koji izdaju root certifikate i za cijeli sustav sigurnosti ključno je da ti poslužitelji nisu kompromitirani, tj. da si nitko ne osigura neautorizirani pristup (pristup imaju samo djelatnici kuće kojoj smo dali gore opisano “povjerenje”).

Pravno gledano, najbolje je onda imati certifikat od kuće iza koje stoji i nekakva garancija, tipično u obliku osiguranja odštete. Naravno, treba razumjeti što ta garancija zapravo pokriva.


Ilustracije radi, tipična situacija kod naših banaka je da one same sebe proglase certifikacijskim autoritetima i izdaju vlastite root certifikate. U tome nema ništa loše - tko bolji od banke, pošto njoj po definiciji, pa i po zakonu dajemo povjernje. Problem je što oni onda distribuiraju svoj root certifikat tako što ga objave na svojim web-stranicama kojima se pristupa otvoreno, kao bilo kojoj drugoj stranici na internetu! Dovoljno je da se napadač “ubaci” u žrtvinu vezu i razriješi zahjev njenog preglednika za “www.mojabanka.hr” u IP adresu napadačevog servera na kojem je složio iste web-stranice kakve ima banka, ali gdje je objavio svoj vlastiti root certifikat. I infiltrirao se u sustav. Tipičan način na koji se to radi je “phishing” emailovima koji, kao, dolaze od banke i pozove se klijent da obnovi svoj certifikat. Ali moguće su i tehničke intervencije.

Drugi način je da banka koristi root-certifikat neke dobre kuće poput VeriSigna. To je sve pet, ali se meni osobno ne čini baš pravno utemeljenim da ja - koji sam zakonom dužan dati povjerenje svojoj banci - od svoje banke budem prisiljen dati povjerenje i nekakvom poduzeću iz Amerike čiji sam root-certifikat dobio instaliran na svom kućnom računalu, a za što banka ne odgovara. Koga ću ja tužiti u slučaju probijanja sigurnosti?

No, to je sve samo moje mišljenje. Ja nisam čuo niti jednog “velikog” stručnjaka iz Hrvatske da o tome govori, pa valjda ja nešto tu ne vidim kako spada.

Moje osobno mišljenje jest da država treba pomoću FINA-e osigurati certifikacijski server (to je zapravo već i učinjeno, FINA izdaje smart-kartice) i root-certifikat FINA-e treba biti dostupan svakom građaninu RH na način da ga fizički i osobno podigne na CD-u u poslovnici FINA-e, gdje će i potpisati da ga je primio.

Onda se ostale institucije platnog prometa, kao i općenito državna e-uprava može vezati na to.

Konačno, svaki građanin bi (idejno govoreći) mogao dobiti osobnu iskaznicu s čipom na kojem bi bio pohranjen i njegov osobni certifikat (dakle smart-karticu), koji bi građanin mogao, ako želi, koristiti za različite potrebe. Između ostalog, za pristup do svog portala na stranicama državne e-uprave, za slanje kriptiranih e-mailova, za dokazivanje svog identiteta na različitim servisima na internetu i sl.

jos jedan “mali” detalj, ako pogledate na google-u, svaka stranica koja preko verisign-a ima ssl, u izlistu pretrazivanja ima ikonu od verisign-a dok ostali to nemaju. Razlog vise, ali je zato i cijena astonomska.

tchibo - ponavljam: koliko tvojih korisnika zna što je Verisign, što uopće znači njihova ikona i što je SSL? Jest, meni i tebi je svakako cool, ali donosi li ti to ekstra ulaganje ikakvu opiljivu korist tebi i tvojim korisnicima?