Vlákno názorů k článku Postřehy z bezpečnosti: odhalena totožnost vývojáře LockBitu od Bez přezdívky: - S cookies se tu zase vari voda v...

S cookies se tu zase vari voda v hrnci. Snad uz 27let se davno vi, ze kazda sluzba ma logovat ip adresu a pokud se pristupuje z jine, tak je jasne ze je nutne vynutit prihlaseni. Drive to bylo reseni 100%, dnes je to horsi, protoze clovek muze pristupovat z mobilu ktery meni bts a muze se mu zmenit ip adresa. Lze to resit informaci proc se to deje a nebo zaskrtnou, docasne po dobu sezeni povolit zmeny ip ze stejne zeme. Takze opet snadno resitelne. Nechapu jak se tohle muze resit v roce 2024 jako bezpecnostni incident.

Pokud tu cookie útočník "nějak sebere" z počítače tak to pomůže, ale v textu je explicitně řečeno man-in-the-middle útok. Tam pak je ta cookie spojená s IP adresou útočníka, nebo něco přehlížím?

13. 5. 2024, 08:28 editováno autorem komentáře

Jednou věcí je "co se dávno ví" a druhou věcí co je vám ochoten kdo zaplatit k implementaci. Dávno se ví leccos. Klientům můžete desetkrát říkat, že je něco potřeba a stejně budete mít co dělat, abyste je přesvědčili o mnohem základnějších věcech co se zabezpečení týká a zbytek vám prostě nezaplatí.

Proto se to řeší jako bezpečnostní incident.

nj. ale to prakticky nelze, čím dál čaštěji se klientům mění IP adresa během provozu. IPV6 je tak skoro navržená, různí ISP to mění také často, mobilní operátoři nedrží také tvoji IP adresu. Firemní brány často cyklují více IP adres.

Ze stejné země? IP adresy zemi neznají, jsou tady neoficiální databáze, jsou tady majitelé AS a to je tak nějak vše.

Bezpečnost, která závisí na pinnování síťové vrstvy moc nefunguje a stejně se tím jen záplatuje situaci, kdy máš persistentní heslo (token, cookie, whatever), které ještě posíláš po sítia opravňuje tě k přístupu. To je principálně špatně.

Toto by opravdu nefungovalo. Nevim, jak casto jsi na cestach - predstav si, ze po kazdem presunu by ses musel do kazde sluzby prihlasovat znovu, nedejboze s 2FA:)

Jestli je cookie pouzita ve stejnem prohlizeci / zarizeni, kteremu byla vydana, mi prijde jako dobry napad.

Právě že se už docela dávno ví opak, že vázat uživatelskou session na IP adresu je nepraktické a funguje to čím dál hůř. Vedle už zmíněných problémů je dalším problémem třeba dual-stack, kdy se navazují spojení někdy po IPv4 a někdy po IPv6. Prostě představa, že uživatel má stálou IP adresu neodpovídá realitě.

Identifikátor sezení má být chráněn tak, aby nebylo možné se k němu dostat. Pokud ho útočník může získat, je potřeba se zaměřit na to, jak ho získá. Protože obvykle pokud může získat identifikátor sezení, není to jediný bezpečnostní problém.

Pak je také zabudovaná autentizace do protokolu HTTP, ta by problém řešila, protože se dá autentizovat každý požadavek. Ale to zabili tvůrci prohlížečů tím, že to na straně prohlížečů bylo takřka nepoužitelné.

Problem HTTP auth je primarne v tom, ze s kazdym requestem posilate to jmeno/heslo neprilis zabezpecene. To je horsi varianta, nez kdyz se pri uspesnem prihlaseni vygeneruje nejaky identifikator sezeni... kdy aspon mate moznost jeho platnost casove omezit i v pripade, ze se k nemu nekdo dostane. A bylo to cele designovane v dobe, kdy tukat heslo pres plaintextovy telnet nikoho netrapilo. Zabezpeceni (zasifrovani) transportu je v tomhle pripade jen workaround.

Ne, to není problém. Protože HTTP Auth neomezuje použitý způsob autentizace, takže když na to přijde, můžete tam posílat třeba hash celého požadavku spolu s časovou značkou podepsaný privátním klíčem.

Ano, jsou i jine auth metody nez basic. Ale ty zas prohlizece nijak nezabiji, ty proste jen musite implementovat primo na strane samotne webove aplikace v zavislosti na te metode a prislusnou hlavicku nastavit z te aplikace.