Begin met twee dingen te scheiden die tegelijk veranderden: het netwerkpad en de handhaving door de browser. Een VPN verandert het uitgangsadres; hij verandert niet de origin van de pagina, die uit schema, host en poort bestaat. Als het verzoek nu slaagt, is er iets in de respons veranderd, of het verzoek zelf is veranderd. Uitzoeken wat van beide het is, vormt het hele onderzoek.

CORS is een headerprotocol dat de browser handhaaft, dus niets op het netwerkpad kan het uitzetten.

De origin is geen IP-adres

Een origin is een schema, een host en een poort. Het is niet het adres waarvan pakketten vertrekken, en het is niet het IP dat de server ziet. Daarom kan een VPN elk waarneembaar adres veranderen en de origin gelijk laten. De browser vergelijkt de Access-Control-Allow-Origin van de respons met de origin van de pagina, en het uitgangsadres komt nooit in die vergelijking terecht.

Een extensie of proxy die een CORS-fout lijkt te verhelpen, doet dus iets anders: hij herschrijft headers of routeert het verzoek zodat het niet langer cross-origin is. Geen van beide is een eigenschap van de VPN.

Wat de browser werkelijk verstuurt

Bij een cross-origin verzoek dat niet eenvoudig is, stuurt de browser eerst een preflight OPTIONS, met de bedoelde methode en headers. De server moet antwoorden met de permissies die hij toestaat, en het echte verzoek volgt alleen als dat antwoord aan de regels voldoet. Een VPN verandert het pad dat beide uitwisselingen draagt en kan veranderen wat tussenliggende diensten antwoorden. Hij verandert niet de origin-string of de preflight-eis.

Een commandoregelclient toont daar meestal niets van. Hij stuurt mogelijk geen Origin-header, slaat de preflight vaak over en kan andere inloggegevens dragen. Een body die aan curl wordt teruggegeven, bewijst dat de server curl heeft geantwoord.

Vind de respons die veranderde

Vergelijk de werkelijke respons via elk pad, niet alleen de statuscode. Kijk naar de headers met CORS-permissies, het inhoudstype, elke omleiding, en of een WAF- of CDN-variant een andere pagina heeft opgeleverd. Een regionale weigering, een authenticatie-omleiding of een foutpagina zonder de permissieheader falen allemaal in de browser terwijl ze op een CORS-bug lijken. Dat zijn verschillen in het leveringspad, en dat is wat gedocumenteerd moet worden.

Leg de responsheaders van beide paden vast en vergelijk ze regel voor regel. Als het enige verschil de ontbrekende Access-Control-Allow-Origin op één foutpagina is, heb je de oorzaak gevonden.

Repareer de dienst, niet de handhaving

Als de dienst van jou is, noem dan de toegestane origins en verzoekfuncties expliciet, en lees daarna de fouten die de frontend en de tussenlagen produceren. Als je dat niet doet, stuur de diensteigenaar dan een opgeschoonde vergelijking. Neem nooit cookies, autorisatieheaders of sessie-exports op in dat rapport, want dat zijn de inloggegevens die het beleid beoogt te beschermen.

Vermijd browserextensies die CORS uitzetten. Ze veranderen de beveiligingsgrens terwijl ze het responsverschil verbergen dat uitgelegd had moeten worden, en ze laten dezelfde fout staan voor elke andere gebruiker.

Leg beide responsen vast, de gebruikte origin en het gevolgde pad. Dat verslag maakt van een VPN-gerucht een dienstfout.

Gerelateerde artikelen