Nettapplikasjoner er sårbare fordi de er tilgjengelige for et stort antall internettbrukere, inkludert mange som aktivt prøver å omgå sikkerhetsmekanismer, av ulike grunner.
I internettets tidlige dager var en vanlig angrepsmetode «brute force», en metode der roboter eller personer med mye fritid prøvde utallige kombinasjoner av brukernavn og passord for å få tilgang til en applikasjon.
Brute force-angrep er ikke lenger en stor trussel på grunn av passordretningslinjer, begrensede innloggingsforsøk og CAPTCHA-løsninger. Imidlertid er nettkriminelle alltid på jakt etter nye sårbarheter. De oppdaget for lenge siden at tekstfelt i applikasjoner og nettsider kan misbrukes ved å skrive inn uventet tekst som tvinger applikasjonen til å utføre handlinger den ikke var ment å utføre. Dette førte til det som er kjent som injeksjonsangrep.
Injeksjonsangrep kan brukes til å få uautorisert tilgang til applikasjoner, avdekke konfidensiell informasjon eller til og med ta kontroll over en hel server. Dette gjør angrepene til en alvorlig trussel, ikke bare for selve nettapplikasjonene, men også for brukernes data og potensielt for andre tilknyttede applikasjoner og tjenester.
Kodeinjeksjon
Kodeinjeksjon er en av de mest vanlige formene for injeksjonsangrep. Angripere som kjenner til programmeringsspråket, rammeverket, databasen eller operativsystemet som en nettapplikasjon bruker, kan injisere kode via tekstfelt for å manipulere webserveren.
Denne typen angrep er mulig i applikasjoner som ikke har tilstrekkelig inputvalidering. Hvis et tekstfelt lar brukere skrive inn hva som helst, er applikasjonen sårbar. For å forhindre dette, må applikasjonen begrense hva brukerne kan skrive inn, inkludert mengden forventede data, dataformatet og tillatte tegn.
Sårbarheter for kodeinjeksjon er ofte enkle å finne ved å teste tekstfeltene i en applikasjon med ulike typer input. Selv om selve utnyttelsen kan være moderat vanskelig, kan virkningen være alvorlig, med tap av konfidensialitet, integritet, tilgjengelighet eller applikasjonsfunksjonalitet.
SQL-injeksjon
I likhet med kodeinjeksjon involverer SQL-injeksjon å sette inn et SQL-skript i et tekstfelt. SQL er språket som brukes av de fleste databaser for å utføre spørringer. Skriptet sendes til applikasjonen, som utfører det direkte på databasen. Dette kan gjøre det mulig for en angriper å omgå en innloggingsskjerm, lese sensitive data direkte fra databasen, endre eller ødelegge data, eller utføre administrative oppgaver.
PHP- og ASP-applikasjoner er spesielt utsatt for SQL-injeksjon på grunn av eldre funksjonelle grensesnitt, mens J2EE- og ASP.Net-apper vanligvis har bedre beskyttelse. Når en SQL-injeksjonssårbarhet er identifisert, er omfanget av angrepet begrenset av angriperens ferdigheter og fantasi, noe som gjør virkningen potensielt veldig stor.
Kommandoinjeksjon
Kommandoinjeksjonsangrep utnytter også utilstrekkelig inputvalidering. I stedet for kode, setter angriperen inn systemkommandoer. Dette krever ikke kunnskap om programmeringsspråket som brukes av applikasjonen eller databasen, men om operativsystemet som brukes av serveren.
De injiserte systemkommandoene utføres med applikasjonens rettigheter, og kan for eksempel gjøre det mulig for angriperen å få tilgang til filer på serveren, se serverens mappestruktur eller endre brukerpassord. Systemadministratorer kan forhindre disse angrepene ved å begrense systemtilgangen til nettapplikasjoner som kjører på en server.
Kryss-side-skripting (XSS)
Når en applikasjon setter inn input fra en bruker i output den genererer uten å validere den, åpner den for et XSS-angrep. Angriperen kan injisere ondsinnede skript på et pålitelig nettsted som deretter blir sendt til andre brukere, som blir ofrene.
Ofrenes nettleser vil kjøre skriptet, uvitende om at det ikke er til å stole på, og kan dermed gi tilgang til økttokener, informasjonskapsler eller annen sensitiv informasjon. I noen tilfeller kan skriptene endre innholdet i en HTML-fil.
XSS-angrep deles vanligvis i to kategorier: lagret og reflektert. Lagret XSS innebærer at skriptet ligger permanent på serveren, f.eks. i et forum, en database eller en besøkslogg. Offeret får skriptet når nettleseren ber om den lagrede informasjonen. Reflektert XSS betyr at skriptet reflekteres i et svar som inneholder input sendt til serveren, for eksempel i en feilmelding eller et søkeresultat.
XPath-injeksjon
XPath-injeksjon er mulig når en applikasjon bruker brukerinput for å bygge en XPath-spørring for XML-data. Angripere sender feilaktig informasjon for å forstå strukturen til XML-dataene og deretter få tilgang til dem.
XPath er et standardspråk for å spesifisere attributter som skal finnes i XML-data. Ved å sende feil input, kan angripere endre datamønsteret til en operasjon de ønsker å utføre. I motsetning til SQL finnes det ingen forskjellige versjoner av XPath, noe som gjør at angrep kan utføres på alle applikasjoner som bruker XML-data og potensielt automatiseres.
Injisering av postkommando
Denne metoden brukes for å utnytte e-postservere og applikasjoner som bygger IMAP- eller SMTP-meldinger med feilaktig validerte brukerinput. IMAP- og SMTP-servere har ofte ikke like sterk beskyttelse som webservere, og kan derfor være lettere å utnytte. Ved å gå via en e-postserver, kan angripere omgå restriksjoner som CAPTCHAs og begrensninger på antall forespørsler.
For å utnytte en SMTP-server trenger angriperen en gyldig e-postkonto for å sende meldinger med injiserte kommandoer. Hvis serveren er sårbar, kan angriperen for eksempel omgå restriksjoner og bruke tjenestene til å sende spam. IMAP-injeksjon kan utføres på webmail-applikasjoner ved å utnytte meldingslesingsfunksjonalitet, for eksempel ved å skrive en URL med de injiserte kommandoene i adressefeltet.
CRLF-injeksjon
CRLF-injeksjon innebærer å sette inn vognretur- og linjeskifttegn (CRLF) i tekstfelt. Disse usynlige tegnene indikerer slutten av en linje eller kommando i internettprotokoller som HTTP, MIME og NNTP. For eksempel kan injeksjon av en CRLF i en HTTP-forespørsel, etterfulgt av HTML-kode, sende egendefinerte nettsider til besøkende.
Dette angrepet er mulig i applikasjoner som ikke filtrerer brukerinput på riktig måte. Denne sårbarheten kan også åpne døren for andre angrep, som XSS og kodeinjeksjon, eller føre til at et nettsted blir kapret.
Host Header-injeksjon
På servere som hoster mange nettsteder eller applikasjoner, brukes vertsoverskriften til å bestemme hvilken virtuell vert som skal behandle en innkommende forespørsel. Hvis serveren mottar en ugyldig vertsoverskrift, sendes den vanligvis til den første virtuelle verten på listen. Dette gir angripere muligheten til å sende vilkårlige vertsoverskrifter til den første virtuelle verten.
Manipulering av vertsoverskriften er ofte knyttet til PHP-applikasjoner, men kan også utføres med andre teknologier. Denne typen angrep kan fungere som en katalysator for andre angrep, som web-cache forgiftning. Konsekvensene kan være alvorlige, som for eksempel utføring av sensitive operasjoner som tilbakestilling av passord.
LDAP-injeksjon
LDAP er en protokoll som brukes til å søke etter ressurser i et nettverk. Den er nyttig for intranett og kan brukes i et enkelt påloggingssystem. LDAP-spørringer bruker spesielle kontrolltegn. Angripere kan endre virkemåten til en LDAP-spørring ved å injisere disse tegnene.
Som med de andre injeksjonstypene, er problemet her utilstrekkelig validering av brukerinput. Hvis teksten som sendes av brukeren brukes i en LDAP-spørring uten å renses, kan angriperen hente en liste over alle brukere ved å sette inn en stjerne på riktig sted i teksten.
Forebygging av injeksjonsangrep
Alle injeksjonsangrep er rettet mot servere og applikasjoner som er tilgjengelige for internettbrukere. Ansvaret for å forhindre disse angrepene deles mellom applikasjonsutviklere og serveradministratorer.
Applikasjonsutviklere må være klar over risikoen ved feil validering av brukerinput og implementere beste praksis for å rense input. Serveradministratorer må jevnlig revidere systemene sine for å oppdage og fikse sårbarheter. Det finnes mange alternativer for å utføre disse revisjonene, både på forespørsel og automatisk.