javascript injection tutorial
Hva er Javascript Injection?
Javascript er en av de mest populære teknologiene og brukes mest for websider og webapplikasjoner.
Den kan brukes til å realisere forskjellige funksjoner på nettstedet. Imidlertid kan denne teknologien gi noen sikkerhetsproblemer, som utvikleren og testeren bør være bevisste på.
Javascript kan ikke bare brukes til gode formål, men også for noen ondsinnede angrep. En av dem er Javascript Injection. Essensen av JS Injection er å injisere Javascript-koden, som kjøres fra klientsiden.
I denne veiledningen vil vi lære mer om hvordan du sjekker om Javascript Injection er mulig, hvordan JS Injection kan utføres og hva er konsekvensene som JS Injection kan medføre.
Hva du vil lære:
- Risiko for JavaScript-injeksjon
- Hvorfor er det viktig å teste JS Injection?
- Sammenligning med andre angrep
- Ser etter JavaScript-injeksjon
- Parametere Modifikasjon
- Nettsteds designendring
- Hvordan teste mot JavaScript-injeksjon
- Mulig beskyttelse mot dette angrepet
- Konklusjon
- Anbefalt lesing
Risiko for JavaScript-injeksjon
JS Injection gir mange muligheter for en ondsinnet bruker til å endre nettstedets design, få informasjon om nettstedet, endre informasjonen til det viste nettstedet og manipulere med parametrene (for eksempel informasjonskapsler). Derfor kan dette føre til alvorlige skader på nettstedet, informasjonslekkasje og til og med hack.
Hovedformålet med JS Injection er å endre nettstedets utseende og manipulere parametrene. Konsekvensene av JS Injection kan være veldig forskjellige - fra å skade nettstedets design til å få tilgang til andres konto.
Hvorfor er det viktig å teste JS Injection?
Mange vil spørre om testing for JS Injection virkelig er nødvendig.
Å sjekke om JS Injection-sårbarheter er en del av sikkerhetstesting. Sikkerhetstesting utføres vanligvis bare hvis det ble inkludert i prosjektplanleggingen, da det krever tid, mye oppmerksomhet og kontroll av flere detaljer.
Jeg har lagt merke til at det under prosjektets realisering er ganske vanlig å hoppe over testing mot eventuelle angrep - inkludert JS Injection. På denne måten prøver teamene å spare tid på prosjektet. Denne praksisen ender imidlertid ofte med kundens klager.
Det bør være kjent at sikkerhetstesting anbefales på det sterkeste selv om det ikke er inkludert i prosjektplanene. Det bør utføres kontroll av mulige angrep - samtidig må du sjekke om det er mulig JS Injection-sårbarheter.
Forlater enkelt Javascript Injeksjonssårbarheter i produktet kan koste produktets kvalitet og selskapets omdømme. Hver gang jeg har lært å teste mot mulige angrep og generelt sikkerhetstesting, hopper jeg aldri over denne delen av testingen. På denne måten er jeg bare mer sikker på produktets kvalitet.
Sammenligning med andre angrep
Det bør nevnes at JS Injection ikke er så risikabelt som SQL Injection , ettersom den utføres på klientsiden og den ikke når systemets database slik den skjer under SQL Injection-angrep. Det er heller ikke så risikabelt som XSS-angrep.
Under dette angrepet til tider kan bare utseendet til nettstedet endres, mens hovedformålet med XSS-angrep er å hacke andre påloggingsdata.
Imidlertid kan JS Injection også forårsake alvorlige skader på nettstedet. Det kan ikke bare ødelegge utseendet til nettstedet, men også bli et godt grunnlag for å hacke andres påloggingsdata.
Ser etter JavaScript-injeksjon
Når du begynner å teste mot JS Injection, er det første du bør gjøre å sjekke om JS Injection er mulig eller ikke. Det er veldig enkelt å sjekke etter denne typen injeksjonsmuligheter - når du navigerer til nettstedet, må du skrive inn nettleserens adressestrekkode slik:
javascript: alert (‘Executed!’);
Hvis et popup-vindu med meldingen 'Executed!' Vises, er nettstedet sårbart for JS Injection.
Deretter kan du prøve forskjellige Javascript-kommandoer i adresselinjen til nettstedet.
Det bør nevnes at JS Injection ikke bare er mulig fra nettstedets adressefelt. Det er forskjellige andre nettstedselementer som kan være sårbare for JS Injection. Det viktigste er å vite nøyaktig hvilke deler av nettstedet som kan påvirkes av Javascript Injection og hvordan du sjekker det.
Typiske JS-injeksjonsmål er:
- Ulike fora
- Artikkelens kommentarfelt
- Gjestebøker
- Eventuelle andre skjemaer der tekst kan settes inn.
For å teste om dette angrepet er mulig for tekstsparingsskjemaet, til tross for normal tekst, skriv inn Javascript-kode som nevnt nedenfor og lagre teksten i skjemaet og oppdater siden.
javascript: alert (‘Executed!’);
Hvis det på den nylig åpnede siden inneholder en tekstboks med meldingen 'Utført!', Er denne typen injeksjonsangrep mulig for det testede skjemaet.
Hvis en tekstboks med meldingen vises på begge måter, kan du prøve å bryte nettstedet med mer vanskelige JS Injection-metoder. Deretter kan du prøve forskjellige injeksjonstyper - parameterendring eller modifikasjon av design.
Selvfølgelig er modifisering av parametere ansett som en mer risikofylt end designmodifikasjon. Derfor, mens du tester mer oppmerksomhet bør vies til parametere endring.
Det bør også huskes at deler av mer sårbare nettsteder for Javascript Injection er inndatafelt der alle typer data lagres.
Parametere Modifikasjon
Som nevnt tidligere, er en av de mulige Javascript Injection-skader parameterendring.
Under dette injeksjonsangrepet kan en ondsinnet bruker få parametereinformasjon eller endre hvilken som helst parameterverdi( Eksempel ,informasjonskapselinnstillinger). Dette kan føre til ganske alvorlige risikoer ettersom en ondsinnet bruker kan få sensitivt innhold. En slik type injeksjon kan utføres ved hjelp av noen Javascript-kommandoer.
La oss huske at Javascript-kommandoen som returnerer gjeldende økt-informasjonskapsel er skrevet i samsvar med dette:
javascript: alert (document.cookie);
Oppgitt i nettleserens nettadresselinje, vil den returnere et popup-vindu med gjeldende øktcookies.
Hvis nettstedet bruker informasjonskapsler, kan vi lese slik informasjon som serverøkt-ID eller andre brukerdata som er lagret i informasjonskapslene.
Det må nevnes at i stedet for alarm () kan en hvilken som helst annen Javascript-funksjon brukes.
For eksempel ,hvis vi har funnet et sårbart nettsted, som lagrer økt-ID i informasjonskapselparameteren ‘session_id’. Deretter kan vi skrive en funksjon som endrer gjeldende økt-id:
javascript: void (document.cookie = “session_id =<>');
På denne måten vil økt-ID-verdien endres. Også andre måter å endre parametere på er mulig.
For eksempel, en ondsinnet bruker vil logge på som andre mennesker. For å utføre pålogging vil den ondsinnede brukeren for det første endre innstillingene for autorisasjonskapsler til sant. Hvis innstillinger for informasjonskapsler ikke er satt til “sant”, kan informasjonskapselverdien returneres som “udefinert”.
hvordan du åpner en .dat fil i Windows
For å endre disse informasjonskapselverdiene, vil en ondsinnet bruker utføre i henhold til Javascript-kommandoen fra URL-linjen i nettleseren:
javascript: void (document.cookie = “autorisasjon = sann”);
I resultatet blir nåværende informasjonskapsler parameter autorisasjon = usann endret til autorisasjon = sann. På denne måten vil en ondsinnet bruker kunne få tilgang til det sensitive innholdet.
Det må også nevnes at Javascript-kode noen ganger gir ganske sensitiv informasjon.
javascript: alert (document.cookie);
For eksempel, hvis nettstedsutvikleren ikke var forsiktig nok, kan den også returnere navn og verdier for brukernavn og passord. Så kan slik informasjon brukes til å hacke nettstedet eller bare endre verdien av den sensitive parameteren.
For eksempel, med koden nedenfor kan vi endre brukernavnverdien:
javascript: void (document.cookie = ”brukernavn = otherUser”);
På denne måten kan alle andre parametere endres.
Nettsteds designendring
Javascript kan også brukes til å endre hvilket som helst nettsteds skjema og generelt nettstedets utforming.
For eksempel, med Javascript kan du endre all informasjon som vises på nettstedet:
- Viste tekst.
- Nettsteds bakgrunn.
- Nettstedets skjema utseende.
- Popup-vinduets utseende.
- Ethvert annet nettstedelements utseende.
For eksempel, for å endre den viste e-postadressen på nettstedet, bør du bruke passende Javascript-kommando:
javascript: void (document.forms [0] .email.value = ”Test@test.com”) ;
Få andre kompliserte manipulasjoner med nettstedets design er også mulig. Med dette angrepet kan vi også få tilgang til og endre nettstedets CSS-klasse.
For eksempel, hvis vi ønsker å endre nettstedets bakgrunnsbilde med JS Injection, bør kommandoen kjøres tilsvarende:
javascript: ugyldig (dokument. bakgrunnsbilde: url (“andre-image.jpg“);
En skadelig bruker kan også skrive Javascript Injection code som er nevnt nedenfor i skjemaet for tekstinnsetting og lagre den.
javascript: void (alert („Hello!“));
Hver gang når en side åpnes, vises en tekstboks med meldingen “Hei!”.
Endret design av nettstedet med Javascript Injection er mindre risikabelt enn endring av parametere. Men hvis nettsteds design vil bli endret på en ondsinnet måte, kan det koste selskapets omdømme.
Hvordan teste mot JavaScript-injeksjon
Det kan testes på følgende måter:
- Manuelt
- Med testverktøy
- Med nettleser-plugins
Mulige Javascript-sårbarheter kan kontrolleres manuelt hvis du har god kunnskap om hvordan det skal utføres. Det kan også testes med forskjellige automatiseringsverktøy.
For eksempel, Hvis du har automatisert testene dine på API-nivå med SOAP UI-verktøyet, er det også mulig å kjøre Javascript Injection tester med SOAP UI .
Imidlertid kan jeg bare kommentere fra min egen erfaring, at du burde ha hatt god kunnskap om SOAP UI-verktøyet for å teste med det for JS Injection, da alle teststrinnene skal skrives uten feil. Hvis et testtrinn er skrevet feil, kan det også føre til feil sikkerhetstesteresultater.
Du kan også finne forskjellige nettleserens plugins for å sjekke mot mulig angrep. Det anbefales imidlertid å ikke glemme å sjekke mot dette angrepet manuelt, da det vanligvis gir mer nøyaktige resultater.
Jeg vil si at testing manuelt mot Javascript Injection får meg til å føle meg mer trygg og trygg på nettstedets sikkerhet. På denne måten kan du være sikker på at ingen skjemaer ble savnet mens du testet, og at alle resultatene er synlige for deg.
For å teste mot Javascript Injection, bør du ha generell kunnskap om Javascript og må vite hvilke deler av nettstedet som er mer sårbare. Du bør også huske at nettstedet kan være beskyttet mot JS Injection, og mens du tester, bør du prøve å bryte denne beskyttelsen.
På denne måten vil du være sikker på om beskyttelsen mot dette angrepet er sterk nok eller ikke.
Mulig beskyttelse mot dette angrepet
For det første, for å forhindre dette angrepet, bør alle mottatte innspill valideres. Inngangene bør valideres hver gang, og ikke bare når dataene først aksepteres.
Det anbefales på det sterkeste å ikke stole på validering av klientsiden. Det anbefales også å utføre en viktig logikk på serversiden.
Mange prøver å beskytte mot Javascript Injection ved å endre anførselstegnene til doble, og Javascript-koden skal ikke utføres på den måten.
For eksempel, hvis du vil skrive noe i sitatfeltet med anførselstegn…, vil anførselstegnene bli erstattet med dobbelt -<>...<>. På denne måten blir den angitte Javascript-koden ikke utført.
Jeg har lagt merke til at å erstatte anførselstegn med doble anførselstegn er en ganske vanlig praksis for å unngå mulige JS-injeksjonsangrep. Det er imidlertid noen måter å kode sitatene for å utføre JS-injeksjonskode. Derfor er det ikke en perfekt måte å beskytte mot dette angrepet å endre sitater til dobbelt.
Konklusjon
Det bør alltid holdes i bakhodet at Javascript Injection er et av de mulige angrepene mot nettsteder, ettersom Javascript er en av de mest brukte teknologiene for nettstedene. Derfor, mens du tester nettsteder eller andre webteknologier, bør det ikke glemmes å teste mot dette angrepet.
Når du utfører sikkerhetstesting, bør ikke JS Injection glemmes. Noen mennesker anser denne testingen som et mindre risikabelt angrep ettersom den utføres på klientsiden.
Imidlertid er det feil tilnærming, og vi bør alltid huske at Javascript Injection kan forårsake alvorlig skade på nettstedet som sensitiv informasjonslekkasje, endring av parametere eller hacking av brukerkontoer.
Derfor bør vi betrakte dette som en viktig del av testingen, og det er en del av investeringen for å få gode produkter og selskapets omdømme.
Det er ikke veldig vanskelig å teste for JS-injeksjon. For det første bør du ha generell kunnskap om Javascript og må vite hvordan du kan sjekke om dette angrepet er mulig for den nåværende webløsningen eller ikke.
Også mens du tester, bør du huske at et nettsted kan ha beskyttelse mot denne typen angrep, men det kan være for svakt - det bør også sjekkes. En annen viktig ting å huske er at det finnes forskjellige typer Javascript Injection-angrep, og ingen av dem skal glemmes å teste.
Har du utført Javascript Injection Testing ?? Vi vil gjerne høre fra deg, del gjerne dine erfaringer i kommentarfeltet nedenfor.
Anbefalt lesing
- In-Depth Eclipse Tutorials For Beginners
- Hvordan sette opp Node.js Testing Framework: Node.js Tutorial
- HTML Injection Tutorial: Typer og forebygging med eksempler
- SQL Injection Testing Tutorial (Eksempel og forebygging av SQL Injection Attack)
- Java Reflection Tutorial med eksempler
- SVN Tutorial: Source Code Management Using Subversion
- Python DateTime Tutorial med eksempler
- Tortoise SVN Tutorial: Revisions In Code Repository