Jak je to s tou bezpečností

Posted 28. 12. 2009 / By Petr Soukup / Aktualitky

V poslední době se pořád mluví o zabezpečenosti webových aplikací, serverů, hostingů, eshopů, … Většina lidí ale ani netuší o čem mluví, když situaci komentuje, takže si uděláme bezpečnostní rychlokurz :)

Na začátek ale říkám, že o bezpečnosti dohromady nic moc nevím. Na to jsou jiní. Ale nějaký manažerský úvod snad zvládnu.

SQL Injection

Ta se nám objevila první. Osobně to považuju za úplně nejhloupější chybu. O co jde? útočník použije webové stránky a zkusí s normálním vstupem (například vyhledávaná fráze) propašovat i nějaký SQL kód. Zní to složitě? Pokud chcete vytahovat obsah celé databáze, tak je otázkou hraní si s manipulací dotazu. Hodně to ovšem usnadní, pokud server jako chybou odpověď rovnou vrátí znění celého SQL dotazu. Pokud útočník ale chce jen škodit, tak často stačí do dotazu dostat frázi DROP TABLE zbozi

Nejrychlejší test na náchylnost? Zkuste napsat do vyhledávacího políčka apostrof. Nebo uvozovku. Skončí dotaz nějakou zrůdnou chybou? Jste na dobré cestě.

Ať tu nepovídám na prázdno, zkusím příklad. Očekávaný dotaz na vyhledávání by měl vypadat například takto:

SELECT FROM zbozi WHERE zbozi_nazev like 'hledana fraze';
Pokud ale dotaz není chráněný, tak útočník místo hledana fraze do vyhledávání napíše ‘; DROP TABLE zbozi WHERE ‘1‘=’1 a z dotazu se stane
SELECT FROM zbozi WHERE zbozi_nazev like ‘; DROP TABLE zbozi WHERE ‘1‘=’1 ';
Podobně se dá také například obejít přihlašování a podobně. Google vám toho určitě najde spoustu. Je úplně jedno, jestli hostujete u banánu, u forpsi nebo máte vlastní server. Tohle je díra ve webu. Vaše díra. Vaše chyba. Náchylnější je na to opensource. Jednoduše proto, že má otevřené zdrojáky a proto, že odhalená díra je aplikovatelná na velké množství lidí, takže stojí za to hledat. Navíc tvůrci opensource v php jsou často patlalové :) Po krátkém výkladu můžu konečně vytáhnout prehistorický vtip:
Telefonát: "Dobrý den a opravdu se váš syn jmenuje "Robert') DROP TABLE Students;—"?

XSS

Cross-site scripting (XSS) je metoda narušení WWW stránek využitím bezpečnostních chyb ve skriptech (především neošetřené vstupy). Útočník díky těmto chybám v zabezpečení webové aplikace dokáže do stránek podstrčit svůj vlastní javascriptový kód, což může využít buď pouze k poškození vzhledu stránky, jejímu znefunkčnění anebo dokonce k získávání citlivých údajů návštěvníků stránek, obcházení bezpečnostních prvků aplikace a phishingu. http://cs.wikipedia.org/wiki/Cross-site_scripting
Jinými slovy: útočníkovi se podaří například přes komentář dostat do obsahu webu skript, který by tam normálně být neměl. A ten může třeba přesměrovávat návštěvníky pryč, případně čekat až přijde někdo přihlášený jako admin a přímo ovládat systém. V miniBB byla například velmi dlouho chyba, která umožňovala vložit do příspěvku obrázek (na to tam bylo tlačítko), který se tvářil vcelku normálně, dokud nepřišel admin – obrázek pak smazal téma (takhle to tlačítko asi fungovat nemělo). Další možností taky je posílat xss přímo v URL (a počítat s tím, že aplikace někde vypisuje parametry přímo). Hezké na to jsou pak různé zkracovače adres. Manipulovaný odkaz přecijen vypadá dost podezřele, protože je obvykle zatraceně dlouhý a plný “nesmyslů”.

Špatné nastavení hostingu

Za předchozí jmenované ještě může majitel webu. Pokud ale hostuje na nezabezpečeném serveru, tak už s tím moc neudělá.
Mimochodem: Pokud mi ještě někdo řekne, že je v pohodě, protože hostuje na linuxu, tak přísahám, že mu jednu natáhnu vražedným pádýlkem
O hostingu má útočník velkou výhodu. Stačí mu pořídit si za pár korun hosting a pak zkoušet, co je nastavené špatně. Například: Zkuste se podívat, jakou máte absolutní cestu ke svým skriptům. Zřejmě tam bude vidět vaše doména. Přepište ji na jinou, která je na serveru (samozřejmě jiná vaše doména :)) a zkuste file_get_contents na nějaký typický soubor – třeba index.php. Neskončilo chybou, ale zobrazil se zdroják? Pak máte problém. Tohle byl zrovna příklad pro lamy a pevně doufám, že ani ten nejlevnější hosting takou díru nemá. Ale zkazit se toho dá hodně.

FTP, MySQL účty

Často se taky objevují zavirované weby – na konec webu je vložen nenápadný iframe přenášející kód. Většinou to dělají trojani, kteří kradou hesla k ftp třeba z totalcomanderu. Mimochodem jsou ještě hodní, že jen přidávají iframe. Mohli by weby rovnou mazat. A u některých hostingů bez záloh by to byla konečná. Řešení? Nepoužívat FTP :) Nejde totiž jen o kradení hesel trojany. Odchytnout heslo k FTP po síti není zrovna náročný úkol. Hostingy navíc taky často moc neřeší počet pokusů o přihlášení. To platí i pro MySQL. Řešení? Omezení jen na určitou IP.

Plaintext

U jednoho vyhackovaného projektu se lidi rozčilovali, že hesla v databázi nebyla zahashovaná, ale byla uložena jako plaintext.
Co je to hash? Například md5 hash slova simplia je 66d18acaff16586b12ac7f01010f4e58. Kouzelné je, že z hashe už zpátky nezjistíte původní slovo. Taková je aspoň teorie.
Naprosto mě ale fascinuje, že všichni jsou nejvíc pobouření z tohoto. Ano, ukládat hesla v plaintextu je zlo bla bla bla. Někdo si ho pak přečte a může se dostat k systému. Nikomu ale nevadí, že ta hesla se dostala ven přitom, když stáhl CELOU databázi? Se všemi údaji o prodejích, údajích zákazníků a vším? A že s databází taky mohl manipulovat? Mimochodem součástí správného postupu v takové situaci je podle ÚOOU okamžitě pracovat na zamezení opakování, ale především změnit přístupová hesla, která byla odhalena. Nechci tu na nikoho ukazovat, ale po měsíci není okamžitě. Takové věci přitom nejsou už žádná sranda, protože jsou pak ve hře milionové pokuty.

Neomezeny-hosting.cz

Podle mě největší borci. Z ničeho nic skončili, protože jim někdo vyhackoval server. Na titulce jen umístili suché oznámení:
Dne 8.12. došlo k neopravitelné poruše na diskovém poli, tím byla ztracena všechna data. Z tohoto důdovu ukončujeme provoz veškerých služeb. Na email [email protected] nám prosím zašlete jméno, adresu, variabilní symbol, doménu, zakoupenou službu a číslo bankovního účtu, kam máme poslat peníze za nevyužitou dobu služeb. Je nutné, abyste přesunuli své domény na nové DNS servery. S převodem Vám poradí nový webhosting. Děkujeme za využítí našich služeb a přejeme Vám mnoho úspěchů s novým webhostingem.
Není to krása? Mě se jejich vyjádření hrozně líbí. V podstatě říkají - “Smůla, přišli jsme o všechna vaše data, nemáme žádnou zálohu. Tak se mějte hezky a pápá”. Úplně do kolen mě ale dostalo, když dnes obnovili provoz. Vy byste se svěřili do rukou hostingu, který se zachoval tak jak se zachoval? Pánové měli možná radši koupit aspoň jinou doménu. Vcelku zajímavé ale je, že nabízí i SSH přístup. Jenže. Když nedokázali zabezpečit ani klasický hosting, tak mají teď s SSH vzbuzovat větší důvěru? Nemyslím si.

A co my?

My to máme daleko jednodušší. Víme přesně co na našich serverech běží. Navíc jsou servery naše, takže vše nastaveno jak má být. Tím že se nemusíme trápit s absurdními požadavky hostingových klientů, tak můžeme vesele všechno blokovat a povolovat jen to co je potřeba. Hostingům ne závidím, mají práci o mnoho horší. Aspoň se ale vyčistí trh a lidi si uvědomí, že za pár korun měsíčně nemůžou čekat zázraky. Nainstalovat na server cpanel umí každý blbec, ale provozovat bezpečný a stabilní hosting už je jiná liga.
Původně jsem chtěl psát úplně o něčem jiném :) Nakonec z toho vznikl obvyklý zmatenec.


O blogu
Blog o provozování eshopů a technologickém zázemí.
Aktuálně řeším hlavně cloud, bezpečnost a optimalizaci rychlosti.

Rozjíždím službu pro propojení eshopů s dodavateli.