Varnost spletne trgovine: tehnični ukrepi za podjetja

Za takojšnje zmanjšanje tveganja uvedite TLS/HTTPS s HSTS, posodobite CMS in odstranite vtičnike, ki jih ne potrebujete, ter plačila vedno potrjujte na strežniku. Pri varnosti spletne trgovine se najprej zapre tisto, kar napadalci izkoriščajo najpogosteje: nezaščiten promet, zastarela koda in zaupanje podatkom iz brskalnika. Ostalo si sledi v razlagi spodaj.

---

Na kratko:

• Pred sprostitvijo naročila naj strežnik pri plačilnem prehodu preveri status, znesek in številko naročila; odgovor brskalnika sam po sebi ne potrjuje plačila.
• Sporočilo plačilnega prehoda sprejmite le ob veljavnem podpisu, ponovljeno sporočilo pa ne sme sprožiti dvojne izvedbe ali dvojnega knjiženja.
• Za skrbnike in zaposlene zahtevajte večfaktorsko prijavo; kupcem jo ponudite kot možnost, pri čemer imajo aplikacije za kode in varnostni ključi prednost pred sporočili SMS.
• Varnostne kopije hranite ločeno od trgovine, jih šifrirajte in obnovitev preizkusite vsaj nekajkrat letno, saj nepreverjena kopija ni zagotovilo.

---

Kazalo

• Kako zaščitite komunikacijo med trgovino in kupcem
• Zakaj CMS in vtičniki najpogosteje odpovejo
• Kako varno povežete plačilni prehod in webhooke
• Poslovna logika kot vir ranljivosti
• Spremljanje, testi in odziv na incidente
• Kako OWASP ASVS vključi varnost že v razvoj
• Kaj poročila o incidentih povedo o trendih
• Upravljanje uporabniških dostopov in gesel
• Dvofaktorska avtentikacija za kupce in skrbnike
• Posodobitve in varnostne kopije
• Zaščita strežnika in obramba pred DDoS napadi
• Šifriranje občutljivih podatkov v bazi
• Varnostno usposabljanje zaposlenih in uporabnikov
• Perspektiva avtorja: kako varnost vgradimo v projekte
• Varnostni pregled in storitve Moxy-web
• Pogosta vprašanja
• Viri

Kako zaščitite komunikacijo med trgovino in kupcem

Podatek, ki potuje med brskalnikom in vašim strežnikom, je lahko brez šifriranja izpostavljen prestrezanju. Zato je prvi korak obvezna raba TLS na celotni trgovini, ne le na blagajni. Priročnik OWASP Developer Guide zahteva, da podporo za navaden HTTP opustite, SSL stiskanje izklopite in povezave gradite na standardnih TLS konfiguracijah z veljavnimi certifikati.

Praktično to pomeni nekaj konkretnih nastavitev:

• Ves promet s HTTP samodejno preusmerite na HTTPS in odstranite vsebino, ki se še nalaga prek nešifriranih povezav.
• Vključite glavo Strict-Transport-Security (HSTS), da brskalnik sam zavrne nešifrirano povezavo in se tako zmanjša možnost napada s posrednikom (MITM).
• Nastavite Content-Security-Policy, ki brskalniku pove, iz katerih virov sme nalagati skripte, in s tem oteži vstavljanje tujih skript (XSS).
• Izklopite stare različice SSL/TLS in šibke cipher suite, certifikate pa redno preverjajte in obnavljajte pred potekom.
• Iz konfiguracije odstranite stiskanje na ravni SSL, ker odpira vrata napadom, ki iz velikosti odgovorov izluščijo vsebino.

Primerjajte to s fizično trgovino: TLS je zaprta vrata med blagajno in ulico, HSTS pa brskalniku sporoči, naj uporablja varno povezavo. Dobra konfiguracija je nevidna, zato jo podjetja pogosto zanemarijo, dokler ne pride do incidenta.

Strokovni nasvet: Po vsaki spremembi strežnika ali CDN-ja ponovno preverite glave HSTS in CSP, ker jih posodobitve konfiguracije tiho prepišejo.

Za bralce, ki želijo širši pogled na varovanje podatkov, imamo pripravljeno tudi besedilo o varnosti podatkov na spletni strani.

Zakaj CMS in vtičniki najpogosteje odpovejo

Vdori v manjše trgovine se lahko začnejo z vtičnikom, ki ga nihče ni posodobil. SI-CERT opozarja, da lastniki trgovin pogosto podcenjujejo varnostne konfiguracije osnovnih komponent. Napadalci izkoriščajo zastarele vtičnike in napačne pravice za zapisovanje, kar jim omogoča, da v trgovino vstavijo zlonamerno kodo, na primer nevidne obrazce, ki prestrezajo podatke o karticah.

Varnost CMS-ja zato gradite po tem vrstnem redu:

1. Posodobite jedro CMS-ja in vse vtičnike, nato odstranite tiste, ki jih ne uporabljate. Neaktiven vtičnik lahko poveča površino za napad, ne da bi koristil poslovanju.
2. Izbirajte vtičnike z aktivnim vzdrževanjem, jasno zgodovino popravkov in majhnim obsegom funkcij, ki jih resnično potrebujete.
3. Omejite pravice za zapisovanje na strežniku, tako da spletni proces ne more spreminjati programskih datotek. Omejevanje zapisovalnih pravic lahko oteži vstavljanje skimmerja.
4. Vpeljite spremljanje celovitosti datotek, ki vas opozori, ko se katera od sistemskih datotek spremeni brez vašega posega.
5. Zaženite avtomatizirano skeniranje ranljivosti in ga ponavljajte po vsaki večji posodobitvi.

Poseben primer so obrazci, prek katerih zlorabe pogosto vstopajo. Več o tem najdete v prispevku o zaščiti obrazcev pred spletnimi zlorabami.

Kako varno povežete plačilni prehod in webhooke

Plačilni tok je mesto, kjer se napake takoj spremenijo v denar. OWASP Cheat Sheet za integracijo plačilnih prehodov je jasen: status plačila potrdite med strežnikoma, ne na podlagi tega, kar vrne brskalnik. Kupec, ki sam pokliče naslov za uspešno plačilo, ne sme dobiti pošiljke.

Pri integraciji držite naslednja pravila:

• Pred sprostitvijo naročila strežnik pri prehodu preveri status plačila, znesek in ID naročila.
• Webhook sprejmite samo, če je podpis (HMAC) veljaven, in ga primerjajte s skrivnostjo, ki je ni v brskalniku ali javni kodi.
• Obdelavo naredite idempotentno: če prehod isto sporočilo pošlje dvakrat, se naročilo ne sme izvesti ali knjižiti dvakrat.
• Vsako spremembo stanja naročila zapišite v dnevnik in nastavite opozorila ob nenavadnih vzorcih, na primer ob številnih zavrnjenih podpisih.
• Podatkov o karticah ne shranjujte in jih ne zapisujte v dnevnike, če jih plačilni ponudnik sam obdela.

Če trgovino povezujete še z drugimi poslovnimi sistemi, je koristen tudi pregled, kako povezati ERP, POS in CRM, saj vsaka dodatna povezava prinese novo točko, ki jo je treba zavarovati.

Poslovna logika kot vir ranljivosti

Napadi na poslovno logiko lahko izkoristijo pravila, ki jih je razvijalec predpostavil, ne pa preveril. Business Logic Security Cheat Sheet opozarja, da sistemi pogosto ne preverijo, ali ima prijavljen uporabnik pravico izvesti prav to dejanje na prav tem viru. Arhitektura mora lastništvo nad virom preveriti ob vsakem zahtevku.

Ključna pravila za trgovino:

• Vse varnostno pomembne vrednosti, kot so cena, popust in identiteta kupca, izračunajte na strežniku in jih ne sprejemajte iz brskalnika.
• Vsak večstopenjski postopek, na primer od košarice do plačila, naj ima na strežniku shranjeno stanje, ki preveri dovoljene prehode.
• Kritične spremembe izvedite v atomarnih transakcijah z zaklepi ali strogo izolacijo, da se izognete sočasnim zahtevkom, ki bi dvakrat unovčili isto kupono.
• Za občutljive funkcije razmislite o omejitvah zahtevkov, da otežite avtomatizirano preizkušanje kod za popust.

Strokovni nasvet: Pri vsakem novem koraku v naročilu se vprašajte: kaj se zgodi, če kupec ta korak preskoči, ponovi ali pokliče dvakrat hkrati?

Spremljanje, testi in odziv na incidente

Varnost brez opazovanja je ugibanje. Dnevniki morajo zajeti, kdo je naredil kaj in kdaj, hkrati pa ne smejo vsebovati občutljivih podatkov. OWASP smernice za plačilne prehode priporočajo logiranje s korelacijskimi identifikatorji, kodo CVV pa je treba iz dnevnikov izločiti.

Priporočen načrt:

1. Beležite IP naslove, časovne žige in korelacijske identifikatorje za vsak ključni dogodek, od prijave do spremembe naročila.
2. Iz dnevnikov izločite CVV in druge občutljive podatke, saj je dnevnik pogosto slabše zaščiten od baze.
3. Izvajajte redne penetracijske teste in avtomatizirano odkrivanje ranljivosti, vključno s testi za sočasne zahtevke (race condition).
4. Pripravite postopek prijave incidenta: SI-CERT kot nacionalni odzivni center nudi tehnično pomoč, prijave sprejema na cert@cert.si, njegovi napotki pa pokrivajo tudi forenziko.
5. Po vsakem incidentu zabeležite, kaj se je zgodilo, kaj ste spremenili in kdo je odgovoren za naslednji pregled.

Izkušnje iz forenzike kažejo, da pogosto pomaga že to, da so datoteke in dostopi spremljani od prvega dne.

Kako OWASP ASVS vključi varnost že v razvoj

Varnost, dodana po koncu razvoja, je vedno dražja kot varnost, vgrajena med njim. OWASP Application Security Verification Standard 4.0 svetuje, naj varnostne kontrole vključite že v fazi načrtovanja in testiranja aplikacije. ASVS Level 1 pomaga preprečiti osnovne malomarnosti in podpira skladnost s PCI DSS, ki je za trgovine s karticami pomembna.

V praksi to pomeni, da varnost postane del vsakodnevnega dela, ne enkratna naloga pred zagonom:

• Zahteve iz ASVS prenesite v seznam nalog pred začetkom razvoja, ne po njem.
• Vsako novo funkcijo, ki obdeluje podatke o kupcih ali plačila, pregledajte z vidika zlorabe, ne le pravilnega delovanja.
• Poiščite prevzeto kodo, knjižnice in vtičnike tretjih oseb in preverite njihovo vzdrževanje.
• Testirajte pred objavo, ne šele po prvem incidentu, in spremembe pregledajte še enkrat, ko se kodna zbirka spremeni.

Za naročnike je to tudi poslovno vprašanje. Trgovina, zasnovana po preverjenem standardu, lažje dokazuje skladnost in hitreje prestane zunanji pregled. Ker kodo razvijamo sami in ne sestavljamo trgovin iz predpripravljenih platform, lahko kontrole vgradimo v zasnovo. Več o naših spletnih aplikacijah po meri najdete na naši strani.

Kaj poročila o incidentih povedo o trendih

Statistike niso razlog za paniko, so pa dobro merilo, kje se napadi dogajajo. Poročilo SI-CERT za leto 2024 navaja 4.587 obravnavanih incidentov, kar je sedem odstotkov več kot prej. Poročilo izpostavlja rast phishinga, naprednejših phishing napadov na podjetja in primerov izsiljevanja z velikimi potencialnimi finančnimi posledicami.

Polletna poročila o kibernetskih incidentih to sliko dopolnjujejo. Prvo polletno poročilo za leto 2025 kaže naraščajoče prijave spletnih goljufij, zlorabe nepriviligiranih računov in incidentov, povezanih s spletnim nakupovanjem. Pogosti vzrok so neustrezno upravljanje dostopov in ranljivosti v spletnih aplikacijah. Drugo polletno poročilo izpostavlja prevlado goljufij, izsiljevanja in incidentov, povezanih s spletnim nakupovanjem, s posledicami v obliki finančne škode in motenj v poslovanju.

Za lastnika trgovine iz tega izhajajo trije zaključki. Prvič, napadalci ciljajo tudi manjše trgovine, ker so pogosto slabše zaščitene. Drugič, najpogostejši vstopi so dostopi in ranljive aplikacije, torej nekaj, kar lahko nadzorujete. Tretjič, posledica ni le izgubljen denar, ampak tudi ustavljeno poslovanje, zato ima smisel pripraviti odzivni načrt vnaprej.

Na ravni EU se pravila zaostrujejo. Smernice Komisije za Cyber Resilience Act pojasnjujejo obseg, podporna obdobja in obveznosti poročanja. Poročanje se po tem viru začne 11. septembra 2026, glavne obveznosti pa veljajo od decembra 2027.

Upravljanje uporabniških dostopov in gesel

Veliko vdorov ne zahteva niti ene tehnične ranljivosti, samo ukraden ali ugibljiv dostop. Zato mora biti vsak račun v trgovini, od skrbnika do skladiščnika, urejen po načelu najmanjših pravic: vsak vidi in spreminja samo tisto, kar za delo potrebuje.

Dobro upravljanje dostopov ima nekaj jasnih elementov:

• Vsak zaposleni ima lasten račun in nikoli skupnega, da je vsako dejanje sledljivo.
• Ob odhodu sodelavca ali zunanjega izvajalca dostope še isti dan odpravite.
• Gesla zahtevajo zadostno dolžino, preverjanje proti znanim uhajanjem podatkov in prepoved ponovne uporabe istega gesla drugje.
• Gesla se na strežniku shranjujejo samo kot zgoščene vrednosti s počasnim algoritmom, nikoli kot besedilo.
• Število neuspelih prijav je omejeno, nenavadne prijave pa sprožijo opozorilo.

ASVS 4.0 vsebuje priporočila za življenjski cikel poverilnic, večfaktorsko avtentikacijo in načela za zaščito pred napadi na seje. Uporabite ga kot kontrolni seznam, ne kot dokument za branje po zagonu.

Za praktične nasvete o varovanju osebnih podatkov kupcev si oglejte še naša navodila o zaščiti uporabniških podatkov.

Dvofaktorska avtentikacija za kupce in skrbnike

Geslo samo po sebi ni več zadostna ovira. Dvofaktorska avtentikacija (2FA) doda drugi dokaz, da je oseba res tista, za katero se izdaja, zato ukraden ali uhajan geslo napadalcu samo po sebi ne odpre vrat. ASVS 4.0 večfaktorsko avtentikacijo obravnava kot del priporočil za življenjski cikel poverilnic.

Pri uvedbi 2FA ločite dve skupini uporabnikov:

• Skrbniki in zaposleni: 2FA naj bo obvezna brez izjem, saj en prevzet skrbniški račun pomeni dostop do vseh naročil, kupcev in nastavitev.
• Kupci: ponudite 2FA kot možnost, po možnosti s preprostim potekom, ker odločilno vpliva na zaupanje in zmanjša zlorabo računov.

Pri izbiri drugega faktorja imajo prednost aplikacije za generiranje kod in strojni varnostni ključi pred SMS sporočili, ker so manj dovzetni za prestrezanje številke. Poskrbite tudi za varen postopek obnovitve dostopa, ker je pogosto prav ta najšibkejši člen: kodo za obnovitev hranite ločeno in zahtevajte ponovno preverjanje identitete.

Upoštevajte, da 2FA ne nadomesti drugih ukrepov. Če napadalec že ima sejo prijavljenega skrbnika, se mora še vedno ustaviti pri pravicah in omejitvah na strežniku.

Posodobitve in varnostne kopije

Posodobitve zapirajo znane luknje, varnostne kopije pa omejujejo škodo, ko se kljub vsemu kaj zgodi. Oboje mora biti redno in preverjeno, ne zgolj načrtovano. Kot opozarja SI-CERT, prav zastareli vtičniki so pogosta pot za napadalce.

Za posodobitve uvedite stalen postopek:

• Določite osebo, odgovorno za spremljanje varnostnih popravkov CMS-ja, vtičnikov in strežniške programske opreme.
• Posodobitve najprej preizkusite na kopiji trgovine, nato jih uvedite v produkcijo izven konic prometa.
• Kritične varnostne popravke uvajajte hitro, manj pomembne pa po običajnem urniku.

Za varnostne kopije velja pravilo, da kopija, ki je nikoli niste obnovili, ni kopija, ampak upanje. Priporočamo:

1. Kopije datotek in baze delajte samodejno in redno, pogostost pa prilagodite številu naročil, ki bi jih lahko izgubili.
2. Kopije hranite na ločeni lokaciji, do katere napadalec z dostopom do trgovine ne more.
3. Obnovo preizkusite vsaj nekajkrat letno in si zabeležite, koliko časa traja.
4. Podatke v kopijah zaščitite s šifriranjem, ker vsebujejo iste občutljive podatke kot živa baza.

Pri nas posodobitve in kopije vključimo v storitve podpore in vzdrževanja, tako da ni treba, da za to skrbite sami.

Zaščita strežnika in obramba pred DDoS napadi

Napad DDoS trgovino zaseda z lažnim prometom, da pravi kupci ne pridejo do blagajne. Zaščita je plastna: nobena posamezna rešitev ne pokrije vsega, skupaj pa močno zmanjšajo možnost izpada.

Osnovni gradniki obrambe:

• Strežnik postavite za omrežje za dostavo vsebin (CDN) ali storitev za filtriranje prometa, ki absorbira večino škodljivega prometa, preden doseže vaš strežnik.
• Nastavite omejitve števila zahtevkov na IP naslov in na posamezne dražje funkcije, kot sta iskanje in prijava.
• Statično vsebino in pogosto zahtevane strani predpomnite, da strežnik ne obdeluje vsakega zahtevka znova.
• Požarni zid na ravni aplikacije blokira znane vzorce napadov, še preden dosežejo kodo trgovine.
• Strežnik utrdite: izklopite storitve, ki jih ne potrebujete, zaprite nepotrebna vrata in uporabljajte ločene račune z minimalnimi pravicami.

Pomembna je tudi priprava vnaprej. Zapišite, kdo odloča in koga pokličete, ko promet nenadoma poskoči: vaš ponudnik gostovanja, ponudnik zaščite in po potrebi SI-CERT. Če trgovina deluje na skupnem gostovanju, se obseg obrambe razlikuje od namenskega strežnika, zato je smiselno že ob izbiri gostovanja vprašati, kakšno zaščito pred DDoS vključuje.

Čas je ključen: ob napadu vsaka ura izpada pomeni izgubljena naročila, zato odzivni načrt pripravite, preden ga potrebujete.

Šifriranje občutljivih podatkov v bazi

TLS ščiti podatke na poti, a ko pristanejo v bazi, jih mora ščititi drugo šifriranje. Če napadalec pride do baze ali njene kopije, šifriranje lahko zmanjša uporabnost podatkov brez ključa. OWASP Developer Guide zaščito podatkov obravnava kot nepogrešljiv del zasnove, ne le prometa.

Pri odločanju, kaj šifrirati, ločite podatke po občutljivosti:

• Gesla ne šifrirajte, ampak jih zgostite s počasnim algoritmom, ki je zasnovan prav za ta namen.
• Osebne podatke kupcev, kot so naslovi, telefonske številke in dokumenti, šifrirajte na ravni polj ali celotne baze, glede na tveganje.
• Podatkov o karticah ne hranite, če vam jih lahko obdela plačilni ponudnik. Kar ne hranite, ne more uhajati.
• Varnostne kopije šifrirajte enako kot živo bazo.

Najpogostejša napaka ni izbira algoritma, ampak ravnanje s ključi. Ključ, shranjen poleg šifriranih podatkov ali vpisan v kodo, lahko oslabi zaščito. Ključe hranite ločeno od baze, jih redno menjajte in omejite število ljudi, ki jih lahko beri.

Poleg tega zbirajte le toliko podatkov, kot jih trgovina res potrebuje. To lahko zmanjša tveganje in omeji škodo, če pride do uhajanja.

Varnostno usposabljanje zaposlenih in uporabnikov

Tehnične kontrole lahko odpovejo, če zaposleni klikne na napačno povezavo. SI-CERT v poročilu za leto 2024 izpostavlja rast phishinga, vključno z naprednejšimi napadi na podjetja, zato je usposabljanje del tehnične zaščite, ne dodatek.

Učinkovito usposabljanje je kratko, redno in konkretno:

• Zaposleni se naučijo prepoznati sumljiva sporočila, ki se pretvarjajo, da prihajajo od dobavitelja, plačilnega ponudnika ali vodstva.
• Vsak ve, kam sporoči sum in da za prijavo ne bo kaznovan, ker hitro poročilo omeji škodo.
• Skrbniki in razvijalci poznajo osnove varnega programiranja, vključno s pravili, ki jih predpisuje ASVS.
• Preverjanja sprememb plačilnih podatkov dobavitelja in nenavadnih naročil ne potekajo samo prek e-pošte.

Tudi kupci so del uravnoteženja. Jasna obvestila o tem, česa vaša trgovina nikoli ne zahteva, na primer gesla po e-pošti, ter preprosta navodila za varnejši račun lahko pomagajo omejiti zlorabe. Pomagajo tudi smernice EU za označevanje umetne inteligence, ki bodo po navedbah Komisije začele veljati 2. avgusta 2026 in so odziv na tveganja, kot sta deepfake in lažno predstavljanje.

Usposabljanje redno ponavljajte, preizkušajte z vajami in po incidentih posodobite gradivo.

Perspektiva avtorja: kako varnost vgradimo v projekte

Pri pregledih trgovin se lahko pokažejo težave, kot so zastareli vtičniki, preširoke pravice in plačila, ki jih potrdi brskalnik namesto strežnika. Zato varnost ne obravnavamo kot dodatek na koncu, ampak jo vgradimo v zasnovo, gostovanje in vzdrževanje. Ob začetku pregleda lahko pričakujete pogovor o tem, kaj trgovina dejansko počne, pregled konfiguracije in jasen seznam ukrepov po prednosti.

— Ziga

Varnostni pregled in storitve Moxy-web

Če želite zgornje ukrepe uvesti brez lastne ekipe, jih izvedemo mi: izdelamo spletno trgovino po meri in poskrbimo za gostovanje in vzdrževanje. V pregled najpogosteje vključimo preverjanje TLS in glav, posodobitev CMS-ja in vtičnikov, plačilni tok ter pravice dostopa. Naročite varnostni pregled ali nam pišite, pa vam povemo, kje začeti. Cene so na voljo na zahtevo.

Pogosta vprašanja

Kateri ukrepi so pri zaščiti spletne trgovine najpomembnejši?

Najprej poskrbite za šifriran promet s HTTPS in HSTS, posodobljen CMS brez nepotrebnih vtičnikov ter strežniško potrditev plačil. Ti ukrepi pomagajo nasloviti pogoste poti napadov. Podrobnosti so opisane v OWASP Developer Guide.

Ali se lahko pri potrditvi plačila zanesem na brskalnik kupca?

Ne, status plačila vedno potrdite med strežnikoma. Na podatke iz brskalnika se ne zanašajte, plačilo potrdite na strežniku. Postopek opisuje OWASP Cheat Sheet za plačilne prehode.

Kam prijavim varnostni incident v trgovini?

Incident prijavite nacionalnemu odzivnemu centru SI-CERT na naslov cert@cert.si. Center nudi tehnično pomoč, postopke za prijavo in napotke za forenziko, kot je opisano v priročniku kibernetske varnosti.

Ali je dvofaktorska avtentikacija nujna za skrbnike trgovine?

Da, za skrbniške račune naj bo obvezna. En prevzet račun odpre dostop do naročil, kupcev in nastavitev, zato drugi faktor bistveno zmanjša tveganje. Kupcem jo ponudite kot možnost.

Kako pogosto naj preizkusim obnovitev varnostne kopije?

Obnovo preizkusite redno, vsaj nekajkrat letno, in po vsaki večji spremembi sistema. Kopija, ki je nikoli niste obnovili, ni zagotovilo, da jo boste ob težavi zares lahko uporabili.

Viri

• Protect Data Everywhere - OWASP Developer Guide
• Spletni seminar Kibernetska varnost za spletne trgovce - SI CERT
• Application Security Verification Standard 4.0
• Third Party Payment Gateway Integration - OWASP Cheat Sheet Series
• Priročnik kibernetske varnosti

Priporočeno

• Spletna varnost za podjetja brez nepotrebnih tveganj
• Kako urediti varno gostovanje spletne strani
• Varnost spletne strani podjetja brez iluzij
• Vodnik spletnih varnostnih kopij za podjetja