Modules voor het uploaden van bestanden zijn een van de zwakste schakels in webapplicaties. Alle gemaakte fouten, zelfs kleine, kunnen ertoe leiden dat de servercontrole rechtstreeks in de handen van een cyberaanvaller valt. Om deze reden moeten softwareontwikkelaars de meest voorkomende fouten en enkele aanvalsmethoden kennen die kunnen optreden.
Dus wat is geknoei aan de clientzijde? Hoe kunt u dit bestrijden om uw sites en uw gebruikers veilig te houden?
Wat is sabotage aan de clientzijde?
Client-side sabotage is het basisconcept van webapplicatie-aanvallen als geheel. Simpel gezegd betekent dit dat u de gegevens die u naar de gebruiker stuurt niet langer kunt vertrouwen. Bovendien is sabotage aan de clientzijde een van de fundamenten van veilige applicatie-ontwikkeling. Als u de module voor het uploaden van bestanden waar u mee bezig bent onderzoekt en overweegt om aan de clientzijde te knoeien, zijn de gegevens die u niet kunt vertrouwen:
- De naam van het geüploade bestand.
- Het inhoudstype van het geüploade bestand.
Deze twee items zijn waar je hebt de mogelijkheid om op de witte lijst te zetten als softwareontwikkelaar. De naamgegevens van het geüploade bestand kunnen van alles bevatten met geknoei aan de clientzijde. Met de Content-Type-gegevens van het geüploade bestand, zelfs als de aanvaller een .exe-bestand uploadt, kan dit bestand verschijnen als een afbeelding/jpeg in het systeem.
Bestandsextensie en witte lijst
Bij het ontwikkelen van modules voor het uploaden van bestanden is het eerste wat u moet doen het whitelisting-proces voor de bestandsextensie. Een gebruiker wil bijvoorbeeld een bestand met de naam "muo.jpeg" uploaden. U moet ervoor zorgen dat de bestandsextensie die de gebruiker wil uploaden .jpeg is. Hiervoor moet het systeem het geüploade bestand controleren en kijken of het een van de toegestane bestandsextensies is. Bekijk de volgende eenvoudige PHP-code om te begrijpen hoe u dit kunt doen:
$file_parts = pathinfo($bestandsnaam);
schakelaar($file_parts['extensie'])
{
geval "jpg":
pauze;geval "knuppel": // Of exe, dll, dus, enz.
pauze;
geval "":
gevalNUL: // Geen bestandsextensie
pauze;
}
U kunt dit doen met een codeblok dat lijkt op het bovenstaande, of u kunt de klassen en functies gebruiken die worden geboden door het framework dat u gebruikt.
Pas op dat u geen bestandsextensiegegevens maakt door de bestandsnaam te parseren volgens het puntteken (.), omdat de aanvaller deze controlestap kan omzeilen met een bestandsnaam zoals "muo.jpeg.php".
Wat is inhoudstype-informatie?
Informatie over het inhoudstype is een stuk informatie dat wordt verzonden in het HTTP-verzoek voor elke bestandsupload. De internetbrowser detecteert deze info en voegt deze toe aan het verzonden verzoek. De aanvaller kan proberen de informatie te wijzigen door aan de clientzijde te knoeien en validaties aan de serverzijde te omzeilen. In dit stadium hebben ontwikkelaars een controlemechanisme nodig om validaties uit te voeren over de informatie over het inhoudstype. Dit alleen zal niet genoeg zijn; toch is het een belangrijk punt voor ontwikkelaars om op te letten.
Stel dat u een mechanisme codeert om de bestandsextensie correct te controleren, en u accepteert alleen bestanden met de extensie .jpeg. Naast dit voorzorgsmechanisme kunt u de informatie over het inhoudstype gewoon controleren case en accepteer alleen bestanden met afbeelding/jpeg-informatie, een extra niveau van bescherming tegen cyberaanvallen
SWF Flash-bestanden en aanvalsstappen
De bestandsextensie en Content-Type-gegevens betekenen niets voor internetbrowsers die plug-ins zoals Adobe Flash Player ondersteunen. Hoewel ondersteuning voor die speler niet langer beschikbaar is, is het nog steeds mogelijk om die gerelateerde bestanden op veel systemen te installeren, ook al blijft Flash een veiligheidsrisico. In een systeem dat niet de relevante voorzorgsmaatregelen heeft genomen, is het mogelijk om een Flash-bestand aan te roepen met de
Om actie te kunnen ondernemen, moeten ontwikkelaars weten welke wegen cybercriminelen kunnen volgen. Hier is hoe het kan gebeuren:
- De kwaadwillende aanvaller uploadt een SWF (een Adobe Flash-bestandsindeling) met de naam "image.jpeg" naar de doelwebsite. Tijdens het uploadproces wordt in de whitelisting-verificatie bevestigd dat het door de aanvaller geüploade bestand een .jpeg-extensie heeft. Verificatie van het inhoudstype wordt omzeild door knoeien aan de clientzijde. Stel je voor dat dit bestand, geüpload door de bedreigingsactor, naar "www (dot) target-site (dot) com/images/images.jpeg" gaat.
- Stel dat de aanvaller een website heeft met de naam aanvaller (dot) com. De aanvaller roept het image.jpeg-bestand op dat is geüpload naar de doelsite op deze website met behulp van de
- Een onschuldige gebruiker logt in op aanvaller (dot) com. Die site roept het SWF-bestand op www (dot) target-site (dot) com/images/image.jpeg op en voert de opdrachten uit die aan de SWF zijn gegeven.
- Hierdoor kan de cyberaanvaller HTTP-verzoekacties maken voor het target-site (dot) com-adres zonder dat normale gebruikers het merken. Met deze verzoeken zal de aanvaller de sessie van de onschuldige gebruiker gebruiken en omzeilen de CSRF-controle.
Om dit aanvalsscenario beter te begrijpen, moet u overwegen dat de volgende code in de HTML staat
stijl="hoogte: 1px; breedte: 1px;" gegevens="www.target-site.com/images/image.jpeg" type="applicatie/x-shockwave-flash" allowscriptaccess="altijd" flashvars="c=lezen&u=iets"
Een van de beste oplossingen is om toegang te krijgen tot de bestanden die zijn geüpload met bestandsupload via een ander subdomein. In het bovengenoemde scenario hebt u als volgt toegang tot statische bestanden die niet afkomstig zijn van hetzelfde domein, maar van een ander subdomein: "http (dubbele punt)//file.target-site (dot) com/images/image.jpeg".
Een andere oplossing is toevoegen Inhoud-dispositie: gehechtheid informatie naar het HTTP-antwoord wanneer u een verzoek ontvangt voor toegang tot de bestanden die u wilt uploaden.
Neem voorzorgsmaatregelen voor kwetsbaarheden bij het uploaden van bestanden
Elke bestandsupload die gebruikers naar een website kunnen maken, is gevaarlijk, dus dit is een van de problemen waar ontwikkelaars de meeste aandacht aan moeten besteden. Als aanvallers zo'n kwetsbaarheid ontdekken, kunnen ze een shell binnen de site openen en gemakkelijk de informatie op de server misbruiken. Het is van vitaal belang om alle bestanden die door gebruikers zijn geüpload te controleren, whitelist-methoden toe te passen en de locatie van de geüploade map indien mogelijk te verbergen.
En natuurlijk zijn er nog vele andere aanvullende stappen die u moet nemen om uw site te beschermen, zelfs als u alle geadviseerde voorzorgsmaatregelen neemt om bestandsmodules te uploaden. Het gebruik van HTTP-beveiligingsheaders is zo'n stap die u kunt nemen.
