A VPN nem tudja kikapcsolni a CORS-t, a választ változtatja meg

Kezdje két dolog szétválasztásával, amelyek egyszerre változtak meg: a hálózati útvonal és a böngésző érvényesítése. A VPN megváltoztatja a kilépési címet; nem változtatja meg az oldal origóját, amely sémából, hosztból és portból áll. Ha a kérés most sikeres, valami megváltozott a válaszban, vagy maga a kérés változott meg. Annak kiderítése, hogy melyik, az egész vizsgálat.

A CORS egy fejlécprotokoll, amelyet a böngésző érvényesít, ezért a hálózati útvonalon semmi sem kapcsolhatja ki.

Az origó nem IP-cím

Az origó egy séma, egy hoszt és egy port. Nem az a cím, ahonnan a csomagok elindulnak, és nem az az IP, amelyet a szerver lát. Ezért a VPN minden megfigyelhető címet megváltoztathat, az origót pedig változatlanul hagyhatja. A böngésző a válasz Access-Control-Allow-Origin fejlécét az oldal origójához hasonlítja, és a kilépési cím soha nem kerül bele ebbe az összehasonlításba.

Tehát egy bővítmény vagy egy proxy, amely úgy tűnik, mintha javítana egy CORS-hibát, valami mást tesz: átírja a fejléceket, vagy úgy irányítja a kérést, hogy az már ne legyen eltérő origójú. Egyik sem a VPN tulajdonsága.

Mit küld valójában a böngésző

Egy nem egyszerű, eltérő origójú kérés esetén a böngésző először egy OPTIONS előzetes ellenőrzést küld, amely a szándékolt metódust és fejléceket hordozza. A szervernek a megengedett engedélyekkel kell válaszolnia, és a valódi kérés csak akkor következik, ha ez a válasz megfelel a szabályoknak. A VPN megváltoztatja az útvonalat, amely mindkét cserét szállítja, és megváltoztathatja, mit válaszolnak a köztes szolgáltatások. Nem változtatja meg az origó karakterláncát vagy az előzetes ellenőrzés követelményét.

Egy parancssori kliens általában semmit sem mutat ebből. Lehet, hogy nem küld Origin fejlécet, gyakran kihagyja az előzetes ellenőrzést, és más hitelesítő adatokat hordozhat. A curlnek visszaküldött törzs bizonyítja, hogy a szerver a curlnek válaszolt.

Keresse meg a megváltozott választ

Hasonlítsa össze a tényleges választ minden útvonalon, ne csak a státuszkódot. Nézze meg a CORS-engedélyeket hordozó fejléceket, a tartalomtípust, minden átirányítást, és hogy egy WAF- vagy CDN-változat más oldalt állított-e elő. A regionális elutasítás, a hitelesítési átirányítás vagy az engedélyfejléc nélküli hibaoldal mind elbukik a böngészőben, miközben CORS-hibának tűnnek. Ezek a kézbesítési útvonal különbségei, és ezeket kell dokumentálni.

Rögzítse mindkét útvonal válaszfejléceit, és hasonlítsa össze őket soronként. Ha az egyetlen különbség az, hogy egy hibaoldalon hiányzik az Access-Control-Allow-Origin, megtalálta az okot.

A szolgáltatást javítsa, ne az érvényesítést

Amikor a szolgáltatás az Öné, mondja ki egyértelműen az engedélyezett origókat és a kérés jellemzőit, majd olvassa el a hibákat, amelyeket a frontendje és a közvetítők előállítanak. Ha nem teszi, küldjön a szolgáltatás tulajdonosának egy megtisztított összehasonlítást. Soha ne tegyen sütiket, engedélyezési fejléceket vagy munkamenet-exportokat abba a jelentésbe, mert ezek azok a hitelesítő adatok, amelyek védelmére a szabályzat létezik.

Kerülje azokat a böngészőbővítményeket, amelyek kikapcsolják a CORS-t. Megváltoztatják a biztonsági határt, miközben elrejtik a válaszkülönbséget, amelyet meg kellett volna magyarázni, és ugyanazt a hibát hagyják meg minden más felhasználónak.

Rögzítse mindkét választ, a használt origót és a megtett útvonalat. Ez a feljegyzés a VPN-ről szóló pletykát szolgáltatáshibává alakítja.