Nešvarem dnešní doby je trend programovat rychle a efektivně na úkor kvality. Na riziku SQL injektáže komerčních aplikací, jednoho z největších bezpečnostních strašáků dnešní doby, se tak stejnou měrou podílejí pohodlní programátoři i manažeři, říká Pavel Stěhule, IT expert pracující v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény .CZ.
O SQL injektáži se v poslední době hodně mluví, ale povědomí o principech útoku a hlavně jeho rizicích trochu pokulhávají. Jaké jsou vůbec základní druhy ohrožení, které SQL injektáž do byznysu přináší?
Základní riziko pro firmy je, a to si řada manažerů dosud nejspíše neuvědomuje, ztráta samotného byznysu. Z pohledu uživatele je to pak ztráta, nebo zveřejnění citlivých (např. osobních) dat, nebo rovnou peněz. Když se to pokusím rozvést, tak firma průnikem do svých databází může přijít o svá data, v trochu méně katastrofické variantě pak o know-how a důvěru. Ztráta důvěry je přitom riziko, které není radno podceňovat. Určitě by bylo zajímavé zjistit, nakolik například otřásly úspěšné útoky na levné webhostingové služby jejich zákaznickými základnami. Ale nejde jen o hostingové služby. Pokud by se stala nedůvěryhodnou například e-mailová služba Seznamu nebo Google, většina uživatelů odejde a vzhledem k oblíbenosti služby to ohrozí celý byznys této velké společnosti.
Pavel Stěhule je IT expert
pracující v Laboratořích CZ.NIC,
výzkumném a vývojovém centru
správce české národní domény.
Dalším dobrým příkladem jsou e-shopy. Ještě dříve, než jsem se začal problematikou SQL injektáže více zabývat, tak jsem třeba nevěnoval takovou pozornost tomu, komu svěřuji svoje kontaktní údaje, natož pak číslo karty. Dnes si již vybírám daleko obezřetněji. Jinými slovy, nízko-nákladový obchod se vám ve finále může docela prodražit.
Trochu problém je v tom, že já jakožto běžný uživatel nemám informace, jak moc dobře zabezpečený daný obchod je. Velký i malý obchod může mít stejné bezpečnostní nedostatky. Typickou chybou je například to, když ukládá do databáze informace o platbách, namísto toho, že je hned zahodí, nebo pošle dál.
Mediálně známé případy z Ameriky ukázaly, že je riziko poměrně vysoké a obchody, které útokům neodolaly, na čas ohrozily důvěru v celý trh a snížily obraty. Osobně raději upřednostňuji ty větší, kde si myslím, že je pravděpodobnost rizika přece jenom o něco menší.
Představují větší riziko vendor lock-in aplikace, nebo Open-source? Pokud tedy vůbec lze podobnou otázku zodpovědět.
Metoda SQL injektáže je z principu použitelná, ať zdrojové kódy znáte, nebo ne. To je věc, která je mimo diskuzi. Pokud ovšem toto hledisko vynecháme, tak si myslím, že bude rizikovější spíše uzavřený software. Je to z toho důvodu, že masivně používaný Open-source software, jako například WordPress, prošel a neustále prochází masivním uživatelským testováním a pokud zde díra je, tak je zpravidla rychle odhalena. U E-shopu, který napsala soukromá společnost , je situace opačná, čímž riziko vzrůstá. Ani u velice dobře známého kódu vám ovšem nepomůže, pokud ho nepoužíváte správně.
Měl jsem za to, že útočníky často láká právě to množství instancí, ve kterých ony „velmi dobře známé kódy“ běží. Jak to tedy je?
Pokud máte na mysli automaty, které zkouší prolomit vstupy do CMS systémů jako je již zmíněný WordPress, Drupal a další, nebo třeba Wikipedia, pak ano. Jenže problém není ani tak u originálního kódu, který podléhá častým aktualizacím a chyby se v něm neohřejí příliš dlouho, jako jeho derivátům. Pokud si vezmete původní software, ten přepíšete, tím pádem se odříznete od aktualizací, pak se stáváte velmi zranitelní vůči všem chybám, na které se mezi tím přišlo a u vás nejsou upravené.
Jaké typy aplikací bývají napadány nejčastěji?
Pokud jde o napadnutelnost, tak je to prakticky vše, co využívá nějakou SQL databázi. Před lety tato zranitelnost v systému Windows NT ohrozila velkou část byznysu software Microsoftu. Když se ale zaměříme na motivaci, pak nejvíce útočníky lákají osobní údaje, nebo data, ze kterých se dá finančně profitovat. Velmi žádanou komoditou na černém trhu jsou například čísla kreditních karet.
Velkým rizikem nízkonákladových hostingových služeb je například již to, že zpravidla z důvodu šetření nákladů nepoužívají skutečné virtualizované servery, ale pouze virtualizovaný webserver (nejčastěji Apache). To má za následek, že se skrz kteroukoli jednu napadnutelnou aplikaci dostanete ke všem zbývajícím i když jsou ošetřené. Následně můžete vesele instalovat viry, rozesílat červy, nahlížet do databáze.
Již několikrát jsem se setkal s názorem, že jsou některé dražší databáze proti injektáži imunní. Jaká je realita?
Dražší databáze vám riziko SQL injektáže rozhodně nesníží. Problém je na aplikační úrovni. Nicméně, při nevhodně nakonfigurované databázi, lze skrz SQL injektáž zaútočit na hostitelský operační systém. Většina moderních databází má nějakou funkcionalitu, která dokáže volat funkce systému. Když nad touto funkcionalitou získáte kontrolu, můžete přepisovat data v souborovém systému. Pak stačí, abych si upravil třeba PHP kód nějaké aplikace, která na serveru běží a svůj útok zkombinoval například s rozesíláním virů a máte tu hrozbu jako hrom.
Jaké bývají nejčastější cíle SQL útoků a jak velká je hrozba ve srovnání s jinými bezpečnostními riziky.
Bohužel ani jednu otázku nelze uspokojivě zodpovědět, protože na povrch vyplave jen malé procento útoků. Zajímavé by bylo zjistit, kolik například bylo úspěšně napadeno bankovních systémů, ani jedna strana útoku vám to ale dobrovolně nejspíš neřekne.
Atraktivním cílem útoků jsou systémy, kde se lze dostat k osobním údajům, respektive jednoznačně identifikovatelným řetězcům, jako jsou třeba čísla kreditních karet. Pokud by se čistě hypoteticky někdo naboural do databází Google, bude mít najednou k dispozici tolik údajů, že je bez opravdu velkého zázemí pravděpodobně nedokáže efektivně zpracovat. Pokud se však zaměří na řetězce, jako je číslo kreditní karty, nebo čísla účtů může být jeho dataminig úspěšný. Samozřejmě jeho cílem může být také třeba jen poškodit renomé společnosti, pak si může gratulovat.
Jaký vliv má na SQL injektáž použitá architektura? Nebude riziko injektáží s příchodem Cloud computingu rapidně narůstat?
Na riziko injektáže nemá architektura vliv. U cloudu je samozřejmě riziko, které je spojeno s tím, že je to něco nového. Programátoři, kteří s nimi přicházejí do styku tudíž nemusí mít dostatek zkušeností, aby se uvědomili některá elementární rizika a dostaly se jim pod kůži správné pracovní návyky.
Pokud jsem to teď správně pochopil základní chyba je tedy v programátorech.
Stoprocentně, ale pozor, chyba je stejnou měrou i v manažerech, kteří nejsou schopní si uvědomit správné priority. Hlavním cílem IT posledních let se stala produktivita za každou cenu. Tedy pracovat levně a rychle. Úplně zde chybí například jistá sebekázeň, sebekontrola, profesionální hrdost. To je potřeba změnit, jinak se nepohneme dále.
Běžně se programátoři zapojují do komerčního vývoje bez potřebných zkušeností a znalostí – k čemuž jsou pobízeni, případně nuceni svými manažéry. Levná pracovní síla, která se učí za provozu , není v tomto oboru řešením.
Jaká je tedy ideální prevence? Co byste poradil ať již programátorům, nebo firmám?
Ideální prevence je zaměstnávat lidi, kteří o riziku SQL injektáže vědí, rozumí mu a nepodceňují je. A když již máte existující kód, tak pak důkladná revize kódu. Vývoj se tím prodlouží a tím pádem stoupnou náklady, ale dlouhodobá návratnost, která se odrazí například v pověsti stabilní bezpečné aplikace, je k nezaplacení. Navíc ušetříte na opravách kódu později. Další možností jsou penetrační testy. Riziko tu spočívá trochu v tom, že pokud je test neúspěšný, tak jste sice utratili balík peněz, ale nezjistili prakticky nic.
Když už se firma rozhodne k revizi kódu, co může udělat proto, aby si mohla být jistá, že výsledkem bude skutečně maximálně bezpečný kód?
V podstatě stačí používat API, které je bezpečné. Jedná se o takzvané „prepared statements“ a „parametrizated queries. Jakékoli jiné API by mělo být striktně odmítáno. Programátoři vás například mohou přesvědčovat, že mají kontrolované vstupy (například zakázali určité řetězce či znaky). Jenže v takovém případě nikdy nevíte, jestli někdo kombinací vstupů na různých úrovních přeci jen nemůže hacker v součtu dosáhnout stejného výsledku, jako kdyby do formuláře zadal najednou celý kód. Jediná bezpečná cesta je tedy použití statického SQL.
Můžete ještě na závěr popsat, jak takový typický útok vypadá?
Cracker si zpravidla vezme automat s databázi, kde má připravené fragmenty kódu a následně zkouší pro jednotlivá URL, na kterých se nalézají vytipované aplikace, jednotlivé dotazy. Jedná se zpravidla skutečně o crackery, málokdy se do útoků pouštějí programátoři, kteří problematice skutečně rozumí. Riziko právního postihu je příliš velké. Tito lidé ale mohou připravovat automaty pro SQL útoky, které pak prodávají kriminálním živlům, kteří je nasadí do reálného provozu. Jde o to, že psaním kódu se žádnému riziku právního postihu nevystavují (zatím a zde v Evropě). Naopak profesionálním podvodníkům je riziko lhostejné, pokud přináší adekvátní finanční návratnost.
Děkuji za rozhovor.
