Scanner voor gevaarlijke HTTP-methoden

Hoe deze controle werkt

Scanaris stuurt een OPTIONS-verzoek naar de gescande URL, zonder omleidingen te volgen, en leest twee antwoordheaders: Allow, waarmee een server aangeeft welke methoden hij op die route accepteert, en Access-Control-Allow-Methods, die van CORS. Als een van beide TRACE, TRACK, PUT, DELETE of CONNECT vermeldt, opent hij een bevinding met lage ernst en de lijst. Het is een voorzichtige controle: hij meldt alleen wat de server expliciet aankondigt. Hij stuurt nooit een test-PUT of -DELETE, en als de server niet antwoordt op de OPTIONS of die headers niet teruggeeft, is er geen bevinding.

Waarom dit belangrijk is

Een normale website heeft GET, HEAD, POST en, voor CORS, OPTIONS nodig. De rest zijn methoden met een geschiedenis. TRACE stuurt het verzoek precies terug zoals het binnenkwam, headers inbegrepen; gecombineerd met een andere fout kun je daarmee cookies lezen die als HttpOnly gemarkeerd zijn (de aanval heet Cross-Site Tracing). PUT en DELETE maken, vervangen of verwijderen bronnen: op een verkeerd geconfigureerde bestandsserver uploadt een PUT een bestand naar de openbare map. CONNECT maakt van de server een proxy. Dat ze aan staan betekent niet dat ze zonder authenticatie werken, vandaar de lage ernst; maar ze aankondigen zonder ze te gebruiken is gratis aanvalsoppervlak.

Hoe je het oplost

• Apache: TraceEnable Off in de hoofdconfiguratie (TRACE staat in oudere versies standaard aan). Voor de rest, binnen de Directory of Location van je site: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: implementeert TRACE niet. Om de rest te beperken in een location-blok: limit_except GET POST HEAD OPTIONS { deny all; }. Gebruik je if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, zet het dan op server-niveau.
• IIS: de WebDAV-module is de gebruikelijke reden dat PUT en DELETE worden aangekondigd. Verwijder hem als je hem niet gebruikt, en beperk in web.config de werkwoorden met requestFiltering/verbs.
• Express en API's: gebruikt je API PUT of DELETE met authenticatie, dan is het legitiem dat Access-Control-Allow-Methods ze vermeldt; wat hij niet moet doen, is ze voor de hele site vermelden of * gebruiken. Zet in de CORS-middleware methods: ['GET', 'POST'] op openbare routes en verruim alleen waar nodig.
• Vercel, Netlify, Cloudflare Pages: kondigen deze methoden standaard niet aan. Verschijnt de bevinding, dan komt die meestal van een CORS-header die je zelf met de volledige lijst hebt geconfigureerd.

Controleer of het opgelost is

curl -si -X OPTIONS https://jouwdomein.nl | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://jouwdomein.nl | head -1

In de eerste mogen Allow en Access-Control-Allow-Methods op openbare routes geen TRACE, TRACK, PUT, DELETE of CONNECT bevatten. De tweede moet 405 of 403 teruggeven, nooit 200 met je verzoek weerspiegeld in de body.

Veelgestelde vragen

Mijn REST API gebruikt PUT en DELETE. Moet ik ze verwijderen?

Nee. Wat telt, is dat die routes authenticatie vereisen en dat de CORS-header ze niet aankondigt voor het hele domein of voor elke origin. Richt de scan zich op de root van je API, dan kun je de bevinding met lage ernst als geaccepteerd markeren zodra je dat hebt gecontroleerd. De configuratie van origins wordt nagekeken door permissieve CORS.

Access-Control-Allow-Methods noemt methoden, maar er is geen Allow. Is dat hetzelfde?

Niet helemaal. Allow beschrijft wat de server accepteert; de CORS-header beschrijft wat hij toestaat aan pagina's van andere origins. Beide worden gelezen omdat beide informatie zijn die je weggeeft. Wat elk deel van een CORS-antwoord betekent, wordt uitgelegd in verkeerd geconfigureerde CORS.

Waarom wordt OPTIONS niet als gevaarlijk beschouwd?

Omdat het de methode is waarmee de browser vóór bepaalde verzoeken naar CORS vraagt. Hem blokkeren breekt aanroepen tussen domeinen. Hij is onschadelijk en noodzakelijk.