Meny

HTML Injection Tutorial: Typer og forebygging med eksempler

html injection tutorial

standard gateway er ikke tilgjengelig windows 7

Prøv Instrumentet Vårt For Å Eliminere Problemer

En grundig titt på HTML Injection:

For å få en bedre oppfatning av HTML-injeksjon, bør vi først vite hva HTML er.

HTML er et kodespråk der alle nettstedets elementer er skrevet i kodene. Det blir mest brukt til å lage nettsteder. Nettsider blir sendt til nettleseren i form av HTML-dokumenter. Deretter konverteres disse HTML-dokumentene til vanlige nettsteder og vises for sluttbrukerne.

Denne opplæringen vil gi deg en fullstendig oversikt over HTML Injection, dens typer og forebyggende tiltak sammen med praktiske eksempler i enkle termer for enkel forståelse av konseptet.

HTML-injeksjon

Hva du vil lære:

Hva er HTML-injeksjon?

Essensen av denne typen injeksjonsangrep er å injisere HTML-kode gjennom de sårbare delene av nettstedet. Den ondsinnede brukeren sender HTML-kode gjennom et hvilket som helst sårbart felt med det formål å endre utformingen av nettstedet eller all informasjon som vises til brukeren.

I resultatet kan brukeren se dataene som ble sendt av den ondsinnede brukeren. Derfor er HTML Injection generelt bare injeksjon av kodespråk-koden til dokumentet på siden.

Data som sendes under denne typen injeksjonsangrep kan være veldig forskjellige. Det kan være noen HTML-koder som bare viser den sendte informasjonen. Det kan også være hele den falske skjemaet eller siden. Når dette angrepet skjer, tolker nettleseren vanligvis ondsinnede brukerdata som legitime og viser dem.

Å endre utseendet til et nettsted er ikke den eneste risikoen som denne typen angrep medfører. Det er ganske likt XSS-angrepet, der den ondsinnede brukeren stjeler andres identiteter. Derfor kan stjele en annen persons identitet også skje under dette injeksjonsangrepet.

Typer HTML-injeksjon

Dette angrepet ser ikke ut til å være veldig vanskelig å forstå eller utføre, ettersom HTML betraktes som et ganske enkelt språk. Imidlertid er det forskjellige måter å utføre denne typen angrep på. Vi kan også skille mellom forskjellige typer av denne injeksjonen.

For det første kan forskjellige typer sorteres etter risikoen de medfører.

Som nevnt kan dette injeksjonsangrepet utføres med to forskjellige formål:

  • For å endre utseendet til det viste nettstedet.
  • Å stjele en annen persons identitet.

Dette injeksjonsangrepet kan også utføres gjennom forskjellige deler av nettstedet, dvs. datainformasjonsfelt og nettstedets lenke.

Imidlertid er hovedtypene:

  • Lagret HTML-injeksjon
  • Reflektert HTML-injeksjon

# 1) Lagret HTML-injeksjon:

Hovedforskjellen mellom disse to injeksjonstypene er at lagret injeksjonsangrep oppstår når ondsinnet HTML-kode lagres på webserveren og utføres hver gang når brukeren kaller en passende funksjonalitet.

Imidlertid blir skadelig HTML-kode ikke lagret permanent på webserveren i det gjenspeiles angrepssaken. Reflected Injection oppstår når nettstedet umiddelbart svarer på den ondsinnede innspillingen.

# 2) Reflektert HTML-injeksjon:

Dette kan igjen deles inn i flere typer:

  • Reflektert GET
  • Reflektert POST
  • Reflektert URL

Reflektert injeksjonsangrep kan utføres forskjellig i henhold til HTTP-metodene, dvs. GET og POST. Jeg vil minne om at med POST-metoden blir data sendt og med GET-metoden blir data bedt om.

For å vite hvilken metode som brukes for passende nettstedselementer, kan vi sjekke kilden til siden.

binært tre implementering c ++

For eksempel , en tester kan sjekke kildekoden for påloggingsskjemaet og finne hvilken metode som brukes til det. Deretter kan passende HTML-injeksjonsmetode velges tilsvarende.

HTML-injeksjonsmetode

Reflektert GET-injeksjon oppstår når innspillene våre vises (reflekteres) på nettstedet. Anta at vi har en enkel side med et søkeskjema som er sårbart for dette angrepet. Så hvis vi skriver inn noen HTML-kode, vil den vises på nettstedet vårt, og samtidig vil den bli injisert i HTML-dokumentet.

For eksempel skriver vi inn enkel tekst med HTML-koder:

HTML-injeksjonstekst

Reflektert POST HTML-injeksjon er litt vanskeligere. Det oppstår når en ondsinnet HTML-kode blir sendt i stedet for riktige parametere for POST-metoden.

For eksempel , vi har et påloggingsskjema som er sårbart for HTML-angrep. Data skrevet i påloggingsskjemaet sendes med POST-metoden. Så hvis vi skriver inn en HTML-kode i stedet for de riktige parametrene, vil den sendes med POST-metoden og vises på nettstedet.

For å utføre Reflected POST HTML-angrep, anbefales det å bruke en spesiell nettlesers plugin, som vil falske sendte data. En av det er Mozilla Firefox plugin 'Tamper Data'. Plugin tar over de sendte dataene og lar brukeren endre det. Deretter sendes endrede data og vises på nettstedet.

For eksempel, Hvis vi bruker et slikt plugin, vil vi sende den samme HTML-koden

eller søk skjema kode, hvis du vil teste med noe mer komplisert

Skriv inn tekst for å søke

Hvis det vises en HTML-kode som lagres et sted, kan testeren være sikker på at dette injeksjonsangrepet er mulig. Da kan en mer komplisert kode prøves - for Eksempel , for å vise det falske påloggingsskjemaet.

En annen løsning er HTML Injection scanner. Det kan spare mye tid å skanne automatisk mot dette angrepet. Jeg vil varsle at det ikke er mange verktøy for HTML Injection testing sammenlignet med andre angrep.

Imidlertid er en mulig løsning WAS-applikasjon. WAS kan navngis som en ganske sterk sårbarhetsskanner, da den tester med de forskjellige inngangene og ikke bare stopper med den første mislykkede.

Det er nyttig for testing, kanskje som nevnt i ovennevnte nettleser-plugin 'Tamper Data', det får sendte data, lar testeren endre det og sender til nettleseren.

Vi kan også finne noen online skanneverktøy, der du bare trenger å oppgi nettstedets lenke og skanning mot HTML-angrep vil bli utført. Når testingen er fullført, vises sammendraget.

Jeg vil kommentere at når vi velger et skanneverktøy, må vi ta hensyn til hvordan det analyserer resultatene og er det nøyaktig nok eller ikke.

Det bør imidlertid huskes at testing manuelt ikke bør glemmes. På denne måten kan vi være sikre på hvilke eksakte innganger som er prøvd og hvilke nøyaktige resultater vi får. Også på denne måten er det lettere å analysere resultatene også.

Ut av min erfaring i en testkarriere for programvare, vil jeg kommentere at for begge testmåtene bør vi ha god kunnskap om denne typen injeksjon. Ellers ville det være vanskelig å velge et passende automatiseringsverktøy og analysere resultatene. Det anbefales også alltid å ikke glemme å teste manuelt, da det bare gjør oss mer sikre på kvaliteten.

Hvordan forhindre HTML-injeksjon?

Det er ingen tvil om at hovedårsaken til dette angrepet er utviklerens uoppmerksomhet og mangel på kunnskap. Denne typen injeksjonsangrep oppstår når inngang og utgang ikke er riktig validert. Derfor er hovedregelen for å forhindre HTML-angrep riktig datavalidering.

Hver inngang bør kontrolleres hvis den inneholder skriptkode eller HTML-kode. Vanligvis blir det sjekket hvis koden inneholder spesielle skript eller HTML-parenteser -,.

Det er mange funksjoner for å sjekke om koden inneholder spesielle parenteser. Valg av kontrollfunksjon avhenger av hvilket programmeringsspråk du bruker.

Det skal huskes, så bra sikkerhetstesting er også en del av forebygging. Jeg vil være oppmerksom på at HTML-injeksjonsangrep er svært sjelden, at det er mindre litteratur å lære om det og mindre skanner å velge for automatisk testing. Imidlertid bør denne delen av sikkerhetstesting ikke gå glipp av, ettersom du aldri vet når det kan skje.

Både utvikleren og testeren skal også ha god kunnskap om hvordan dette angrepet utføres. God forståelse av denne angrepsprosessen kan bidra til å forhindre den.

Sammenligning med andre angrep

Sammenlignet med de andre mulige angrepene, vil dette angrepet definitivt ikke bli ansett som så risikabelt som SQL Injection eller JavaScript-injeksjonsangrep eller til og med XSS kan være. Det vil ikke ødelegge hele databasen eller stjele all data fra databasen. Imidlertid bør det ikke betraktes som ubetydelig.

Som nevnt tidligere, er hovedformålet med denne typen injeksjon å endre utseendet til nettstedet med ondsinnet formål, og vise den sendte informasjonen eller dataene dine til den endelige brukeren. Disse risikoene kan betraktes som mindre viktige.

Endret utseende på nettstedet kan imidlertid koste firmaets omdømme. Hvis en ondsinnet bruker vil ødelegge utseendet til nettstedet ditt, kan det endre besøkendes meninger om selskapet ditt.

Det skal huskes at en annen risiko, som dette angrepet på nettstedet medfører, er å stjele identiteten til andre brukere.

Som nevnt, med HTML Injection kan den ondsinnede brukeren injisere hele siden, som vil bli vist for den endelige brukeren. Så hvis den endelige brukeren vil indikere påloggingsdataene på den falske påloggingssiden, vil de bli sendt til den ondsinnede brukeren. Denne saken er selvfølgelig den mer risikable delen av dette angrepet.

Det skal nevnes at for å stjele andre brukeres data, blir denne typen angrep sjeldnere valgt, da det er mange andre mulige angrep.

Det er imidlertid veldig likt XSS-angrepet, som stjeler brukerens informasjonskapsler og andre brukeridentiteter. Det er også XSS-angrep, som er HTML-baserte. Testing mot XSS og HTML-angrep kan derfor være veldig likt og utført sammen.

Konklusjon

Siden HTML Injection ikke er like populær som andre angrep, kan det betraktes som mindre risikabelt enn andre angrep. Derfor tester man mot denne typen injeksjon noen ganger.

Det merkes også at det definitivt er mindre litteratur og informasjon om HTML-injeksjon. Derfor kan testere bestemme seg for ikke å utføre denne typen testing. I dette tilfellet er risikoen for HTML-angrep kanskje ikke evaluert nok.

verktøy for ytelsestesting for Java-applikasjoner

Som vi har analysert i denne opplæringen, med denne typen injeksjon kan hele utformingen av nettstedet ditt bli ødelagt, eller til og med brukerens påloggingsdata kan bli stjålet. Derfor anbefales det sterkt å inkludere HTML Injection i sikkerhetstesting og investere god kunnskap.

Har du kommet over noen typiske HTML-injeksjoner? Del gjerne dine erfaringer i kommentarfeltet nedenfor.

Anbefalt lesing

^