Betalingssikkerhet: PCI og svindel

Modul 6: Drift og sikkerhet · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du forklare hvorfor en nettbutikk aldri behandler kortdata selv, hva PCI DSS og SAQ A betyr for en liten nettbutikk, hvordan du beskytter kassesiden, og hvordan du kjenner igjen og begrenser svindel og card testing.

Nøkkelbegreper: PCI DSS, kortdata, betalingsleverandør, videresending til betalingssiden, innebygd betalingsskjema (iframe), SAQ A, skript på kassesiden, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, tilbakeføring (chargeback), svindelrisiko

Kortdata hører ikke hjemme i nettbutikken din

Et kredittkortnummer, utløpsdatoen og sikkerhetskoden er gull verdt for kriminelle. Den som lagrer eller videreformidler dem, faller inn under PCI DSS (Payment Card Industry Data Security Standard), sikkerhetsstandarden til kortselskapene. Gjeldende versjon er v4.0.1. For en bedrift som behandler kortdata selv, er det en stor pakke med krav: nettverkssegmentering, logger, skanninger og testing utført av en godkjent aktør.

En liten nettbutikk vil ikke havne der, og trenger heller ikke det. Den faste regelen: kortdata kommer aldri inn i nettbutikken din. Kunden skriver dem inn hos betalingsleverandøren din (Mollie, Stripe, PayPal, WooPayments eller en annen, leksjon 4.4). Nettbutikken får deretter bare beskjed om betalingen er gjennomført eller ikke, med en referanse. Ikke noe kortnummer, ingen kode. Det betyr også:

• lag aldri et eget skjemafelt for kortnummer, heller ikke "bare for en telefonbestilling";
• ta aldri imot kortdata på e-post, chat eller telefon for å legge dem i et notat på bestillingen;
• ikke bruk en utvidelse som lagrer kortdata i din egen database.

Videresending eller innebygd: SAQ A

Små nettbutikker viser med en SAQ (Self-Assessment Questionnaire, et spørreskjema) at de oppfyller PCI DSS. Betalingsleverandøren din ber noen ganger om dette. Det enkleste er SAQ A, for nettbutikker som setter betalingen helt ut. Det kan fungere på to måter i en nettbutikk:

1. Videresending. Etter "bestill" sendes kunden til betalingssiden hos leverandøren og deretter tilbake. Nettbutikken ser aldri kortdataene, og heller ikke siden der de skrives inn.
2. Innebygd skjema. Betalingsfeltet står på kassesiden din, men er en iframe (en bit av en side) fra leverandøren. Kortdataene går fra nettleseren direkte til leverandøren.

Siden 31. mars 2025 gjelder en ny versjon av SAQ A. Den inneholder et vilkår som særlig gjelder den andre måten: den som bruker et innebygd skjema, må bekrefte at nettstedet ikke er sårbart for angrep med skript som kan ramme betalingssystemet. Bakgrunnen er e-skimming: et ondsinnet skript på kassesiden som leser med på det kunden skriver, eller som legger et falskt betalingsfelt over det ekte. Den som videresender til leverandørens side, omfattes ikke av dette vilkåret. Spør betalingsleverandøren din hvilken SAQ som gjelder for din integrasjon; de vet det nøyaktig.

Dette gjør du uansett:

• Hold kassesiden enkel. Ethvert skript på den siden kan i prinsippet lese med: chatwidgeter, tag managers, annonsepiksler, A/B-testverktøy. Last bare inn det som trengs for betalingen på kassesiden. En tag manager på kassesiden er en port der alle med tilgang til den kontoen kan legge til skript.
• Få utvidelser, og hold dem oppdatert (leksjon 6.2). Mesteparten av e-skimming på WordPress kommer inn via et sikkerhetshull i en utvidelse eller et stjålet administratorpassord.
• En Content-Security-Policy (en header som angir hvilke domener skript får komme fra) begrenser skaden hvis noe likevel kommer inn. Det er en jobb for noen som kan teste det; en feil CSP ødelegger betalingsknappen din.

https og HSTS på kassesiden

At hele nettbutikken din kjører på https, er en selvfølge (WordPress-kurset, leksjon 3.1). For kassesiden kommer to ting i tillegg:

• http må videresende direkte til https, med en permanent videresending (301 eller 308). En kunde som en gang skriver inn http://shop.example.com/kasse/, skal ikke få en ukryptert side.
• HSTS (HTTP Strict Transport Security) er en header som ber nettleseren åpne nettstedet ditt bare via https i en periode. Slik hindrer du at noen på et åpent wifi fanger opp den første ukrypterte forespørselen. En max-age på minst 180 dager er et vanlig minimum. Slå på HSTS først når alt, også underdomener du tar med, fungerer via https: en nettleser som har sett HSTS, nekter http etterpå. KB 6752 forklarer hvordan du stiller det inn.

Blandet innhold (et skript eller stilark via http på en https-side) på kassesiden er ekstra farlig: akkurat en slik fil kan byttes ut underveis.

Card testing

Ved card testing bruker kriminelle nettbutikken din til å prøve ut stjålne kortnummer. De legger automatisk inn hundrevis av små bestillinger. Hver vellykket betaling forteller dem at et kort virker. Du får en bunke mislykkede bestillinger, kostnader per transaksjon, tilbakeføringer og i verste fall en betalingsleverandør som sperrer kontoen din.

Slik kjenner du det igjen: mange bestillinger på kort tid, ofte av det samme lille produktet, med ulike navn men like eller rare adresser, og mange med statusen Mislyktes.

Slik begrenser du det:

• Rate limiting (en grense for antall forespørsler per tidsenhet). Store API i WooCommerce, som blokkene for handlekurv og kasse bruker, har innebygd rate limiting, men den er av som standard. Under WooCommerce > Innstillinger > Avansert > Funksjoner kan du slå på "Rate limiting Checkout block and Store API" for innlegging av bestillinger. Med kode (et filter) kan du stille inn grensen selv; standarden er 25 forespørsler per 10 sekunder, og bare bestillinger og andre skrivehandlinger telles. Står nettbutikken din bak en proxy eller et CDN, må proxystøtten være slått på, ellers telles alle besøkende som én.
• En captcha eller en lignende terskel i kassen. WooCommerce sier selv at rate limiting og captcha fungerer best sammen: angripere bytter ofte IP-adresse.
• Innstillingene hos betalingsleverandøren din. Leverandører har egne svindelfiltre og grenser. Slå dem på og se hva de varsler om.
• 3-D Secure (den ekstra bekreftelsen i bankappen, en del av sterk kundeautentisering i EU) gjør det vanskeligere for kriminelle og flytter ved en tvist ofte ansvaret over på kortinnehaverens bank.

Annen svindel

Ikke all svindel er automatisert. Signaler som til sammen gir grunn til å vente litt med å sende:

• faktura- og leveringsadresse i ulike land, eller en leveringsadresse hos en videresendingstjeneste;
• en første bestilling med bare dyre produkter som er lette å selge videre, med ekspressfrakt;
• flere forsøk med ulike kort;
• en kunde som etter betalingen ber om å få sendt varen til en annen adresse.

En tilbakeføring (chargeback) betyr at kundens bank reverserer en kortbetaling. Du mister beløpet, ofte med gebyrer, og produktet er borte. Ta derfor vare på bevis for forsendelse og levering. En iDEAL-betaling (Nederland) har hittil ikke kunnet reverseres på denne måten; hvordan det fungerer med Wero, får du vite av betalingsleverandøren din (leksjon 4.4). I Norge er Vipps, kort og Klarna vanlige betalingsmåter; spør leverandøren din hvordan tilbakeføring fungerer for hver av dem.

Sammendrag

• Kortdata kommer aldri inn i nettbutikken din: ikke i skjemaer, notater eller e-poster. Betalingsleverandøren behandler dem.
• Videresending til betalingssiden eller et innebygd felt fra leverandøren holder deg i det enkleste PCI-spørreskjemaet (SAQ A); med et innebygd felt må kassesiden være beskyttet mot skriptangrep.
• Hold kassesiden enkel, på https med 301 fra http og med HSTS på minst 180 dager.
• Card testing begrenser du med rate limiting (av som standard), en captcha og filtrene hos leverandøren din.
• Følg med på tegn på svindel og ta vare på bevis for levering mot tilbakeføringer.

Quiz

Oppgave

Oppgave A6.3: Er kassesiden din sikker? Fyll inn adressen til nettbutikken din og adressen til kassesiden din. Programmet kontrollerer sertifikatet, henter kassesiden via http (uten å følge videresending) og via https (med tom handlekurv, ingenting blir bestilt). Grønt hvis sertifikatet er gyldig, http sender videre til https med 301 eller 308, headeren Strict-Transport-Security har en max-age på minst 180 dager, det ikke finnes blandet innhold og høyst fem andre domener laster skript på siden (programmet viser dem). Oransje ved manglende eller for kort HSTS, en midlertidig videresending (302 eller 307), mer enn fem skriptdomener eller en tag manager, eller et kortnummerfelt i din egen HTML i stedet for hos leverandøren. Rødt hvis https eller sertifikatet ikke stemmer, http ikke sender videre, eller skript eller stilark lastes via http. Lagre aldri kortdata selv. Denne kontrollen ser bare det som står på siden uten handlekurv.

Spørsmål til deg selv (blir ikke rettet): sender betalingsutvidelsen din kunden videre til leverandøren, eller står betalingsfeltet på siden din? Hvilken SAQ sier leverandøren din at gjelder?

En grønn hake betyr at denne kontrollen stemmer nå, ikke at nettbutikken din er sikker.

Les mer

Trinn i et kontrollpanel gjelder for WebOké; hos andre leverandører fungerer det tilsvarende.

• Gratis WordPress-kurs 3.1: Https og sertifikatet
• HSTS og sikkerhetsheadere for nettstedet ditt
• Tving besøkende over til https
• DirectAdmin-veiledning 6.4: Besøkende alltid sende til https
• Gratis kurs Trygt på nett for bedrifter 4.2: Nettstedet ditt: https, HSTS og sikkerhetsheadere
• Oppdateringer for 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/