Betalningssäkerhet: PCI och bedrägerier

Modul 6: Förvaltning och säkerhet · Lästid: 11 minuter

Lärandemål: Efter den här lektionen kan du förklara varför en butik aldrig själv hanterar kortuppgifter och vad PCI DSS och SAQ A betyder för en liten butik. Du vet också hur du skyddar kassasidan och hur du känner igen och begränsar bedrägerier och card testing.

Nyckelbegrepp: PCI DSS, kortuppgifter, betalleverantör, vidarebefordran till betalsidan, inbäddat betalformulär (iframe), SAQ A, skript på kassasidan, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, återdebitering (chargeback), bedrägeririsk

Kortuppgifter hör inte hemma i din butik

Ett kreditkortsnummer, utgångsdatumet och säkerhetskoden är guld värda för brottslingar. Den som sparar eller vidarebefordrar dem omfattas av PCI DSS (Payment Card Industry Data Security Standard), kortbolagens säkerhetsstandard. Den aktuella versionen är v4.0.1. För ett företag som själv hanterar kortuppgifter innebär det ett stort paket krav: nätverkssegmentering, loggar, skanningar och tester av en godkänd part.

Det vill en liten butik inte hålla på med, och det behöver den inte heller. Den fasta regeln: kortuppgifter kommer aldrig in i din butik. Kunden skriver in dem hos din betalleverantör (Mollie, Stripe, PayPal, WooPayments eller en annan, lektion 4.4). Butiken får sedan bara veta: betalt eller inte, med en referens. Inget kortnummer, ingen kod. Det betyder också:

• skapa aldrig ett eget formulärfält för kortnummer, inte ens "snabbt för en telefonbeställning";
• ta aldrig emot kortuppgifter via mejl, chatt eller telefon för att lägga dem i en anteckning till beställningen;
• använd inget tillägg som sparar kortuppgifter i din egen databas.

Vidarebefordran eller inbäddat: SAQ A

Små butiker visar med en SAQ (Self-Assessment Questionnaire, ett frågeformulär) att de uppfyller PCI DSS. Din betalleverantör ber ibland om det. Det lättaste är SAQ A, för butiker som helt lägger ut betalningen. Det finns två sätt som det fungerar på i en butik:

1. Vidarebefordran. Efter "beställ" skickas kunden till leverantörens betalsida och sedan tillbaka. Butiken ser aldrig kortuppgifterna, inte heller sidan där de skrivs in.
2. Inbäddat formulär. Betalfältet finns på din kassasida, men är en iframe (en bit sida) från leverantören. Kortuppgifterna går direkt från webbläsaren till leverantören.

Sedan 31 mars 2025 gäller en ny version av SAQ A. Där finns ett villkor som främst berör det andra sättet: den som använder ett inbäddat formulär måste bekräfta att webbplatsen inte är sårbar för attacker med skript som kan påverka betalsystemet. Bakgrunden är e-skimming: ett skadligt skript på din kassasida som läser av det kunden skriver in, eller lägger ett falskt betalfält ovanpå det riktiga. Den som vidarebefordrar till leverantörens sida omfattas inte av det villkoret. Fråga din betalleverantör vilken SAQ som gäller för din koppling; den vet exakt.

Det här gör du i alla fall:

• Håll kassasidan avskalad. Varje skript på den sidan kan i princip läsa av: chattwidgetar, tagghanterare, annonspixlar, verktyg för A/B-tester. Ladda bara det som behövs för betalningen på kassasidan. En tagghanterare på kassasidan är en port där alla med åtkomst till det kontot kan lägga till skript.
• Få tillägg, och uppdaterade (lektion 6.2). Det mesta av e-skimmingen på WordPress kommer in via en sårbarhet i ett tillägg eller ett stulet administratörslösenord.
• En Content-Security-Policy (en header som anger från vilka domäner skript får komma) begränsar skadan om något ändå kommer in. Det är ett jobb för någon som kan testa det; en felaktig CSP kan få din betalknapp att sluta fungera.

https och HSTS på kassasidan

Att hela butiken körs via https är självklart (WordPress-kursen, lektion 3.1). För kassasidan tillkommer två saker:

• http måste direkt vidarebefordras till https, med en permanent omdirigering (301 eller 308). En kund som någon gång skriver http://shop.example.com/afrekenen/ får inte få en okrypterad sida.
• HSTS (HTTP Strict Transport Security) är en header som säger åt webbläsaren att under en tid bara öppna din webbplats via https. Det hindrar att någon på ett öppet wifi fångar upp den första okrypterade förfrågan. En max-age på minst 180 dagar är ett vanligt minimum. Slå på HSTS först när allt, även underdomäner som du tar med, fungerar via https: en webbläsare som har sett HSTS vägrar därefter http. KB 6752 förklarar hur du ställer in det.

Blandat innehåll (ett skript eller en stilmall via http på en https-sida) på kassasidan är extra farligt: just en sådan fil kan bytas ut på vägen.

Card testing

Vid card testing använder brottslingar din butik för att prova stulna kortnummer. De lägger automatiskt hundratals små beställningar. Varje lyckad betalning berättar för dem att ett kort fungerar. Du får en hög misslyckade beställningar, avgifter per transaktion, återdebiteringar och i värsta fall en betalleverantör som spärrar ditt konto.

Känna igen: många beställningar på kort tid, ofta av samma lilla produkt, med olika namn men samma eller konstiga adresser, och många med status Misslyckad.

Begränsa:

• Rate limiting (en gräns för antalet förfrågningar per tidsenhet). WooCommerce Store API, som blocken för varukorg och kassa använder, har inbyggd rate limiting, men den är avstängd som standard. Under WooCommerce > Inställningar > Avancerat > Funktioner kan du slå på "Rate limiting Checkout block and Store API" för när beställningar läggs. Med kod (ett filter) kan du själv ställa in gränsen; standard är 25 förfrågningar per 10 sekunder och bara beställningar och andra skrivåtgärder räknas. Ligger din butik bakom en proxy eller ett CDN måste proxystödet vara på, annars räknas alla besökare som en.
• En captcha eller ett liknande hinder i kassan. WooCommerce säger själv att rate limiting och captcha fungerar bäst tillsammans: angripare byter ofta IP-adress.
• Din betalleverantörs inställningar. Leverantörer har egna bedrägerifilter och gränser. Slå på dem och se vad de rapporterar.
• 3-D Secure (den extra bekräftelsen i bankappen, en del av stark kundautentisering i EU) gör det svårare för brottslingar och flyttar vid en tvist ofta ansvaret till kortinnehavarens bank.

Andra bedrägerier

Alla bedrägerier är inte automatiserade. Signaler som sammantaget ger skäl att vänta lite med att skicka:

• faktura- och leveransadress i olika länder, eller en leveransadress hos en eftersändningstjänst;
• en första beställning med bara dyra produkter som är lätta att sälja vidare, med expressfrakt;
• flera försök med olika kort;
• en kund som efter betalningen ber dig skicka till en annan adress.

En återdebitering (chargeback) innebär att kundens bank återför en kortbetalning. Du förlorar beloppet, ofta med avgifter, och produkten är borta. Spara därför bevis på leverans och utdelning. En betalning med iDEAL kunde hittills inte återföras på det här sättet; hur det fungerar med Wero får du veta av din betalleverantör (lektion 4.4). Säljer du till kunder i Sverige är Swish, Klarna och kort exempel på betalsätt; även där frågar du din betalleverantör hur återföringar fungerar.

Sammanfattning

• Kortuppgifter kommer aldrig in i din butik: inte i formulär, anteckningar eller mejl. Betalleverantören hanterar dem.
• Vidarebefordran till betalsidan eller ett inbäddat fält från leverantören håller dig i det lättaste PCI-frågeformuläret (SAQ A); med ett inbäddat fält måste kassasidan vara skyddad mot skriptattacker.
• Håll kassasidan avskalad, via https med en 301 från http och med HSTS på minst 180 dagar.
• Card testing begränsar du med rate limiting (avstängd som standard), en captcha och leverantörens filter.
• Var uppmärksam på tecken på bedrägeri och spara bevis på leverans mot återdebiteringar.

Quiz

Uppgift

Uppgift A6.3: Är din kassasida säker? Fyll i adressen till din butik och adressen till din kassasida. Programmet kontrollerar certifikatet och hämtar kassasidan via http (utan att följa omdirigeringar) och via https (med en tom varukorg, ingenting beställs). Grönt om certifikatet är giltigt, http skickar vidare till https med 301 eller 308, headern Strict-Transport-Security har en max-age på minst 180 dagar, det inte finns något blandat innehåll och högst fem andra domäner laddar skript på sidan (programmet visar dem). Orange vid ingen eller för kort HSTS, en tillfällig omdirigering (302 eller 307), fler än fem skriptdomäner eller en tagghanterare, eller ett fält för kortnummer i den egna HTML-koden i stället för hos leverantören. Rött om https eller certifikatet inte stämmer, http inte skickar vidare eller skript eller stilmallar laddas via http. Spara aldrig kortuppgifter själv. Den här kontrollen ser bara det som finns på sidan utan varukorg.

Fråga dig själv (kontrolleras inte): skickar ditt betaltillägg vidare till leverantören, eller finns betalfältet på din sida? Vilken SAQ säger din leverantör att det gäller?

En grön bock betyder att den här kontrollen stämmer just nu, inte att din butik är säker.

Läs mer

Stegen i en panel gäller för WebOké; hos andra leverantörer fungerar det på liknande sätt.

• Gratis WordPress-kurs 3.1: Https och certifikatet
• HSTS och säkerhetsheaders för din webbplats
• Tvinga besökare att omdirigeras till https
• DirectAdmin-guide 6.4: Besökare alltid till https
• Gratis kurs Säkert online för företagare 4.2: Din webbplats: https, HSTS och säkerhetsheaders
• Uppdateringar för SAQ A (PCI Security Standards Council, engelska): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting för Store API (developer.woocommerce.com, engelska): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, engelska): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/
• Betalsäkerhet i din webbshop: PCI, card testing och vad ditt webbhotell gör