Så hvordan beskytter man seg mot Injection-baserte angrep? Svaret er at det er relativt enkelt å beskytte seg og teknikken kalles Input Validering. Alle utviklere kjenner til dette, så hvorfor synker ikke denne sårbarheten i hyppighet?
Vi må understreke ordet relativt i utsagnet over fordi det er mange ulike metoder å utføre Injection angrep på, og det er nesten like mange måter å forhindre det på. Når man utfører risiko- og sårbarhetsanalyser, intervjuer en utviklerne om metoder og kontroller som de implementerer for å bygge sikkerhet inn i applikasjonene. Da får man svaret: Utvikleren vet at de trenger input validering, og de er glade for at rammeverket de benytter tar seg av slikt.
En sannhet med modifikasjoner. Ja, moderne web rammeverk hjelper deg med input validering, men langt fra fullstendig. Mye av jobben er fortsatt opp til utvikleren. Så hvordan gjør man det?
Før vi kan implementere de korrekte tiltakene må vi kjenne til de forskjellige Injection angrepene. Vi må vite når vi utsetter oss for hva, og hvilke tiltak vi kan bruke. Og for å gjøre det hele enda mer komplekst så dikterer også applikasjonsbehovene hva som er mulig og ikke. Men først; Injection baserte angrep.
PS: OWASP lister flere injection-baserte angrep forskjellig, men alle angrepene listet nedenfor er Injection-baserte, selv om dette ikke er en komplett liste. Det finnes også angrepsvektorer for XML External Entity og Server-Side Includes.
1. Cross-Site Scripting
Cross-Site Scripting (XSS) er en av de mest vanlige Injection-baserte angrepene på web-applikasjoner. For bare noen år siden ble det estimert at over 1/3 av alle applikasjoner på Internett var sårbare for XSS. Utvikler du SPA (Single-Page Application) applikasjoner er det ekstra stor sannsynlighet for at man ender opp med XSS sårbarheter. Med mindre man benytter SPA som en del av BFF (Backend for Front-End, hvor SPA applikasjonen bare er et skall i front som kaller på APIer på backend, selv om dette er heller ingen sølvkule).
XSS er en svakhet hvor data man ikke stoler på (JavaScriptet) sendes inn og kommer tilbake som en del av HTTP responsen. Alle moderne nettlesere har et sikkerhetstiltak som kalles SOP (Same-Origin Policy), som skal forhindre at et artifakt som ikke har lik origin (lik origin er å ha samme scheme (HTTP e.l.), host navn og port nummer) skal kunne få tilgang til en annen side. Dette innebærer at hver nettside som nettleseren henter får sin egen sandbox og ingen nettside kan nå en annen nettside via DOM.
Liten digresjon: lagrer applikasjonen din data i LocalStorage så er ikke den beskyttet under SOP. Scripts fra ondsinnede nettsider kan få tilgang til den dataen.
Årsaken til at SOP ikke hindrer XSS angrep er fordi scriptet blir sendt fra angriper som benytter nettsiden, og på grunn av manglende input validering vil web serveren tolke det som om det kom fra nettsiden den selv server.
XSS blir oftest delt inn i tre kategorier.
- Reflected XSS
- Persisted (aka Stored) XSS
- DOM (Document Object Model) based XSS
Reflected XSS
Her blir parametere som du sender inn via et input felt embedded i siden og reflektert tilbake til brukeren i responsen. På denne måten kan en angriper lage en ondsinnet URL som han/hun sender til en bruker. Brukeren ser på URL og ser at dette er fra en side som han/hun kjenner og stoler på og trykker derfor på linken. Brukerens nettleser sender en request til den snille siden, men med i requesten er angriperens slemme script. Når requesten når web serveren og sender responsen tilbake til brukeren blir scriptet sendt med som en del av siden. Responsen når brukeren, og fordi scriptet kommer sammen med siden kjøres det i kontekst av siden når det ankommer brukerens browser. Nettleser klarer ikke se at dette er et brudd på SOP (fordi det på en måte ikke er det). Dette JavaScriptet kan være en exploit som utnytter en sårbarhet i brukerens nettleser eller det henter ut informasjon om brukeren fra cookies e.l. og sender til angriper.
Les mer: Hvordan utføre risikoanalyser med fokus på skyløsninger
Persisted XSS
Ved Persisted XSS klarer angriper å få lagret sitt ondsinnede JavaScript i databasen på applikasjonen. Hver gang applikasjonen henter frem data fra denne tabellen vil JavaScriptet trigges. På denne måten trenger ikke en angriper å sende noen egen-utviklede URL til noen bruker. Her vil alle brukere som besøker siden hvor scriptet blir lastet bli offer. Det mest kjente angrepet av denne typen er Samy ormen på MySpace.
DOM Based XSS
I DOM-baserte XSS angrep eksekveres scriptet ved å modifisere DOM-miljøet i brukerens browser. I motsetning til Reflected og Persisted (hvor sårbarheten for XSS er server-side) blir aldri scriptet sendt til serveren og returnert i Responsen. DOM Based XSS kalles også Client-Side XSS. Angrepsvektorer her er å sende en spesiallaget URL til et offer, som ved å trykke på lenken eksekverer skriptet lokalt hos seg.
Hvordan utføre sikkerhetstesting gjennom hele utviklingsløpet? Last ned guide og få konkrete tips:
2. SQL Injection
Sannsynligvis den mest kjente typen av Injection-angrep og helt klart den som rammeverk gir deg mest beskyttelse imot ut av boksen. SQL Injection (SQLi) fungerer når en bruker kan sende inn data i et felt som starter et database-kall i bakgrunnen. Hvis applikasjonen ikke validerer input kan en angriper terminere SQL spørringen og deretter få eksekvert sin egen SQL kode.
Det finnes en flere typer SQLi angrep. De vanligste er:
- Blind based
- Error based
- Union based
- Tautologies
- Stored Procedure based
Blind Based
Denne typen SQLi angrep teppebomber applikasjonen med en rekke TRUE/FALSE utsagn, og benytter feilmeldingene som kommer tilbake til å kartlegge applikasjonen. Benyttes oftest når utviklerne har fulgt med i timen å utstyrt applikasjonen med generiske feilmeldingssider, men har glemt å validere input for å sikre SQL spørringene i bakgrunnen.
Error Based
Angriper starter oftest med ERROR baserte angrep. Her sender man inn SQL spørringer for å se på feilmeldingene man mottar. Disse meldingene vil potensielt fortelle hvilken type database som kjører i bakgrunnen, gi indikasjoner på database strukturen, kunne gi indikasjoner på om databaser, tabeller eller forskjellig data finnes eller ikke. F.eks. vil en ukorrekt SQL spørring ofte returnere raskere enn en korrekt. Slike time-based angrep kan avsløre mye om det bakomforliggende selv om ikke angriperen får se direkte svar. Syntax feil kan avsløre injection parametere, visse feilmeldinger gir indikasjon på datatyper, logiske feil meldinger kan avsløre tabell eller kolonnenavn.
Union Based
Her vil en angriper sende inn parametere som terminerer applikasjonens spørring, deretter kjøre en UNION SELECT etterfulgt av egne parametere. Målet med denne typen SQLi angrep er å hente ut data fra tabeller i databasen som den opprinnelige spørringen ikke prøver å hente ifra. Databasen returnerer først data fra den opprinnelige spørringen, deretter fra den UNION koblede spørringen.
Tautologies
Her sender man inn et statement til WHERE spørringen som alltid vil være sant for å få ut data. Man kan ikke påvirke SQL koden som kommer før parameteret vi sender inn, men man kan enkelt hindre at resten blir kjørt ved å kommentere den ut. Dette er kanskje den meste kjente SQL Injection angrepssnutten; ‘ or 1=1 — . Hvis dette er kode for et login felt som er svakt skrevet, f.eks:
SELECT * FROM users WHERE username = ‘Jack Hackerman’ and password= ‘Amazing!’;
Så vil den første backticken terminere strengen, SQL motoren vil prøve å se om 1=1 er TRUE eller FALSE, og — vil kommentere ut den siste snutten (and password=’…’;).
Ved suksess på et slikt angrep vil spørringen bli
SELECT * FROM users WHERE username=’’ or 1=1;
Og deretter leveres alle brukerne fra tabellen users.
Les mer: 12 mulige trusler når man flytter til skyen
Stored Procedure Based
Her prøver angriperen å trigge lagrede prosedyrer i applikasjonen. Som nevnt tidligere kan informasjon om Stored Procedures komme til syne ved ‘korrekt’ ERROR baserte angrep. Stored procedures kan utsette applikasjonen din for nye angrepsvektorer utover SQLi, som f.eks. command injection (hvis prosedyren gjøre system kall til operativ systemet) eller andre tradisjonelle sårbarheter på OS eller mellomvare nivå. Bare så det er klart; Stored Procedures er ikke en automatisk fix mot SQLi angrep.
3. Command Injection
Ikke lenger så vanlig å finne som de teknikkene som er gjennomgått. Java, PHP og .Net har innebygd beskyttelse for det meste av slike angrepsvektorer i rammeverkene sine, som ligger som et lag mellom applikasjonen og operativsystemet. Men er du en stakkar som sitter med forvaltning på gammal moro, eller du benytter et moderne rammeverk som feilaktig trigger et systemkall, så kan dette være vektorer du må mitigere.
Hvis applikasjonen har funksjonalitet som kjører en OS kommando i bakgrunnen og en angriper kan sende inn data, og input validering ikke er på plass, så kan angriper terminere kommandoen og kjøre sine egne OS kommandoer.
4. Code Injection
En sjelden vektor å finne i dagens landskap av web applikasjoner, men de kan forekomme. Her kan angriperen sende inn kodesnutter i samme språk som applikasjonen er skrevet i. Hvis denne koden blir eksekvert vil den kjøre i samme kontekst som brukeren som sender den inn, eller i samme kontekst av service-brukeren som applikasjonen kjører under. Hvis man kjører flere applikasjoner på samme web-server kan dette ha katastrofale følger for nabo-applikasjoner. Konsekvensen av et vellykket Code Injection angrep er alt fra korruptering av data, data på avveie, ta ned serveren og hindre tilgang, etc. Her er det oftest angripers kreativitet som setter begrensningen. Det er ikke bare input validering som er med på å forhindre dette, men også least-privilege design, og sterk separasjon mellom applikasjonene er viktig.
5.CRLF Injection: HTTP Response Splitting
Ved å modifisere et HTTP parameter eller URL kan angriper sende inn CRLF et sted hvor det ikke er forventet til applikasjonen. Et av de vanligste angrepene med CRLFi er det som kalles HTTP Response Splitting. Her sender en angriper inn CRLF som ikke blir input validert, og applikasjonen inkluderer dataen i HTTP Response headeren. Dette betyr at angriperen kan ta kontroll over resterende HTTP headers og response body som sendes, og angriper kan legge til egne Responser.
Les mer: 8 risikoer ved å benytte Github eller andre kodehus
6. CRLF Injection: Log Injection
Hvis applikasjonen ikke validerer input til både seg selv og log systemet som benyttes kjøres på default format vil applikasjonen potensielt være sårbar for log Injection. Et suksessfullt angrep her vil gjøre det mulig for angripere å injecte ondsinnet data inn i loggene. Dette kan være for å kontaminere logger som gjør at det blir vanskelig for etterforskere å se hva som faktisk har skjedd, og det vil gjøre at loggene potensielt blir ugyldig som bevis i en rettsak, men det kan også være rom for å injecte exploit scripts. Disse exploit scriptene kan være skrevet slik at applikasjonen gjør nettopp det den skal, og så logger inputen. Da denne log meldingen skal parses senere av et log system (eks. Kibana) så eksekveres det ondsinnede scriptet.
7. LDAP Injection
Der hvor applikasjoner lager LDAP uttrykk basert på bruker input kan en angriper, ved bruk av en lokal proxy, modifisere LDAP uttrykkene. Dette kan medføre at angriper kan eksekvere vilkårlige kommandoer eller modifisere data i LDAP treet. Igjen; hoved synderen for at dette fungerer er manglende input validering.
8. XPath Injection
XPath injection forekommer når applikasjonen benytter parametre sendt inn av sluttbruker for å bygge en XPath spørring på XML data. Som SQLi angrep kan ikke angriper kontrollere spørringen som ligger i forkant av input feltet, men, også som i SQLi, vi kan ta kontroll over hva som kommer i input feltet og etterpå. En angriper kan ved XPath injection:
- Se strukturen i XML data
- Få tilgang til XML data bruker normalt ikke har tilgang til
- Privilege escalation – hvis applikasjonen bruker XML data til Autentisering
9. Host Header Injection
I de tilfeller hvor man hoster flere applikasjoner/nettsider på samme host-server (samme IP adresse) og benytter host header for navigering av hvor en bruker skal kan en angriper, ved å sende ondsinnet input i host header, utføre web-cache poisining eller misbruke alternative kanaler for å utføre sensitive operasjoner.
Når en bruker spesifiserer et ugyldig host parameter vil de fleste web servere sende brukeren til den første virtuelle hosten i lista på web serveren. En annen måte å sende manipulert input til Host header er å benytte X-FORWARDED-HOST header. Denne kan i visse konfigurasjoner skrive om i Host verdien.
10. SMTP Header Injection
Applikasjoner som benytter en Form som sender e-post til en mottaker, men som ikke validerer input kan være sårbar for Email Header Injection hvor en angriper kan legge til flere SMTP headers for å manipulere SMTP server til å utføre andre eller flere handlinger enn det den er designet for.
En angriper kan f.eks. legge til en rekke flere mottakere enn det som skal være mulig, og på denne måten sende eposter anonymt. Slike angrep kan benyttes for phishing angrep eller spam mailing.
Guide: Slik utfører du sikkerhetstesting gjennom hele utviklingsløpet
Det har aldri vært mer snakk om sikkerhet i IT verdenen enn nå. Last ned vår guide der vår sikkerhetsekspert, Even Lysen, deler hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.