Usikkert dansk plugin: 20.000 danske webshops lader kunders kortdata køre gennem egne servere

Illustration: Yourpay
En dansk leverandør af betalings-gateways til webshops lader køberes betalingsoplysninger køre igennem butikkernes egne servere. Det truer sikkerheden for både webshops og handlende vurderer flere eksperter.

Når danskerne i disse coronatider sidder hjemmefra og køber sushi eller betaler deres inkassoregninger på nettet, risikerer de, at kortoplysningerne opsnappes af ondsindede hackere. Omkring 20.000 danske webshops bruger nemlig Wordpress-pluginet Yourpay.

Læs også: Kæmpe hul i dansk software til fjerninstallering: »Jeg indkalder hele virksomheden med det samme«

Og Yourpay lader som betalings-gateway alle kortdata og betalingsoplysninger passere gennem webshoppenes egne servere. Det betyder, at hvis bare ét af de Wordpress-plugins, en af yourpays 20.000 webshop-kunder ellers har hentet, kan kompromitteres, kan angribere få fingre i kundernes betalingsoplysninger.

»Det er helt skørt. Normalt ville man sørge for, at oplysningerne gik direkte til indløserne(I Danmark hovedsagelig Nets, red.). Det her er en ulykke, der venter på at ske,« siger Magnus Paaske, der som selvstændig it-konsulent opdagede fejlen, fordi Yourpay crashede på hans egen Wordpress-server.

Og derfor så han koden igennem.

»Udover en masse sjuskefejl fandt jeg ud af, at Yourpay lader de her data passere gennem sidernes egne servere, og det tror jeg ærligt talt ikke, indehaverne af siderne aner,« siger Magnus Paaske.

Placerer ansvar hos webshops

Udover at det udgør en sikkerhedsrisiko, gør også siderne ansvarlige for kortdataene. Og for, at de ikke lækkes.

»Jeg ville ellers mene, man køber og bruger en betalingsgateway netop for ikke selv at stå med det ansvar. Og Yourpay skriver intet om, at man håndterer kortdata serverside, så jeg tror som sagt ikke, deres kunder aner, de har et kæmpe ansvar,« siger Magnus Paaske.

Læs også: Sådan fandt tre unge danskere verdensomspændende sikkerhedshul i modemmer: »Hvis vi kan verificere det her, så skal der øl på bordet!«

Det ekstra ansvar, de enkelte webshops, der blandt andet tæller Sushi 2500 i Valby og inkassofirmaet Sergel, pludselig står med, er klart formuleret i den internationale standard PCI.

Atypisk løsning

Magnus Paaske fortæller da også, at Yourpay står alene med den usikre praksis. Andre, større gateways som for eksempel Stripe eller Amazon Pay, sender informationerne direkte og krypteret til indløserne, uden at vende dem serverside først.

Hvis man havde ladet betalingsoplysningerne gå direkte til indløserne, ville man som hacker have langt sværere ved at stjæle brugernes kortoplysninger, fortæller Frederik Raabye, der er sikkerhedskonsulent hos Dubex:

»Allerede ved første gennemlæsning af koden ringer et par alarmklokker. Måden Yourpay er bygget op på gør, at hvis enten ejeren af webshoppen eller bare en af de andre webshops, de måske deler server med, bliver kompromitteret, så kan angribere gemme ofrenes kortdata, efterhånden som de tikker ind« siger Frederik Raabye, der ligesom Magnus Paaske finder flere andre småfejl i Yourpays kode.

»»Yourpays plugin bruger desuden brugerdata fra såkaldte GET-requests direkte uden validering af indholdet. Det giver potentielt angribere mulighed for at kompromittere pluginet på en række måder, blandt andet gennem SQL injection og XSS-angreb, « uddyber Frederik Raabye.« uddyber Frederik Raabye.

Den usikre praksis betyder da også, at Wordpress har sat Yourpay i karantæne, mens folkene bag Wordpress gennemgår koden. Derfor kan man i skrivende stund ikke hente Yourpay direkte fra Wordpress. Der er ingen information om denne karantæne på Yourpays hjemmeside, men Yourpay beder i stedet folk selv hente plugin’et ned og installere Yourpay manuelt.

Opfordrer til at deaktivere sikkerhedsfeatures

Yourpays små og store sikkerhedsproblemer stopper ikke ved virksomhedens eget plugin. Selskabets brugere har nemlig haft bøvl med integrationen med et andet stort webshop-plugin, Woocommerce.

For at løse det problem foreslår Yourpay, at man går ind i koden til Woocommerce og gør noget, man ifølge de to sikkerhedskonsulente, aldrig bør gøre. Yourpay [skriver](:

»Vælg Yourpay Payment Platform i dropdown og klik Select. Find de markerede linjer, som på billedet herunder, og slet dem.

Illustration: Mads Lorenzen Screendump

Én ting er at råde sine 20.000 kunder til at slette kode i et andet plugin, hvilket er en uskik ifølge både Magnus Paaske og Frederik Raabye. En anden er, at der er tale om den kodestump, der tjekker, om forbindelsen er krypteret.

Læs også: Endnu en alvorlig sårbarhed i Yousee-hardware: TDC vil ikke oplyse, hvor mange der er ramt

Hvis Woocommerce stopper med at tjekke, om forbindelsen er krypteret åbnes brugeren op for endnu en type angreb, nemlig såkaldte Man In The Middle(MITM)-angreb, hvor hackere omgår krypteringen og lytter med på kommunikationen, der indeholder blandt andet kortdata.

»At leverandøren aktivt foreslår at sænke den kryptografiske sikkerhed i en webshop er ikke tillidsvækkende. Særligt ikke når Yourpay desuden behandler kreditkortinformation på deres kunders webservere, og ikke ser ud til at følge aktuelle best practices for sikker udvikling,« siger Frederik Raabye.

Forsøgte at hyre Magnus Paaske

Da Magnus Paaske i første omgang informererede Yourpay om de mange små og store problemer, stod det sløjt til med at få dem fikset. Det fremgår af en mailkorrespondence mellem Yourpay og Magnus Paaske, som Version2 har fået indsigt i.

»Har I fået set på de her svagheder? Som jeg har nævnt tidligere vil jeg gå videre med svaghederne onsdag, hvis ikke jeg inden har hørt fra jer, hvad I forventer at gøre for at løse dem. Det er rimeligt alvorligt, at jeres kunder skal gå imod al god IT-sikkerhedsskik for ikke at skulle håndtere kortdata på deres egne servere. Det er ligeledes rimeligt alvorligt at I intet sted i jeres dokumentation fortæller jeres kunder om PCI-compliance, og hvordan de skal være opmærksomme på, at deres servere sikkert kan håndtere kortdata,« skriver Magnus Paaske til Yourpay.

Uden at få svar.

I stedet fik han en besked på LinkedIn:

»Hej Magnus. Jeg blev opmærksom på dig gennem vores support har haft noget dialog omkring en mail, du har sendt ind.

Vi søger i øjeblikket nye udviklere til at være en fast bestanddel af Yourpay, der kommer stillingsopslag på det i løbet af de næste par uger, men jeg er i første omgang lidt på jagt efter, hvilke sprog du dev-mæssigt er fan af og bruger af?

Best Regards
Mathias Gajhede, Yourpay.«

Hverken Yourpay eller Wordpress har ønsket at stille op til interview inden denne artikels deadline. Version2 følger op med deres kommentarer, såfremt det lykkes senere.

Illustration: Magnus Paaske, screendump
Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Mogens Lysemose

Dengang jeg rodede med den slags klagede/undrede nogen af kunderne over at man forlod deres domæne ifm med betaling og blev sendt til betalingsudbyderen og så blev sendt tilbage igen (call back). Vi forklarede dem bare at det var en del af sikkerheden og nej vi kunne/ville ikke gøre noget ved den del. hvis de blev ved vidste vi dem pbs' side om hvad det kostede selv at blive valideret som betalingsudbydder, og så plejede de a stoppe.

Mon dette overhovedet er lovligt? Men hvis man som programmør bare ønsker at opfylde alle kunders ønsker uanset hvor usmarte og uden at forstå konsekvenserne så sker sådan noget her.

  • 2
  • 0
#3 Jens Beltofte

Mon dette overhovedet er lovligt? Men hvis man som programmør bare ønsker at opfylde alle kunders ønsker uanset hvor usmarte og uden at forstå konsekvenserne så sker sådan noget her.

Husker tydeligt hvor man viderestillede brugene til den valgte betalingsgateways domæne. Det gør man i mange tilfælde stadigvæk.

Dog er der flere løsninger hvor betalingsformularen indlejres på webshoppen og hvor kortdata sendes med Javascript til betalingsgateway. Derved undgår man redirect til det eksterne domæne og samtidig at skulle håndtere kortdata lokalt i sin egen webshop.

Men ja, det er faktisk lovligt at behandle kortdata lokalt i webshoppen. Mange af de store online-shops og brugere af betalingskort gør dette, men det kræver at hele deres setup PCI-certificeres.

  • 6
  • 0
#4 Morten Hartvig

Mange af de "nye" uden support for andet end VISA/Mastercard modtager også kortoplysninger inline på siden. Enten gennem iframe eller med JavaScript kode. Selvom kommunikationen kan være sikker nok, er det stadig (ligeså) farligt ift. XSS eller på hackede sites.

DVS. Man bør vel bruge det eksterne vindue i alle tilfælde, hvis man tænker på sine kunder (og bruger Wordpress)

  • 2
  • 1
#5 Christine Rosenberg

Yourpay kommenterer, at der er testet ud fra et gammelt plugin og at de følger samme industri formel som Stripe og Quickpay?!

Deres argument ang slet af SSL er, at hvis man på sin site allerede har SSL vil det konflikte og det vil derfor ikke har nogen indvirkning, hvis man sletter det.

Yourpays argument er, at de ikke sender videre til indløser fordi de er indløser.

Yourpay siger at data er på deres egne servere og ikke kundernes servere, og at IPC ansvaret ikke er korrekt

......

Jeg er ikke klog nok på det her - hvad skal jeg tro? artiklen eller dem, der vil sælge en ydelse?

  • 3
  • 0
#6 Jens Beltofte

Yourpay kommenterer, at der er testet ud fra et gammelt plugin og at de følger samme industri formel som Stripe og Quickpay?!

Nu kender jeg ikke detaljerne i koden på Stripe og Quickpay, men er ret overbevist om at deres integrationer ikke sender data til det CMS / Commerce løsning som websitet benytter, men i stedet sender data direkte til Stripe / Quickpay.

Deres argument ang slet af SSL er, at hvis man på sin site allerede har SSL vil det konflikte og det vil derfor ikke har nogen indvirkning, hvis man sletter det.

Men at slette kode i et tredjeparts plugin til Wordpress eller et andet system er direkte dumt, da det er sværre efterfølgende at vedligeholde det plugin og opdatere det når der kommer kritiske sikkerheds- eller fejlrettelser til plugin'et.

  • 2
  • 0
#7 Thomas Jensen

Hej

"Yourpay kommenterer, at der er testet ud fra et gammelt plugin og at de følger samme industri formel som Stripe og Quickpay?!"

Hvor siges dette ?

Det er tæt på, at være injuriende.

Derudover må man gerne skrive QuickPay med stort "P" :)

Vh Thomas Jensen, QuickPay

  • 5
  • 1
#8 Jens Beltofte

Yourpay kommenterer, at der er testet ud fra et gammelt plugin...

Hvis det er korrekt at det er et gammelt plugin, så er det jo stadig et stort problem, da rigtig mange ejere af Wordpress websites meget sjældent for dem opdateret og slet ikke skiftet til en opdateret udgave af Yourpay integration. Dvs. at selv om Yourpay har løst problemerne hos dem, fortsætter det med at eksisterede i produktion hos mange af deres kunder der benytter Wordpress.

  • 1
  • 1
#9 Jens Beltofte

Har kigget lidt på nogle af Yourpay implementeringerne rundt omkring, og det virker til at det generelt er på Wordpress + WooCommerce hvor problemet opstår, da WooCommerce som standard har indlejret felterne til betalingskortoplysninger i deres "one page checkout", og hvor alle formularfelter inkl. betalingskortoplysninger sendes tilbage til CMS / Commerce løsning med en alm. POST-request. Her burde Yourpay og andre betalingsløsninger (nævner ingen navne) ikke benytte standard WooCommerce løsningen til betalingskort, men i stedet lave en "off site" løsning der redirecter brugeren til en formular på et eksternt domæne. Med en sådan løsning burde det også være lettere at implementere de nye PSD2-krav med en ekstra faktor.

I min snusen rundt fandt jeg en anden dansk udbyder der benytter eller benyttede samme implemtering i WooCommerce som Yourpay.

Denne "on site"-model har også været standarden i andre open source commerce løsninger eller commerce-moduler / plugins til CMS'er tidligere. Tænker om det skyldes, at man i f.eks. USA har haft nogle meget lempligere krav (hvis nogen overhovedet) til behandling af betalingskortoplysninger.

  • 3
  • 0
#10 Bo AA

Bare wow. Man skal holde sig langt væk fra at håndtere betalingsoplysninger hvis man er amatør og ikke mestrer de mest basale færdigheder inden for sikkerhed.

  • 2
  • 1
#11 Kim Schulz

Jeg har selv været aktiv bruger af yourpay til flere projekter og kan godt huske nogle "udfordringer" i de tidlige dage. Men kigger jeg på koden til det nuværende plugin, så benytter den sig af en indlejret iframe der poster kort info direkte til yourpays servere via deres api og javascript:

function submityourpayform(clsbtn) {  
            $.ajax({  
                type: 'POST',  
                url: 'https://webservice.yourpay.dk/httpd.php?json=1',  
                crossDomain: true,  
                data: { "function": "TransactionTokenGenerate" },  
                dataType: 'json',  
                success: function(responseData, textStatus, jqXHR) {  
                    transactiontoken = responseData.Token;  
                    respondtoken(transactiontoken);  
                    $("body").prepend("<div class='yourpayoverlay'></div>").addClass('cover');  
                    $(".yourpayoverlay").addClass('cover');  
                    $(".yourpayoverlay").before("<div class='yourpay iframeview'></div>");  
                    $(".yourpay.iframeview").before("<div class='yourpay closebutton'><img src='" + clsbtn + "'></div>");  
                    $(".yourpay.iframeview").append("<iframe src='https://payments.yourpay.se/betalingsvindue_cardtype.php?paymenttoken=" + transactiontoken + "&" + $(".yourpay_form").serialize() + "'>");  
                    $(".yourpay.closebutton").css("margin-left", (($(".yourpay.iframeview").width()/2)-24));  
   
                    $(".yourpay.closebutton").click(function()  {  
.......

Der laves derfra et callback der fortæller om betaling er gået godt, transaction ID mm. Så vidt jeg husker giver den også nogle anonymiserede kort-data tilbage til webshoppen således at der kan laves en "ønsker du at benytte samme kort 1234 1234 1234 XXXX som sidst" for kunder der har oprettet en bruger. Disse kommer ganske rigtigt via en GET.

  • 1
  • 0
#12 Thomas Knudsen

Jeg tror ikke at netbutikkerne er klar over det, men de skal lave en selvcertificering hvis de benytter et plugin som beskrevet i artiklen, hvor kortdata transmitteres til gateway via den server, der hoster hjemmesiden.

Det er meget nemt, hvis der finder kortdata processing sted på butikkens hjemmeside så skal butikken som minimum have en lave selvcertificering fra VISA og Mastercard. For denne løsning er det en SAQ-EP eller SAQ-D.

SAQ-EP er et dokument som skal udfyldes, som en del af det skal der også foretages kvartalsvis eksterne scanninger. Alle self assements fra VISA/Mastercard kan findes under PCI council på deres hjemmeside.

Det er naturligvis vanskeligt at validere sikkerheden, hvis forretningens hjemmeside ligger placeret på en shared server med andre hjemmesider og kontrolleret af en tredje-part, der formodentlig ikke er PCI-certifificeret på samme niveau, som forretningen kræver.

SAQ-EP er samme som scope som en egentligt PCI DSS level 1 certificering blot uden audit og uden en større transaktionsvolume.

Dette krav er en en stramning, derfor har Stripe også udfaset deres gamle løsning kaldes stripe.js.

En anden ting er at, alle virksomheder gemmer/behandler kortdata skal have en PCI DSS Level 1 certificering som f.eks. payment gateways. Det er omkostningstungt og kræver eksternt audit, processer, eksterne scanninger m.m. Det er også gateways ansvar at de har overblik over hvor rå kortdata modtages og hvor rå kortdata sender det hen.

Det er faktisk et krav for gateways (providers) at sikre modtagere og afsendere af rå kortdata er inden for PCI-Scope. Jeg formoder Yourpay har fulgt op på sine kunder, der transmitterer rå kortdata, hvilket er en del af PCI DSS compliance.

For at se om en betalingsløsning/gateway er PCI DSS Level 1 certificeret, kan man se om de har en AOC (Attestation Of Compliance). Denne AOC er udstedt af en auditor på vegne af VISA og Mastercard, den bør ligge tilgængelig på hjemmesiden eller kunne udleveres på forspørgelse. Alternativt bør de findes på VISA eller Mastercards lister over godkendte providers (gateways).

https://www.mastercard.us/content/dam/mccom/global/documents/Sitedatapro...

Jeg kan ikke finde AOC eller Yourpay på Mastercards liste, hermed ikke sagt at de ikke har en AOC, men den bør butikken så få udleveret når man får en aftale med dem som butik. På den måde sikrer man som butik processen og ansvaret er i orden, når der modtages betalinger via den valgte indløser (f.eks. NETS, Clearhaus, Bambora, Swedbank, Handelsbanken, som er blandt de største indløsere i norden.). Disse indløsere kræver butikkens gateway har en gyldig AOC, da det tekniske ansvar ellers vil blive flyttet fra gateway til indløser (liability)

I tilfælde kortdata kompromisseres er bødestørelsen fra kort-skemaerne (VISA, Mastercard m.m.) er normalt et større beløb per kort misbrugt. Så det kan hurtigt blive en dyr affære for butikken og gateway ikke og have styr på både sikkerhed og compliance. Jeg kan kun opfordre butikkerne til at følge op på denne sag, således ingen får endnu en økonomisk overraskelse i disse hårde corona-tider.

  • 3
  • 0
#13 Jens Beltofte

Jeg har selv været aktiv bruger af yourpay til flere projekter og kan godt huske nogle "udfordringer" i de tidlige dage. Men kigger jeg på koden til det nuværende plugin, så benytter den sig af en indlejret iframe der poster kort info direkte til yourpays servere via deres api og javascript:

Jf. https://www.yourpay.io/support/woocommerce-betalingsvindue-i-iframe/ så benyttes inpage så snart WooCommerce løsningen kører https, og det kræver specifikt en ændring i Yourpay pluginet hvis man øsnker at kører iframe. Når jeg kigger på nogle sites der kører Yourpay og WooCommerce benyttes der inpage og ikke iframe - også på forrige patch release af Yourpay plugin'et. Reelt burde Yourpage integrationen slet ikke understøtte inpage og kun tilbyde redirect til ekstern betalingsformular eller tilnød iframe / overlay.

  • 0
  • 0
Log ind eller Opret konto for at kommentere