Vlákno názorů k článku Jaké změny čekají datové schránky? od Mard - Mám čerstvou zkušenost - a to hroznou. Zkoušel...

Já jsem to pochopil tak, že autor pracoval v prohlížeči na počítači, a ten počítač byl k internetu chvíli připojen přes jedno připojení a chvíli přes jiné. V tomto případě o tom věděl, pokud na síti funguje vyvažování zátěže nebo záložní konektivita, děje se úplně to samé, ale bez vědomí uživatele. Session je dělána buď pomocí cookie nebo pomocí parametru v URL, a ani jedno není svázáno s odchozí IP adresou (kterou ostatně prohlížeč často ani neví).

Pak by byl rozdíl zcela zanedbatelný, a to byste měl samozřejmě pravdu :-) Vzhledem k tomu, co všechno už u DS vyplavalo na povrch jsem se tomu ani nedivil, a zmíněná možnost mě napadla až když jste to zmínil :-)

Čemu nerozumíte na "změna session id při každém načtení stránky"?

Já tomu rozumím – když je nějaký web udělaný blbě, musí se to zmršit pořádně, třeba změnou session ID při každé změně stránky a zneplatněním předchozích. Když předchozí session ID nezneplatníte, nijak jste si proti ukradení session nepomohl, když je zneplatníte, znemožníte používat historii prohlížeče nebo otevřít aplikaci ve více záložkách. A přitom je to vše zbytečné…

Změna IP adresy během relace ve skutečnosti nastává jen v málu sítí, a pokud je to rychlejší než řekněme 30 minut, tak to je jenom prasárna, a s rozložením zátěže nebo s rozumným nastavením clusteru/proxy serveru to nemá nic společnýho.

Typický argument někoho, kdo potřebuje nějak obhájit kontrolu IP adresy. Mně úplně stačí to, že kontrola IP adresy může způsobit problém, a bezpečnost rozumně zabezpečeného systému to nezvýší.

Ani jedno zbytečné není, pokud se jedná o bezpečnostní hledisko.

Nedělat kontrolu IP adresy u DS bych pochopil, bohužel i z toho důvodu, že teoreticky by proxy měla posílat i mohla posílat původní IP, ale to bychom už byli u adminů v rámci sci-fi procentuálního pokrytí.

Jinak i ty nejprimitivnější programovací jazyky pro web umožňují řešit změnu session id v rámci oné funkce. Že to třeba php nemá jako defaultní hodnotu je hodný kritiky, ale dle mě se to v budoucnu změní.

Možná se té změny session id a detekce změny IP adresy nakonec dočkáte. Zní to totiž jako super killer feature, jak otrávit uživateli přístup do DS. Při detekci změny IP adresy by se mohlo šáhnout k blokaci přístupu do DS z daných IP adres a směle to vydávat za další výrazné posílení bezpečnosti dat.

U DS jsem psal, že kontrola IP adresy je z důvodu neschopných adminů nepoužitelná. A ohledně session id vás opravdu lituju, že vám nebude fungovat Back v prohlížeči, nebo dokonce historie suburl DS, strašlivá to killer feature, zvlášť když se uvedený dá zařídit v rámci aplikace.

Jestli je něco killer feature, tak je to autorizovaná konverze s certifikátem v CRL, případně dokumentu s porušenou integritou. Dokonce to není killer feature, ale totální průser jako Brno.

Ano průser jak Brno. Jen asi bude ještě dlouho trvat než bude první kauza. A pak...? Všechny konverze do listiné podoby půjdou do kytek.

Průser už trvá tři roky, a to je § 72 daňového zákona s jeho sankcí 2000 Kč.Což postihlo podle vikipedie 12 000 daňových poplatníků. Dobrý kšeft pro stát ca 24 000 000 za nic.

Předvádíte klasickou ukázku amatérského pojetí bezpečnosti. Nejprve se vymyslí způsob autentizace, kdy se uživatel autentizuje jen na začátku práce a následně se mu už důvěřuje na základě toho, že se jedná o stejnou session – přičemž identifikaci session může v případě HTTP ukrást kdokoli po cestě, v případě HTTPS „pouze“ něco uvnitř prohlížeče. A pak se snažíte takto vytvořenou díru zalátat, přičemž se vůbec nehledí na to, jaké mají ony záplaty vliv na bezpečnost – hlavně to musí vypadat dostatečně sofistikovaně. A pokud to nefunguje, svede se to na neschopnost někoho jiného – třeba adminů koncového uživatele.

Žádné RFC ani nic podobného nevyžaduje, aby všechna HTTP spojení v rámci jedné session pocházela z jedné IP adresy – vyžadovat to ani nemůže, protože HTTP je bezestavový protokol, a session si vytváří až server tím, že některé požadavky podle určitých pravidel poskládá k sobě. Takže pokud někde vzniká problém s tím, že se odchozí IP adresy mění, není to neschopnost admina klientské sítě, ale neschopnost tvůrce aplikace. Proxy může (ale nemusí) posílat originální IP adresu, která je ale tvůrci aplikace k ničemu, protože ji stejně tak může podvrhnout útočník.

Změna session ID ničemu nepomůže, už jsem to psal. Za prvé tím znemožníte používat historii prohlížeče nebo otevřít aplikaci vícekrát (a nepřinese to nic), za druhé tím stejně nezabráníte únosu session – útočník ji může unést pořád stejně, akorát následující požadavek oprávněného uživatele bude vyhodnocen jako útok a uživatel bude odhlášen. Může se pak pokoušet účet okamžitě zablokovat, ale to už je jenom souboj, zda bude rychlejší útočník nebo běžný uživatel – a útočník bude pravděpodobně připraven a bude systém dobře znát.

Pořád ještě jste nevysvětlil, k čemu je dobrá kontrola IP adresy. Jak zabrání únosu session, pokud je útočník za stejným proxy serverem nebo za stejným NATem? Já myslím, že nijak. Takže musíte mít stejně nějaké jiné opatření, které tomuhle zabrání. Jenže to bude fungovat i pro všechny ostatní případy, takže kontrola IP adresy je pak zbytečná.

Kontrola IP adresy jako prevence únosu session může mít smysl jedině v případě, kdy web není zabezpečen vůbec nijak – pak kontrola IP adresy zamezí alespoň takovým útokům, kdy by se k session ID dostal někdo víceméně náhodně. Proti cílenému útoku na daného uživatele ale nepomůže nijak.

Když se používá HTTPS spojení, je kontrola IP adresy úplně zbytečná – jediný rozumný způsob, jak session ID získat, je z prohlížeče uživatele. A když má útočník pod kontrolou prohlížeč uživatele, může samozřejmě provádět akce z jeho IP adresy.

Nechápu vaši snahu, kdy je možnost posílit bezpečnost, se tomu bránit, protože "to je zbytečný", a uživateli to může přinést v případě nezakomponování do aplikace trochu nepohodlí. Tak buď jsou DS běžnej systém kluka/holky, co vyrobil/a místní chat (kde je přesto na místě z těchto pomocných způsobů zabezpečení některý použít, jestli se tedy nechce, aby to byl jeden velkej backdoor s používáním nicků kohokoliv kýmkoliv, a z toho totální chaoz, kdy by se to stejně chtě nechtě muselo předělat, nebo to zrušit), a nebo obrovsky důležitej systém, stejně tak jako např. příští rok základní registry. Tam je to úplně stejně neprůhledný, a může se stát, že to bude ještě otřesnější implementace. A vám to vůbec nevadí, evidentně.

Navázanost na IP adresu jsme už u DS odmítli, z důvodu především nutný co nejglobálnější funkčnosti. Změna IP adresy co půl minuty na některých místních sítích vám nepřipadá jako čuňárna, no, mně, a některým implementátorům webových služeb a serverů, ano. Ale budiž, každej se dle toho jistě zařídí dle svých priorit, jako čuňárna to zůstává (opakuju - v rámci relace, že se změní po běžné době vyřízení relace je již bezvýznamná věc, a ať si vytížené servery mají navenek klidně desítky IP adres).

Ohledně autentizace odkážu jen na rozdíl autentizace a autorizace, dál určitě netřeba.

Co se týče SSL/TLS, opět zapomínáte na to, jak to u DS začalo, a taky na to, jak to je v globálu aktuálně někde jinde. Kdyby bylo SSL zcela bez chyb, včetně implementace, pak ano. Bez chyb není, běžný hashe za chvíli přestanou stačit, dokonce se nekontrolují při instalaci certifikátů, CRL je kontrolováno v prohlížečích mnohdy mimo defaultní nastavení, v prohlížečích jsou chyby, jsou defaultně zapnuté volby pravěkého SSL 2.0, implementace má mnohde trhliny i na serverech, to všechno má za důsledek buď možné nabourání nebo obcházení SSL relací (malware, man-in-middle...), a vy mi tu budete tvrdit, že SSL/TLS je spása.

Celou dobu tu píšu, že se jedná jen o "pomocné, přídavné..." zabezpečení autentizace, kde je to teoreticky úplně to samé, jako si u wifiny zapnout maskování SSID a filtr MAC adres. Ano, samo o sobě je to k ničemu, ale jako přídavnej střípek do skládačky, zvlášť pro lamy, objíždějící s notebooky se script kiddies vilový čtvrtě, proč ne.
Dál je samozřejmě třeba řešit právě autorizaci, ale to už je poněkud jinej příběh, že.

Nechápu vaši snahu, kdy je možnost posílit bezpečnost, se tomu bránit,

To vidím, že nechápete, co se tady celou dobu snažím vysvětlit. Kontrola IP adresy není posílení bezpečnosti. Nebo je, ale zhruba stejně účinné, jako zakopat pod server kořen madragory a do CD-ROM mechaniky nacpat česnek.

Změna IP adresy co půl minuty na některých místních sítích vám nepřipadá jako čuňárna, no, mně, a některým implementátorům webových služeb a serverů, ano.

Není to v rozporu s žádnými internetovými standardy, takže není vaší úlohou posuzovat, zda to má některý správce takto nastavené správně nebo ne – je to jeho věc a vy s tím musíte počítat.

Ohledně autentizace odkážu jen na rozdíl autentizace a autorizace, dál určitě netřeba.

Netřeba, celou dobu se tady bavíme o autentizaci, webový prohlížeč s údaji o uživateli ani nikdy nic jiného nedělá – autorizaci dělá až serverová strana.

Co se týče SSL/TLS…

HTTPS stále jako prostředek k zabezpečení integrity spojení a nemožnosti odposlechu stačí, i proti naposledy oběvené slabině se lze bránit. SSL není spása, pokud si uživatel nainstaluje pochybný plugin nebo má na počítači keylogger, SSL jej nezachrání. Ale proti útokům MITM je to silná ochrana (pokud si uživatel zkontroluje certifikát a prohlížeč kontroluje CRL), srovnávat to s kontrolou IP adresy je poněkud mimo – když bych měl zabezpečení ohodnotit na stupnici od nuly do sta, bude mít SSL třeba nějakých 85 a kontrola IP adresy 0,0001.

Celou dobu tu píšu, že se jedná jen o "pomocné, přídavné..." zabezpečení autentizace,

To je přesně ono – řeší se pomocné a přídavné zabezpečení, které nezabezpečí skoro nic, a na skutečné zabezpečení se pak kašle – vždyť je tam přece hromada těch pomocných a přídavných, tak to musí stačit. DS by měly být zabezpečené víc, než jenom proti script kiddies, a zabezpečení proti schopným útočníkům samozřejmě zabere i proti těm script kiddies.

Takže bych to ze svý strany uzavřel...

IP adresa
- Ano, jistě, je to na adminech příslušný sítě/clusteru/proxy, a na web adminech a jejich nadřízených (případně vlastníka domény/služby) je zase, jestli je nutný takový uživatele plně podporovat a nebo je nechat se co půl minuty znovu přihlašovat, protože dneska není žádnej rozumnej důvod měnit IP adresu v limitu menším než desítky minut. Stejně tak je na web adminech zvážení rozsahu podpory starých verzí prohlížečů, starých verzí proxyn, který někdy posílají v hlavičkách neplatný paskvily atd.

Ale proti útokům MITM je to silná ochrana (pokud si uživatel zkontroluje certifikát a prohlížeč kontroluje CRL), srovnávat to s kontrolou IP adresy je poněkud mimo
- Mluvíte o jednotkách procent uživatelů, kteří si skutečně správně zkontrolují hash, v prohlížeči zkontrolují zapnutí CRL (mnohde je ještě nutný nastavit jeho adresu pro jednotlivý CA), a kteří nemají zasviněný PC běžným malwarem. Ano, tam SSL nepomůže, jenže v drtivý většině pomůže třeba jednorázovej kód (s výjimkama typu: http://www.root.cz/clanky/bezpecnostni-stripky-socialni-site-v-centru-pozornosti-hackeru/nazory/318466/ ), a ten (v jakýkoliv podobě) jste třeba vůbec nezmínil jako dost slušný bezpečnostní řešení, kryjící jako pomocnej způsob další desítky procent hacků (když se dobře naimplementuje a je samozřejmě zcela mimo PC kanál, a zároveň i tento kanál je dobře ošetřen - SMS 3DES, včetně jeho změny...).
A nakonec: Kdo SSL/TLS srovnával s IP adresou? Nikdo, nikde.

To je od vás hezké, že víte o všech sítích na světě, jestli jejich administrátor má nebo nemá nějaký důvod pro to, aby se IP adresa v rámci jedné session změnila. Určitě vám nebude vadit, když správce nějaké sítě na oplátku usoudí, že jeho uživatelé váš web nepotřebují a na bráně jej zakáže. Je to rozhodnutí plně stejného druhu – rozhoduje o něčem, do čeho mu vůbec nic není.

Proti útokům MITM není kontrola IP adresy žádná ochrana. Je to ochrana proti útokům, kdy útočník není uprostřed, ale někde co nejdál od uživatele. Protože když bude útočník uživateli blízko, může vůči serveru snadno vystupovat se stejnou IP adresou, jako uživatel, a vaše kontrola IP adresy je pak k ničemu. Proti MITM pomůže buď šifrování nebo digest autentizace.

Proti únosu session nepomůže ani jednorázový kód, ale jedině autentizace každého jednotlivého požadavku.

Je to úplně to stejný, jako když server odmítne autentizaci u klienta, kterej mu na žádost serveru o inicializaci SSL odpoví zastaralým algoritmem s krátkou délkou klíče. Některý adminy fakt nezajímá, že uživatel pochází z Británie, kde komanči brzy asi zakážou i šifrování obecně, nebo z Číny, nebo má zastaralý prohlížeč MSIE s vynucenou krátkou délkou klíče ještě do nedávný doby. Zásady zabezpečení serveru má nastaveny od majitele nebo správce prostě takový, a basta. Kdo je z příslušný strany neschopnej (jestli uživatel/admin/vláda...) je serveru docela šumafuk.

MITM samozřejmě vůbec neznamená "uprostřed", ale i třeba těsně před serverem, nebo paralelně úplně někde jinde, takže zase jsme u pravděpodobnosti, co je ještě "k něčemu" a co podle vás "k ničemu".

Digest autentizace by byla zajímavá i do budoucna, kdyby se už odstřihla od MD5, protože jinak by to mohla být (až na to "ošklivý okno" generovaný prohlížečem, jak tu někdo zmínil) celkem slušná věc, i třeba jako nouzovka mimo SSL/TLS. Navíc je implementace primitivní, v zásadě to může obsluhovat server včetně toho, že se do kódu služby/stránek ani nešáhne (zvlášť na Apachi), což je i obrana proti chybné a relativně složité implementaci autentizace v kódu, a s úspěchem to bezpečně může realizovat i začínající správce stránek.

Jednorázový kód jsem nemyslel ohledně autentizace, ale autorizace. Ono, autentizace by byla útočníkovi k ničemu, když by pak už nemohl udělat vůbec nic, že.

Odmítnutí autentizace klienta slabým algoritmem je oprávněné, protože to řeší bezpečnostní problém – kontrola IP adresy nic takového neřeší. Zvlášť když se používá (rozumně nastavené) SSL, protože pak je jediná možnost úniku session ID ze serveru nebo z prohlížeče uživatele – a v obou případech je kontrola IP adresy klienta k ničemu.

To nejdůležitější jste u MITM vynechal – totiž že útočník může být „velmi blízko“ uživateli. A tam právě kontrola IP adresy selže. Takže pokud chcete bránit MITM útoku u HTTP, kontrola IP adresy k tomu nestačí.

MD5 u digest autentizace zatím nevadí, ale je pravda, že pokud se má algoritmus změnit, mělo by se s tím začít co nejdřív, aby se to stihlo. U webu se momentálně řeší podružnosti typu HTML5 nebo videa, takže nějaká digest autentizace skoro nikoho nezajímá. Ani s tou lehkostí nasazení to není tak růžové – zrovna nedávno jsem narazil na problém (a zatím neznám řešení) mezi Apachem a MSIE7, kdy MSIE7 se na výzvu serveru sice uživatele zeptá na heslo, ale hlavičku Authorization pak nepošle. Proti jinému serveru (Jetty) to přitom fungovalo, takže MSIE7 vadí asi nějaká specifická kombinace parametrů výzvy. Člověk by čekal, že v roce 2009 už nebudou s implementací tak široce používaného protokolu, jakým je HTTP, problémy, ale opak je pravdou (jmenovaný problém samozřejmě není jediný).

S IP adresou už se točíme dost dlouho v kruhu, takže to dál nemá smysl. A nic jsem nevynechal, opět, to, že by byl útočník uživateli blízko je spíš mizivý procento útoků, a jinak to může pomoct.

Tak nekompatibility jsou. Někdy za to může chybně nastavenej server, někdy chyba v prohlížeči (je jich spoustu i v MSIE 8, dokonce takových, který MS odmítá opravit, a opraví je prej až v MSIE 9), ale to neznamená, že by to bránilo používání.

Ale diskuze byla zajímavá...