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, med omfattande avsökning av opatchade butiker efter att detaljerna blev offentliga.
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.
De tre lagren av upptäckt
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. En stor andel av skadlig kod i e-handel gömmer sig istället på servern, på platser en extern skanning inte når. En realistisk uppsättning kombinerar därför tre lager, som vart och ett fångar en annan typ av attack.
- Skanning på serversidan körs på hostingservern och granskar filer, databasinnehåll och schemalagda uppgifter efter känd skadlig kod, obehöriga adminkonton och sårbara modulversioner.
- En brandvägg för webbapplikationer blockerar kända attackmönster innan de når butiken. En brandvägg som förstår plattformen kan köpa tid medan butiken väntar på en officiell patch.
- Övervakning av kassans skript bevakar vilka skript som laddas på betalningssidorna och flaggar förändringar. Det är det lager som fångar skimmers i webbläsaren.
Sansecs eComscan och Shield är exempel på de två första lagren för Magento och Adobe Commerce. Vår sida om Sansec går igenom hur verktygen passar varje plattform och vad leveransen runt dem innebär.
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.
Patchning är fortfarande det första försvaret. En skanner eller brandvägg köper tid, men hålet står öppet tills rättningen är installerad. Samma sak gäller servern under plattformen. Guiden om PHP2Shell går igenom PHP-sårbarheterna från oktober 2026, som påverkar Magento-butiker på servernivå även när alla Adobes patchar är installerade.
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.