Problemet med nettapplikasjoner er at de er åpent eksponert for milliarder av internettbrukere, hvorav mange vil ønske å bryte sikkerhetstiltakene – uansett årsak.
I de tidlige dagene av Internett var en av de vanligste angrepsmetodene grunnleggende, enkel brute force. Bots utførte vanligvis disse angrepene – eller personer med mye fri – som prøvde zillioner av kombinasjoner av brukernavn og passord til de fant en som ville gi tilgang til målapplikasjonen.
Brute force-angrep er ikke lenger en trussel, takket være passordpolitikk, begrensede påloggingsforsøk og captchaer. Men nettkriminelle elsker å oppdage nye bedrifter og bruke dem til å utføre nye typer angrep. For lenge siden oppdaget de at tekstfelt på applikasjoner eller nettsider kunne utnyttes ved å skrive inn – eller injisere – uventet tekst i dem som ville tvinge applikasjonen til å gjøre noe den ikke var ment å gjøre. På den måten kom de såkalte injeksjonsangrepene inn på stedet.
Injeksjonsangrep kan ikke bare brukes til å logge på en applikasjon uten å vite brukernavn og passord, men også til å avsløre privat, konfidensiell eller sensitiv informasjon, eller til og med til å kapre en hel server. Det er derfor disse angrepene ikke bare er en trussel mot nettapplikasjoner, men også for brukerne hvis data ligger på disse applikasjonene, og i verste fall mot andre tilkoblede applikasjoner og tjenester.
Innholdsfortegnelse
Kodeinnsprøytning
Kodeinjeksjon er en av de vanligste typene injeksjonsangrep. Hvis angripere kjenner programmeringsspråket, rammeverket, databasen eller operativsystemet som brukes av en nettapplikasjon, kan de injisere kode via tekstinntastingsfelt for å tvinge webserveren til å gjøre det de vil.
Disse typene injeksjonsangrep er mulig på applikasjoner som mangler validering av inndata. Hvis et tekstinntastingsfelt lar brukere skrive inn hva de vil, kan applikasjonen potensielt utnyttes. For å forhindre disse angrepene, må applikasjonen begrense så mye den kan at inndatabrukerne får lov til å gå inn.
For eksempel må den begrense mengden forventet data, kontrollere dataformatet før det godtas, og begrense settet med tillatte tegn.
Kodeinjeksjonssårbarhetene kan være enkle å finne, bare ved å teste tekstinndataene til en nettapplikasjon med ulike typer innhold. Når de blir funnet, er sårbarhetene moderat vanskelige å utnytte. Men når en angriper klarer å utnytte en av disse sårbarhetene, kan virkningen omfatte tap av konfidensialitet, integritet, tilgjengelighet eller applikasjonsfunksjonalitet.
SQL-injeksjon
På en lignende måte som kodeinjeksjon setter dette angrepet inn et SQL-skript – språket som brukes av de fleste databaser for å utføre spørringsoperasjoner – i et tekstinndatafelt. Skriptet sendes til applikasjonen, som kjører det direkte på databasen. Som et resultat kan angriperen gå gjennom en påloggingsskjerm eller gjøre farligere ting, som å lese sensitive data direkte fra databasen, endre eller ødelegge databasedata, eller utføre admin-operasjoner på databasen.
PHP- og ASP-applikasjoner er utsatt for SQL-injeksjonsangrep på grunn av dets eldre funksjonelle grensesnitt. J2EE- og ASP.Net-apper er vanligvis mer beskyttet mot disse angrepene. Når en SQL-injeksjonssårbarhet blir funnet – og de kan lett bli funnet – vil omfanget av de potensielle angrepene bare begrenses av angriperens dyktighet og fantasi. Dermed er virkningen av et SQL-injeksjonsangrep utvilsomt høy.
Kommandoinjeksjon
Disse angrepene er også mulige, hovedsakelig på grunn av utilstrekkelig inndatavalidering. De skiller seg fra kodeinjeksjonsangrep ved at angriperen setter inn systemkommandoer i stedet for deler av programmeringskode eller skript. Derfor trenger ikke hackeren å kunne programmeringsspråket som applikasjonen er basert på eller språket som brukes av databasen. Men de trenger å kjenne operativsystemet som brukes av vertsserveren.
De innsatte systemkommandoene utføres av vertsoperativsystemet med privilegiene til applikasjonen, noe som kan tillate å eksponere innholdet i vilkårlige filer som ligger på serveren, for å vise katalogstrukturen til en server, for å endre brukerpassord, blant annet .
Disse angrepene kan forhindres av en systemadministrator ved å begrense systemtilgangsnivået til nettapplikasjonene som kjører på en server.
Skripting på tvers av nettsteder
Når en applikasjon setter inn input fra en bruker i utdataene den genererer, uten å validere eller kode den, gir den muligheten til en angriper til å sende ondsinnet kode til en annen sluttbruker. Cross-Site Scripting (XSS)-angrep benytter disse mulighetene til å injisere ondsinnede skript på pålitelige nettsteder, som til slutt sendes til andre brukere av applikasjonen, som blir angriperens ofre.
Ofrenes nettleser vil kjøre det ondsinnede skriptet uten å vite at det ikke skal stoles på. Derfor vil nettleseren la den få tilgang til økttokens, informasjonskapsler eller sensitiv informasjon lagret av nettleseren. Hvis de er riktig programmert, kan skriptene til og med skrive om innholdet i en HTML-fil.
XSS-angrep kan generelt deles inn i to forskjellige kategorier: lagret og reflektert.
I lagrede XSS-angrep ligger det ondsinnede skriptet permanent på målserveren, i et meldingsforum, i en database, i en besøkslogg osv. Offeret får det når nettleseren ber om den lagrede informasjonen. I reflekterte XSS-angrep gjenspeiles det ondsinnede skriptet i et svar som inkluderer input sendt til serveren. Dette kan for eksempel være en feilmelding eller et søkeresultat.
XPath-injeksjon
Denne typen angrep er mulig når en nettapplikasjon bruker informasjon gitt av en bruker til å bygge en XPath-spørring for XML-data. Måten disse angrepene fungerer på, ligner på SQL-injeksjon: angripere sender feilformet informasjon til applikasjonen for å finne ut hvordan XML-dataene er strukturert, og deretter angriper de igjen for å få tilgang til disse dataene.
XPath er et standardspråk som du, i likhet med SQL, kan spesifisere attributtene du vil finne. For å utføre en spørring på XML-data, bruker nettapplikasjoner brukerinndata for å angi et mønster dataene skal samsvare med. Ved å sende feilaktige input kan mønsteret bli til en operasjon som angriperen ønsker å bruke på dataene.
I motsetning til det som skjer med SQL, i XPath, er det ingen forskjellige versjoner. Dette betyr at XPath-injeksjon kan gjøres på alle nettapplikasjoner som bruker XML-data, uavhengig av implementeringen. Det betyr også at angrepet kan automatiseres; derfor, i motsetning til SQL-injeksjon, har den potensialet til å bli avfyrt mot et vilkårlig antall mål.
Injeksjon av postkommando
Denne angrepsmetoden kan brukes til å utnytte e-postservere og applikasjoner som bygger IMAP- eller SMTP-setninger med feil validerte brukerinndata. Noen ganger har ikke IMAP- og SMTP-servere sterk beskyttelse mot angrep, slik det ville vært tilfelle med de fleste webservere, og kan derfor være mer utnyttelige. Ved å gå inn via en e-postserver kan angripere unngå restriksjoner som captchas, et begrenset antall forespørsler osv.
For å utnytte en SMTP-server trenger angripere en gyldig e-postkonto for å sende meldinger med injiserte kommandoer. Hvis serveren er sårbar, vil den svare på angripernes forespørsler, slik at de for eksempel kan overstyre serverbegrensninger og bruke tjenestene til å sende spam.
IMAP-injeksjon kan hovedsakelig gjøres på webmail-applikasjoner, ved å utnytte meldingslesingsfunksjonaliteten. I disse tilfellene kan angrepet utføres ved ganske enkelt å skrive inn, i adressefeltet til en nettleser, en URL med de injiserte kommandoene.
CRLF-injeksjon
Innsetting av vognretur- og linjeskifttegn – kombinasjon kjent som CRLF – i inndatafelt for nettskjemaer representerer en angrepsmetode kalt CRLF-injeksjon. Disse usynlige tegnene indikerer slutten på en linje eller slutten av en kommando i mange tradisjonelle internettprotokoller, for eksempel HTTP, MIME eller NNTP.
For eksempel kan innsetting av en CRLF i en HTTP-forespørsel, etterfulgt av en viss HTML-kode, sende tilpassede nettsider til besøkende på et nettsted.
Dette angrepet kan utføres på sårbare nettapplikasjoner som ikke bruker riktig filtrering på brukerinndata. Denne sårbarheten åpner døren for andre typer injeksjonsangrep, som XSS og kodeinjeksjon, og kan også skyldes at et nettsted blir kapret.
Host Header-injeksjon
I servere som er vert for mange nettsteder eller nettapplikasjoner, blir vertsoverskriften nødvendig for å bestemme hvilke av de lokale nettstedene eller nettapplikasjonene – hver av dem kjent som en virtuell vert – som skal behandle en innkommende forespørsel. Verdien av overskriften forteller serveren til hvilken av de virtuelle vertene som skal sende en forespørsel. Når serveren mottar en ugyldig vertshode, sender den den vanligvis til den første virtuelle verten på listen. Dette utgjør en sårbarhet som angripere kan bruke til å sende vilkårlige vertshoder til den første virtuelle verten på en server.
Manipulering av vertshodet er vanligvis relatert til PHP-applikasjoner, selv om det også kan gjøres med andre nettutviklingsteknologier. Host header-angrep fungerer som muliggjører for andre typer angrep, for eksempel web-cache-forgiftning. Konsekvensene kan omfatte utførelse av sensitive operasjoner av angriperne, for eksempel tilbakestilling av passord.
LDAP-injeksjon
LDAP er en protokoll utviklet for å lette søket etter ressurser (enheter, filer, andre brukere) i et nettverk. Det er veldig nyttig for intranett, og når det brukes som en del av et enkelt påloggingssystem, kan det brukes til å lagre brukernavn og passord. LDAP-spørringer involverer bruk av spesielle kontrolltegn som påvirker kontrollen. Angripere kan potensielt endre den tiltenkte oppførselen til en LDAP-spørring hvis de kan sette inn kontrolltegn i den.
Igjen, rotproblemet som tillater LDAP-injeksjonsangrep er feilaktig validert brukerinndata. Hvis teksten en bruker sender til en applikasjon brukes som en del av en LDAP-spørring uten å rense den, kan spørringen ende opp med å hente en liste over alle brukere og vise den til en angriper, bare ved å bruke en stjerne
på rett sted i en inndatastreng.
Forebygging av injeksjonsangrep
Som vi så i denne artikkelen, er alle injeksjonsangrep rettet mot servere og applikasjoner med åpen tilgang til enhver internettbruker. Ansvaret for å forhindre disse angrepene er fordelt på applikasjonsutviklere og serveradministratorer.
Applikasjonsutviklere må kjenne til risikoene forbundet med feil validering av brukerinndata og lære beste praksis for å rense brukerinnspill med risikoforebyggende formål. Serveradministratorer må revidere systemene sine med jevne mellomrom for å oppdage sårbarheter og rette dem så snart som mulig. Det er mange alternativer for å utføre disse revisjonene, enten på forespørsel eller automatisk.