Filopplastingsmoduler er en av de svakeste leddene i nettapplikasjoner. Eventuelle feil som gjøres, selv de du anser som små, kan føre til at serverkontrollen faller direkte i hendene til en nettangriper. Av denne grunn må programvareutviklere vite de vanligste feilene og noen angrepsmetoder som kan oppstå.
Så hva er tukling på klientsiden? Hvordan kan du bekjempe dette for å holde nettstedene dine og brukerne dine trygge?
Hva er tukling på klientsiden?
Inngrep på klientsiden er det grunnleggende konseptet for nettapplikasjonsangrep som helhet. Enkelt sagt betyr det at du ikke lenger kan stole på noen av dataene du sender til brukeren. I tillegg er tukling på klientsiden et av grunnlaget for sikker applikasjonsutvikling. Hvis du undersøker filopplastingsmodulen du har å gjøre med og vurderer tukling på klientsiden, inkluderer dataene du ikke kan stole på:
- Navnet på den opplastede filen.
- Innholdstypen til den opplastede filen.
Disse to elementene er hvor du har muligheten til å hviteliste som programvareutvikler. Navnedataene til den opplastede filen kan inneholde alt med manipulering på klientsiden. Med Content-Type-dataene til den opplastede filen, selv om angriperen laster opp en .exe-fil, kan denne filen vises som et bilde/jpeg i systemet.
Filutvidelse og hvitlisting
Mens du utvikler filopplastingsmoduler, er det første du må gjøre hvitelisteprosessen for filtypen. For eksempel vil en bruker laste opp en fil med navnet "muo.jpeg". Du må sørge for at denne filtypen som brukeren vil laste opp er .jpeg. For dette bør systemet sjekke den opplastede filen og se om det er en av de tillatte filtypene. For å forstå hvordan du kan gjøre dette, undersøk følgende enkle PHP-kode:
$fil_deler = baneinfo($filnavn);
bytte om($file_parts['utvidelse'])
{
sak "jpg":
gå i stykker;sak "flaggermus": // Eller exe, dll, så osv.
gå i stykker;
sak "":
sakNULL: // Ingen filtype
gå i stykker;
}
Du kan gjøre dette med en kodeblokk som ligner på den ovenfor, eller du kan bruke klassene og funksjonene som tilbys av rammeverket du bruker.
Vær forsiktig så du ikke oppretter filtypedata ved å analysere filnavnet i henhold til prikktegn (.), fordi angriperen kan omgå dette kontrolltrinnet med et filnavn som "muo.jpeg.php".
Hva er innholdstypeinformasjon?
Innholdstypeinformasjon er en del informasjon som sendes i HTTP-forespørselen for hver filopplasting. Nettleseren oppdager denne informasjonen og legger den til den sendte forespørselen. Angriperen kan prøve å endre informasjonen med tukling på klientsiden og omgå valideringer på serversiden. På dette stadiet trenger utviklere en kontrollmekanisme for å foreta valideringer over innholdstypeinformasjonen. Dette alene vil ikke være nok; likevel er det en viktig sak for utviklere å ta hensyn til.
La oss si at du koder en mekanisme for å kontrollere filtypen riktig, og at du bare godtar filer med filtypen .jpeg. I tillegg til denne forsiktighetsmekanismen kan du sjekke innholdstypeinformasjonen bare inn sak og kun godta filer med bilde/jpeg-informasjon, et ekstra beskyttelsesnivå mot nettangrep
SWF Flash-filer og angrepstrinn
Filtypen og Content-Type-data betyr ingenting for nettlesere som støtter plug-ins som Adobe Flash Player. Selv om støtte for den spilleren ikke lenger er tilgjengelig, er det fortsatt mulig å installere de relaterte filene på mange systemer, selv om Flash fortsatt er en sikkerhetsrisiko. I et system som ikke har tatt de relevante forholdsreglene, er det mulig å kalle en Flash-fil med
For å kunne iverksette tiltak, må utviklere vite hvilke veier nettkriminelle kan ta. Slik kan det skje:
- Den ondsinnede angriperen laster opp en SWF (et Adobe Flash-filformat) kalt "image.jpeg" til målnettstedet. Under opplastingsprosessen bekreftes det i godkjenningsverifiseringen at filen lastet opp av angriperen har en .jpeg-utvidelse. Innholdstypebekreftelse omgås med manipulering på klientsiden. Tenk deg at denne filen, lastet opp av trusselaktøren, går til "www (dot) target-site (dot) com/images/images.jpeg".
- La oss si at angriperen har et nettsted kalt attacker (dot) com. Angriperen kaller image.jpeg-filen som er lastet opp til målnettstedet på denne nettsiden, ved å bruke
- En uskyldig bruker logger på angriper (dot) com. Dette nettstedet kaller opp SWF-filen på www (dot) target-site (dot) com/images/image.jpeg og utfører kommandoene gitt til SWF.
- Gjennom dette kan nettangriperen lage HTTP-forespørselshandlinger for target-site (dot) com-adressen uten at vanlige brukere merker det. Med disse forespørslene vil angriperen bruke økten til den uskyldige brukeren og omgå CSRF-sjekken.
For å forstå dette angrepsscenarioet klarere, bør du vurdere følgende kode å være i HTML-en
stil="høyde: 1px; bredde: 1px;" data="www.target-site.com/images/image.jpeg" type="applikasjon/x-shockwave-flash" allowscriptaccess="alltid" flashvars="c=lest&u=noe"
En av de beste løsningene er å få tilgang til filene lastet opp med filopplasting via et annet underdomene. I det nevnte scenariet kan du få tilgang til statiske filer ikke fra samme domene, men fra et annet underdomene som følger: "http (kolon)//file.target-site (dot) com/images/image.jpeg".
En annen løsning er å legge til Innhold-Disposisjon: vedlegg informasjon til HTTP-svaret når du mottar en forespørsel om tilgang til filene du vil laste opp.
Ta forholdsregler for sårbarheter for filopplasting
Enhver filopplasting som brukere kan gjøre til et nettsted er farlig, så dette er et av problemene som utviklere bør være mest oppmerksomme på. Hvis angripere oppdager en slik sårbarhet, kan de åpne et skall på nettstedet og enkelt utnytte informasjonen på serveren. Det er svært viktig å kontrollere alle filer lastet opp av brukere, bruke hvitelistemetoder og skjule plasseringen til den opplastede katalogen hvis mulig.
Og selvfølgelig er det mange andre ekstra skritt du må ta for å beskytte nettstedet ditt, selv om du tar alle de anbefalte forholdsreglene for å laste opp filmoduler. Å bruke HTTP-sikkerhetshoder er et slikt skritt du kan ta.