Maksuturvallisuus: PCI ja petokset

Moduuli 6: Ylläpito ja tietoturva · Lukuaika: 11 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää, miksi verkkokauppa ei koskaan käsittele korttitietoja itse, mitä PCI DSS ja SAQ A tarkoittavat pienelle verkkokaupalle, miten suojaat kassasivun ja miten tunnistat ja rajoitat petoksia ja korttitestausta.

Keskeiset käsitteet: PCI DSS, korttitiedot, maksupalvelu, ohjaus maksusivulle, upotettu maksulomake (iframe), SAQ A, kassasivun skriptit, e-skimming, https, HSTS, korttitestaus (card testing), pyyntöjen rajoitus (rate limiting), captcha, 3-D Secure, takaisinveloitus (chargeback), petosriski

Korttitiedot eivät kuulu verkkokauppaasi

Luottokortin numero, voimassaoloaika ja turvakoodi ovat rikollisille kullanarvoisia. Joka tallentaa tai välittää niitä, kuuluu PCI DSS -standardin (Payment Card Industry Data Security Standard) piiriin. Se on korttiyhtiöiden tietoturvastandardi, ja sen nykyinen versio on v4.0.1. Yritykselle, joka käsittelee korttitietoja itse, se tarkoittaa melkoista vaatimuspakettia: verkon eriyttäminen, lokit, skannaukset ja hyväksytyn tahon tekemät testit.

Pieni verkkokauppa ei halua sellaiseen, eikä sen tarvitsekaan. Pysyvä sääntö: korttitiedot eivät koskaan päädy verkkokauppaasi. Asiakas syöttää ne maksupalvelusi (Mollie, Stripe, PayPal, WooPayments tai jokin muu, oppitunti 4.4) sivulle. Kauppa saa sen jälkeen tiedon vain siitä, onnistuiko maksu, sekä viitetunnuksen. Ei kortin numeroa eikä koodia. Se tarkoittaa myös:

• älä koskaan tee omaa lomakekenttää korttinumeroille, et edes "nopeasti puhelintilausta varten";
• älä koskaan ota korttitietoja vastaan sähköpostilla, chatissa tai puhelimessa ja kirjaa niitä tilauksen muistiinpanoon;
• älä käytä lisäosaa, joka tallentaa korttitietoja omaan tietokantaasi.

Ohjaus vai upotus: SAQ A

Pienet verkkokaupat osoittavat SAQ-lomakkeella (Self-Assessment Questionnaire, itsearviointikysely), että ne täyttävät PCI DSS -vaatimukset. Maksupalvelu pyytää sitä joskus. Kevyin on SAQ A, joka on tarkoitettu kaupoille, jotka ulkoistavat maksamisen kokonaan. Verkkokaupassa se toimii kahdella tavalla:

1. Ohjaus. Tilaamisen jälkeen asiakas siirtyy maksupalvelun maksusivulle ja sieltä takaisin. Kauppa ei näe korttitietoja koskaan, eikä edes sivua, jolla ne syötetään.
2. Upotettu lomake. Maksukenttä on kassasivullasi, mutta se on maksupalvelun iframe (sivun osa). Korttitiedot kulkevat selaimesta suoraan maksupalvelulle.

31. maaliskuuta 2025 alkaen on ollut voimassa uusi SAQ A -versio. Siinä on ehto, joka koskee erityisesti toista tapaa: upotetun lomakkeen käyttäjän on vahvistettava, että sivusto ei ole altis skriptihyökkäyksille, jotka voivat vaikuttaa maksujärjestelmään. Taustalla on e-skimming: kassasivulla oleva haitallinen skripti, joka lukee asiakkaan syöttämät tiedot tai asettaa väärennetyn maksukentän oikean päälle. Jos ohjaat asiakkaan maksupalvelun sivulle, ehto ei koske sinua. Kysy maksupalvelultasi, mikä SAQ koskee sinun integraatiotasi; se tietää sen tarkasti.

Tee joka tapauksessa näin:

• Pidä kassasivu riisuttuna. Jokainen sivun skripti voi periaatteessa lukea tietoja: chat-widgetit, tagienhallinnat, mainospikselit ja A/B-testityökalut. Lataa kassasivulla vain se, mitä maksaminen vaatii. Kassasivun tagienhallinta on portti, jonka kautta kuka tahansa tilin käyttöoikeuden omaava voi lisätä skriptejä.
• Vähän lisäosia, ja ajan tasalla (oppitunti 6.2). Suurin osa WordPressin e-skimmingistä tulee sisään lisäosan haavoittuvuuden tai varastetun ylläpitäjän salasanan kautta.
• Content-Security-Policy (otsakerivi, joka kertoo, miltä verkkotunnuksilta skriptejä saa ladata) rajoittaa vahinkoja, jos jotain kuitenkin pääsee sisään. Se on työtä henkilölle, joka osaa testata sen; väärin tehty CSP rikkoo maksupainikkeesi.

https ja HSTS kassasivulla

On itsestään selvää, että koko kauppasi toimii https-yhteydellä (WordPress-kurssi, oppitunti 3.1). Kassasivulla siihen tulee kaksi lisäasiaa:

• http-osoitteen on ohjattava heti https-osoitteeseen pysyvällä uudelleenohjauksella (301 tai 308). Asiakas, joka joskus kirjoittaa http://shop.example.com/afrekenen/, ei saa salaamatonta sivua.
• HSTS (HTTP Strict Transport Security) on otsakerivi, jolla käsket selainta avaamaan sivustosi jonkin aikaa vain https-yhteydellä. Näin estät sen, että joku avoimessa wifissä sieppaa ensimmäisen salaamattoman pyynnön. Vähintään 180 päivän max-age on yleinen minimi. Ota HSTS käyttöön vasta, kun kaikki, myös mukaan otettavat aliverkkotunnukset, toimii https-yhteydellä: HSTS:n nähnyt selain kieltäytyy sen jälkeen http-yhteydestä. KB 6752 kertoo, miten asetat sen.

Sekasisältö (http-yhteydellä ladattu skripti tai tyylitiedosto https-sivulla) on kassasivulla erityisen vaarallista: juuri sellainen tiedosto voidaan vaihtaa matkalla.

Korttitestaus

Korttitestauksessa (card testing) rikolliset käyttävät kauppaasi varastettujen korttinumeroiden kokeilemiseen. He tekevät automaattisesti satoja pieniä tilauksia. Jokainen onnistunut maksu kertoo heille, että kortti toimii. Sinä saat kasan epäonnistuneita tilauksia, tapahtumakohtaisia kuluja, takaisinveloituksia ja pahimmassa tapauksessa maksupalvelun, joka sulkee tilisi.

Tunnistaminen: paljon tilauksia lyhyessä ajassa, usein samaa pientä tuotetta, eri nimillä mutta samoilla tai oudoilla osoitteilla, ja paljon tilaa Epäonnistunut.

Rajoittaminen:

• Pyyntöjen rajoitus (rate limiting, raja pyyntöjen määrälle aikayksikössä). WooCommercen Store API, jota ostoskorin ja kassan lohkot käyttävät, sisältää pyyntöjen rajoituksen, mutta se on oletuksena pois päältä. Kohdassa WooCommerce > Asetukset > Edistyneet > Ominaisuudet voit ottaa käyttöön asetuksen "Rate limiting Checkout block and Store API" tilausten tekemiselle. Koodilla (suodattimella) voit asettaa rajan itse; oletus on 25 pyyntöä 10 sekunnissa, ja vain tilaaminen ja muut kirjoittavat toiminnot lasketaan. Jos kauppasi on välityspalvelimen tai CDN:n takana, välityspalvelintuki on otettava käyttöön, muuten kaikki kävijät lasketaan yhdeksi.
• Captcha tai vastaava kynnys kassalla. WooCommerce toteaa itse, että pyyntöjen rajoitus ja captcha toimivat parhaiten yhdessä: hyökkääjät vaihtavat usein IP-osoitetta.
• Maksupalvelusi asetukset. Maksupalveluilla on omat petossuodattimet ja rajat. Ota ne käyttöön ja seuraa, mitä ne ilmoittavat.
• 3-D Secure (lisävahvistus pankkisovelluksessa, osa EU:n vahvaa asiakkaan tunnistamista) tekee rikollisten työstä vaikeampaa ja siirtää riitatilanteessa vastuun usein kortinhaltijan pankille.

Muut petokset

Kaikki petokset eivät ole automatisoituja. Merkkejä, jotka yhdessä antavat syyn odottaa hetki ennen lähettämistä:

• laskutus- ja toimitusosoite eri maissa, tai toimitusosoite edelleenlähetyspalvelussa;
• ensimmäinen tilaus, jossa on vain kalliita, helposti edelleen myytäviä tuotteita ja pikatoimitus;
• useita yrityksiä eri korteilla;
• asiakas, joka maksun jälkeen pyytää lähettämään tilauksen toiseen osoitteeseen.

Takaisinveloitus (chargeback) tarkoittaa, että asiakkaan pankki peruu korttimaksun. Menetät summan, usein kulujen kera, ja tuote on mennyt. Säilytä siksi todisteet lähettämisestä ja toimituksesta. Alankomaissa iDEAL-maksua ei tähän asti ole voinut perua tällä tavalla; miten Wero toimii, kerrot maksupalvelultasi (oppitunti 4.4).

Yhteenveto

• Korttitiedot eivät koskaan päädy kauppaasi: ei lomakkeisiin, muistiinpanoihin eikä sähköposteihin. Maksupalvelu käsittelee ne.
• Ohjaus maksusivulle tai maksupalvelun upotettu kenttä pitää sinut kevyimmässä PCI-kyselyssä (SAQ A); upotetun kentän kanssa kassasivusi on oltava suojattu skriptihyökkäyksiltä.
• Pidä kassasivu riisuttuna, https-yhteydellä, 301-ohjauksella http-osoitteesta ja vähintään 180 päivän HSTS:llä.
• Korttitestausta rajoitat pyyntöjen rajoituksella (oletuksena pois päältä), captchalla ja maksupalvelusi suodattimilla.
• Seuraa petosten merkkejä ja säilytä todisteet toimituksesta takaisinveloitusten varalta.

Tietovisa (quiz)

Tehtävä

Tehtävä A6.3: Onko kassasivusi turvallinen? Syötä kauppasi osoite ja kassasivusi osoite. Ohjelma tarkistaa varmenteen ja hakee kassasivun http-yhteydellä (ilman uudelleenohjauksen seuraamista) ja https-yhteydellä (tyhjällä ostoskorilla, mitään ei tilata). Vihreä, jos varmenne on voimassa, http ohjaa 301- tai 308-ohjauksella https-osoitteeseen, Strict-Transport-Security-otsakkeen max-age on vähintään 180 päivää, sekasisältöä ei ole ja enintään viisi muuta verkkotunnusta lataa sivulle skriptejä (ohjelma näyttää ne). Oranssi, jos HSTS puuttuu tai on liian lyhyt, ohjaus on tilapäinen (302 tai 307), skriptiverkkotunnuksia on yli viisi tai käytössä on tagienhallinta, tai jos korttinumerokenttä on omassa HTML:ssä eikä maksupalvelulla. Punainen, jos https tai varmenne ei ole kunnossa, http ei ohjaa tai skriptejä tai tyylitiedostoja ladataan http-yhteydellä. Älä koskaan tallenna korttitietoja itse. Tämä tarkistus näkee vain sen, mitä sivulla on ilman ostoskoria.

Kysymys itsellesi (ei tarkisteta): ohjaako maksulisäosasi maksupalvelulle, vai onko maksukenttä sivullasi? Mikä SAQ maksupalvelusi mukaan koskee sinua?

Vihreä merkki tarkoittaa, että tämä tarkistus on nyt kunnossa, ei sitä, että kauppasi olisi turvallinen.

Lue lisää

Ohjauspaneelin vaiheet koskevat WebOkéta; muilla palveluntarjoajilla se toimii samaan tapaan.

• Ilmainen WordPress-kurssi 3.1: Https ja sertifikaatti
• HSTS ja suojausotsikot verkkosivustollesi
• Ohjaa kävijät pakotetusti https-osoitteeseen
• DirectAdmin-ohje 6.4: Kävijät aina https-osoitteeseen ohjaaminen
• Ilmainen kurssi: Turvallisesti verkossa yrittäjille 4.2: Verkkosivustosi: https, HSTS ja suojausotsikot
• SAQ A:n päivitykset (PCI Security Standards Council, englanniksi): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Store API:n pyyntöjen rajoitus (developer.woocommerce.com, englanniksi): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, englanniksi): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/