javascript injection tutorial
Vad är Javascript-injektion?
Javascript är en av de mest populära teknikerna och används mest för webbsidor och webbapplikationer.
Den kan användas för att förverkliga olika webbplatsfunktioner. Denna teknik kan dock medföra vissa säkerhetsproblem som utvecklaren och testaren bör vara medvetna om.
Javascript kan inte bara användas för goda ändamål utan även för vissa skadliga attacker. En av dem är Javascript Injection. Kärnan i JS Injection är att injicera Javascript-koden, som kommer att köras från klientsidan.
I den här handledningen lär vi oss mer om hur man kontrollerar om Javascript Injection är möjligt, hur JS Injection kan utföras och vilka konsekvenser JS Injection kan få.
Vad du kommer att lära dig:
- Risker med JavaScript-injektion
- Varför är det viktigt att testa JS-injektion?
- Jämförelse med andra attacker
- Söker efter JavaScript-injektion
- Parametrar Modifiering
- Webbplatsens designändring
- Hur man testar mot JavaScript-injektion
- Möjligt skydd mot denna attack
- Slutsats
- Rekommenderad läsning
Risker med JavaScript-injektion
JS Injection ger en hel del möjligheter för en skadlig användare att modifiera webbplatsens design, få webbplatsinformation, ändra den visade webbplatsens information och manipulera med parametrarna (till exempel cookies). Därför kan detta orsaka allvarliga webbplatsskador, informationsläckage och till och med hack.
Huvudsyftet med JS Injection är att ändra webbplatsens utseende och manipulera parametrarna. Konsekvenser av JS Injection kan vara mycket olika - från att skada webbplatsens design till att komma åt någon annans konto.
Varför är det viktigt att testa JS-injektion?
Många skulle fråga om det är nödvändigt att testa för JS Injection.
Kontroll av säkerhetsproblem med JS-injektion är en del av säkerhetstestningen. Säkerhetstester utförs vanligtvis bara om det inkluderades i projektplaneringen, eftersom det kräver tid, mycket uppmärksamhet och kontroll av flera detaljer.
Jag har lagt märke till att det under projektets genomförande är ganska vanligt att hoppa över testning mot eventuella attacker - inklusive JS Injection. På så sätt försöker teamet spara tid för projektet. Denna praxis slutar dock ofta med kundens klagomål.
Det bör vara känt att säkerhetstester rekommenderas starkt även om det inte ingår i projektplanerna. Kontroll av eventuella huvudsakliga attacker bör utföras - samtidigt måste man kontrollera om det finns möjliga JS-injektionssårbarheter.
Lämna ett enkelt Javascript Injektionssårbarheter i produkten kan kosta produktens kvalitet och företagets anseende. När jag har lärt mig att testa mot möjliga attacker och i allmänhet säkerhetstester hoppar jag aldrig över den här delen av testningen. På så sätt är jag bara mer säker på produktens kvalitet.
Jämförelse med andra attacker
Det bör nämnas att JS Injection inte är så riskabelt som SQL-injektion , eftersom det utförs på klientsidan och det inte når systemets databas som det händer under SQL Injection-attack. Det är inte lika riskabelt som XSS-attack.
Under denna attack ibland kan endast webbplatsens utseende ändras, medan huvudsyftet med XSS-attacken är att hacka andra inloggningsdata.
Men JS Injection kan också orsaka allvarliga webbplatsskador. Det kan inte bara förstöra webbplatsens utseende utan också bli en bra grund för att hacka andras inloggningsdata.
Söker efter JavaScript-injektion
När du börjar testa mot JS Injection är det första du bör göra att kontrollera om JS Injection är möjlig eller inte. Det är väldigt enkelt att kontrollera denna typ av injektionsmöjlighet - när du navigerar till webbplatsen måste du skriva in webbläsarens adressstreckkod så här:
javascript: alert ('Executed!');
Om ett popup-fönster med meddelandet ”Executed!” Visas är webbplatsen sårbar för JS Injection.
Sedan kan du prova olika Javascript-kommandon i webbplatsens adressfält.
Det bör nämnas att JS Injection inte bara är möjligt från webbplatsens adressfält. Det finns olika andra webbplatselement som kan vara sårbara för JS Injection. Det viktigaste är att veta exakt vilka delar av webbplatsen som kan påverkas av Javascript Injection och hur man kontrollerar det.
Typiska JS-injektionsmål är:
- Olika forum
- Artikelns kommentarfält
- Gästböcker
- Alla andra former där text kan infogas.
För att testa om denna attack är möjlig för textsparningsformuläret, trots att du tillhandahåller normal text, skriv Javascript-kod som nämns nedan och spara texten i formuläret och uppdatera sidan.
javascript: alert ('Executed!');
Om det på den nyligen öppnade sidan finns en textruta med meddelandet ”Executed!”, Är denna typ av injektionsattack möjlig för det testade formuläret.
Om på båda sätten en textruta med meddelandet visas kan du försöka bryta webbplatsen med mer knepiga JS-injektionsmetoder. Sedan kan du prova olika injektionstyper - parametermodifiering eller designmodifiering.
Naturligtvis anses modifieringar av parametrar vara mer riskfyllda än designmodifiering. Därför bör mer uppmärksamhet ägnas åt modifieringen av parametrar under testningen.
Man bör också komma ihåg att mer utsatta webbplatsens delar för Javascript Injection är inmatningsfält där alla typer av data sparas.
Parametrar Modifiering
Som tidigare nämnts är en av de möjliga skadorna på Javascript-injektion parametrar modifiering.
Under denna injektionsattack kan en skadlig användare få parametrarinformation eller ändra parametervärde( Exempel ,cookie-inställningar). Detta kan orsaka ganska allvarliga risker eftersom en skadlig användare kan få känsligt innehåll. En sådan typ av injektion kan utföras med hjälp av vissa Javascript-kommandon.
Låt oss komma ihåg att det Javascript-kommandot som returnerar aktuell session cookie skrivs i enlighet med detta:
javascript: alert (document.cookie);
Inmatad i webbläsarens URL-fält kommer den att returnera ett popup-fönster med aktuella sessionscookies.
Om webbplatsen använder cookies kan vi läsa sådan information som serversession-id eller annan användardata som lagras i kakorna.
Det måste nämnas att i stället för alert () kan någon annan Javascript-funktion användas.
Till exempel ,om vi har hittat en sårbar webbplats, lagras sessions-id i cookieparametern 'session_id'. Sedan kan vi skriva en funktion som ändrar det aktuella sessionens id:
javascript: void (document.cookie = “session_id =<>');
På så sätt ändras sessions-ID-värdet. Alla andra sätt att ändra parametrar är också möjliga.
Till exempel, en skadlig användare vill logga in som andra människor. För att utföra inloggning kommer den skadliga användaren först att ändra inställningarna för auktoriseringskakor till sant. Om cookieinställningarna inte är inställda som “sanna” kan cookievärdet returneras som ”odefinierat”.
vad är den bästa programvaran för röstigenkänning
För att ändra dessa cookievärden kommer en skadlig användare att utföra enligt Javascript-kommandot från URL-fältet i webbläsaren:
javascript: void (document.cookie = “auktorisering = true”);
I resultatet ändras nuvarande cookieparametertillstånd = falskt till auktorisering = sant. På så sätt kan en skadlig användare få tillgång till det känsliga innehållet.
Det måste också nämnas att Javascript-kod ibland returnerar ganska känslig information.
javascript: alert (document.cookie);
Till exempel, om en webbplatsutvecklare inte var försiktig kan den också returnera användarnamn och lösenordsparametrar namn och värden. Då kan sådan information användas för att hacka webbplatsen eller för att bara ändra den känsliga parameterns värde.
Till exempel, med koden nedan kan vi ändra användarnamnvärdet:
javascript: void (document.cookie = ”username = otherUser”);
På detta sätt kan alla andra parametervärden också ändras.
Webbplatsens designändring
Javascript kan också användas för att ändra vilken webbplats som helst och i allmänhet webbplatsens design.
Till exempel, med Javascript kan du ändra all information som visas på webbplatsen:
- Visad text.
- Webbplatsens bakgrund.
- Webbplatsens formulär utseende.
- Popup-fönstrets utseende.
- Någon annan webbplatselements utseende.
Till exempel, för att ändra den visade e-postadressen på webbplatsen bör lämpligt Javascript-kommando användas:
javascript: void (document.forms (0) .email.value = ”Test@test.com”) ;
Få andra komplicerade manipuleringar med webbplatsens design är också möjliga. Med denna attack kan vi också komma åt och ändra webbplatsens CSS-klass.
Till exempel, om vi vill ändra webbplatsens bakgrundsbild med JS Injection, bör kommandot köras i enlighet med detta:
javascript: ogiltigt (dokument. bakgrundsbild: url (“annan bild.jpg”);
En skadlig användare kan också skriva Javascript Injection-kod som nämns nedan i formuläret för textinsättning och spara den.
javascript: void (alert („Hello!“));
Varje gång en sida öppnas visas en textruta med meddelandet 'Hej!'.
Ändrad webbdesign med Javascript Injection är mindre riskabelt än ändring av parametrar. Men om webbplatsens design kommer att ändras på ett skadligt sätt kan det kosta företagets rykte.
Hur man testar mot JavaScript-injektion
Det kan testas på följande sätt:
- Manuellt
- Med testverktyg
- Med webbläsarinsticksprogram
Möjliga Javascript-sårbarheter kan kontrolleras manuellt om du har god kunskap om hur det ska utföras. Det kan också testas med olika automatiseringsverktyg.
Till exempel, om du har automatiserat dina tester på API-nivå med SOAP UI-verktyget är det också möjligt att köra Javascript Injection-tester med SOAP UI .
Jag kan dock bara kommentera från min egen erfarenhet att du verkligen borde ha haft god kunskap om SOAP UI-verktyget för att testa med det för JS Injection, eftersom alla teststegen bör skrivas utan misstag. Om något teststeg är skrivet fel kan det också orsaka felaktiga säkerhetstestresultat.
Du kan också hitta olika webbläsares plugins för att kontrollera mot eventuella attacker. Det rekommenderas dock att man inte glömmer att kontrollera mot denna attack manuellt, eftersom det vanligtvis ger mer exakta resultat.
Jag vill säga att testning manuellt mot Javascript Injection gör att jag känner mig mer säker och säker på webbplatsens säkerhet. På det här sättet kan du vara säker på att ingen form missades under testningen och att alla resultat är synliga för dig.
För att testa mot Javascript Injection bör du ha allmän kunskap om Javascript och måste veta vilka delar av webbplatsen som är mer sårbara. Du bör också komma ihåg att webbplatsen kan vara skyddad mot JS Injection och när du testar bör du försöka bryta detta skydd.
På detta sätt kommer du att vara säker på om skyddet mot denna attack är tillräckligt starkt eller inte.
Möjligt skydd mot denna attack
För det första, för att förhindra denna attack, bör varje mottagen input valideras. Inmatningen ska valideras varje gång, och inte bara när data initialt accepteras.
Det rekommenderas starkt att inte lita på validering av klientsidan. Det rekommenderas också att utföra en viktig logik på serversidan.
Många försöker skydda mot Javascript-injektion genom att ändra offerten till dubbelt och Javascript-koden ska inte utföras på det sättet.
Till exempel, om du skulle skriva något i citatfältet med citat ... kommer dessa citat att ersättas med dubbel -<>...<>. På det sättet körs inte den angivna Javascript-koden.
Jag har märkt att att ersätta citat med dubbla citat är en ganska vanlig metod för att undvika eventuella JS-injektionsattacker. Det finns dock några sätt att koda offerten för att göra JS-injektionskoden utförd. Att ändra citat till dubbelt är därför inte ett perfekt sätt att skydda mot denna attack.
Slutsats
Man bör alltid komma ihåg att Javascript Injection är en av de möjliga attackerna mot webbplatser, eftersom Javascript är en av de mest använda teknikerna för webbplatserna. Därför bör du inte glömma att testa mot denna attack när du testar webbplatser eller någon annan webbteknik.
När du utför säkerhetstester bör JS Injection inte glömmas bort. Vissa människor anser att denna testning är en mindre riskabel attack eftersom den utförs på klientsidan.
Det är dock fel metod och vi bör alltid komma ihåg att Javascript Injection kan orsaka allvarliga webbplatsers skador som känslig informationsläckage, parametrar som ändras eller hackar användarkontona.
Därför bör vi betrakta detta som en viktig del av testningen och det är en del av investeringen för goda produkter och företagets rykte.
Att testa för JS-injektion är inte särskilt svårt. För det första bör du ha allmän kunskap om Javascript och måste veta hur du kan kontrollera om denna attack är möjlig för den aktuella webblösningen eller inte.
Även när du testar bör du komma ihåg att en webbplats kan ha skydd mot den här typen av attacker, men den kan vara för svag - den bör också kontrolleras. En annan viktig sak att komma ihåg är att det finns olika typer av Javascript Injection-attacker och ingen av dem bör glömmas bort att testa.
Har du utfört Javascript Injection Testing ?? Vi skulle gärna höra från dig, gärna dela dina erfarenheter i kommentarfältet nedan.
Rekommenderad läsning
- Fördjupade förklaringar om förmörkelser för nybörjare
- Så här ställer du in Node.js Testing Framework: Node.js Tutorial
- HTML-injektionshandledning: Typer och förebyggande med exempel
- SQL Injection Testing Tutorial (Exempel och förebyggande av SQL Injection Attack)
- Java Reflection Tutorial med exempel
- SVN-handledning: Källkodshantering med subversion
- Python DateTime-handledning med exempel
- Tortoise SVN Tutorial: Revisions In Code Repository