Web14: Beveiligingsproblemen in het HTTP-protocol

Dit artikel presenteert enkele beveiligingsproblemen in het HTTP-protocol , die aan de orde komen in twee documenten RFC 7230 en RFC 7231. In het artikel wordt naar voorbeelden van specifieke fouten verwezen vanuit OWASP.

1. Risico's van intermediaire factoren

HTTP maakt het gebruik van tussenpersonen mogelijk om via een reeks verbindingen op verzoeken te reageren. Er zijn drie gemeenschappelijke intermediaire elementen: proxy, gateway en tunnel.

Een verzoek of antwoord zal via de punten A, B en C moeten gaan. Ze hebben toegang tot gevoelige informatie die wordt verzonden, zoals persoonlijke informatie van gebruikers of organisaties. Het gebrek aan aandacht voor veiligheid en privacy door tussenpersonen kan leiden tot een breed scala aan potentiële aanvallen.

Systeemontwikkelaars en ontwikkelaars moeten rekening houden met privacy- en beveiligingsfactoren tijdens het ontwerp-, coderings- en implementatieproces van het systeem.

Gebruikers moeten zich bewust zijn van de gevaren van het gebruik van niet-vertrouwde proxy's of gateways.

2. Antwoordsplitsing

Het splitsen van reacties (ook wel CRLF-injectie genoemd) is een populaire techniek voor webexploitatie. De aanvaller verzendt gecodeerde gegevens, in sommige verzoekparameters, die vervolgens worden gedecodeerd en herhaald in een bepaald veld van de antwoordheader.

Als deze gegevens een symbool zijn dat het einde van het antwoord vertegenwoordigt en er een volgend antwoord wordt geïnitieerd, wordt het oorspronkelijke antwoord in tweeën gesplitst en wordt de inhoud van het tweede antwoord beheerd door de aanvaller. De aanvaller kan vervolgens binnen dezelfde persistente verbinding nog een verzoek indienen en de ontvanger (inclusief tussenpersonen) laten geloven dat dit tweede antwoord een reactie is op het tweede verzoek.

3. Verzoek om smokkel

Verzoeksmokkel is een techniek die gebruik maakt van verschillen in de verwerking van verzoeken door verschillende soorten servers om ogenschijnlijk onschuldige verzoeken die aan het oorspronkelijke verzoek zijn toegevoegd, te verbergen.

Laten we het volgende voorbeeld bekijken:

Stel dat een POST-verzoek twee “Content-length”-velden in de header bevat met twee verschillende waarden. Sommige servers zullen dit verzoek weigeren (IIS en Apache), maar andere niet. SunONE W/S 6.1 gebruikt bijvoorbeeld eerst het veld Inhoudslengte, terwijl sunONE Proxy 3.6 het veld Inhoudslengte als tweede gebruikt.

Ervan uitgaande dat SITE de DNS is van een SunONE W/S, die zich achter een SunONE Proxy bevindt, bevindt zich een gif.html-bestand op de SunONE W/S. Hier leest u hoe u HTTP Request Suggling kunt misbruiken op basis van inconsistenties in de verwerking tussen twee servers:

[Merk op dat elke regel eindigt met een CRLF (“”), behalve regel 10]

Laten we eens kijken wat er gebeurt als een verzoek via de proxyserver naar W/S wordt verzonden. Eerst analyseert de proxy het verzoek van regel 1 tot en met 7 (blauw) en komt hij twee Content-Length-velden tegen. Zoals hierboven vermeld, negeert het het eerste veld en begrijpt het dat de verzoektekst 44 bytes lang is. Daarom behandelt het de gegevens van de regels 8 tot en met 10 als de eerste verzoektekst (van de regels 8 tot en met 10 zijn de gegevens precies 44 bytes lang). De proxy analyseert vervolgens de regels 11 tot en met 14 (in rood) als het tweede verzoek van de klant.

Laten we nu eens kijken hoe W/S de bovenstaande gegevens interpreteert, zoals deze worden doorgestuurd vanuit de proxy. In tegenstelling tot proxy's zal W/S het eerste Content-Length-veld gebruiken en dit als volgt interpreteren: het eerste verzoek heeft geen hoofdtekst en het tweede verzoek begint vanaf regel 8 (merk op dat W/S vanaf regel 11 zal parseren als de waarde van het Bla-veld).

Laten we vervolgens kijken hoe het antwoord wordt teruggestuurd naar de client. Het verzoek dat W/S begrijpt is “POST /foobar.html” (van regel 1) en “GET /poison.html” (van regel 8), dus het zal de klant twee antwoorden sturen met de inhoud van de foobar-pagina. html en gif.html. De proxy begrijpt dat deze 2 antwoorden overeenkomen met 2 verzoeken: "POST /foobar.html" (van regel 1) en "GET /page_to_poison.html" (regel 11). De proxy slaat de inhoud van de gif.html-pagina op die overeenkomt met de URL “page_to_poison.html” (cachevergiftiging). Van daaruit ontvangt de klant, wanneer hij "page_to_poison.html" opvraagt, de inhoud van de gif.html-pagina.

4. Aanval op basis van bestandspad

Webservers gebruiken vaak hun lokale bestandssysteem om de toewijzing van bestandsnamen in URI's aan daadwerkelijke bronnen op de server te beheren. De meeste bestandssystemen zijn niet ontworpen om bescherming te bieden tegen kwaadaardige bestandspaden. Daarom moet de server de toegang tot belangrijke systeembestanden vermijden.

UNIX, Microsoft Windows en verschillende andere besturingssystemen gebruiken bijvoorbeeld “..” als padelement om een ​​map weer te geven die één niveau boven het huidige bestand/de huidige map ligt. Zonder de juiste invoercontrole en autorisatie kunnen gevoelige bestanden/mappen van het systeem worden benaderd door paden in te voeren die naar deze bestanden/mappen verwijzen.

5. Soorten aanvallen: Commando-injectie, Code-injectie, Query-injectie

[Webservers gebruiken vaak parameters in de URI als invoer om systeemopdrachten en databasequery's uit te voeren. De gegevens die in het verzoek worden ontvangen, kunnen echter niet altijd worden vertrouwd. Een aanvaller kan componenten in het verzoek maken en wijzigen (zoals methoden, velden in de header, body...), om systeemopdrachten uit te voeren, de database te doorzoeken...

SQL-injectie is bijvoorbeeld een veel voorkomende aanval waarbij de webserver parameters in de URI ontvangt die deel uitmaken van de SQL-query. Daarom kan een aanvaller de webserver misleiden om illegale SQL-query's uit te voeren, om zo de database te stelen of te saboteren.
Over het algemeen mogen door gebruikers ingediende gegevens niet rechtstreeks worden gebruikt om bewerkingen op de server uit te voeren. Deze gegevens moeten door filters gaan die bepalen wat geldig en wat ongeldig is, waardoor ongewenste gegevens worden geëlimineerd.

6. Het onthullen van persoonlijke informatie

Clients bevatten vaak veel persoonlijke informatie, waaronder informatie die door de gebruiker wordt verstrekt om met de server te communiceren (zoals gebruikersnaam, wachtwoord, locatie, e-mailadres, enz.) en informatie over de surfactiviteiten van de gebruiker (geschiedenis, bladwijzers, enz.). Bij de implementatie moet aandacht worden besteed aan het voorkomen van punten die deze privé-informatie kunnen onthullen.

7. Gevoelige informatie onthullen in de URI

URI's zijn per definitie bedoeld om met alle gebruikers te worden gedeeld en zijn niet gegarandeerd veilig. URI's worden vaak weergegeven in de broncode van de website en worden zonder beschermingsmechanismen opgeslagen in bladwijzers. Daarom is het onveilig als de URI gevoelige informatie, persoonlijke informatie, enz. bevat.

Vermijd het gebruik van de GET-methode om persoonlijke informatie naar de server te verzenden, aangezien deze in de URI wordt weergegeven. Gebruik in plaats daarvan de POST-methode.

8. Onthulling van gebruikte software-informatie

De velden User-Agent, Via, Server in de header geven doorgaans informatie over de software die door de afzender wordt gebruikt. In theorie kunnen aanvallers hierdoor gemakkelijker misbruik maken van bekende kwetsbaarheden in deze software.