Új hozzászólás Aktív témák

• #17074 sztanozs veterán supercow #17073

  Új Válasz 2015-01-22 12:59:47 #17074

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sztanozs

  veterán

  válasz supercow #17073 üzenetére

  Jó az oldal, amit linkeltél (bár több, mint két éves a cikk) - de továbbra is kitartok amellett, hogy a böngésző a leggyengébb szem a védelmi láncban. Amennyiben böngésző dekódol az egyetlen helyben tárolt kulccsal - itt az egyetlen probléma maga a böngésző - egyszerűen nincs lehetőség megfelelően "elzárni" a kulcsot, amit a kliens oldali kód használ.

  Kicsit végiggondolva, akövetkezők használhatók a kulcs átadására (szerver és kliens oldal között):
  1. Cookie, form fields, header fields - mindegyikkel az a gond, hogy bármelyik JS elérheti, amelyik be tud töltődni az oldal scope-ja alatt...
  2. Javascript (non-global) hardcoded privát változó/konstans - ezzel az a gond, hogy cache-elődik a gépre és utólag kibányászható...
  3. XHTTP Request http-only cookie-val, válasz (master password, titkosított jelszó adatbázis) privát változókba tárolva - ez talán legkevésbé kockázatos megoldás, így nem kell hardcode-olni a master hash-t és a jelszó adatbázist. az alábbi triviális támadási módok vannak ellene:
  - Másik JS is tud egy XHTTP kérést küldeni és neki is elküldi a szerver a master hash-t/ jelszó adatbázist. Illetve másik JS is el tudja érni a privát változóink publikus interfészét, tudja hívogatni a metódusokat...
  Digitálisan aláírt JS kikényszerítésével lehet esetleg védekezni ezek ellen.
  - Böngésző JS debuggerén keresztül hozzá lehet férni a változókhoz (egyes beépülő modulok ezt is tudják kontrollálni)

Új hozzászólás Aktív témák