Ehm, predstavte si, ze vite, ze identifikatory jsou jen v rozmezi 0 az 1'000'000. Pak vsechny tyhle identifikatory muzete zahashovat (a je uplne jedno jak dobrym hashem) a pak zkouset jenom ty hashe, co vam to vyplivne. Zadne 2^256 moznosti.
Rika se tomu generovani slovniku a pouzivalo se to pro hackovani hashovanych hesel uz v sedmdesatych letech. Presne to je ten duvod, proc se dnes nepouzivaji slovnikova hesla.
Pokud ID bude sha-256, tak to sice volný přístup přímým zvýšením čísla už neumožní, ale stále je to opět „security through obscurity“ a pokud bude někdo chtít, tak si prostě toho robota se všemi sha-256 kombinacemi může napsat a poslat ho na jejich web. Nehledě na to, že stále zůstává problém v tom, že případná „prozrazená“ adresa bez žádosti o přihlášení bude znamenat, že se vše stane přístupné někomu, kdo k tomu přístup mít nemá.
Proč o bezpečnosti píše někdo, kdo jí vůbec nerozumí? Kdyby ten webserver dokázal obsloužit noniliardu (tj. 1057) požadavků za sekundu, bude zkoušení všech kombinací SHA-256 pořád trvat několikrát déle, než je současné stáří vesmíru.
To, že není (nyní ani v blízké budoucnosti) reálně možné vyzkoušet všechny možné hodnoty hashovací funkce, je důvod, proč se vůbec hashovací funkce používají. Což je ta první věc, kterou by měl o hashovacích funkcích vědět někdo, kdo chce pochopit základy bezpečnosti.
Ochrana nějakým tajným údajem není „security throught obscurity“. To Dočekalovo „přihlášení“ není nic jiného, než ochrana tajným údajem. Je úplně jedno, jestli se tomu tajnému údaji říká heslo nebo bezpečnostní kód. A je celkem jedno, zda ten tajný údaj je součástí URL nebo se posílá jako HTTP hlavička nebo formulářové pole – pořád to putuje ve stejném HTTP požadavku a typicky stejným paketem. Jediný rozdíl je v tom, že u hesel ví každý, že je nemá nikomu říkat, v případě URL s kódem je potřeba na to uživatele explicitně upozorňovat.
Amatérismus Filipa Jirsáka v online podobě.
http://www.lupa.cz/clanky/helpdesk-na-webu-muze-byt-problem-kdyz-ochranu-dat-neberete-vazne/nazory/736968/
Helpdesk: "Potřebuju fixnout to a to na MS SQL serveru s IP x.x.x.x. Lojza Kropášek, nemocnice"
Odpověď: "Ve verzi a.b.c. to není podporováno, bude to ve verzi d.e.f., kterou nasadím 1.8. Můžete si to vyzkoušet na testovacím buildu, heslo je xxhtfdsiuw564465fdf$%^%^85, je to na adrese x.x.x.y. SW Project Manager"
Black Hat:
- Ví, kde sedí SQL server, stačí jenom očuchat porty.
- Ví, jaký DB server tam je (MS SQL) a stačí se mrknout na CVEčka a vyzkoušet.
- Ví, že se dostane na 95% k datům o pacoších.
- Může si v klidu prohlídnout nový systém,, který je v debug módu (backdoor, výpis debug zpráv, omezený zabezpečení) a vytipovat díru, kterou se 2.8. dostane k produkčním datům.
- Ví, kdo dělá SW a ví, kam poslat "objednávku backdooru" a čím jménem.
Tam přihlášení jenom pomocí identifikátoru v URL bez ověření totožnosti nemá co dělat.
Tohle je ovšem vaše teorie, která je v rozporu s tím, co je napsáno v článku. V článku není napsáno, že hash bude SHA-256 hash číselného identifikátoru. Je tam napsáno, že identifikátor bude SHA-256 hash. A Daniel Dočekal v článku píše: „robota se všemi sha-256 kombinacemi může napsat“. „Se všemi SHA-256 kombinacemi“, ne „se všemi SHA-256 hashi možných číselných identifikátorů“.
Vaše verze, že to udělají špatně a budou jednoduše hashovat to číselné ID, je samozřejmě možná, ale nic v článku jí nenaznačuje. Daniel Dočekal ale píše o vyzkoušení všech možností SHA-256, což je právě těch 2256.
Nemusí. Ale pak jde právě o toho "obyčejného" zákazníka, kterému je to fuk.
Pokud jde o zákazníka, kterému jde o bezpečí, tak se chtě nechtě musí zabývat zabezpečením. To znamená poptat se dodavatele jaké má zabezpečení, jak docílit, aby citlivá data neutekla ven.
Než na firmu TaskPool.net či podobných hned házet špínu, tak je dobrý se nejdříve zeptat na zásadnější otázku.
Je unikátní URL ve výchozím stavu povoleno?
Pokud ano. Pak jde o velký problém a měli by raději tuto funkcionalitu v základu zakázat. To je všechno. Dále to nemá cenu rozebírat.
Pokud ne. Pak už to není problém dodavatele, ale problém zákazníka, že si to dobrovolně povolil a tedy zákazník je tím pádem zodpovědný za únik citlivých dat.
Není to veřejný údaj. To, že prohlížeč URL zobrazuje nebo ukládá do historie ničemu nevadí, protože je to pořád jen ten prohlížeč, kterému uživatel důvěřuje. Ostatně hesla prohlížeč také zobrazuje i ukládá. Referrer si musí provozovatel ošetřit, už vznikají i standardy pro to, aby to mohl ošetřit i na straně prohlížeče.
Zakódování URL (SHA-cokoli, GUID apod.) bez přihlašování nic neřeší, protože "oprávněný" uživatel pak klikne na bookmark google (nebo napíše něco do hledání) a google se dozví v referreru tu URL, kterou OBRATEM stáhne a všechno je víme kde.... a to nevratně. Navíc stačí napsat site:helpdesk.cz a vypíše všechny takové URL. NoRobots apod. to řeší velmi málo. SSL nepomáhá. Proč tam nemají aspoň trvalou cookie a první přihlášení mi nikdo nevysvětlí.
URL se pro přihlášení používá běžně. Používá to tak i Google, používá to tak Dropbox a všichni ostatní. Nevím, co myslíte tím „bookmark google“, při vyhledávání z prohlížeče se referrer neodesílá (protože to vyhledávání nemá nic společného se stránkou, kterou má uživatel náhodou otevřenou). Google nemůže indexovat stránky, o kterých se dozví z prohlížeče (např. při analýze malware stránek).
Pozná se to podle toho, zda je to určené ke zveřejnění nebo není… Představte si jako příklad asymetrickou kryptografii. Vygenerujete si dvojici klíčů, a jeden z nich prohlásíte za privátní, druhý za veřejný. Klidně byste to mohl udělat i opačně. Není to obecná vlastnost klíčů (existují klíče soukromé i veřejné), není to ani předem daná vlastnost konkrétního klíče, je to vlastnost, kterou vy klíči přidělíte. Stejně je to s URL – to není předem ani veřejné ani privátní. Pokud na něj odkážete z nějaké veřejné webové stránky, učiníte to URL veřejné. Pokud si v Dropboxu vytvoříte privátní URL k souboru, v Google Calendar privátní URL ke kalendáři nebo v Doodle získáte privátní URL pro administraci ankety, jsou to privátní URL, se kterými tak musíte zacházet a sdělit je jenom těm, kterým chcete daný soubor nebo kalendář zpřístupnit (administraci Doodle ankety obvykle nezpřístupňujete nikomu).
Takova funcionalita nema na podobnem typu webu vubec co pohledavat(naprosto nikdy) a se zakaznikem to nema zhola nic spolecneho. Obhajujete neobhajitelne.
Korunu tomu pak nasazuje prave zduvodneni, ktere zcela jasne identifikuje naproste diletanty na strane provozovatele.
Neco podobnemo ma smysl mozna na webu dopravce, kde se ocekava ze podle ID zasilky je mozne zjistit jeji stav a nejde o zadne tajne informace, nebot nelze zjistit ani odesilatele ani adresata.
Je to help desk. Je pravděpodobnost 99,9999%, že se tam budou probírat detaily o chybách aplikací, uživatelé budou žádat o přístup k zabezpečeným systémům. A tyhle chyby se dají vždycky zneužít.
Takže jsou tady čtyři možnosti:
1) Autor toho webu neví, co je to help desk a co se s ním dělá. Pak je otázka, proč ho vlastně napsal.
2) Autor toho bastlu neví vůbec ani o základech bezpečnosti.Pak je otázka, proč si nepřečte aspoň jednu jedinou knížku o bezpečnosti webu. Tohle musí být absolutně všude.
3) Autor toho webu má soudem v reálným světě určenýho opatrovníka, jenom soudce nezohlednil, že ho potřebuje i v kyberprostoru.
4) Autor toho webu je jednoduše blbej jak papuč.
> pokud bude někdo chtít, tak si prostě toho robota se všemi sha-256 kombinacemi může napsat a poslat ho na jejich web.
Ehm, všech 2^256 možností? Good luck, je to víc než je počet atomů vodíku ve viditelném vesmíru.
Nic proti Dočekalovskému stylu žurnalistiky, ale tahle „obscurity“ už JE dostatečně „secure“.
Chyba zakaznika to vubec byt nemusi. Vetsinou se podobne sluzby nabizi s tim, ze nepotrebujete zadneho administratora, protoze provozovatel se vam o vse postara, a budete to mit (temer) zadarmo.
Pripadne, ze se o to muze starat sekretarka, ktera ve skutecnosti nezvlada ani scitani v excelu.
Zakaznik prevazne vubec netusi jak ty veci funguji, natoz aby mel poneti o tom, co se jak da vyuzit a zneuzit.
Nezbyva pak nez zopakovat "data v cloudu === data v coudu". Ve 100% pripadech plati, ze o data muzete prijit i na vlastnim HW s vlastnim SW a vlastnim IT supportem, ale v cloudu je to jistota.
Nevím proč z toho autor dělá takový humbuk. Zvolená technika unikátní URL je běžná metoda ochrany přístupu. Stejně jako v případě hesla nebo jiné metody přístupu. Sice není spolehlivá, ale běžně dostatečná. Vždyť ji používají i velcí hráči jako třeba Google Drive, kde mezi metody sdílení je unikátní URL. Dokument sice bude rázem veřejný, ale URL zná jen pár lidí.
Unikátní URL má znát jen ten, komu je určeno. Že se dá jistou technikou toto URL zjistit, je už jiná věc. To je to samý jako pokus o uhádnutí hesla.
Jediný problém je akorát citlivost dat, které se za tímto URL skrývá. Pokud jsou tam natolik citlivá data, které by neměl nikdo znát, pak je na místě zakázat unikátní URL. Což o HelpDesku pochybuji. Jde jen o to, kdo jsou klienti. Buď jsou to obyčejní zákazníci, kteří mají obyčejný neškodný dotaz nemající žádný citlivý charakter, pak je unikátní URL vítaná funkce, nebo jsou to korporace, úřady, kteří řeší citlivé záležitosti, pak by právě tito měli zajistit lepší zabezpečení, jakým je i zákaz unikátního URL.
Jak čtu, tak TaskPool.net URL umožňoval vypnout. Chyba je tedy skutečně na straně zákazníků, že to měli povolené. Shazovat to na nevědomost není na místě. Každý zákazník, který řeší citlivé záležitosti, musí bezpečnost řešit hned na začátku. Tedy s TaskPool.net projednat možnosti zabezpečení. Pak by hned na začátku došlo k tomu, že unikátní URL vypnou.
Nevím co má autor za problém. Co v tom vidí za amatérismu. Já v tom nic závažného nic nevidím. Pokud je unikátní URL doplňková funkce, kterou lze vypnou, tak v tom nevidím problém. Tak nevím proč útočit na TaskPool.net jako na nějaké amatéry.
Zajimalo by me, zda byste byl ve svem hodnoceni stejne prikry i v pripade firmy Google. Jeji AndroidStudio uklada do logu hesla jak ke storage klicu, tak i k samotnym podpisovym klicum aplikaci. Pro nekoho detail, pro hackera dost brutalni fakt a zlaty dul. Zvlaste, kdyz se treba tyhle logy muzou posilat mimo vas pocitac...
Hlavni je, ze provozovatel toho Helpdesku rychle zareagoval. Sice je zvolene reseni hrube nedokonale, ale v dalsi iteraci uz mozna budou tvrdsim cilem pro skutecne hackery.
1) Alespoň můj Firefox neposílá referrer při otevření bookmarku do existujícího tabu.
2) Tohle jsem kdysi zkoušel, vyrobil jsem si stránku a Google jsem na ni různě vábil (Safe broswing, posílání odkazu přes GMail…), a nejen, že se neobjevila ve vyhledávání, on ji dokonce ani nestáhl (koukal jsem do access logu). Máš vyzkoušený nějaký postup, jak robota přilákat?