Vad skadlig kod i e-handel faktiskt gör
Skadlig kod i en e-handelsbutik syns sällan som en trasig kassa eller en långsam sida. Den syns oftast inte alls. En betalningsskimmer ligger tyst i kassaflödet och kopierar kortuppgifter medan kunden skriver in dem. En bakdörr på serversidan ger en angripare en väg tillbaka in i butiken veckor efter det ursprungliga intrånget. Båda typerna av attacker är byggda för att köra ostört så länge som möjligt, eftersom varje extra dag med dold åtkomst innebär mer stulen kortdata.
Den här typen av attack kallas ofta Magecart, ett namn som ursprungligen kom från gruppen som populariserade kortskimning på Magento-butiker. Begreppet har sedan breddats till att täcka digital skimning oavsett plattform. Säkerhetsforskare, bland annat teamet bakom Sansec, har följt den här typen av attacker sedan 2015 och delar in dem i två huvudkategorier: skimmers som injicerar skadlig JavaScript i kassasidan, och skadlig kod på serversidan som gömmer sig i filer, databastabeller eller schemalagda uppgifter i hostingmiljön.
Varför Magento och Adobe Commerce står för den största risken
Magento och Adobe Commerce är öppen källkod-plattformar med ett stort och moget ekosystem av tilläggsmoduler. Det ekosystemet är också den största attackytan. En sårbar tredjepartsmodul, en föråldrad kärninstallation eller en komprometterad modulleverantör kan var för sig ge angripare en väg in. Sansecs forskning har dokumenterat flera händelser som visar mönstret. CosmicSting (CVE-2024-34102) var en kritisk XXE-sårbarhet som enligt Sansecs uppföljning ledde till att cirka 5 procent av alla Adobe Commerce- och Magento-butiker fick en betalningsskimmer installerad inom några veckor efter att sårbarheten publicerades. SessionReaper (CVE-2025-54236) följde ett liknande mönster. Sansec rapporterade att 81 procent av alla Magento-butiker hade blivit avsökta för sårbarheten inom tre veckor efter att den blev känd, trots att en patch redan fanns tillgänglig.
Sansec upptäckte också en attack i leverantörskedjan 2022, då distributionsservern för Magento-modulleverantören FishPig blev komprometterad och användes för att injicera en fjärråtkomsttrojan i varje butik som installerade eller uppdaterade den drabbade modulen. Händelser som denna visar att risken sträcker sig bortom er egen kod. Den omfattar varje modulleverantör butiken är beroende av.
Plattformar med ett mindre eller mer kontrollerat ekosystem av tillägg, till exempel Shopify, ser färre incidenter av det här specifika slaget, till stor del eftersom plattformsleverantören kontrollerar en större del av stacken. Skillnaden i arkitektur, inte plattformens kvalitet, förklarar det mesta av gapet i rapporterade attacker.
Hur verktyg som Sansec faktiskt fungerar
De flesta diskussioner om e-handelssäkerhet fokuserar på webbläsaren, eftersom det är där en kund skulle märka att något är fel. Sansecs egen forskning menar att en stor andel av skadlig kod i e-handel istället gömmer sig på servern, på platser en vanlig extern säkerhetsskanning inte når. Deras skanner, eComscan, körs direkt på hostingservern och granskar filer, databasinnehåll och schemalagda uppgifter efter kända signaturer för skadlig kod, obehöriga adminkonton och sårbara modulversioner. Den stödjer Magento, Adobe Commerce, Shopware, WooCommerce, PrestaShop och OpenCart.
Sansecs andra produkt, Sansec Shield, fungerar annorlunda. Det är en brandvägg byggd för att förstå Magento-specifika attackmönster och blockerar kända attacker i realtid, som ett skyddslager medan butiken väntar på en officiell patch. Den körs sida vid sida med generella brandväggar som Cloudflare snarare än att ersätta dem, eftersom en generell brandvägg saknar insyn i Magento-specifika attackmönster.
Sansec är också listad som partner för hotdata hos VirusTotal och samarbetade med Europol i en gränsöverskridande skimningsutredning i januari 2024 som resulterade i att 443 handlare fick information om att deras kunders betalningsdata hade komprometterats. Den typen av hotinformation påverkar direkt hur snabbt ett skanningsverktyg kan känna igen ett nytt attackmönster.
Var det här passar in i PCI DSS och det dagliga arbetet
PCI DSS version 4.0 lade till två krav, 6.4.3 och 11.6.1, som specifikt riktar sig mot manipulerade betalningssidor och obehöriga skriptändringar. Båda blev obligatoriska i mars 2025. Skanning av skadlig kod på serversidan stödjer det underliggande kravet på skydd mot skadlig kod i PCI DSS, medan övervakning av skript i webbläsaren, ibland kallat CSP-övervakning, mer direkt hanterar de nyare kraven. Ingen av metoderna täcker allt på egen hand, vilket är varför de mest seriösa säkerhetsuppsättningarna för e-handel kombinerar en serversideskanner, en brandvägg och någon form av klientside-övervakning.
Patchdisciplin väger fortfarande tyngre än något enskilt verktyg. Sansecs egna siffror kring SessionReaper visar att de flesta butiker förblev exponerade i veckor även efter att en akutpatch släppts. En skanner eller brandvägg köper tid. Den tar inte bort behovet av att patcha.
Att utvärdera en leverantör av säkerhetsövervakning
Alla säkerhetsleverantörer inom e-handel täcker inte samma hotbild, så det är värt att ställa konkreta frågor innan ni väljer en. Fråga om detekteringen sker på servern, i webbläsaren, eller båda, eftersom de fångar olika typer av attacker. Fråga vilka plattformar som stöds direkt, eftersom ett verktyg byggt för Magento inte automatiskt förstår Shopwares arkitektur. Fråga hur ofta hotsignaturer uppdateras, och om leverantören publicerar egen forskning, eftersom offentliga upptäckter är ett rimligt sätt att bedöma hur seriöst en leverantör tar hotet. Sansec publicerar till exempel namngiven sårbarhetsforskning som CosmicSting, SessionReaper och CronRAT, snarare än bara marknadspåståenden, vilket ger er något konkret att verifiera.
Att bygga en realistisk åtgärdsplan
En åtgärdsplan bör finnas innan en incident inträffar, inte under den. Det innebär åtminstone att veta vem som har adminåtkomst till butiken, att hålla listan över installerade moduler uppdaterad, och att ha en dokumenterad process för vad som händer när en skanner flaggar något. Nordic Web Team behandlar det här som en del av det omgivande arbetet runt varje Magento- eller Shopware-projekt. Plattformsval, hosting och integrationsarbete via molninfrastruktur formar tillsammans hur exponerad en butik faktiskt är, och säkerhetsövervakning bör planeras tillsammans med de besluten snarare än läggas till efteråt.