Neautorizovaný přístup k datům

V posledních dnech, týdnech a měsících jsem několikrát slyšel a četl o tom, že velkým hráčům unikla nějaká data, případně se někdo dostal k informacím, které vidět neměl, a to naprosto jednoduchým způsobem. „Útočník“ pouze změnil nějaké číslo v adrese stránky a v prohlížeči se mu najednou ukázaly údaje, k jejichž prohlížení nebyl autorizován. Jak je to jen možné?

Představte si, že nakoupíte někde v oblíbeném e-shopu, na pozadí se vytvoří objednávka, kterou nějak zaplatíte a pak už jen čekáte na svůj vysněný a tvrdou prací zaplacený kryt na telefon. Kryt chrání váš telefon jak se sluší a patří, a vy si koncem března najednou vzpomenete, že by se vám hodila faktura. Takže jdete do zákaznické sekce vašeho obchodníka, najdete vaši objednávku, kliknete na odkaz ke stažení faktury, vytisknete ji a radujete se, když v tom najednou uvidíte v URL nějaké zajímavé číslo.

O půl vteřiny později se ve vás strhne obrovský vnitřní boj, ve kterém zvítězí temná strana síly, kliknete do řádku s adresou ve vašem prohlížeči a naprosto přirozeně a s klidem v duši to číslo změníte, třeba ho o jedničku snížíte. Adresu potvrdíte a najednou, jako mávnutím kouzelného proutku, zapomenete na nějakou vytištěnou fakturu. V prohlížeči se vám totiž objeví detaily objednávky někoho úplně jiného, včetně uživatelského jména, celkové sumy, seznamu objednaného zboží a kupónu na 10% slevu na příští nákup. A poněvadž síla temna jen tak nepoleví, napíšete si jednoduchý skript, který postupně mění ono číslo v URL a stránku vždy uloží a vy tak získáte hezký přehled o finančních transakcích vašeho oblíbeného obchodníka. A taky spoustu slevových kupónů.

Tahle technika není nic nového pod sluncem, většina z nás má podobné návyky zažité z dob stahování obrázkových galerií z webů z kategorie 18+, tam také často stačilo měnit čísla v URL, abyste se dostali k obsahu, na který zrovna náhodou nevede žádný odkaz.

Zatím jsme si popisovali jen co-by-kdyby příklady, ale tohle se opravdu stává i ve světě před monitorem. Nebo vlastně spíš za monitorem. Vzpomeňme službu Facebooku pro zasílání novoročních přání.

Stačilo měnit parametr id a mohli jste si nejen číst cizí pozdravy, ale mohli jste je dokonce i mazat.

Toto drobné vývojářovo přehlédnutí se nevyhýbá ani naším kotlinám. Josef Průša před pár dny zjistil, že dobré jídlo se na 3D tiskárně vytisknout zatím nedá, a tak zkusil do svého prohlížeče zadat www.damejidlo.cz, nějaké to OMNOMNOM si objednat a během té chvilky, která ho dělila od toho, než kurýr zazvoní u jeho dveří, stihl přijít na to, že na stránce s potvrzením objednávky stačí změnit číslo v URL a dostat se na potvrzení objednávky někoho jiného. Na té stránce není nic podstatného, kromě kreditu v hodnotě 5% objednávky, z čehož se dalo jednoduše prozkoumáním všech objednávek za vydatné pomoci matematické operace zvané součet zjistit třeba to, jak si vlastně DámeJídlo vede. Prý žádné citlivé informace.

Asi známější (tzn. psala o něm Lupa) je případ z roku 2009, který se týkal Sazky a jejího e-sázení. Jména a čísla všech sázejících, to jste mohli získat pouhou změnou parametru id. V případu padla nějaká trestní oznámení, no a tak vůbec, byla to legrace. Sazka tvrdila, že data byla náhodně generována, nicméně náhodně vygenerovat jméno Davida Grudla, které se v datech vyskytlo, to asi umí jen generátor náhody od Sazky.

Nejen ve Spojených státech je relativně hodně sledovaný případ chlapíka jménem Andrew Auernheimer (Weev/@rabite). Jeho kamarád Daniel Spitler totiž jednoho krásného dne roku 2010 podojil server AT&T a dostal z něj přes sto tisíc e-mailových adres majitelů iPadu 3G, včetně adres lidí z vlády, armády a pár šéfů fakt velkých firem. Jenom tím, že trochu upravil HTTP hlavičku User-Agent a měnil čísla v URL, resp. posílal na server různé ICCID (19 až 20 číslic). Seznam e-mailových adres pak získal Andrew a o pár měsíců později byli oba dva obžalováni. Ve Státech totiž platí zákon (Computer Fraud and Abuse Act, CFAA) z doby, kdy v Sovětském svazu vybuchovaly jaderné elektrárny, tedy z roku 1986, který říká, že přístup k počítači není autorizován, pokud se tak rozhodne majitel toho počítače. Není třeba tedy hackovat žádné heslo, není třeba někam injektážovat SQL, stačí si jen v prohlížeči načíst stránku. Takže je možné, že i vy, moji milí čtenáři, tento zákon právě porušujete. Stejně tak ho porušili i Daniel a Andrew, pouhou změnou pár čísel v URL, čímž se dostali v podstatě k veřejným informacím. Daniel nakonec vypovídal proti Andrewovi, ten byl shledán vinným a hrozí mu až 10 let v chládku.

Popisovaný problém nesou na svých bedrech vývojáři, zkrátka ukazují data někomu, kdo je vidět nemá. Odhalit tuto bezpečnostní mezeru nemusí být úplně jednoduché, můžete změnit parametr v URL na nějaké číslo objednávky, která v systému neexistuje (nebo je stornovaná) a systém se bude tvářit, že z něj nic nedostanete. Nicméně pokud budete zkoušet vlastní aplikaci, tak asi budete i vědět, jaké číslo máte vlastně zadat, budete znát číslo existující objednávky a podobně. To je asi jediná možnost, jak vaši aplikaci otestovat, tedy dokončit dvě objednávky pro dva různé uživatele a poté zkusit pro jednoho uživatele zobrazit data z té druhé objednávky zadáním jejího čísla.

Z pohledu vývojáře to není tak jednoznačné. Pokud nechcete náhodného návštěvníka měnícího čísla v URL poslat do chládku, tak ve veřejné aplikaci, která posílá data do prohlížeče, nesmíte v podstatě nikdy mít SQL dotaz, který vypadá nějak takto:

SELECT … FROM orders WHERE id = ?

(použití nebo nepoužití prepared statements nemá na popisovaný problém žádný vliv, tento „útok“ nemá s SQL injection nic společného)

Musíte tedy do podmínky vždy přidat uživatelské jméno nebo session id, nebo něco podobného, co jednoznačně identifikuje návštěvníka:

SELECT … FROM orders WHERE id = ? AND username = ?

No a hlavně na to musíte pamatovat pokaždé, když píšete nějaký SQL dotaz, přeju hodně štěstí.

Jako pomyslnou třešničku na dortu, k tomu pamatování, že musíte přidat další podmínku, byste mohli pro účely zobrazování a přenosu v URL použít něco jiného, než číslo objednávky, třeba GUID, které vypadá např. takto: fa4cee73-8cf5-41be-87d7-dede5d160236 nebo rovnou objednávky vůbec nečíslovat lineárně, ale použít nějaké hausnumero, třeba ono zmíněné GUID. Musím dodat, že samotné použití něčeho takového vaši aplikaci samozřejmě neochrání, spolehlivě to však některé jedince odradí od pokusů jakkoliv tyto čísla měnit, je jich tam totiž nějak moc.

Hezkou možností, tedy vlastně spíš vedlejším efektem při přesunu logiky do databázových funkcí, je to, že do každé funkce budete posílat uživatelské jméno. Budete ho mít pořád na očích a snad do té funkce tu podmínku WHERE username = … napsat nezapomenete. A kromě toho se vám to bude hodit později při škálování a rozdělování databází podle uživatelských jmen. A to se vyplatí!

Napadají vás nějaké další možnosti, jak se proti získávání dat pouhou změnou čísel v URL nejlépe bránit?

Michal je webový vývojář a bezpečnostní p̶r̶ů̶výzkumník. První webové stránky vytvořil když ještě zuřila První válka prohlížečů, ve které to Netscape Navigator prohrál proti Internet Exploreru. Pořádá školení, zajímá ho bezpečnost a výkon, staví, boří a testuje webové aplikace. Přednášel na více než 70 konferencích a akcích, včetně konference WebExpo v Praze a konference Passwords v Las Vegas, na obou opakovaně.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 51

Přehled komentářů

M. Jak se bránit?
Rexxar User_id v kazdom dotaze je overkill
pb Re: User_id v kazdom dotaze je overkill
Čelo Re: User_id v kazdom dotaze je overkill
Rax To je staré
Martin Hassman opakování taťka moudrosti
Josef Vybíhal Re: Neautorizovaný přístup k datům
Jakub Vrána Automatická kontrola
Rax Re: Automatická kontrola
Jakub Vrána Re: Automatická kontrola
china Re: Automatická kontrola
Cermi HMAC
Rax Re: HMAC
Karel Userid když neexistují uživatelé
greeny Což takhle...
Ja Docasna url s generovanym id
Michal nikdo neslyšel o ACL?
roman Re: nikdo neslyšel o ACL?
Petr Nautorizovaný přistup k datům DameJidlo
Opravdový odborník :-) Odborný názor
Rax Re: Odborný názor
Opravdový odborník :-) Re: Odborný názor
Rax Re: Odborný názor
Opravdový odborník :-) Re: Odborný názor
Rax Re: Odborný názor
Opravdový odborník :-) Re: Odborný názor
Rax Re: Odborný názor
Opravdový odborník :-) Re: Odborný názor
j Re: Odborný názor
Jan Náhodný hash
expert Re: Náhodný hash
janpoboril Frameworky
diverman Re: Frameworky
janpoboril Re: Frameworky
Honza Re: Frameworky
j Re: Frameworky
Michal Špaček Re: Frameworky
Karel zlobivy googl
j Re: zlobivy googl
koudy Re: zlobivy googl
Opravdový odborník :-) Re: zlobivy googl
maio Validace || Repository
juzna Na čí straně je chyba a jak to vysvětlit normálním lidem
https://tomasfejfar.mojeid.cz/#bLGPpVT97A Re: Na čí straně je chyba a jak to vysvětlit normálním lidem
Flašinet Re: Na čí straně je chyba a jak to vysvětlit normálním lidem
Jenda Re: Na čí straně je chyba a jak to vysvětlit normálním lidem
juzna Re: Na čí straně je chyba a jak to vysvětlit normálním lidem
Jenda Re: Na čí straně je chyba a jak to vysvětlit normálním lidem
JeanSolPartre chybí mi ještě 2 patra
JeanSolPartre shrnuti problemu autentizace
antiamík
Zdroj: https://www.zdrojak.cz/?p=3771