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.
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 fendrychmartin@neomezeny-hosting.cz 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.


01:38 on Prosinec 28th, 2009
Ad plaintext/md5 – To, že bude mít útočník přístup k celé databázi ještě nemusí znamenat, že vyhrál všechno. Pokud budu mít hesla v té databázi uložena v plain textu, nebo v md5(rainbow tables), tak si klidně může vytipovat někoho, o kom třeba podle nicku ví, že má účet i na jiným webu a zkusit se s tím heslem přihlásit i tam. Anebo do mailové schránky. Spousta lidí má hesla stejná úplně pro všechno.
Pokud by však hesla byla v databázi uložena „osolená“ (viz password salt), tak by odhalení hesla bylo daleko obtížnější. A při tom to není vůbec žádná extra práce navíc toto implementovat.
01:42 on Prosinec 28th, 2009
Ano, s tím souhlasím. Jen mě zaujala priorita zděšení. Přehledy prodeje, statistiky zisků a podobně jsou VELMI citlivá data. Že navíc získá heslo, se kterým se přihlásí třeba ještě k emailu už je spíš bonusový hřebíček do rakve.
02:06 on Prosinec 28th, 2009
Když jsem cca před 2 lety upravoval databázi jednoho nejmenovaného obchodu s nábytkem, tak měli také uložené hesla jako plain text, bylo docela „zajímavé“ si ty heslo procházet, většina byla buď stejná jako login, nebo ženská jména, jména zvířecích mazlíčků apod:) Ono není na škodu přidat jako podmínku hesla zadání alespoň velkých a malých písmen + čísel.
02:08 on Prosinec 28th, 2009
Márty: Ono je to vidět v hashích. Doporučuju udělat si hash(‘hovno’) a projet počet výsledků
02:24 on Prosinec 28th, 2009
dik za pouucny clanok pre mna ako lamu :)
02:55 on Prosinec 28th, 2009
Díky za článek,
tyhle informace by měl vědět každý, kdo má nějakou databázi uživatelů.
A kdo používá všude stejné heslo je sebevrah – i ty největší (nerovná se nejbezpečnější) weby mají řadu chyb. Stačí se podívat co nahackoval igigi…
10:23 on Prosinec 28th, 2009
Když už si zmiňoval XSS, tak bych se v tomhle kontextu zaměřil trochu více na CSRF.
S kombinací XSS je to jeden z nejčastějších způsobů (a také velmi obtížně trasovatelný), jak se nabourat do špatně zabezpečených webových aplikací.
Nechci tu pedantsky vyjmenovávat na co si zapomněl, naopak slušný článek. Jde mi jen o to, že je to trochu zapomínaný způsob nabourání se do stránek.
14:26 on Prosinec 28th, 2009
Zajímavý článek. Za nejpřínosnější informaci ale považuju info o existenci vražedného pádýlka :D
18:25 on Prosinec 28th, 2009
Když už se dostane na cizí server, tak tam samozřejmě každý soudný člověk nacpe backdoory, kam se podíváš. Takže správný postup po hacku je JEDINĚ čistá instalace všeho od začátku. Samozřejmě jen nejnovější verze. Nějaká změna hesel naprosto nepomůže. Garantuji vám, že jen v .cz existují stovky serverů, do kterých mají přístup i další lidé, aniž by o tom měli majitelé nejmenší tušení.
Dále z toho plyne, že je úplně jedno, jestli jsou hesla plaintext anebo ne. Když jsou tam totiž ty „super bezpečné“ hashe se saltem, tak stačí modifikovat přihlašovací rutinu a čistá hesla si ukládat někam stranou, případně si je rovnou někam posílat. Pak už stačí jen sedět a čekat. A hesla aktivních uživatelů jsou za chvíli doma.
18:32 on Prosinec 28th, 2009
Martin: Samozřejmě. Ale pokud jde o vytáhnutí dat přes sql injection, což byl tento případ, tak je logický postup zadělat díru a změnit hesla. Čistit, zabezpečovat apod samozřejmě ano, ale šlo mi o první krok.
23:42 on Prosinec 28th, 2009
K těm heslům v plain textu… je docela zajímavé dát si vyhledat na googlu frázi „md5 cracker“ … samotné md5 se dá zpětně „uhodnout“ = najít třeba jiné heslo, ale se stejným hashem bez přístupu k super počítači (já to zvládnul na eee) během asi 10ti vteřin, btw Souki nekecal, ten jeho hash simplia je dobře (tam i zpátky to zafungovalo na prvním odkazu z googlu) … takže na heslech v plaintextu mi ani nevadí to, že se pak dají někde jinde použít, protože to jdou i s hashem (uznávám, sou lepší metody zabezpečení hesel, než v PHP md5() … ), ale zmínil bych trochu programátorské etiky, mít hesla uložená v plaintextu je prostě prasárna, ani programátor by neměl při běžném procházení mít přístup k heslům uživatelů při prvním pohledu do db! … vůbec celé zabezpečení podle mého patří ke slušnosti programátora a tomu, že se nesnaží klienta opít rohlíkem, ale prodává mu skutečně funkční produkt (kterému rozumí do detailu), ne jenom něco co dobře vypadá a třeba i funguje, ale při prvních potížích celý spadne atd. Jinak s článkem naprosto souhlasím v tom směru, že únik + nedůveryhodnost dat po útoku je extrémně závažný problém…
11:12 on Prosinec 29th, 2009
Ještě doplním jednu zajímavou techniku pro ty, kteří mají třeba týden staré zálohy a jsou příliš klidní:
Vtipné je, když hacker data ukradne a poté je nesmaže, ale instaluje skript, který třeba jednou denně 5 procent dat náhodně pomíchá. Třeba vybere náhodně dva řádky db a prohodí jim id a podobně. Fantazii se meze nekladou.
Majiteli si začínají stěžovat uživatelé a on pořád netuší, co se děje. Po čtrnácti dnech zjistí příčinu, ale to už je pozdě. I nejstarší týden stará záloha je pomíchaná a nepoužitelná. Jistě si dokážete představit, jaké důsledky by to mělo třeba pro eshop a jak vás může konkurent snadno zničit!
21:49 on Prosinec 29th, 2009
Martin Lendo: Kolikrát už jsem opravoval někomu web, kde i na měsíc staré záloze už byl nějaký backdoor script. Naštěstí se to jednoduše spraví, leckdo ale hack podcení a nechá tam díru jinou.
Musim říct, že s takovouhle škodolibostí jsem se ještě nesetkal.
10:38 on Prosinec 31st, 2009
Ano, je to usmevne, prevadzkovat webhosting a nerobit ani backupy. Ludia ako D. P. by nemali podnikat. Potom to vyzera ako vyzera. Bohuzial, takto to ide dokola, neni to prvy pripad. Zalozi sa nova sro a ideme znova, budeme neobmedzeni a lacni. Snad rok vydrzime.
00:42 on Leden 4th, 2010
K tomu plaintextu – za posledních několik měsíců jsem žádal asi 20krát o zaslání hesla… Vždycky přišel plaintext… Používají to i na obrovských projektech (snad přímo Souki tady v některém článku zmiňoval Mironet) a já se víc a víc bojím o své soukromí. No, myslím, že situace, kdy si pak nějaký brigádník otevře DB a vesele projíždí e-mailové schránky zákazníků (většina lidí používá stejná hesla všude), je dosti reálná…
Jinak ta věc s Neomezeny-hosting.cz mě opravdu překvapila a hrozně moc mě štve, že se takové zásadní věci nedají více dostat mezi veřejnost… Protože těch lidí, co tam narazí, bude určitě spousta…