18. maj 2003 - 00:20Der er
66 kommentarer og 3 løsninger
Sikkerhed ved kreditkort
Hej!
Sidder og programmere en kreditkort løsning og går sådan set også meget godt.
Man kan på siden (step1.asp) udfylde kortnr., udløbsdato (osv.) og på samme side er der et felt med et tilfældigt odrenummer som sendes til betalingsgatewayen. Samme sted står der hvilken side der vises hvis transaktionen gennemføres.
På den side (accept.asp) sender gatewayen en querystring med Transact med det som blev angivet på startsiden (step1.asp) og derved opfatter systemet den som betalt.
Men tager man den kode som står på step1.asp og indsætter i querystring transact værdi på siden accept.asp opfattes den også som betalt, men er den jo ikke da den ikke har været gennem gatewayen.
kaptajnkemo>> altså problemet er at jeg får svar fra gatewayen i querystring om at den er betalt. Men man kan jo snyde ved at kopier det nummer over på filnavnet og i querystringen transact.
Kan da ikke passe det kun mig som har problemet ?? :o)
kaptajnkemo >> alt med kortnummer og sådan noget er sikkret gennem betalingsgatewayen, og hvis det er forkert, ryger de tilbage på siden med en querystring svar i "reason"
På den her side står der i kildekoden et transact nr. samt hvor siden ryger hen hvis transaktionen bliver gennemført: /betaling/pay/step2-2-2.asp
Man kan se at den går hen til: /betaling/pay/step3-1-2-makethisps.asp
og putter man transact ind med i querystring sådan her tror den at den er betalt: /betaling/pay/step3-1-2-makethisps.asp?transact=1pw42EEga42UwUrdu9kPY64zo56r78h3
kaptajnkemo >> jaja, det meget fint, ville jeg også gøre hvis jeg kunne men min betalingsgateway sender svaret til mig i querystingen "transact" og jeg skal også sende alt til gatewayen i typen POST
dhgpower -> tjaa, men hvis kunden prøver bevist at snyde ved at ændre i querystrengen, ja så ved han jo at varen ikke er betalt, det ved du også da du kan se at du intet har modtaget fra kunden på din konto på betalingsgatewayen (du kan vel holde øje med betalinger der ikke?) Så i princippet er det jo ikke et decideret sikkerhedshul, men bare en irriterrende ting?
gonza.dk >> det er ikke en præcis vare, men det er hvor at betalingen er gennemført fremvises et X antal password's alt efter hvor meget der er indbetalt...
Det minder lidt om Den Blå Avis type. Der er nogle informationer og vil du have resten skal du købe passwords for at se dem. Og for at man ikke bare skal smutte uden om betalingen skal jeg jo have lavet et eller fiks, men igen hvordan :)
Du kunne jo tjekke hvilken siden brugeren kommer fra og så validere ud fra det. Ved ikke hvordan man gør i ASP. Er php-mand. Men det kan du jo sikkert sagtens selv lave. Bare et forslag, men tror at det vil virke ;o)
kaptajnkemo -> dhqpower er ikke selv herre over hvordan querystringen bliver overført, det kommer fra betalingsgatewayen som han ikke har noget med at gøre (andet end at han lejer sig ind på den) og dermed kan han ikke 'bare' overføre ID'et i et hidden felt.
Hvis du indsætter et hidden felt med transaktionsnummeret på den side der modtager fra gatewayen kan du sammenligne det med det ID som står i URL'en... hvis man vil snyde og har tastet et andet ID i URL er de to jo forskellige, så ved du at folk har snydt...
kaptajnkemo>>> Ærligt talt så synes jeg ikke at dine råd er specielt gode. Det er så nemt at snyde med dine forslag som at prutte i en flaske.
dhgpoer>>> Du kan godt undgå snyd, men det kræver at din betalingsgateway understøtter en elelr anden form for hash-signatur af de værdier som du får tilbage.
I dit eksempel står der en parameter som er "1pw42EEga42UwUrdu9kPY64zo56r78h3" er det dit ordrenummer eller vhor komemr det fra? Hvilken betalingsgateway benytter du?
Har du snakket med dem om det?
Jeg vil bestemt ikke anbefale kaptajnkemos forslag. De er usikre og du risikerer at få ørerne i maskinen hvis du ikke gør mere end det.
dhq -> hvad jeg lige kunne finde frem til skal du bruge Request.ServerVariables("HTTP_REFERER") er utestet og jeg er stadig ikke en asp mand, men prøv det. ;o)
Vedrørende idéen med at sammenligne to ID'er. Jeg går ud fra at brugeren har adgang til værdien ved blot at vælge "View source" i sin browser. Herefter skal man bare sende check-værdien over. Det holder ikke. Hidden frame: holder ej heller.
Spørg betalingsgateway-udbyderen om de understøtter hashing af returfelterne og lad høre hvad deres svar er. Alt afhængigt af hvad de siger, skal jeg nok hjælpe dig.
P.S. Jeg er tidligere arkitekt på den første dankortsoftware i danmark :-)
Hvis du benytter freepay er der *ingen* måde at du kan gøre det sikkert på. Du er nødt til at lade butiksejeren checke hver transaktion manuelt.
Det eneste alternativ er at bruge en HTTPS-klient som dit script benytter til at kalde freepay med, så det ikke er brugerens browser der kommunikerer med freepay, men dit eget script.
Alt andet omgåes og er dermed en rigtig skidt idé.
darkstar -> Hmm, sad faktsisk lige og tænkte på det samme, men den hjælper vel med til at sorterer en stor del 'snydere' væk. Men okay, du lyder som om du ved hvad du taler om så vil ikke gøre mig klog på noget ;o)
dhqpower -> lyder som om du lige skal forhøre dig hos din betalingsgateway og så tale en fornuftig snak med darkstar :-D
Vedrørende referer: hvis du har en webadresse hvor du kan se referer i din log, skal jeg fluks sende dig en forespørgsel med lige netop den referer, du måtte ønske.
gnoza.dk>>> Selvfølgelig vil det hjælpe, men det er ikke nogen skudsikker løsning og det er altså hvad man har brug for, når det gælder pengetransaktioner :-)
Alle forslag her vil på den ene eller anden måde gøre det mere besværligt at snyde, men når folk som jeg (eller andre teknisk mindede) på ½ time kan skrive et script som kan hælde vilkårligt mange ordrer igennem butikken uden at betale, er det ikke meget værd.
darkstar -> det har du skam fuldstændig ret i. det er jo halv svær at drive en butik/virksomhed hvis ikke man får noget som helst for sinde varer/serviceydelser eller hvad det måtte være :-D
Vedrørende Freepay: deres system understøtter ikek automatisk registrering af status på pengetransaktionerne. Det skal gøres manuelt. Hvis de siger noget andet, så vil jeg meget gerne høre fra dig igen, for i så fald må det skyldes manglende dokumentation af hvad deres system kan... eller uvidenhed.
Vedrørende referer-feltet i HTTP. Da det er en værdi som er sendt af brugeres browser kan man i sagens natur ikke stole på den. Mange program-biblioteker med HTTP-funktioner tillader at man selv sætter referer som det passer en.
Vedrøende Hotpeople>>> Jeps. Nu har jeg fundet deres betalingsfunktion. De cheker referer, men deres betalingsfunktion er faktisk ikke sikker. Jeg har kontaktet dem. Desværre vrimler det med den slags. Det er et rent slaraffenland for folk som gerne vil snyde. I sin tid havde Nem Computer og Scor.dk samme problem :-)
Jeg vil *meget* gerne høre fra dig hvis du får at vide at det er sikkert nok blot at se hvor brugeren bliver sendt hen. Får du en længere opskrift fra dem, så post den her.
glæder mig til at høre hvordan det kan komme til at funge på en sikker måde.
Men hvis nu man har fysiske varer der skal sendes til kunden, er det så også nødvendigt med denne sikkerhed? (selvfølgelig vil det være godt, sikkerhed er godt) men er det nødvendigt? Jeg mener, virksomheden kan jo tjekke om betalingen rent faktisk ER gennemført før kunden modtager varen, derefter kan viksomheden kontakte kunden hvis varen ikke er betalt. Men under alle omstændigheder vil det jo spare en masse besvær at sørge ordenligt for sikkerheden før man sælger til sine kunder.
Da jeg sidder og arbejder som freelance programmør for et firma, med speciale i at sælge internetsystem, der i blandt også en shop med kreditkort betaling, så ved jeg også at når jeg har fundet en løsning til det her, skal det også ordnes i shoppen for at undgå det.
Problemet for mig er bare at den faktisk selv skal tjekke om betalingen er udført på en eller anden måde, så derfor afventer jeg svar fra Freepay :o)
gonza.dk>>> Hvis man sørger for at checke at betalingen er gået igennem, før man sender varen, er der ikke noget at bekymre sig om. Det er bare vigtigt at ejeren af butikken er klar over at transaktionerne nogle gange kan mangle og at det betyder at varen ikke skal sendes.
Det er klart meste praktisk at vide om autorisationen er gået igennem fra første færd af. At butiksejeren kan risikere at skulle afvise ordrer fordi transaktionen mangler kan godt virke ret u-handy.
Hvad med at du på side 2 og 3 checker hvilken refere man kommer fra:
Response.Write Request.ServerVariables("HTTP_REFERER") udskriver den side man kom fra... På denne må kan du også checke om brugeren kom fra den rigtige side - altså om vedkommende har været forbi betalingsgatewayen.
_darkstar_ >> korrekt nok, men bare ikke nemt når der i dette tilfældes skal være sikkerhed i top da "varen" bliver leveret med det samme transaktionen bliver anset som betalt.
riwen >> Ehm, altså normalvis vil personen jo lige meget hvad skulle igennem alle siderne. Jeg vil også lige prøve at lave sådan at reference siden skal være den adresse som gatewayen ligger på. Men nogen siger det ikke altid er til at stole på!??
dhgpower>>> Så er du nødt til at finde en anden betalingsgateway eller (som jeg også skrev tidligere) benytte et https-bibliotek til selv at håndtere kommunikationen med betalingsgatewayen. Det kræver dog så at du også har et SSL-certifikat, da dit script skal modtage kreditkortnummer, mm. og sende dette videre.
Og ja - REFERER er ikke til at stole på.
Jeg sætter gerne en kasse øl på højkant til den person der kan bruge referer-feltet til at afgøre om nogen har været forbi freepays betalingsgateway eller ej. Vedkommende skal skrive to sider som hhv. sende brugeren til betaling hos freepay og modtager brugeren derfra. Hvis modtagerscriptet kan skrive "Du kom ikke fra freepay.", når det er tilfældet så giver jeg en kasse øl til vedkommende, som har skrevet de to sider.
P.S. Jeg vil selvfølgelig skrive et lille script som gennemfører transaktionen udenom freepay ved bare at sætte referer-feltet selv. Jeg betragter det som en en rimelig måde at vise at det ikke fungerer på.
Iøvrigt vil jeg understrege at når det gælder pengetransaktioner, er det nogle lidt andre spilleregler, der gælder. Hvis man udvikler et system, hvor man er bekendt med at der kan forekomme svind fordi at sikkerheden ikke er på plads, kan det altså blive et meget alvorligt problem.
Specielt hvis man ved at der kan udbedres. Jeg savner en smule respekt for folks penge og forretning i denne diskussion.
Hvad anbefaler freepays og PSB? Jeg kender ikke til nogle af de 2 firmaers spilleregler, men de specielt PSB må have udarbejdet noget skift om hvordan man laver et sikkert system.
PBS' retningslinier er meget generelle, men jeg ersikker på at hvis de vidste at man kunne snyde så nemt, ville de kræve at man udbedrede fejlen. Det er dog meget hypotetisk, for så grundige er de ikke.
Jeg er også nysgerrig efter at høre hvad Freepay siger.
darkstar -> 'Jeg savner en smule respekt for folks penge og forretning i denne diskussion.'??? Jeg mener bestemt at jeg har respekt for pengetransactioner, alt andet er forkert at sige, ja REFERER er nok ikke den bedste løsning, dog vidste jeg ikke at den var så nem at snyde med som du siger ;o). Derfor stopper jeg da også med flere 'småsnuskede' løsninger, der jo i den sidste ende ikke er sikkert nok til dette formål.
Hvis man skal drive en forretning, skal det gøres ordentligt, kunderne skal ligeledes behandles ordentligt, ellers kommer de jo nok ikke igen og handler ;o)
Jeg har forsøgt at kontakte Freepay men for heller ikke rigtig noget svar fra dem, så de skal nok snart lette røven ellers må jeg jo finde en anden leverandør af betalingsgatewayen, der er jo nok af dem :o)
Har modtaget svar fra Freepay, og det er fordi der er en special reference side som skal bruges til hver kunde som jeg har forstået - modtog følgende svar:
"Læs inde under admin --> opsætning --> premium opsætning. Der har man mulighed for at angive en "hemmelig" accept URL. I skal så blot sørge for at denne URL ikke kan findes af brugerne, samt at det er denne URL som sørger for opdatering af databasen."
Så den med reference side er jo vist god nok ! Men kender ikke lige på nuværende tidspunkt den side, må jeg heller ikke oplyse hvis jeg gjorde, men tror ikke det er lige så let at bryde igennem !
Hmmmm... hvor hemmelig er så den URL hvis det første der sker når man betaler er, at systemet sender dig hen til den?
Så kræver det jo ikke andet end at jeg betaler én gang, hvorefter alt andet er gratis. Det virker kun hvis de proxy'er siden og man så iøvrigt indretter den således at kun freepays server må tilgå den.
_darkstar_ > jeg ved virkelige ikke hvordan det er opsat , men skal nok vende tilbage når jeg får adgang til deres system. Altså ikke for at afsløre det men komme med en redegørelse for det !
Freepay har mulighed for at man sætter en URL, som de kalder efter at authorisationen er gået igennem. Denne URL kaldes direkte fra deres server til din. Brugerens browser er altså ikke med i dette. Parametrene er de samme som dem, der bliver sendt til den almindelige Accept-URL.
darkstar påstår jo at dette ikke er sikkert (hvis man bare kan gætte den hemmelige URL) eller gør han ??????
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
