Webservere hoster de filer (websider, billeder, videoer, formularer osv.), der udgør din webapplikation og serverer disse filer, når nogen besøger din hjemmeside. Nogle servere er mere avancerede og kontrollerer også, hvor meget adgang webbesøgende har. De kan begrænse almindelige besøgende i at få adgang til andre brugeres konti eller administrative dashboards. Selvom webservere er effektive til, hvad de gør - og de gør det ret sikkert - kan angribere udnytte fejl, der opstår som følge af menneskelige fejl eller mangelfuld logik i, hvordan en server betjener de filer, den hoster.
Hvad er et LFI-angreb?
Et Local File Intrusion (LFI)-angreb sker, når angribere udnytter sårbarheder i, hvordan en webserver gemmer, betjener, validerer eller kontrollerer adgangen til sine filer. Denne sårbarhed er fælles for PHP-baserede websteder.
I modsætning til mange former for cyberangreb, hvor angribere er afhængige af malware for at ødelægge en applikation, er angribere i LFI'er mest afhængige af smarte tricks og korte kodelinjer. Dette kræver sjældent sofistikerede værktøjer eller komplekse scripts; angreb sker typisk på webbrowseren. Det mest almindelige trick, som angribere bruger, er at ændre URL-strengen med kode, filstier eller filnavne.
Hvordan sker LFI-angreb?
LFI-angreb sker typisk i fire faser.
Først identificerer angriberen et PHP-websted, der kører en sårbar webapplikation, normalt ved at køre en grundlæggende kode i browserens URL for at se, om webapplikationen (dvs. webstedet) håndterer kommandoen. Tænk på det som at trykke på tastekombinationer på din spilcontroller for at låse et påskeæg op - for eksempel at trykke på ned-tasten for at komme ind i tunneler i Super Mario. Men de kommandoer, som angriberne kører i LFI-angreb, er mere konsekvente end at tjekke hver tunnel i Super Mario.
En webapplikation eller server, der er blevet forkert konfigureret eller undlader at validere input, vil udføre den ondsindede kode. Herfra kan hackeren få den adgang og det privilegium, de har brug for til at læse sårbare filer eller uploade ondsindede filer til serveren.
De fleste LFI-angreb resulterer i, at angriberen får adgang til følsomme oplysninger. Muligheden for at uploade malware er sjældent vellykket, fordi der ikke er nogen garanti for, at webapplikationen gemmer filen på den samme server, hvor LFI-sårbarheden eksisterer. Dette er ofte tilfældet, hvis webapplikationen er i et multi-server miljø.
Så hvis LFI-sårbarheden findes på den server, der er vært for billeder, men ikke den server, der gemmer medarbejderen legitimationsoplysninger eller brugeradgangskoder, ville angriberen kun have adgang til billedfiler på den sårbare server. Uanset hvad, cyberbegivenheder som angrebet på LastPass viser, at hackere kan skabe kaos med tilsyneladende det mest ubetydelige adgangsniveau.
Sådan forhindrer du LFI-angreb
LFI-angreb er ret almindelige, ifølge Åbn Web Application Security Project (OWASP). Forståeligt nok ville hackere favorisere dette angreb, da, som W3Techs rapporter, kører næsten otte ud af 10 websteder PHP som et programmeringssprog på serversiden - en overflod af ofre, så at sige. Det er muligt at forhindre et LFI-angreb ved at vedtage bedste praksis for websikkerhed.
Hvidliste offentlige serverfiler
Webapplikationer bruger ofte filstier som URL-input. Hackere kan udnytte dette arkiveringssystem ved at ændre den del af URL'en, der fungerer som en filsti. For eksempel kan en angriber ændre sig https://dummywebsite.com/?module=contact.php til https://dummywebsite.com/?module=/etc/passwd. En sårbar server med dårlig filtrering og mangelfuld logik vil vise indholdet af filen gemt i stien /etc/passwd.
Selvfølgelig bruger hackere variationer af almindelige filnavne og kombinationer af forespørgselstegn for at øge oddsene for et vellykket angreb. Målet er at narre webapplikationen til at køre et script eller vise filerne på en webserver.
Du kan blokere denne sårbarhed ved at oprette en hvidliste over offentlige dokumenter på din server og instruere webapplikationen til at se bort fra forespørgsler for hvert andet dokument eller filsti. Så hvis en angriber forsøger at manipulere URL'en til at anmode om eller køre koder, der anmoder om en privat, får de en fejlside i stedet for.
Test for sårbarheder ofte
Du kan bruge webscanningsværktøjer at finde og rette sårbarheder, der kan udsætte dig for LFI-angreb. Web-app-scannere er automatiserede værktøjer, der gennemgår din app som en angriber og advarer dig om potentielle sårbarheder. Der er flere open source-webscannere som OpenVAS og Wireshark, men de fleste sårbarhedsscannere er proprietær software og kræver betalte planer for at bruge.
Men du får selvfølgelig ikke en webscanner til kun LFI-angreb. Disse værktøjer leder også efter bredere sikkerhedssårbarheder som ekstern filinkludering, cross-site scripting, SQL-injektion og dårlige serverkonfigurationer. Så de er det værd.
Begræns besøgendes rettigheder
Hackere udfører ofte LFI-angreb med succes, fordi webapplikationer ikke kan opdele brugerrettigheder, og derved tillader besøgende at få adgang til filer, der kun bør være synlige for administratorer. Denne foranstaltning fungerer som whitelisting: Konfigurer din webapplikation og server, så de serverer offentlige filer og ignorerer uautoriserede anmodninger, når en besøgende interagerer med webappen. Dette er især vigtigt for forespørgsler til filstier, der indeholder følsomme filer.
Til dette formål skal du muligvis forhindre filstier i at blive ændret direkte. Webappen bør kun tjene dokumenter fra en hårdkodet stiliste. Konfigurer desuden webappen til at behandle anmodninger med dynamisk stisammenkædning (URL'erne skal indeholde alfanumeriske tegn) i stedet for base64- eller bin2hex-funktioner.
Hvis du overvejer at sortliste filnavne, så lad være. Hackere har normalt en voksende liste over filnavne, de kan bruge til at udføre et LFI-angreb. Desuden er det praktisk talt umuligt (og et kolossalt spild af tid) at sortliste en liste over konstant stigende kilder af angreb.
Brug et multiservermiljø
Et multi-server-miljø lader dig isolere vigtige, følsomme dokumenter fra offentlige filer, hvilket reducerer din risiko i tilfælde af et brud. Dedikerede servere er mindre sårbare over for LFI-angreb, fordi selvom de arbejder sammen, er deres konfigurationer forskellige.
Udover denne sikkerhed er flere servere også pålidelige (med lavere risiko for nedetid), hurtige og effektive. Det er ganske vist ikke omkostningseffektivt at bruge et multiservermiljø, hvis dit websted er lille. Overvej i så fald at opdele din webapplikations adgang til data mellem en database for private data og en server til offentlige filer.
Bør du være bekymret for LFI-angreb?
Muligheden for et LFI-angreb er der, især hvis dit websted kører på PHP, men du kan reducere din eksponering ved at konfigurere webapplikationer og servere i henhold til bedste praksis for websikkerhed.
Desuden bør du overveje at udføre rutinemæssige sikkerhedstjek for at finde sårbarheder. Ting går i stykker hele tiden, især da webstedets arkitektur bliver kompleks. De værktøjer, du skal bruge for at beskytte dig selv, er automatiserede, og mange kræver ikke en omfattende opsætning eller avanceret teknisk knowhow.
