Ako zabezpečiť komponenty a moduly voči hackerom

Napísal Administrator

Pondelok, 30 Október 2006 20:00

Pred časom bola zaregistrovaná vlha úspešných napadnutí stránok kde bola nasadená Joomla! a Mambo.
Ako sa už vie, nebola na vine samotná Joomla!, ale jej rozšírenia v podobe komponent a modulov ktoré nemá v správe Joomla! team.
Následne na to bol vydaný zoznam bezpečných a nebezpečných rozšírení. Samozrejme producenti reagovali na nedostatky svojich produktov, a okamžite vydali nové opravené verzie.
Čo ale s rožíreniami ktoré sme si napísali sami? Sú bezpečné? Ako ich treba skontrolovať a prípadne opraviť?
So zabezpečením web-stránok je to podobné ako so zabezpečením auta. Ak o to niekto veľmi stojí, raz sa mu podarí nájsť skulinku a tú zneužiť na svoje častokrát deštruktívne ciele.
Ale prečo to útočníkom uľachčovať? Nie je lepšie sa základným chybám brániť?

Teraz si predstavíme dve základné chyby a ako sa dajú napraviť:

1. Umožnenie priameho spúšťania PHP súborov (com_mojakomponenta.php)

Ak Váš php súbor nie je chránený voči priamemu spúšťaniu, a zhodou okolností napríklad spracuváva upload súborov, je možné, aby si útočník na server stiahol ľubovoľný súbor a následne si ho spustil. To má taký dôsledok, že útočník má prakticky voľné ruky a môže vykonať ľubovoľnú činnosť, napríklad čítanie ostatných súborov (odhalenie hesiel do databázy) alebo mazanie súborov.
Obrana je viac ako jednoduchá. Na začiatku každého PHP súboru musí byť umiestnený tento kód:

// no direct access
defined( '_VALID_MOS' ) or die( 'Restricted access' );

Ak premenná _VALID_MOS nie je definovaná, súšťanie súboru sa zastaví. Táto premenná sa definuje v súbore index.php a tým umožňuje spúšťanie ostatných súborov. Ak však na súbor pristupujete priamo, bez toho aby predtým prešlo správou Joomla!, spustenie súboru sa neumožní.
Ako vidíte, za malú kontrolu Vášho kódu to rozhodne stojí.

Pozn.: Práve táto chyba bola zneužitá na takmer všetky útoky ktoré prebehli po celom svete. Útok prebiehal tak, že cez súbor ktorým sa spracuvával upload obrázkov, sa uložil na stránky script, ktorý po spustený pozmenil súbor configuration.php (je to samozrejme zložitejšie ale toto vysvetlenie stačí).

Aplikáciu tejto ochrany doporučujem na každý Váš súbor PHP. Zneužitie bolo dokázané iba pri uploade, ale nikdy neviete čo sa niekomu podarí vykúzliť.

2. Umožnenie SQL Injection (vkladanie útočníkovho SQL do Vášho SQL)

Toto je všeobecne veľmi obľúbená metóda hacku. Patrí do základného balíku útokov na web-stránky.
Dôsledkom je všeobecne odhalenie dátovej štruktúry Vašej databázy, stiahnutie všetkých dát ktoré držíte v databáze, pozmenenie dát (falošné objednávky, nechcená reklama, ....), a v konečnom dôsledku aj zmazanie databázových tabuliek (samozrejme ak práva nad DB ktoré máte pre web-stránky to umožňujú).
Stiahnutie dát sa zdá byť nevinné, ale ak v DB udržujete mená a heslá užívateľov, dáta o bankových kontách klientov, alebo prinajhoršom čísla kreditných kariet a ich overovacie kódy, tak to zaváňa veľkým problémom zo zneužitia citlivých súkromných dát.
Nanešťastie je SQL Injection veľmi úspešný spôsob ako hacknúť web. Na svete je veľa zle napísaných web-stránok ktoré to umožňujú (zdá sa že najviac v USA). Obrana proti tomuto hacku pri použití PHP a MySQL žiaľ nie je nič jednoduché.

Ako sa také niečo dá uskutočniť? Pri zle napísanom webe nie je nič jednoduchšie.
Predstavte si stránku PHP ktorá má za úlohu zobrazovať detail nejakého formulára. Jedná sa o klasický spôsob, kedy zavoláte stránku za pomoci URL: /showDetail.php?id=31
Na tom ešte nie je nič zlého, ale ak tento požiadavok spracuvávate nevhodne, nastávajú problémy. Napríklad:
$id = $_REQUEST['id'];
$sql = 'SELECT * FROM mojaTabulka WHERE id=' . $id;
// .... dalsi kod
?>
Tento spôsob získavania dát určite dôverne poznáte a píše sa o nich vo všetkých príručkách, ale nie je to najsprávnejšie použitie.
Teraz si predstavte že zadáte niečo ako URL: /showDetail?id=31;delete from mojaTabulka;
Keď si to spojíte s SQL ktorý máte v kóde, tak dostanete toto: "SELECT * FROM mojaTabulka WHERE id=31;delete from mojaTabulka;"
Pravdepodobne tušíte problém ktorý nastane. Dôvod názvu útoku SQL Injection je evidentný. Treba si uvedomiť to, že na tento útok stačí iba zadať do URL niečo iné ako sa bežne očakáva. Získanie zoznamu tabuliek a ostatných dát je možné, ale keďže sa nevenujem tejto činnosti tak Vám ju neviem presne popísať. Konieckoncov toto nie je návod na to, ako útok uskutočniť, ale ako sa proti nemu brániť. Ale ak máte o túto oblasť záujem, verím že cez rôzdne internetové vyhľadávače nájdete množstvo príkladov a dokonca automatov pomocou ktorých uskutočníte úspešný útok na web-stránky.

Ako som spomínal skôr, obrana pri použití PHP a MySQL nie je jednoduchá, ale Joomla! samozrejme dodáva spôsob ako získať bezpečný obsah premenných. Jedná sa o použitie kombinácie funkcie mosGetParam(), intval(), floatval() a strval().
Takže upravené získavanie ID bude vizarať takto:
$id = intval( mosGetParam( $_REQUEST , 'id' , 0 ) );
Funkcia mosGetParam umožňuje získať obsah premenných viac menej v bezpečnej forme a php funkcia intval prevedie dodaný obsah premennej na číslo, pričom ostatný text je ignorovaný. Podobným spôsobom sa dajú zabezpečiť aj ostatné premenné. Treba však upozorniť, že PHP ako také nemá podporu vynucovania dátových typov a v kombinácii s MySQL neumožňuje použiť PreparedStatement čo je najbezpečnejší spôsob selektovania dát z databázy. To znamená, že kombinácia PHP a MySQL nie je z pohľadu bezpečnosti najlepšia kombinácia. Tento nedostatok sa dá ošetriť, ale ako vidíte, chybka sa dá spraviť veľmi ľahko.
Ak chcete získať podrobné informácie o mosGetParam doporučujem naštudovanie popisu funkcie ktorý sa nachádza na help.joomla.org .

Téma okolo ochrany pred hackom je nevyčerpatelná, ale dúfam že som Vám objasnil aspoň dve najčastejšie bezpečnostné chyby ktoré sa nachádzajú v kompenentách a moduloch.
Ak máte pripomienky, alebo rošírenia riešení, uvítam Vaše názory v diskusii k článku.

< Dozadu

Posledná úprava Pondelok, 06 Apríl 2009 21:42