luzer.sk

Ci uz hladate na internete materialy na tvorbu webovych stranok, alebo si len tak, raz za cas pozriete nejaky ten bezpecnostny portal, urcite ste sa stretli so slovami ako XSS alebo script injection. V tomto clanku sa na tuto problematiku pozrieme blizsie a predvedieme niektore chyby, ktorym by ste sa urcite mali vyvarovat.

Co to teda script injection je?

Ako uz nazov hovori, jedna sa o metodu vlozenia (napr. skodliveho) kodu, do webovej aplikacie, prostrednictvom nejakej bezpecnostnej diery v danej aplikacii. Netreba zabudat, ze pri pokuse o utok na webovu aplikaciu, su kozmeticke doplnky typu JavaScript absolutne neucinne.

XSS = Cross site Scripting

Cross site Scripting (teda XSS alebo CSS) nastava, ked dynamicke webove stranky zpracuju data podstrcena uzivatelom a zobrazia vystup, bez toho, aby bol poriadne overeny. Tieto data maju vacsinou formu odkazu, ktoreho sucastou je tiez skodlivy kod,a su sirene vsetkymi prostriedkami internetu.

„Webova stranka obsahuje text a HTML tagy, ktore generuje server a ktore potom interpretuje prehliadac. Pri statickych webovych strankach mate plnu kontrolu na tym, ako ich prehliadac interpretuje. Dynamicky tvoreny obsah vsak plnu kontrolou nad interpretaciou klientom neposkytuje. Jadrom problemu je moznost vlozenia skodliveho kodu, ktory je nasledne vlozeny do vystupneho kodu, bez toho, aby mal navstevnik alebo administrator dostatok informacii o tom co sa deje a mohli zaistit dostatocnu ochranu.” ( CERT Coordination Center )

Kedze tento clanok nie je pisany ako navod na utok, ale skor ako navod na obranu pred vyssie zmienenymi metodami, predstavime si niektore zname bezpecnostne diery.

Obycajny php script ako moze vyzerat pomerne bezpecne. Ked vsak napriklad urocnik vlozi za obsah premennej meno napriklad toto: . Co sa stane? Ako vidite, malou upravou kodu ktory som pred chvilkou napisal mozeme dosiahnut presmerovanie na inu stranku (JS je na taketo ucely ako rodeny:) a napr. ukradnut cookies.

alebo na internete tolko omielany priklad: predstavme si, ze formular pomocou metody GET odosle premennu prikaz a kod vyzera takto: exec”man $prikaz”; Vyzera to znovu bezpecne, nie? zadam prikaz ls a vysledny string bude vyzerat : “man ls“. Ale co ak ako premennu $prikaz zadam napr. "ls; rm *"? Aj takto sa moze vytvorit velmi nebezpecna aplikacia.

Okrem vsetkeho vyssie spomenuteho, je taktiez velmi dolezite kontrolovat, ci ta ktora premenna nebola podvrhnuta. Je potrebne si uvedomit aj to, ze kedysi obrovská vyhoda PHP, kedy je jedno ci su udaje odosielane metodou GET alebo POST, pretoze ich hodnoty sa nastavia do premennych zodpovedajucich nazvu parametra, je v dnesnej dobe povazovana za potencialne nebezpecnu a prednastavene je zakazana (register_globals = off). Mnoho bezpecnostnych problemov malo povod v podvrhnuti premennej cez URL, ktora by inak vznikla za behu skriptu napríklad pri prihlásení. Preto sa silne odporuca pouzivat na pristup k parametrom zasadne tieto polia:
$_GET["var1"] // pre parameter var1 predany metodou GET
$_POST["var2"] // pre var2 predany metodou POST
$_SESSION["var3"] // pre premennu var3, ktora je sucastou sedenia