Onveilige HTTP-methodes toegestaan

Een webserver accepteert standaard een ruimer aanbod aan HTTP-methodes dan de applicatie erachter gebruikt. Dat is zelden een acuut probleem en vaak een aanwijzing: het verschil tussen wat er is ingesteld en wat er nodig is, zegt iets over hoe zorgvuldig de omgeving is ingericht. Hieronder leest u welke methodes ertoe doen en waar ze wél tot iets ernstigers leiden.

Welke methodes zijn er en welke horen uit?

HTTP kent een aantal methodes met elk een eigen bedoeling. GET haalt op, POST verstuurt, PUT en DELETE schrijven en verwijderen, HEAD vraagt alleen de headers op, OPTIONS vertelt wat er is toegestaan en TRACE weerkaatst het ontvangen verzoek.

Van onveilige HTTP-methodes spreken we wanneer de server methodes accepteert die de applicatie niet gebruikt. Dat is geen kwetsbaarheid op zichzelf, maar het vergroot het aanvalsoppervlak zonder enige tegenprestatie. Elke methode die is ingeschakeld, is een gedrag dat iemand kan onderzoeken en waarvan de afhandeling ergens is geïmplementeerd, soms door uw applicatie, soms door de webserver, soms door een module waarvan u het bestaan niet kende.

Denk aan een gebouw met deuren naar ruimtes die niemand gebruikt. Op zichzelf gebeurt er niets. Al u moet ze wel allemaal op slot houden, en dat is een taak die u zichzelf ook had kunnen besparen.

Waartoe leiden onveilige HTTP-methodes?

Kwetsbaar:

OPTIONS / HTTP/1.1
Host: portaal.example

HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, PATCH

Dit antwoord geeft in één regel prijs wat er allemaal openstaat. TRACE weerkaatst het verzoek volledig, inclusief alle headers die tussenliggende proxy’s hebben toegevoegd:

TRACE / HTTP/1.1
Host: portaal.example

HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: portaal.example
X-Forwarded-For: 10.0.4.12
X-Internal-Route: cluster-b-node3
Cookie: sid=8f42c19ade7b3f5c

De interne netwerkstructuur en de routeringsheaders van uw infrastructuur staan nu in het antwoord. Ernstiger wordt het wanneer PUT daadwerkelijk is geïmplementeerd door een module van de webserver in plaats van door uw applicatie:

PUT /uploads/shell.jsp HTTP/1.1
Host: portaal.example
Content-Length: 51

<% Runtime.getRuntime().exec(request.getParameter("c")); %>

Bij een verkeerd geconfigureerde server met schrijfrechten op die map is dit een rechtstreekse route naar code-uitvoering. Dat is zeldzaam, maar het komt voor bij oudere installaties en bij standaardconfiguraties die nooit zijn dichtgezet.

Veilig:

# Alleen wat de applicatie gebruikt
location / {
    limit_except GET POST {
        deny all;
    }
    proxy_pass http://applicatie;
}

// En in de applicatie zelf, per route expliciet
app.route('/api/facturen/:id')
  .get(vereistLogin, toonFactuur)
  .put(vereistLogin, wijzigFactuur)
  .all((req, res) => res.status(405).set('Allow', 'GET, PUT').send());

De webserver laat alleen door wat nodig is, en de applicatie antwoordt op alles wat daarbuiten valt met een 405 en een correcte Allow-header. Dat laatste is netjes én informatief zonder te veel prijs te geven: er staat wat dit endpoint ondersteunt, niet wat de server in het algemeen aankan.

Wat is de impact van onveilige HTTP-methodes?

De ernst is doorgaans laag, en dat weerspiegelt de werkelijkheid: in de meeste gevallen gaat het om overbodige functionaliteit zonder direct misbruik. Er zijn twee situaties waarin dat verandert.

De eerste is een schrijvende methode die daadwerkelijk werkt. Kan er via PUT een bestand op de server worden geplaatst, dan is de impact vergelijkbaar met een onbeperkte bestandsupload en dus hoog. Dat vraagt een specifieke combinatie van een ingeschakelde module en schrijfrechten, maar die combinatie bestaat in de praktijk.

De tweede is het omzeilen van toegangscontrole. Zijn er beperkingen die per methode zijn opgeschreven, dan kan een afwijkende methode eromheen. Een bekend patroon is een beheerpagina die voor GET is afgeschermd maar via HEAD of een onbekende methode alsnog wordt verwerkt door de applicatie erachter.

Daarnaast is er de informatiewaarde. Wat een OPTIONS-antwoord en een uitgebreid methodeaanbod vooral verraden, is dat de omgeving op standaardinstellingen draait. Voor een aanvaller is dat een aanwijzing dat er waarschijnlijk meer niet is dichtgezet.

Hoe spoor je onveilige HTTP-methodes op?

Een tester vraagt met OPTIONS op welke methodes de server zegt te ondersteunen, en controleert dat vervolgens in de praktijk: de opgegeven lijst en het werkelijke gedrag lopen namelijk regelmatig uiteen. Elke methode wordt afzonderlijk geprobeerd om te zien welke een zinvol antwoord geeft in plaats van een 405.

Bij TRACE wordt gekeken of het verzoek wordt weerkaatst en of daar headers in staan die door tussenliggende systemen zijn toegevoegd. Bij PUT en DELETE wordt voorzichtig getoetst of ze daadwerkelijk iets schrijven of verwijderen. Verder worden onbekende en verzonnen methodes geprobeerd, omdat sommige servers die doorgeven aan de applicatie zonder ze te beperken: een bekende manier om toegangsregels te omzeilen. Ook wordt gekeken naar mechanismen voor method override via een header of parameter. AssistSec test daarbij expliciet of een afgeschermde route met een afwijkende methode alsnog bereikbaar is, omdat dat het scenario is waarin deze bevinding van hardening naar echte toegangscontrole verschuift.

Hoe voorkom je onveilige HTTP-methodes?

• Sta op elke route alleen de methodes toe die de applicatie werkelijk gebruikt.
• Schakel TRACE uit; er is geen productietoepassing voor.
• Schakel PUT en DELETE uit op de webserver wanneer alleen uw applicatie ze afhandelt.
• Definieer toegangsregels op basis van wat is toegestaan, nooit als een lijst van uitzonderingen.
• Antwoord op niet-ondersteunde methodes met 405 en een correcte Allow-header voor dat endpoint.
• Laat OPTIONS alleen de methodes noemen die op dat endpoint bestaan.
• Schakel method override via headers of parameters uit wanneer u het niet nodig hebt.
• Controleer of de beperkingen ook gelden achter een reverse proxy, loadbalancer of CDN.
• Herhaal de controle na een servermigratie, omdat standaardconfiguraties dan terugkeren.