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.
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č.
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.
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.
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.
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.