javascript injection tutorial
Hvad er Javascript-injektion?
Javascript er en af de mest populære teknologier og bruges mest til websider og webapplikationer.
Det kan bruges til at realisere forskellige webstedsfunktioner. Denne teknologi kan dog medføre nogle sikkerhedsproblemer, som udvikleren og testeren skal være opmærksom på.
Javascript kan ikke kun bruges til gode formål, men også til nogle ondsindede angreb. En af dem er Javascript Injection. Essensen af JS Injection er at injicere Javascript-koden, der køres fra klientsiden.
I denne vejledning lærer vi mere om, hvordan man kontrollerer, om Javascript Injection er mulig, hvordan JS Injection kan udføres, og hvad er de konsekvenser, som JS Injection kan medføre.
Hvad du vil lære:
- Risici ved JavaScript-injektion
- Hvorfor er det vigtigt at teste JS-injektion?
- Sammenligning med andre angreb
- Kontrollerer JavaScript-injektion
- Parametre Ændring
- Websteds designændring
- Sådan tester du mod JavaScript-injektion
- Mulig beskyttelse mod dette angreb
- Konklusion
- Anbefalet læsning
Risici ved JavaScript-injektion
JS Injection bringer mange muligheder for en ondsindet bruger til at ændre webstedsdesignet, få webstedsoplysninger, ændre det viste websteds information og manipulere med parametrene (for eksempel cookies). Derfor kan dette medføre alvorlige skader på hjemmesider, informationslækage og endda hack.
Hovedformålet med JS Injection er at ændre webstedets udseende og manipulere parametrene. Konsekvenser af JS Injection kan være meget forskellige - fra at skade websides design til at få adgang til en andens konto.
Hvorfor er det vigtigt at teste JS-injektion?
Mange vil spørge, om det virkelig er nødvendigt at teste for JS Injection.
Kontrollering af JS-injektionssårbarheder er en del af sikkerhedstest. Sikkerhedstest udføres normalt kun, hvis det var inkluderet i projektplanlægningen, da det kræver tid, meget opmærksomhed og kontrol af flere detaljer.
Jeg har bemærket, at det under projektets realisering er ret almindeligt at springe over test mod eventuelle angreb - inklusive JS Injection. På denne måde prøver holdene at spare projektets tid. Denne praksis slutter dog ofte med kundens klager.
Det skal være kendt, at sikkerhedstest anbefales, selvom det ikke er inkluderet i projektplanerne. Kontrollering af de vigtigste mulige angreb skal udføres - samtidig skal det kontrolleres for mulige JS-injektionssårbarheder.
Efterlader simpelt Javascript Sårbarheder ved injektion i produktet kan koste produktets kvalitet og virksomhedens omdømme. Når jeg har lært at teste mod mulige angreb og generelt sikkerhedstest, springer jeg aldrig over denne del af testningen. På denne måde er jeg bare mere sikker på produktets kvalitet.
Sammenligning med andre angreb
Det skal nævnes, at JS Injection ikke er så risikabelt som SQL-injektion , da det udføres på klientsiden, og det ikke når systemets database, som det sker under SQL Injection-angreb. Det er heller ikke så risikabelt som XSS-angreb.
Under dette angreb til tider kan kun webstedets udseende ændres, mens hovedformålet med XSS-angreb er at hacke andre login-data.
Imidlertid kan JS Injection også forårsage alvorlige skader på websitet. Det kan ikke kun ødelægge websteds udseende, men også blive et godt grundlag for at hacke andres login-data.
Kontrollerer JavaScript-injektion
Når du begynder at teste mod JS Injection, skal du først kontrollere, om JS Injection er mulig eller ej. Det er meget let at kontrollere denne type injektionsmulighed - når du navigerer til webstedet, skal du indtaste browserens adressestregkode som denne:
javascript: alarm ('Udført!');
Hvis et pop op-vindue med meddelelsen 'Udført!' Vises, er hjemmesiden sårbar over for JS Injection.
Derefter kan du prøve forskellige Javascript-kommandoer i webadressens adresselinje.
Det skal nævnes, at JS Injection ikke kun er mulig fra webstedets adresselinje. Der er forskellige andre websides elementer, der kan være sårbare over for JS Injection. Det vigtigste er at vide nøjagtigt, hvilke dele af hjemmesiden der kan påvirkes af Javascript Injection, og hvordan man kontrollerer det.
Typiske JS-injektionsmål er:
- Forskellige fora
- Artikelens kommentarfelter
- Gæstebøger
- Alle andre former, hvor tekst kan indsættes.
For at teste, om dette angreb er muligt for tekstbesparelsesformularen, på trods af normal tekst, skal du skrive Javascript-kode som nævnt nedenfor og gemme teksten i formularen og opdatere siden.
javascript: alarm ('Udført!');
Hvis der på den nyåbnede side indeholder et tekstfelt med meddelelsen 'Udført!', Så er denne type injektionsangreb muligt for den testede form.
Hvis der på begge måder vises et tekstfelt med meddelelsen, kan du prøve at bryde hjemmesiden med mere vanskelige JS-injektionsmetoder. Derefter kan du prøve forskellige injektionstyper - parametermodifikation eller designmodifikation.
Selvfølgelig betragtes parameterændring som en mere risikabel end designmodifikation. Derfor, mens du tester mere opmærksomhed bør være dedikeret til parametrene ændring.
Det skal også huskes, at mere sårbare websides dele til Javascript Injection er inputfelter, hvor enhver form for data gemmes.
Parametre Ændring
Som nævnt tidligere er en af de mulige skader på Javascript-injektion parametreændring.
Under dette injektionsangreb kan en ondsindet bruger få parametreoplysninger eller ændre parameterværdien( Eksempel ,cookie-indstillinger). Dette kan medføre ganske alvorlige risici, da en ondsindet bruger kan få følsomt indhold. En sådan type injektion kan udføres ved hjælp af nogle Javascript-kommandoer.
Lad os huske, at Javascript-kommandoen, der returnerer den aktuelle session cookie, er skrevet i overensstemmelse hermed:
javascript: alarm (document.cookie);
Indtastet i browserens URL-bar, returnerer den et popup-vindue med aktuelle sessionscookies.
Hvis webstedet bruger cookies, kan vi læse sådanne oplysninger som serversession-id eller andre brugerdata, der er gemt i cookies.
Det skal nævnes, at i stedet for alarm () kan enhver anden Javascript-funktion bruges.
For eksempel ,hvis vi har fundet et sårbart websted, gemmer session-id i cookie-parameteren 'session_id'. Så kan vi skrive en funktion, der ændrer det aktuelle session-id:
javascript: void (document.cookie = “session_id =<>');
På denne måde ændres sessionens id-værdi. Eventuelle andre måder at ændre parametre er også mulige.
For eksempel, en ondsindet bruger ønsker at logge ind som andre mennesker. For at udføre login ændrer den ondsindede bruger først autorisationscookieindstillingerne til true. Hvis cookieindstillinger ikke er indstillet til “sand”, kan cookieværdien returneres som “udefineret”.
hvordan man fjerner et element fra en matrix i java
For at ændre disse cookieværdier udfører en ondsindet bruger i henhold til Javascript-kommandoen fra URL-linjen i browseren:
javascript: void (document.cookie = “autorisation = sand”);
I resultatet ændres den aktuelle cookieparameterautorisation = falsk til autorisation = sand. På denne måde vil en ondsindet bruger være i stand til at få adgang til det følsomme indhold.
Det skal også nævnes, at Javascript-kode nogle gange returnerer ret følsomme oplysninger.
javascript: alarm (document.cookie);
For eksempel, hvis et webstedsudvikler ikke var forsigtig nok, kan det også returnere brugernavne og adgangskodeparametre navne og værdier. Derefter kan sådanne oplysninger bruges til at hacke webstedet eller bare ændre den følsomme parameters værdi.
For eksempel, med nedenstående kode kan vi ændre brugernavnværdien:
javascript: ugyldigt (document.cookie = ”brugernavn = anden bruger”);
På denne måde kan andre parameterværdier også ændres.
Websteds designændring
Javascript kan også bruges til at ændre ethvert webstedsformular og generelt webstedsdesignet.
For eksempel, med Javascript kan du ændre alle oplysninger, der vises på hjemmesiden:
- Viste tekst.
- Websteds baggrund.
- Webstedsformularens udseende.
- Pop-up-vindues udseende.
- Ethvert andet websiteelements udseende.
For eksempel, for at ændre den viste e-mail-adresse på webstedet skal passende Javascript-kommando bruges:
javascript: ugyldigt (document.forms [0] .email.value = ”Test@test.com”) ;
Få andre komplicerede manipulationer med hjemmesidens design er også mulige. Med dette angreb kan vi også få adgang til og ændre websteds CSS-klasse.
For eksempel, hvis vi gerne vil ændre websteds baggrundsbillede med JS Injection, skal kommandoen køres i overensstemmelse hermed:
javascript: ugyldigt (dokument. baggrundsbillede: url (“anden-image.jpg”);
En ondsindet bruger kan også skrive Javascript Injection-kode, som er nævnt nedenfor i formularen til tekstindsættelse og gemme den.
javascript: void (alarm („Hello!“));
Derefter vises hver tekst, når en side åbnes, et tekstfelt med meddelelsen “Hej!”.
Ændret websides design med Javascript Injection er mindre risikabelt end parametrering. Men hvis websteds design ændres på en ondsindet måde, kan det koste virksomhedens omdømme.
Sådan tester du mod JavaScript-injektion
Det kan testes på følgende måder:
- Manuelt
- Med testværktøjer
- Med browser-plugins
Mulige Javascript-sårbarheder kan kontrolleres manuelt, hvis du har et godt kendskab til, hvordan det skal udføres. Det kan også testes med forskellige automatiseringsværktøjer.
For eksempel, hvis du har automatiseret dine tests på API-niveau med SOAP UI-værktøjet, er det også muligt at køre Javascript Injection tests med SOAP UI .
Jeg kan dog kun kommentere fra min egen erfaring, at du virkelig skulle have haft god viden om SOAP UI-værktøjet til at teste med det til JS Injection, da alle testtrin skal skrives uden fejl. Hvis testtrin er skrevet forkert, kan det også medføre forkerte sikkerhedstestresultater.
Du kan også finde forskellige browsers plugins til kontrol mod mulige angreb. Det anbefales dog ikke at glemme at kontrollere mod dette angreb manuelt, da det normalt giver mere nøjagtige resultater.
Jeg vil gerne sige, at test manuelt mod Javascript Injection får mig til at føle mig mere selvsikker og sikker på websteds sikkerhed. På denne måde kan du være sikker på, at der ikke blev gået glip af nogen form under testen, og alle resultaterne er synlige for dig.
For at teste mod Javascript Injection skal du have generel viden om Javascript og skal vide, hvilke dele af hjemmesiden der er mere sårbare. Du skal også huske, at webstedet muligvis er beskyttet mod JS Injection, og under test skal du prøve at bryde denne beskyttelse.
På denne måde vil du være sikker på, om beskyttelsen mod dette angreb er stærk nok eller ej.
Mulig beskyttelse mod dette angreb
For det første skal alle modtagne input valideres for at forhindre dette angreb. Input bør valideres hver gang, og ikke kun når dataene oprindeligt accepteres.
Det anbefales stærkt ikke at stole på validering af klientsiden. Det anbefales også at udføre en vigtig logik på serversiden.
Mange forsøger at beskytte mod Javascript-injektion ved at ændre citaterne til dobbelt, og Javascript-kode skal ikke udføres på den måde.
For eksempel, hvis du skriver noget i kommentarfeltet med citater ..., vil disse citater blive erstattet med dobbelt -<>...<>. På denne måde udføres den indtastede Javascript-kode ikke.
Jeg har bemærket, at erstatning af citater med dobbelt citater er en ganske almindelig praksis for at undgå mulige JS-injektionsangreb. Der er dog et par måder at kode tilbudene for at få JS-injektionskoden udført. Derfor er det ikke en perfekt måde at beskytte mod dette angreb på at ændre citater til dobbelt.
Konklusion
Det skal altid holdes for øje, at Javascript Injection er et af de mulige angreb på websteder, da Javascript er en af de mest anvendte teknologier til hjemmesiderne. Derfor, mens du tester websteder eller andre webteknologier, bør det ikke glemmes at teste mod dette angreb.
Når du udfører sikkerhedstest, bør JS Injection ikke glemmes. Nogle mennesker betragter denne test som et mindre risikabelt angreb, da den udføres på klientsiden.
Det er dog den forkerte tilgang, og vi skal altid huske, at Javascript Injection kan forårsage alvorlig websides skade som følsom informationslækage, parametre, der ændrer eller hacker brugerkontiene.
Derfor bør vi betragte dette som en vigtig del af testningen, og det er en del af investeringen for et godt produkts og virksomheds omdømme.
Test af JS-injektion er ikke særlig vanskelig. For det første skal du have generel viden om Javascript og skal vide, hvordan du kontrollerer, om dette angreb er muligt for den aktuelle webløsning eller ej.
Også under test skal du huske, at et websted kan have beskyttelse mod denne type angreb, men det kan være for svagt - det skal også kontrolleres. En anden vigtig ting at huske er, at der findes forskellige typer Javascript Injection-angreb, og ingen af dem skal glemmes at teste.
Har du udført Javascript Injection Testing ?? Vi ville være glade for at høre fra dig, du er velkommen til at dele dine oplevelser i kommentarfeltet nedenfor.
Anbefalet læsning
- Dybdegående formørkelsesvejledninger til begyndere
- Sådan opsættes Node.js Testing Framework: Node.js Tutorial
- HTML-injektionsvejledning: Typer og forebyggelse med eksempler
- SQL Injection Testing Tutorial (Eksempel og forebyggelse af SQL Injection Attack)
- Java Reflection Tutorial med eksempler
- SVN Tutorial: Kildekodestyring ved hjælp af Subversion
- Python DateTime-tutorial med eksempler
- Tortoise SVN Tutorial: Revisions In Code Repository