Az admin aldomain nem állítja meg a CSRF-et: négy ellenőrzés indulás előtt

Az adminfelület átköltöztetése az admin.example.com címre valódi javulás: távol tartja az adminsütiket a nyilvános oldalaktól, külön gyorsítótárat ad a két alkalmazásnak, és lehetővé teszi, hogy szigorúbb hálózati szabályzatot irányítson egyetlen hosztnévre. Ez azonban nem CSRF-védelem, és nem teszi biztonságossá a nyilvános oldal kódját arra, hogy bejelentkezett adminisztrátor előtt nyitva tartsa. A szétválasztás azt változtatja meg, amit a böngésző határnak tekint, nem azt, amit a kiszolgáló ellenőriz, ezért végezze el ezt a négy ellenőrzést, mielőtt késznek nyilvánítja.

Olvassa az origin és a webhely fogalmát két külön szóként

Az origin a séma, a hoszt és a port, tehát a https://www.example.com és a https://admin.example.com különböző origin. A webhely SameSite-értelemben a séma plusz a regisztrálható domain, tehát ez a két hosztnév általában ugyanaz a webhely. Ez a különbség az egész csapda: a SameSite attribútum nem segít testvér aldomainek között, mert a böngésző a kérést egyáltalán nem tekinti webhelyek közöttinek. Irányítsa az adminfelületet valóban másik regisztrálható domainre, például az admin-example.net-re, és a kérés valóban webhelyek közötti lesz, és ott kezd el a SameSite=Lax vagy Strict olyan munkát végezni, amelyre támaszkodhat.

Tesztelje a böngészőben ahelyett, hogy okoskodna róla.

Töltse be a nyilvános oldalt, nyissa meg a fejlesztői eszközöket, és nézze meg, mely sütiket csatolja a böngésző az admin hosztra irányuló kéréshez. Ha a sütinek nincs Domain attribútuma, csak a hoszthoz tartozik, és a saját nevén marad; ha Domain=example.com van rajta, minden testvérhez eljut, és az új aldomain semmit nem adott önnek arra a sütire.

Válassza szét a válasz olvasását a kérés elküldésétől

A azonos origin szabályzata korlátozza a válaszok olvasását az originok között. Nem akadályozza meg a kérés elküldését, és nem akadályozza meg, hogy egy űrlap olyan hitelesítő adatokat vigyen, amelyekkel a böngésző már rendelkezik. Az egyszerű kérés, űrlap tartalomtípussal vagy egyszerű GET-tel, előzetes ellenőrzés nélkül célba ér; a CORS ezután dönti el, hogy a hívó szkript olvashatja-e a választ. A CSRF teljes egészében a küldés oldalán él.

Ezért van szüksége a kiszolgálónak kifejezett ellenőrzésre az állapotot módosító műveleteknél. A munkamenethez kötött szinkronizációs token, vagy a kiszolgálón összehasonlított dupla beküldésű süti lefedi az esetet; az Origin vagy Referer összehasonlítása második kapuként megéri, de nem egyedüli kapuként, mert nem minden kérés viszi a fejlécet, és nem minden proxy őrzi meg. Az OWASP CSRF-megelőzési útmutatója éppen ezért tekinti a SameSite-t egy rétegnek a többiek között.

Döntse el, mit bizonyít valójában a hálózati kapu

A VPN-kimenetek engedélylistája az admin hoszt előtt jó kontroll és gyenge identitásállítás. Azt bizonyítja, hogy a kérés olyan címről érkezett, amelyet a VPN ad, amelyet mindenki megoszthat azon a kimeneten, és semmit nem mond arról, melyik személy vagy eszköz áll mögötte. Kezelje belépési szűrőként, ne hitelesítésként.

Tartsa függetlennek a kérés szintű ellenőrzésektől. Ha a lista az egyetlen dolog a támadó és egy állapotot módosító végpont között, egy rosszul beállított útvonal, egy split-tunnel kliens vagy egy kölcsönkért laptop teljesen megszünteti a kontrollt.

Naplózza a várt tartományokon kívüli elutasításokat is. Azok rohama a leghasznosabb jelzés arra, hogy valaki az imént épített határt szondázza, a csend pedig arra, hogy a szűrőt egyáltalán nem érik el.

Tartsa kifejezettnek a sütiket, a bejelentkezést és az engedélyezést

A süti hatóköre dönti el az eredmény nagy részét. A szülődomain sütije az admin hosztra kerül, ezért a nyilvános oldalon végrehajtott szkriptinjektálás egy adminisztrátor munkamenetével cselekedhet; a csak hoszthoz tartozó süti nem tud. Részesítse előnyben a csak hoszt formát, adja hozzá a Secure attribútumot, és használja a __Host- előtagot ott, ahol a platform támogatja, mert ez az előtag Secure-t, Path=/-t és Domain attribútum nélküliséget követel. A válasz fejlécét olvassa, ne a sütisüveget: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, Domain attribútum nélkül. A böngésző eldobja a Domain-t hordozó __Host- sütit, tehát a testvér hosztokon még látható süti bizonyítja, hogy az előtag soha nem érvényesült.

Utána tartsa az engedélyezést a kiszolgálón, kérésenként, minden adminisztratív végponton, nem csak bejelentkezéskor. Az engedélyezett hálózatról érkező kérést is hitelesíteni kell, és engedélyezni a kért műveletre; a hosztnév nem szereplő. Ha a nyilvános és az admin alkalmazás közös bejelentkezési folyamatot vagy munkamenet-tárat használ, írja le ezt a kapcsolatot, mert ez a legrövidebb út a nyilvános oldal hibájától egy adminisztratív műveletig.

Ellenőrizze újra a határt a szétválasztás után

Futtassa a negatív teszteket, ne csak a boldog utat: a token nélküli webhelyek közötti űrlapot el kell utasítani, a másik munkamenetből származó tokent el kell utasítani, és egyetlen GET sem módosíthat állapotot. Ellenőrizze a sütik attribútumait a fejlesztői eszközökben, erősítse meg, hogy az Origin-ellenőrzés nem egyező kérésnél aktiválódik, és próbálja ki az admin hosztot a VPN-tartományon kívülről, hogy lássa a szűrőt működés közben.

Ezek egyike sem szünteti meg az admin alkalmazáson belüli XSS-hibát. A külön hosztnév valódi értékű böngészőoldali elkülönítési határ, és nem helyettesíti a nem biztonságos kódfuttatás megelőzését vagy a kiszolgálóoldali kérésvédelmet. A szétválasztás után a lista rövidebb, mint amilyennek látszik: külön origin, csak hoszthoz tartozó sütik, token minden módosításnál, olyan belépési szűrő, amelyben nem bízik identitásként, és kérésenként eldöntött engedélyezés.