Problemet med webapplikationer er, at de åbenlyst er eksponeret for milliarder af internetbrugere, hvoraf mange vil bryde deres sikkerhedsforanstaltninger – uanset årsagerne.
I internettets tidlige dage var en af de mest almindelige angrebsmetoder grundlæggende, simpel brute force. Bots udførte normalt disse angreb – eller personer med masser af fri – som prøvede zillioner af kombinationer af brugernavne og adgangskoder, indtil de fandt et, der ville give adgang til målapplikationen.
Brute force-angreb er ikke længere en trussel, takket være adgangskodepolitikker, begrænsede loginforsøg og captchas. Men cyberkriminelle elsker at opdage nye bedrifter og bruge dem til at udføre nye typer angreb. For længe siden opdagede de, at tekstfelter på applikationer eller websider kunne udnyttes ved at indtaste – eller injicere – uventet tekst i dem, som ville tvinge applikationen til at gøre noget, den ikke skulle. På den måde kom de såkaldte injektionsangreb ind på stedet.
Injektionsangreb kan bruges ikke kun til at logge ind på en applikation uden at kende brugernavn og adgangskode, men også til at afsløre private, fortrolige eller følsomme oplysninger eller endda til at kapre en hel server. Derfor er disse angreb ikke kun en trussel mod webapplikationer, men også for de brugere, hvis data ligger på disse applikationer, og i værste tilfælde mod andre forbundne applikationer og tjenester.
Indholdsfortegnelse
Kode indsprøjtning
Kodeinjektion er en af de mest almindelige former for injektionsangreb. Hvis angribere kender programmeringssproget, rammerne, databasen eller operativsystemet, der bruges af en webapplikation, kan de injicere kode via tekstindtastningsfelter for at tvinge webserveren til at gøre, hvad de vil.
Disse typer af injektionsangreb er mulige på applikationer, der mangler inputdatavalidering. Hvis et tekstindtastningsfelt lader brugere indtaste, hvad de vil, så kan applikationen potentielt udnyttes. For at forhindre disse angreb skal applikationen begrænse så meget som muligt, at inputbrugerne får lov til at komme ind.
For eksempel skal den begrænse mængden af forventede data, kontrollere dataformatet, før det accepteres, og begrænse antallet af tilladte tegn.
Kodeindsprøjtningssårbarhederne kan være nemme at finde, blot ved at teste tekstinputtet i en webapplikation med forskellige typer indhold. Når de findes, er sårbarhederne moderat svære at udnytte. Men når en angriber formår at udnytte en af disse sårbarheder, kan virkningen omfatte tab af fortrolighed, integritet, tilgængelighed eller applikationsfunktionalitet.
SQL-injektion
På samme måde som kodeinjektion indsætter dette angreb et SQL-script – det sprog, der bruges af de fleste databaser til at udføre forespørgselsoperationer – i et tekstindtastningsfelt. Scriptet sendes til applikationen, som udfører det direkte på sin database. Som et resultat heraf kunne angriberen passere gennem en login-skærm eller gøre mere farlige ting, såsom at læse følsomme data direkte fra databasen, ændre eller ødelægge databasedata eller udføre admin-handlinger på databasen.
PHP- og ASP-applikationer er tilbøjelige til SQL-injektionsangreb på grund af dets ældre funktionelle grænseflader. J2EE og ASP.Net apps er normalt mere beskyttet mod disse angreb. Når en SQL-indsprøjtningssårbarhed er fundet – og de kunne let findes – vil omfanget af de potentielle angreb kun være begrænset af angriberens dygtighed og fantasi. Således er virkningen af et SQL-injektionsangreb uden tvivl høj.
Kommandoindsprøjtning
Disse angreb er også mulige, primært på grund af utilstrækkelig inputvalidering. De adskiller sig fra kodeinjektionsangreb ved, at angriberen indsætter systemkommandoer i stedet for stykker programmeringskode eller scripts. Derfor behøver hackeren ikke at kende det programmeringssprog, som applikationen er baseret på, eller det sprog, der bruges af databasen. Men de skal kende det operativsystem, der bruges af hostingserveren.
De indsatte systemkommandoer udføres af værtsoperativsystemet med applikationens privilegier, hvilket kan give mulighed for at afsløre indholdet af vilkårlige filer, der ligger på serveren, til at vise mappestrukturen på en server, til at ændre brugeradgangskoder, blandt andet .
Disse angreb kan forhindres af en sysadmin ved at begrænse systemadgangsniveauet for de webapplikationer, der kører på en server.
Cross-site scripting
Når et program indsætter input fra en bruger i det output, det genererer, uden at validere eller kode det, giver det mulighed for en angriber at sende ondsindet kode til en anden slutbruger. Cross-Site Scripting (XSS)-angreb udnytter disse muligheder til at injicere ondsindede scripts på betroede websteder, som i sidste ende sendes til andre brugere af applikationen, som bliver angriberens ofre.
Ofrenes browser vil udføre det ondsindede script uden at vide, at det ikke bør stole på. Derfor vil browseren give den adgang til sessionstokens, cookies eller følsomme oplysninger gemt af browseren. Hvis de er programmeret korrekt, kan scripts endda omskrive indholdet af en HTML-fil.
XSS-angreb kan generelt opdeles i to forskellige kategorier: lagret og reflekteret.
I lagrede XSS-angreb ligger det ondsindede script permanent på målserveren, i et meddelelsesforum, i en database, i en besøgslog osv. Offeret får det, når dets browser anmoder om de lagrede oplysninger. I reflekterede XSS-angreb afspejles det ondsindede script i et svar, der inkluderer input sendt til serveren. Dette kan for eksempel være en fejlmeddelelse eller et søgeresultat.
XPath injektion
Denne type angreb er mulig, når en webapplikation bruger oplysninger leveret af en bruger til at bygge en XPath-forespørgsel til XML-data. Måden disse angreb fungerer på ligner SQL-injektion: Angribere sender forkert udformet information til applikationen for at finde ud af, hvordan XML-dataene er struktureret, og så angriber de igen for at få adgang til disse data.
XPath er et standardsprog, som du ligesom SQL kan angive de attributter, du vil finde. For at udføre en forespørgsel på XML-data bruger webapplikationer brugerinput til at indstille et mønster, som dataene skal matche. Ved at sende forkerte input kan mønsteret blive til en operation, som angriberen ønsker at anvende på dataene.
I modsætning til hvad der sker med SQL, er der i XPath ingen forskellige versioner. Dette betyder, at XPath-injektion kan udføres på enhver webapplikation, der bruger XML-data, uanset implementeringen. Det betyder også, at angrebet kan automatiseres; Derfor har den, i modsætning til SQL-injektion, potentialet til at blive affyret mod et vilkårligt antal mål.
Mail kommando indsprøjtning
Denne angrebsmetode kan bruges til at udnytte e-mail-servere og applikationer, der bygger IMAP- eller SMTP-sætninger med ukorrekt valideret brugerinput. Lejlighedsvis har IMAP- og SMTP-servere ikke stærk beskyttelse mod angreb, som det ville være tilfældet med de fleste webservere, og de kan derfor være mere udnyttelige. Angribere, der går ind gennem en mailserver, kan undgå begrænsninger såsom captchas, et begrænset antal anmodninger osv.
For at udnytte en SMTP-server skal angribere have en gyldig e-mail-konto for at sende beskeder med indsatte kommandoer. Hvis serveren er sårbar, vil den reagere på angribernes anmodninger, hvilket giver dem mulighed for for eksempel at tilsidesætte serverbegrænsninger og bruge dens tjenester til at sende spam.
IMAP-injektion kunne hovedsageligt udføres på webmail-applikationer ved at udnytte meddelelseslæsningsfunktionaliteten. I disse tilfælde kan angrebet udføres ved blot at indtaste en URL med de injicerede kommandoer i adresselinjen i en webbrowser.
CRLF injektion
Indsættelsen af vognretur- og linjeskifttegn – en kombination kendt som CRLF – i webformularinputfelter repræsenterer en angrebsmetode kaldet CRLF-injektion. Disse usynlige tegn angiver slutningen af en linje eller slutningen af en kommando i mange traditionelle internetprotokoller, såsom HTTP, MIME eller NNTP.
For eksempel kan indsættelsen af en CRLF i en HTTP-anmodning, efterfulgt af en bestemt HTML-kode, sende brugerdefinerede websider til de besøgende på et websted.
Dette angreb kan udføres på sårbare webapplikationer, der ikke anvender den korrekte filtrering på brugerinput. Denne sårbarhed åbner døren til andre typer injektionsangreb, såsom XSS og kodeinjektion, og kan også udledes af, at et websted bliver kapret.
Host Header-indsprøjtning
På servere, der hoster mange websteder eller webapplikationer, bliver værtsheaderen nødvendig for at bestemme, hvilke af de hjemmehørende websteder eller webapplikationer – hver af dem kendt som en virtuel vært – der skal behandle en indgående anmodning. Værdien af overskriften fortæller serveren, til hvilken af de virtuelle værter der skal sende en anmodning. Når serveren modtager en ugyldig værtsheader, sender den normalt den til den første virtuelle vært på listen. Dette udgør en sårbarhed, som angribere kan bruge til at sende vilkårlige værtsheadere til den første virtuelle vært på en server.
Manipulation af værtsheaderen er almindeligvis relateret til PHP-applikationer, selvom det også kan udføres med andre webudviklingsteknologier. Host header-angreb fungerer som enablere for andre typer angreb, såsom web-cache-forgiftning. Dets konsekvenser kan omfatte udførelse af følsomme operationer af angriberne, for eksempel nulstilling af adgangskode.
LDAP injektion
LDAP er en protokol designet til at lette søgningen af ressourcer (enheder, filer, andre brugere) i et netværk. Det er meget nyttigt til intranet, og når det bruges som en del af et single sign-on system, kan det bruges til at gemme brugernavne og adgangskoder. LDAP-forespørgsler involverer brug af specielle kontroltegn, der påvirker dets kontrol. Angribere kan potentielt ændre den tilsigtede adfærd for en LDAP-forespørgsel, hvis de kan indsætte kontroltegn i den.
Igen er rodproblemet, der muliggør LDAP-injektionsangreb, forkert valideret brugerinput. Hvis den tekst, en bruger sender til en applikation, bruges som en del af en LDAP-forespørgsel uden at rense den, kan forespørgslen ende med at hente en liste over alle brugere og vise den til en angriber, blot ved at bruge en stjerne
på det rigtige sted inde i en inputstreng.
Forebyggelse af injektionsangreb
Som vi så i denne artikel, er alle injektionsangreb rettet mod servere og applikationer med åben adgang til enhver internetbruger. Ansvaret for at forhindre disse angreb er fordelt mellem applikationsudviklere og serveradministratorer.
Applikationsudviklere skal kende de risici, der er forbundet med forkert validering af brugerinput og lære bedste praksis til at rense brugerinput med risikoforebyggende formål. Serveradministratorer skal revidere deres systemer med jævne mellemrum for at opdage sårbarheder og rette dem så hurtigt som muligt. Der er mange muligheder for at udføre disse revisioner, enten on-demand eller automatisk.