ARCHIV

Bezpečnosť webovej aplikácie I.

Bezpečnosť počítačov v dnešnej dobe je dosť podceňovaná a braná na veľmi malú váhu, čo je veľmi veľká chyba. Rozhodol som sa napísať malý tutoriál, v ktorom vás oboznámim s najčastejšími a najzakernejšími útokmi. V tomto jednom článku sa pokúsim stručne opísať a navrhnúť riešenie najzávažnej zraniteľnosti, tou je Injection.

9.3.2012 00:00 | Marek Beleščiak | Články autora | přečteno 7401×

Za pomoci tejto zraniteľnosti dokáže útočník donútiť program či skript niečo, čo jeho vývojár pôvodne nechcel aby vykonal. Táto zraniteľnosť sa hojne vyskytuje na celom internete vo velkom počte stránok. Je veľa miest, kde sa dá vykonať injektáž, ja sa ale budem venovať len dvom a tie sú SQL Injection a Log injection. Podstatou tohto útoku je nedostatočná kontrola vstupu a z pôvodného plánu vznikne upravený nebezpečný kód. Pozrite si nasledúci dopyt na databázu:

Len málokedy je premenná id statická, takže musíte za id dosadiť vstup, aby ste dostali to, čo potrebujete. Obrovská časť php programátorov to robí veľmi zlým ale zato obľubeným spôsobom. Proste tam dosadia vstup spojením dvoch reťazcov:

Pre neznalcov php poviem len, že $_GET je pole vygenerované z QUERY_STRING. Problém je, ale, že nevieme, čo sa skrýva za magickým $_GET['id']. Príklad: pokiaľ by $_GET['id'] sa rovnal "1 OR 1=1" náš dopyt by zmenil podobu na:

Tento kód namiesto zobrazenia jedného zákaznika zobrazí úplne všetkých. Tento dopyt je sám o sebe neškodný, ale po jeho úspechu si už útočník nájde cestu.

Riešenie ?

Problém je len v tom, že id má byť číslo a nemá sa interpretovať ako reťazec. Medzi jedno z riešení patrí veľmi obľubené a elegatné printf(), funkcia ktorá má veľa variantov (sprintf,snprintf,vprintf,...) stále ale vravíme v podstate o tom istom. Náš problém vyrieší aj nasledujúca funkcia:

Podotýkam, že formátov je v printf veľa, tie najbežnejšie sú %f (float), %d,%i (číslo), %u (kladné číslo), %s (reťazec). S takýmto interpretovaním našho dopytu sme ošetrili vstup a môžme bezpečne odoslať dopyt databázovému serveru.

Ďalším, asi najhorším problémom je, keď máte odoslať na server nejaký reťazec, dáta. Uveďme si zasa nejaký príklad napr. s prihlasením používateľa:

Zasa nemôžeme dôverovať dátam zo vstupu, pretože v nich môže byť absolutne hocičo. Príklad: pokiaľ by sme do mena dali "' OR 1=1 #" náš dopyt by sa zmenil na:

Ako vidíte, dopyt vráti absolutne všetky riadky v tabuľke pretože pre každy platí, že 1=1 a časť za # sa berie ako komentár takže ju server úplne ignoruje. Zvyčajne sa pracuje len s jedným, obyčajne prvým riadkom v tabuľke takže po tomto príklade sa prihlásite za prvého užívateľa, zvyčajne admina s vysokýmmi právami!

Existuje tu funkcia mysql_real_escape_string(), ktorá by mala danému problému predísť, escapnutím všetkých problémových znakov, takže náš dopyt by napokon vyzeral takto:

V takejto podobe, už môžme bezpečne poslať dopyt na server, dôležité je aby ste reťazec uzatvorili do apostrofov príp. úvodzoviek.

Ultimátne riešenie

Asi rok dozadu som objavil jedno vynikajúce riešenie problému sql injection. Je ním prehodenie vstupu do hexadecimálnej reprezentácie a následne poslanie na server. Funkcia pre c/c++ mysql_hex_string(), php bin2hex(). Jediným obmedzením je asi to, že výsledný reťazec bude jeho pôvodná dĺžka * 2, ale myslím, že to není nejaký veľký problém pretože aj pre mysql_real_escape_string() musíte alokovať toľko isto miesta, otázna je len skutočná použitá časť, ktorá sa posiela na server.

Uveďme si malý príklad ako by vyzeral dopyt v hexadecimálnej reprezentácií:

Ako môžte sami vidieť, vstup je dokonale ošetrený tak, že znaky pôvodného reťazca sú zmenené na ich ascii hodnoty v hexe s 0x. Je tu ešte jeden spôsob a to namiesto 0xXX použiť mysql funkciu UNHEX().

Aby som nezabudol, pri písaní svojho programu nezabudnite dobre zvážiť používanie prepared statementov.

Log Injection

Log Injection je zraniteľnosť logov vyzerať inač ako by mali. Stručne vám vysvetlím o čo vlastne ide. Pozrite si nasledujúcu funkciu:

	int Log(const char* file, const char* user) {
		FILE* fp = fopen("access.log", "a");
		fprintf(fp, "User %s: Requested  File %s\n", user, file);
		fclose(fp);
	}
	

Náš log vypadá takto:

	User John: Requested File music.ogg
	User Joe: Requested File project.tar.gz
	

Naša funkcia ale nijak nekontroluje nepovolené znaky to znamená, že ak by sme jej podstrčili napr. správu "article.txt\nUser Admin: Requested File secret.gpg" a systém užívateľa "Joe" náš záznam správ by sa zmenil na:

	User John: Requested File music.ogg
	User Joe: Requested File project.tar.gz
	User Joe: Requested File article.txt
	User Admin: Requested File secret.gpg
	

Záver

Dúfam, že som vám objasnil princípy a problematiku tejto zraniteľnosti. Jediné, čo musíte robiť je stále, stále, stále kontrolovať vstupné dáta a nikdy im neveriť.

Verze pro tisk