Betalingssikkerhed: PCI og svindel

Modul 6: Administration og sikkerhed · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du forklare, hvorfor en shop aldrig selv behandler kortdata, hvad PCI DSS og SAQ A betyder for en lille shop, hvordan du beskytter kassesiden, og hvordan du genkender og begrænser svindel og card testing.

Centrale begreber: PCI DSS, kortdata, betalingsudbyder, viderestilling til betalingssiden, indlejret betalingsformular (iframe), SAQ A, scripts på kassesiden, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, tilbageførsel (chargeback), svindelrisiko

Kortdata hører ikke til i din shop

Et kreditkortnummer, udløbsdatoen og sikkerhedskoden er guld værd for kriminelle. Den, der gemmer eller videregiver dem, er omfattet af PCI DSS (Payment Card Industry Data Security Standard), kortselskabernes sikkerhedsstandard. Den aktuelle version er v4.0.1. For en virksomhed, der selv behandler kortdata, er det en stor pakke krav: netværksadskillelse, logfiler, scanninger og test udført af en godkendt part.

En lille shop vil ikke derind, og det behøver den heller ikke. Den faste regel er: kortdata kommer aldrig ind i din shop. Kunden taster dem ind hos din betalingsudbyder (Mollie, Stripe, PayPal, WooPayments eller en anden, lektion 4.4). Shoppen får derefter kun besked om, hvorvidt der er betalt, sammen med en reference. Intet kortnummer, ingen kode. Det betyder også:

• lav aldrig dit eget formularfelt til kortnumre, heller ikke "lige til en telefonisk bestilling";
• tag aldrig imod kortdata via mail, chat eller telefon, og skriv dem aldrig i en note på ordren;
• brug ikke et plugin, der gemmer kortdata i din egen database.

Viderestilling eller indlejret: SAQ A

Små shops viser med et SAQ (Self-Assessment Questionnaire, et spørgeskema), at de overholder PCI DSS. Din betalingsudbyder beder nogle gange om det. Det letteste er SAQ A, som er til shops, der helt overlader betalingen til andre. Der er to måder, det fungerer på i en shop:

1. Viderestilling. Efter "bestil" sendes kunden til udbyderens betalingsside og derefter tilbage. Shoppen ser aldrig kortdataene, heller ikke den side, hvor de bliver tastet ind.
2. Indlejret formular. Betalingsfeltet står på din kasseside, men er en iframe (et stykke side) fra udbyderen. Kortdataene går direkte fra browseren til udbyderen.

Siden 31. marts 2025 gælder en ny version af SAQ A. Den indeholder en betingelse, der især rammer den anden måde: Den, der bruger en indlejret formular, skal bekræfte, at sitet ikke er sårbart over for angreb med scripts, som kan ramme betalingssystemet. Baggrunden er e-skimming: et ondsindet script på din kasseside, der læser med på det, kunden taster, eller lægger et falsk betalingsfelt oven på det rigtige. Den, der viderestiller til udbyderens side, er ikke omfattet af den betingelse. Spørg din betalingsudbyder, hvilket SAQ der gælder for din integration; det ved udbyderen præcis.

Det gør du under alle omstændigheder:

• Hold kassesiden ren. Ethvert script på den side kan i princippet læse med: chatwidgets, tag managers, annoncepixels, A/B-testværktøjer. Indlæs kun det på kassesiden, som er nødvendigt for betalingen. En tag manager på kassesiden er en port, hvor alle med adgang til den konto kan tilføje scripts.
• Få plugins, og hold dem opdateret (lektion 6.2). Det meste e-skimming på WordPress kommer ind via et hul i et plugin eller en stjålet administratoradgangskode.
• En Content-Security-Policy (en header, der angiver, hvilke domæner scripts må komme fra) begrænser skaden, hvis der alligevel kommer noget ind. Det er en opgave for en, der kan teste det; en forkert CSP ødelægger din betalingsknap.

https og HSTS på kassesiden

At hele din shop kører via https, er en selvfølge (WordPress-kurset, lektion 3.1). For kassesiden kommer der to ting oveni:

• http skal straks viderestille til https med en permanent viderestilling (301 eller 308). En kunde, der på et tidspunkt taster http://shop.example.com/afrekenen/, må ikke få en ukrypteret side.
• HSTS (HTTP Strict Transport Security) er en header, som beder browseren om i en periode kun at åbne dit site via https. Dermed forhindrer du, at nogen på et åbent wifi opsnapper den første ukrypterede forespørgsel. En max-age på mindst 180 dage er et almindeligt minimum. Slå først HSTS til, når alt virker via https, også de subdomæner, du tager med: En browser, der har set HSTS, afviser derefter http. KB 6752 forklarer, hvordan du sætter det op.

Blandet indhold (et script eller stylesheet via http på en https-side) på kassesiden er ekstra farligt: Netop sådan en fil kan blive udskiftet undervejs.

Card testing

Ved card testing bruger kriminelle din shop til at afprøve stjålne kortnumre. De afgiver automatisk hundredvis af små bestillinger. Hver vellykket betaling fortæller dem, at et kort virker. Du får en stak mislykkede ordrer, gebyrer pr. transaktion, tilbageførsler og i værste fald en betalingsudbyder, der spærrer din konto.

Sådan genkender du det: mange ordrer på kort tid, ofte af det samme lille produkt, med forskellige navne men de samme eller mærkelige adresser, og mange med status Mislykket.

Sådan begrænser du det:

• Rate limiting (en grænse for antallet af forespørgsler pr. tidsenhed). WooCommerces Store API, som blokkene til kurv og kasse bruger, har indbygget rate limiting, men den er slået fra som standard. Under WooCommerce > Indstillinger > Avanceret > Funktioner kan du slå "Rate limiting Checkout block and Store API" til for afgivelse af ordrer. Med kode (et filter) kan du selv sætte grænsen; standarden er 25 forespørgsler pr. 10 sekunder, og kun bestillinger og andre skrivehandlinger tæller med. Står din shop bag en proxy eller et CDN, skal proxyunderstøttelsen slås til, ellers tæller alle besøgende som én.
• En captcha eller en lignende forhindring ved kassen. WooCommerce siger selv, at rate limiting og captcha fungerer bedst sammen: Angribere skifter ofte IP adresse.
• Din betalingsudbyders indstillinger. Udbydere har deres egne svindelfiltre og grænser. Slå dem til, og hold øje med, hvad de melder.
• 3-D Secure (den ekstra bekræftelse i bankappen, en del af stærk kundeautentifikation i EU) gør det sværere for kriminelle og flytter ved en tvist ofte ansvaret over på kortholderens bank.

Anden svindel

Ikke al svindel er automatiseret. Tegn, som tilsammen giver grund til at vente lidt med at sende:

• faktura- og leveringsadresse i forskellige lande, eller en leveringsadresse hos en videresendelsestjeneste;
• en første ordre med kun dyre produkter, der er nemme at sælge videre, med ekspreslevering;
• flere forsøg med forskellige kort;
• en kunde, der efter betalingen beder om at få varen sendt til en anden adresse.

En tilbageførsel (chargeback) er, når kundens bank tilbagefører en kortbetaling. Du mister beløbet, ofte med gebyrer, og produktet er væk. Gem derfor dokumentation for forsendelse og levering. En iDEAL-betaling har indtil nu ikke kunnet tilbageføres på denne måde; hvordan det fungerer med Wero, får du at vide af din betalingsudbyder (lektion 4.4). Det samme gælder de betalingsmetoder, der er almindelige i Danmark, som MobilePay, Dankort/Visa-Dankort, betalingskort og Klarna.

Opsummering

• Kortdata kommer aldrig ind i din shop: hverken i formularer, noter eller mails. Betalingsudbyderen behandler dem.
• Viderestilling til betalingssiden eller et indlejret felt fra udbyderen holder dig i det letteste PCI-spørgeskema (SAQ A); ved et indlejret felt skal din kasseside være beskyttet mod scriptangreb.
• Hold kassesiden ren, via https med en 301 fra http og med HSTS på mindst 180 dage.
• Card testing begrænser du med rate limiting (slået fra som standard), en captcha og din udbyders filtre.
• Hold øje med tegn på svindel, og gem dokumentation for levering mod tilbageførsler, også ved danske betalingsmetoder som MobilePay, Dankort/Visa-Dankort, betalingskort og Klarna.

Quiz

Opgave

Opgave A6.3: Er din kasseside sikker? Udfyld adressen på din shop og adressen på din kasseside. Programmet kontrollerer certifikatet og henter kassesiden via http (uden at følge viderestillinger) og via https (med en tom kurv, der bliver ikke bestilt noget). Grøn, hvis certifikatet er gyldigt, http viderestiller med 301 eller 308 til https, headeren Strict-Transport-Security har en max-age på mindst 180 dage, der ikke er blandet indhold, og højst fem andre domæner indlæser scripts på siden (programmet viser dem). Orange ved manglende eller for kort HSTS, en midlertidig viderestilling (302 eller 307), mere end fem scriptdomæner eller en tag manager, eller et kortnummerfelt i din egen HTML i stedet for hos udbyderen. Rød, hvis https eller certifikatet ikke er i orden, http ikke viderestiller, eller scripts eller stylesheets indlæses via http. Gem aldrig selv kortdata. Denne kontrol ser kun, hvad der står på siden uden kurv.

Spørgsmål til dig selv (bliver ikke rettet): Viderestiller dit betalingsplugin til udbyderen, eller står betalingsfeltet på din side? Hvilket SAQ siger din udbyder, der gælder?

Et grønt flueben betyder, at denne kontrol er i orden lige nu, ikke at din shop er sikker.

Læs videre

Trin i et panel gælder for WebOké; hos andre udbydere fungerer det på lignende måde.

• Gratis WordPress-kursus 3.1: Https og certifikatet
• HSTS og sikkerhedsheaders til din hjemmeside
• Tving besøgende til at bruge https
• DirectAdmin vejledning 6.4: Besøgende altid sende til https
• Gratis kursus Sikker online for virksomheder 4.2: Din hjemmeside: https, HSTS og sikkerhedsheadere
• Opdateringer til SAQ A (PCI Security Standards Council, engelsk): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting for Store API (developer.woocommerce.com, engelsk): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, engelsk): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/
• Betalingssikkerhed i din webshop: PCI, card testing, og hvad din hoster gør