Pavel Stěhule: SQL injektáž může firmu připravit o celý byznys

Karel Wolf , 26. únor 2010 13:18 10 komentářů

Pavel Stehule
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 Stehule
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.


Komentáře

Náhodný kolemjdoucí #1
Náhodný kolemjdoucí 26. únor 2010 14:12

purequery to jisti, to umi udelat z dynamickeho SQL staticke a zamknout ho, takze zadne jine SQL statementy da databaze nevykona. Za par dolaru dostanete nejen lepsi vykon, ale i bezpecnost.

Investujte do modernich technologii.

Pavel Stěhule #7
Pavel Stěhule 26. únor 2010 20:44

purequery je API nad prepared statements - v podstatě totéž v bledě modrém.

Náhodný kolemjdoucí #8
Náhodný kolemjdoucí 26. únor 2010 23:54

Doporucuji kratky pq tutorial

http://www.ibm.com/developerworks/data/tutorials/dm-0903optimizenet/index.html

a prepared statementy neumoznuji sql injection pokud tedy nevolaji stored procedury napsany tak aby stavely SQL statementy dynamicky.

petr_p #2
petr_p 26. únor 2010 19:06

V Německu mají zákon, který zakazuje zveřejňovat útočný kód i za mírovými účely.

Náhodný kolemjdoucí #3
Náhodný kolemjdoucí 27. únor 2010 10:03

Při použití prepared statements nebo alespoň nějakého frameworku (dokonce i v PHP) poskytujícího rozhraní k databázi je skoro umění, někde sql injection umožnit. To by člověk musel vytvářet hodně divoké konstrukce odlišující se od standardních tutoriálů. Takže IMHO dnes se sql injection týká spíše amatérských webů.

Nevím jaká data vy svěřujete "nízkonákladovým" eshopům. Já jen své jméno, adresu a telefon. Tedy údaje, které na mne každý snadno získá i z jiných zdrojů. I ty nejlevnější eshopy dnes na placení kartou používají rozhraní 3D secure (u nás třeba přes ČS) nebo v PayPal.

Číslo své karty jsem zadal mimo snad jen jednou: nedávno tuším na eshopu Magnetu a to jsem se hodně ošíval. Kdyby mi za měsíc nekončila platnost, přišli o zakázku.

Takže to nabádání k nákupům jen u velkých nemá s sql injection žádnou souvislost.

Pavel Stěhule #9
Pavel Stěhule 27. únor 2010 19:12

Pokud vývojář ví co dělá, tak s prepared statements může napsat aplikaci, která je 100% neprůstřelná. U frameworků je potřeba respektovat předepsané vzory - a ověřovat si výsledek. Minulý měsíc jsem našel díry v příkladech dodávaných k jednomu populárnímu PHP frameworku, o kterém jeho autor tvrdí, že je neprůstřelný. Neprůstřelný je - pokud vývojář nechybuje (přičemž i jeho vlastní autor chyboval). Ochrana vůči SQL injektáži je velice jednoduchá - a může být 100% - ale je to na vývojářích, kteří, bohužel, z velké většiny nemají páru o tom, jak celý mechanismus funguje - a je to o to tragičtější, že stačí hodinová instruktáž. Jinak, jak poznáte - bez znalosti kódu, že je nějaký web amatérsky naprogramován?

Jan Molič #4
Jan Molič 27. únor 2010 13:36

Souhlasím s tím, že problémem je příliš velká rychlost vývoje. Takzvané agilní programování si většina lidí vykládá jako "prasení" a podle toho vypadá bezpečnost. Pokud však nepracujete zrovna v bance, jste nuceni pracovat rychle. Žádné velké analýzy, žádné rozmýšlení. Platí pravidlo, že konkurence web "naprasí" rychleji a levněji. Klient navíc nevidí, že je to prasečina, ale zajímá ho především design a aby tam byl nějakej ten AJAX...

A tak se pracuje rychle a problémy se řeší až když nastanou (ovšem včetně těch bezpečnostních). Najímají se programátoři, kterým nevadí prasit za pár korun. Z programátorů-tvůrců se tak stávají programátoři-dělníci.

Výsledkem levného a rychlého vývoje proto není jen nebezpečí SQL injektáže, ale celkový úpadek. Například nedávno mi z hostingu utekl klient, poněvadž byl prý můj server pomalý. Ještě poznamenávám, že v té databázi nebyly žádné indexy a že query sloužila k pouhému spočítání řádků:

# Query_time: 53 Lock_time: 0 Rows_sent: 385 Rows_examined: 125049
SELECT * FROM inzeraty WHERE (sekce LIKE 'ona_ho') AND (kraj LIKE '%') AND (publikovan LIKE '1')

Mystify playboy #5
Mystify playboy 28. únor 2010 18:35

Zas ďalší žvást, dopíšem do hocijakého kódu na začiatok kontrolu na 10 riadkov, vždy ma udivujú ľudia čo o blbosti dokážu napísať knihu.

Náhodný kolemjdoucí #6
Náhodný kolemjdoucí 04. březen 2010 15:32

Joomla, Wordpress a Drupal jsou CRM systémy?? Nebo spíš CMS? Pán je odborník co?

Karel Wolf 04. březen 2010 17:53

Myslim, ze pan odbornik skutecne je. Nicmene dekujeme za upozorneni na preklep.


RSS 

Komentujeme

Chatbot mluví za mrtvého – od nápadu k realizaci

Pavel Houser , 30. listopad 2016 13:00
Pavel Houser

Na webu The Verge popsala Casey Newton příběh dvou přátel (Eugenia Kuyda a Roman Mazurenko). Peripet...

Více





Kalendář

20. 03.

24. 03.
CeBIT 2017
RSS 

Zprávičky

Nový zákon o výzkumu chystá "blacklist" příjemců i ministerstvo

ČTK , 09. prosinec 2016 16:31

Velké změny ve fungování Grantové a Technologické agentury, novou vědeckou radu ČR i takzvaný "black...

Více 0 komentářů

Fitbit koupil průkopníka chytrých hodinek Pebble

ČTK , 09. prosinec 2016 15:00

Americký výrobce chytrých náramků a hodinek Fitbit koupil software, patenty a další aktiva duševního...

Více 0 komentářů

Američané možná umožní v letadlech telefonování přes wi-fi

ČTK , 09. prosinec 2016 13:00

Aerolinky ve Spojených státech by v budoucnu mohly umožňovat telefonování v letadle s použitím wi-fi...

Více 2 komentářů

Starší zprávičky

Česká pošta od ledna zdraží posílání do zahraničí o pět až 20 Kč

ČTK , 09. prosinec 2016 11:39

Česká pošta od ledna zvýší ceny za posílání listovních zásilek do zahraničí o pět korun, balíky podr...

Více 0 komentářů

Za vzněcováním smartphonu iPhone 6 jsou vnější vlivy, tvrdí Apple

ČTK , 08. prosinec 2016 11:30

Firma Apple odmítla podezření čínských uživatelů svého chytrého telefonu iPhone 6, že za problémy s ...

Více 0 komentářů

Verizon prodá firmě Equinix datová centra za 3,6 miliardy USD

ČTK , 08. prosinec 2016 10:00

Největší americký mobilní operátor Verizon Communications prodá specializované společnosti Equinix 2...

Více 0 komentářů

Tchajwanský Foxconn jedná o rozšíření svých aktivit v USA

ČTK , 07. prosinec 2016 15:00

Tchajwanská společnost Foxconn jedná o rozšíření svých aktivit ve Spojených státech. Oznámila to dne...

Více 0 komentářů