Cookie-ból kiolvasható-e a jelszó?

Az eltárolt cookiek-ból egy weboldal lekérdezheti-e egy másik betöltött weboldalnak az adatait?

Hozzászólások

Roviden: nem.

Hosszabban: igen.

Meg hosszabban: miert van jelszo egy cookie-ban???

ne legyen benne jelszó, egy token legyen benne

Gábriel Ákos

Imho kb:

  • secure és http only cookiek
  • Rövid lejáratú tokenek (amiket renew tokenekkel frissítgetnek)
  • Forrás ellenőrzés (kb a másik ipről nem fogadom eltől a browser fingerprintelekig)
  • Szenzitív műveleteknél reauthentikáció/második faktor
  • Horrible dictu lehetne kliens tls authot használni.
  • Illetve hát vmennyire ide tartozik a mindenféle cross site policy

Hát, vannak nyilván, de eléggé függ attól, hogy milyen az infra.  (És amit én most lendületből tudnék mutatni, az zorp, azzal nem vagy előre szerintem :) ) Ugye a TLSt nem a webapp kezeli, hanem a a HTTPS infra, szóval az easy case sem teljesen ízi.

  • A minimalista megoldás az kb annyi, hogy be van konfolva az nginx/apache, hogy ellenőrizzen kliens certet. Nyilván bonyolultabb esetekben elindul a ki(k) a load balancer(ek), hol termináljuk a TLSt és hasonló móka. Ez arra már jó, hogy random csóka egy session cookieval sehova nem jut, mert eleve előbb lepattan.
  • Arra viszont nem, hogy a userek ne tudjanak laterális támadást csinálni, ahhoz valahogy össze kell nézni a session cookiehoz tartozó usert, a kliens cert userével. Ehhez jellemzően elérhetővé kell tenni a backend számára a kliens infót, tipikusan headerekbe injektálja be webszerver, de lehetne akár olyat is csinálni, hogy mondjuk a JWTt összenézi a proxy azzal, amit a tlsből kiszedett.

Aztán ez az egész megfejelődik azzal, hogy a hibakezelést így a browser intézi, annak meg az UXe a béka segge alatt van 13 km-el, illetve bejön a cert disztibutálás problémája (hogy konkrét példát mondjak, a takarnet pár éve pl még postán küldött CD-t), és ha a kezedben van a cert, még akkor se trivi, hogy hogyan kerül be a browserba.

Hát, random publikus lófaszokon ezért nem szokott lenni...

Mivel szeretnéd használni? Mert Apache tud, Tomcat tud, Haproxy tud (stb. ennyit láttam/konfiguráltam már ilyenre) kliens certet bekérni és az alapján dönteni, hogy mehet vagy sem (nekem volt olyanhoz is szerencsém, hogy a kliens certből a CN-t használta loginhoz, azaz kellett a cert, _és_ az adott névhez tartozó jelszó is).
Ezeken felül minden TLS-t bontó "rendes" tűzfal képes kéne,hogy legyen kliens cert alapon eldönteni, hogy a benyújtott cert jó-e az adott szolgáltatás eléréséhez vagy sem. (Ilyet Zorppal, illetve most már PNS-sel csináltam).

Most akkor gondoljuk vegig azt is, hogy milyen hozzaferest szerezhet a tamado egy elteritett sessionnel vs ha kezeben van a plaintext jelszavad, amit esetleg mashol is hasznalsz. Szorgalmi feladat osszehasonlitani, mennyivel konnyebb szerveroldalon elkapni egy lopott sessiont (ha mashogy nem, akar azzal, hogy megnezed, ugyanaz-e az IP), mint egy lopott jelszot.