Ako som sľúbil už v článku “Moja prednáška na prvom Slovenskom BarCampe“, rozhodol som sa celú prednášku prepísať aj s dodatočným komentárom. Moja prednáška je síce dostupná aj ako video, no nestihol som sa v nej detailne venovať všetkým častiam, preto tak urobím v tomto článku.

Bezpečnostné chyby pri budovaní projektu

Budovanie projektu

Každý, kto v živote vybudoval akýkoľvek projekt, či už sa jedná o blog, alebo veľký portál si iste pamätá niekoľko základných otázok, ktoré si položil. Určite sa nájdu aj výnimky, ako napríklad ľudia, ktorí si presondovali trh, poznali väčšinu úskalí a problémov, ceny a možnosti, ktoré budú na začiatok k dispozícií.

Ostatní, ako napríklad aj ja, si však položia približne tieto otázky:

• V akom programovacom jazyku chcem mať napísaný projekt?
• Najzákladnejšia otázka, samozrejme až po tej, keď už viete o čom projekt bude. Tá má však s bezpečnosťou pramálo spoločné. Väčšina si volí taký jazyk, v ktorom sú dobrí (aspoň si to myslia). V drvivej väčšine je to php, posledne už aj Ruby. Na túto otázku nadväzuje ďalšia.
• Aký hosting si mám vybrať?
• Hosting si drvivá väčšina vyberá podľa svojich finančných možností a až v druhom rade podľa možností, ktoré im hosting ponúka. Mnoho malých projektov začalo len so zakúpením domény a hostingu, čo často nemusí presiahnuť niekoľko tisíc korún ročne, občas dokonca ani tú tisícku. Málokto si však uvedomuje, že s cenou často súvisí aj kvalita a miera zabezpečenia hostingu.
• Vytvorenie čo najväčšieho množstva funkcií
• Aby ste porazili konkurenciu, je potrebné priniesť niečo viac. Často nové projekty prinesú obrovské množstvo funkcií, mnoho ich je nedotiahnutých, takmer žiadna ošetrená. V praxi sa s týmto fenoménom stretávam denne.
• Použiteľný dizajn
• Párkrát som bol kritizovaný za tento bod, no dizajn je veľmi často dôležitým faktorom, ktorý si majiteľ projektu volí. Dizajn, napríklad na blogu, môže znamenať práve jedinú nebezpečnú časť. Tento fakt však zohľadňuje len málo ľudí pri budovaní nového projektu.
• Motivovať užívateľov
• Užívatelia, hlavne tí, ktorí aktívne sa pohybujú na weboch konkurencie, musia byť pozitívne motivovaný (občas pomôže aj negatívna motivácia, keď sa chodia užívatelia krvopotne biť za svoju pravdu), aby konkurenciu opustili a prešli k vám.
• Vytvoriť si dobré meno
• S predošlým bodom súvisí aj vytvorenie dobrého mena. Je to jeden z najdôležitejších bodov, pretože ak vás niekto prichytí pri tom, že napríklad emaily svojich užívateľov predávate ďalej spamerom, môžete sa s nimi rovno rozlúčiť.

Väčšina z týchto bodov však ignoruje bezpečnosť, teda ak si ich nerozšírite. Napríklad programovací jazyk. Veľmi vhodná otázka je, ktorý z jazykov poskytuje to najväčšie množstvo bezpečnostných riešení, ktoré tvoria profesionáli? U hostingu to zas bude otázka: Ako často robia zálohy svojich serverov a separujú ich od svojich bežných serverov? Otázok by sa dalo nájsť mnoho, tie si však pokladá skutočne málokto.

Najčastejšia a najväčšia chyba

Ak ste už týmito otázkami prešli a začínate pracovať na danom projekte, dávajte si pozor na najčastejšiu a najväčšiu chybu, akú môžete pri budovaní projektu spraviť. Tou je prílišná dôverčivosť. Tá sa potom môže a často sa aj vypomstí väčšine takto trúfalých majiteľov webov.

Hovorím konkrétne o dôvere v:

• Dáta získané od užívateľov
• Veriť užívateľom je tou najväčšou chybou, akú môžete urobiť. Užívatelia sú často tým prvým zdrojom problémov, ktoré vám nastanú. Užívatelia, ktorí navštevujú váš web, majú rôzne odborné znalosti bezpečnosti, pričom sa objavia jak laici, tak určite veľmi znalí, vychytralí jedinci, ktorých nazývame hackeri.
• Dáta získané z databáz
• Veľmi veľkou chybou je veriť vlastným databázam. Neraz sa stalo, že práve databáza bola kompromitovaná a bol pridaný XSS kód, ktorý užívateľov presmeroval na infikované stránky za účelom infikovať ich malwarom.
• Dáta získané od tretích strán
• Do tejto skupiny môžete zaradiť rôzne widgety, gadgety a iné blbôstky, ktorými dnes mnohí blogeri (vrátane mňa) oživujú svoj web. Určite sem však môžete zaradiť aj dáta, ktoré získate napríklad z RSS zdrojov, či cez API od iných webov, alebo aplikácií.
• Dáta získané z dôveryhodných zdrojov
• Dáta, ktoré považujete za dôveryhodné a neočakávate u nich, že by sa vás pokúsili infikovať, ako napríklad dáta, ktoré si vymieňate vrámci affilate programu, či dáta, ktoré vám poskytuje spriatelený obchod. Ak by bol tento “dôveryhodný” zdroj úspešne infikovaný, môžete si byť istý, že sa dostane aj na vás.
• Hostingovú spoločnosť
• Pravdepodobne aj sami uznáte, že hostingová spoločnosť je tou poslednou, ktorá sa vás pokúsi poškodiť. Majte na pamäti, že v tejto spoločnosti pracujú rôzni ľudia a často len cena vás delí od bezpečnostného incidentu. Taktiež spoločnosť prevádzkuje mnoho iných serverov, či dokonca webov na jedinom serveri a tak sa môže ľahko stať, že bude váš web kompromitovaný po zneužití niektorej z bezpečnostných chýb softvéru, ktorý na serveri beží.
• Priateľov
• Parkrát som už vo svojej praxi zažil, že práve urazení kamaráti stáli za poškodením webu. Mnoho začínajúcich projektov je napríklad testovaných na priateľoch, či práve priatelia sa starajú o správu jednotlivých častí. Tento spôsob však môže byť časom deštruktívny, hlavne ak medzi vami dôjde k roztržke a priateľ sa urazí/nahnevá, má dobrú možnosť ako vám ublížiť. Rovnako aj vaši priatelia sa radi pochvália čo kde robia a ak váš projekt bude čo i len trošku úspešnejší, môžete si byť istí, že sa kde tu objavia interné informácie z úzadia budovania projektu.

Byť dôverčivý je veľmi veľká chyba, ktorá sa vám môže veľmi ľahko vypomstiť. Radšej byť zdravo paranoidný ako potom neskôr ľutovať.

Najčastejšie príčiny vzniku bezpečnostných zraniteľností

V svetle týchto poznatkov sa môžeme pozrieť na najčastejšie príčiny vzniku bezpečnostných zraniteľností. Tie vznikajú hlavne v týchto prípadoch:

• Pri používaní cudzích kódoch
• Ak používate cudzí kód, nielen open-source, ale aj iný typ, jeho kód pravdepodobne nebudete poznať a tak len ťažko dokážete odhadnúť riziká. Pri veľkých, známych kódoch (nechcel som písať aplikáciách, často sa jedná len o knižnice) tento problém v určitom zmysle odpadáva, prácu za vás vykoná komunita. Čim je kód menej populárny, tým väčšie riziko predstavuje. Napríklad kód od kamaráta môže znamenať obrovské bezpečnostné riziko, aj keď dotyčný môže dodržiavať všetky princípy písania kvalitného a bezpečného kódu, kde tu chybičku spraví.
• Nedostatočná aktualizácia používaných kódov
• Tento bod sa týka vo veľkej miere hlavne open-source kódov, ktoré sú najčastejšie obeťami útokov. Samozrejme to platí pre všetky typy kódu. Podobný prípad sa stal na súťaži Pwn2Own, keď na hacknutie MacBooku bola využitá rok stará zraniteľnosť, ktorá bola už dávno ošetrená v originálnej knižnici, ktorú však tvorcovia prehliadača Safari zabudli aktualizovať.
• Nadmerná dôvera v dáta prijaté z akéhokoľvek zdroja
• Tento bod som rozobral v sekcii vyššie, odporúčam vám sa k nemu ešte raz vrátiť (veď opakovanie je matka múdrosti)
• Absencia ošetrovania vstupných a výstupných dát
• Tento bod je príčinou 95% všetkých vzniknutých bezpečnostných problémov, keďže neošetriť vstup či výstup je jednou z najzávažnejších chýb vôbec.
• Filtrovanie dát len na jednej strane (vstup/výstup)
• Uvedomujem si, že tento bod patrí pod ten predošlý, ale je tak často podceňovaný, že som sa rozhodol oddeliť. Filtrovanie na jednej strane môže znamenať katastrofu, dôvod vysvetlím nižšie.
• Zlý návrh projektu (z pohľadu kódu)
• Často programátori pri vzniku nového projektu robia mnoho chýb len preto, lebo nemajú čas, či dostatočné skúsenosti. Tieto prehrešky voči bezpečnosti sú následne zodpovedné za majoritné množstvo problémov, keďže upraviť starý kód je niekoľkonásobne ťažšie, ako celý projekt naprogramovať od začiatku.

Vyvarujte sa týmto chybám a odstránite 99% príčin vzniku bezpečnostných zraniteľností vedúcich k vzniku závažných problémov.

Príklad fungovania bežného webu z pohľadu kódu

Bežný web, ale web, ktorý postráda filtrovanie na ktorejkoľvek zo strán, funguje asi tak, ako je zobrazené na obrázku vpravo. Takýto web je náchylný na mnoho rôznorodých typov útokov, pričom porušuje body, ktoré som opisoval vyššie.

Základnou štruktúrou bežného webu je:

• Vstup



• Na vstupe vstupujú dáta, ktoré pochádzajú z rôznorodých zdrojov, či už to sú užívatelia, alebo akýkoľvek iný zdroj. Týmto spôsobom sa môžu do vašej aplikácie dostať prakticky akékoľvek dáta, ktoré môžu poškodiť váš web a to nielen na výstupe, kde môžu napríklad vytvoriť XSS, ale aj v samotnom jadre, kde môžu spôsobiť SQL Injection, či buffer overflow.
• Jadro
• V jadre sa spracovávajú vstupná dáta, s ktorými sa následne pracuje. Príkladom môže byť vyhodnocovanie ankety, kde sa pripočíta hlas, zapíše do databázy z ktorej sa následne vyberie výstup. Ak sú dáta neodfiltrované, môže dôjsť k SQL Injection.
• Výstup
• Výstupné dáta potom putujú na web, alebo do iného rozhrania, napríklad RSS, či WML. Ak tento výstup nepoužíva filtrovanie, môže dôjsť k zobrazeniu XSS kódu, ktorý môže následne napríklad infikovať vašich návštevníkov malwarom. Možností je mnoho, stačí si len vybrať.

Toto sú základné dôvody, prečo by mali byť vstupné dáta filtrované na oboch stranách. Teraz sa pozrieme, ako vyzerá štruktúra web, ktorý takéto filtrovanie má.

Príklad fungovania bezpečného webu z pohľadu kódu

Zabezpečený web musí používať dostatočné filtrovanie proti všemožným škodlivým kódom na oboch stranách, nestačí len na vstupe. Pri tejto sekcii mi včera jeden užívateľ na našom IRC kanáli položil otázku:

Prečo je potrebné filtrovať aj výstup? Nie je jednoduchšie filtrovať len vstup a tým sa vyvarovať možným problémom?

Moja odpoveď bola jasná: nestačí. Ak budete filtrovať vstup, budete musieť veľmi jasne určiť, aký kód môže vstúpiť. Napríklad, ak užívateľ môže poslať kód, budete musieť presne vedieť, aké časti kódu môžu znamenať problém. XSS kód je možné poslať aj cez mnoho iných objektov ako SCRIPT. Budete musieť vedieť dokonale odfiltrovať všetky vstupné dáta, nielen proti SQL Injection, či buffer overflow, ale samozrejme aj proti XSS. Nieže by ste to na výstupe robiť nemuseli, ale ak viete, že užívateľ napríklad v komentári nesmie poslať akýkoľvek tag, tak ich jednoducho vyčistíte, pričom v databáze ho máte v poriadku a tak vás nič neobmedzuje pri vyhľadávaní. Toto však nie je hlavný dôvod. Tým je, že vaša databáza môže byť napadnutá z vonku, pričom môže byť dovnútra vložený škodlivý XSS kód, ktorý môže napríklad vašich návštevníkov infikovať malwarom. Preto, ak filtrujete aj na výstupe, podobný pokus nebude mať žiadny úspech, pretože sa tento kód na webe nezobrazí (minimálne neprevedie). A to je hlavným benefitom filtrovania na výstupe.

Základnou štruktúrou dobre zabezpečeného webu je:

• Vstup
• Na vstupe vstupujú dáta, ktoré pochádzajú z rôznorodých zdrojov, či už to sú užívatelia, alebo akýkoľvek iný zdroj. Týmto spôsobom sa môžu do vašej aplikácie dostať prakticky akékoľvek dáta, ktoré môžu poškodiť váš web a to nielen na výstupe, kde môžu napríklad vytvoriť XSS, ale aj v samotnom jadre, kde môžu spôsobiť SQL Injection, či buffer overflow.
• Filter
• Filter akýkoľvek škodlivý kód zadrží a odstráni, či upraví tak, aby sa stal neškodný. Jeho funkčnosť a spracovanie na jeho tvorcovi, bolo by však dobré, keby zvládal identifikovať všetky existujúce hrozby a bol schopný sa s nimi vysporiadať. Ich zoznam môžete nájsť na stránkach združenia OWASP
• Jadro
• Jadro spracuje príchodzie dáta, ktoré sú už očistené od škodlivého kódu, čo znamená, že môže pokojne vykonať akýkoľvek naprogramovaný úkon.
• Filter
• Ďalším filtrom je ten na výstupe. Ako som už písal vyššie, tento filter sa postará hlavne o XSS, kedy ho buď úplne potlačí vďaka jeho identifikácií a analýze (IDS), alebo ho jednoducho znefunkční za pomoci rôznych dostupných funkcií v jednotlivých jazykoch.
• Výstup
• Výstupom sú potom jasné a čisté dáta, ktoré nemôžu poškodiť Web, či iné rozhranie, ako XML, či WML.

Ak navrhnete vašu aplikáciu (web) takýmto spôsobom môžete si byť istý, že sa len tak nestanete obeťou hackera, ktorý nebude schopný obísť dvojitú filtráciu. Jedinou nevýhodou tohto návrhu je jeho mierne spomalenie aplikácie. To sa však dá kompenzovať skvalitnením celého kódu, vytvorením veľmi dobrého, flexibilného filtra, ktorý môže byť napísaný v nižšom jazyku, aby sa zvýšil jeho výkon, či doplnením výpočtovej kapacity. Viem, že pri vznikajúcom projekte je práve tento bod veľkým problémom, ale zas začínajúci projekt nemá problémy s priveľkým prílivom návštevníkov. Keď budú čísla zaujímavé, budú už aj zisky projektu na veľmi dobrej úrovni a tak bude možné vykonať vyššie zmienené úpravy.

Najčastejšie neošetrované vstupy

Ponúkam vám zoznam najčastejšie neošetrovaných vstupov, na ktoré vývojári zabudnú, alebo jednoducho neočakávajú, že by sa práve tie mohli stať vstupom jednotlivých útokov.

• Vyhľadávacie políčko
• Je tým prvým, ktoré hacker vyskúša pri vstupe na web a to nielen na zraniteľnosti XSS, ale aj SQL Injection. Až príliš často sú náchylné práve tieto políčka. Nenechajte sa zmiasť tým, že dáta posielate metódou POST. Tá vás od prieniku nijak neochráni.
• Referer
• Táto funkcia, či vlastnosť sa nachádza vo väčšine dnešných prehliadačov. Je to údaj, odkiaľ užívateľ na váš web prišiel. Prenáša ho samotný prehliadač a programátori s ním veľmi často pracujú, aby dokázali ponúknuť viac príchodziemu užívateľovi. Práve tieto vstupy bývajú veľmi málo ošetrované a často je cez ne možne vykonávať najrôznejšie typy útokov.
• Cookies
• Dnes jedna z najpoužívanejších častí prehliadača programátormi webu. Cookies sú malé textové reťazce ukladané na strane prehliadača, ktoré najčastejšie nesú identifikačné údaje pre daného užívateľa. Cez 50% webov využívajúcich Cookies je náchylných na niektorú formu útoku práve cez tento vstup.
• URL
• Najčastejšia forma útoku. Hacker len vymení, či doplní údaje zasielané cez URL a tým sa mu často podarí úspešne objaviť niektorú zo zraniteľností. Cez URL je možné vykonať aj CSRF útok, ktorý je dnes najpodceňovanejším, no zároveň asi najnebezpečnejším vôbec.
• Formuláre
• Taktiež veľmi obľúbené miesto pre testovanie zraniteľností. Väčšina formulárov nemá dostatočnú ochranu, hlavne čo sa týka tých atypických, ako ankety. Aj anketa je len formulár, ktorý však len zriedkakedy býva dostatočne zabezpečeným miestom. Je však nutné si pamätať, že váš web je tak bezpečný, ako jeho najmenej zabezpečená časť. Ak aj investujete čas a veľa práce do ošetrenia všetkých možných vstupov ale zabudnete na ankety, vaše úsilie bolo zbytočné.
• Diskusie
• Rovnako veľmi obľúbené miesto na otestovanie bezpečnostných zraniteľností. Diskusie, či komentáre bývajú veľmi častým miestom pre všemožné typy zraniteľností napriek tomu, že sa jedná o výlučne užívateľské dáta. Diskusie sú výborným príkladom prístupu programátora k bezpečnosti celého webu.
• Flash
• Flash predstavuje aplikáciu tretej strany. Dnes ho používa vďaka boomu YouTube takmer 96% všetkých návštevníkov. Flash však môže tiež obsahovať veľmi závažné zraniteľnosti, hlavne XSS. V tomto prípade myslím Flashové objekty vytvorené pre daný web, nie Flash ako technológiu.

Ako môžete vidieť sami, potencionálnych vstupov je mnoho a to som vynechal obrovské množstvo ďalších. Je potrebné zabezpečiť akýkoľvek vstup, najlepšie aj robiť “námatkovú” kontrolu priamo v jadre, nie však na úkor rýchlosti, či kvality celého webu.

Prečo sa zaoberať zabezpečovaním webu

Túto otázku dostávam takmer vždy, keď prezentujem objavené zraniteľnosti na testovanom webe. Veľké množstvo majiteľov webu si jednoducho neuvedomuje závažnosť tej ktorej zraniteľnosti a preto mi pokladajú túto otázku. Moja odpoveď je vždy asi takáto:

• Budovanie dobrého mena
• Ak sa váš web stane obeťou hackera môžete si byť istí, že prídete o časť svojich návštevníkov. Ak sa jedná o internetový obchod, strata môže byť deštruktívna.
• Možnosť predbehnúť konkurenciu
• Ak máte kvalitne zabezpečený web, môžete sa sústrediť na budovanie nových funkcií a iných častí, ktoré vám umožnia predbehnúť konkurenciu. Tá bude neustále bojovať s rôznymi problémami, ktoré ju budú neustále zdržovať.
• Môcť viacej riskovať
• Získate možnosť poukázať na bezpečnostné problémy konkurencie, čím pravdepodobne pritiahnete časť z ich návštevníkov, či si dokážete vytvoriť oveľa lepšie meno v povedomí verejnosti.
• Prinášať lepšie a kvalitnejšie služby
• Keď budete mať dobre navrhnuté bezpečnostné riešenie, môžete ho “posúvať” medzi projektami a ich vznik bude neuveriteľne rýchli oproti konkurencii, ktorá bude neustále musieť riešiť dookola tie isté problémy. Podobné výhody prinášajú dnes frameworky.
• Budete môcť pokojne spať
• Jeden z najväčších benefitov, prečo ošetriť svoj web (aplikáciu). Pokojný spánok vám nevynahradí prakticky nič. Ak prídete o starosti s bezpečnosťou a dokážete sa triezvo postaviť k predchádzaniu bezpečnostných incidentov a eliminovaniu bezpečnostných rizík, získate mnoho krásnych dní, ktoré by ste inak strávili lámaním si hlavy, ako sa teraz dostať z ošemetnej situácie.

Ako zabezpečovať

Zabezpečiť svoj nový, či existujúci projekt je dlhodobý proces, ktorý vyžaduje mnoho malých obetí a ústupkov, ktoré sa po čase zmenia na raj benefitov, ktoré som opísal vyššie.

Najlepšie sa držať asi týchto bodov:

• Vytvoriť si dobré bezpečnostné návyky
• Veľmi dôležitý bod. Ak budete mať dobré bezpečnostné návyky, vytvárať zraniteľnosti bude pre vás veľmi neprirodzené a budú vám byť do očí už z diaľky. Ak poznáte princípy, nepotrebujete svoj web auditovať dookola a nemusíte tak plytvať prostriedkami, ktoré môžete rozumnejšie využiť na ďalšie rozširovanie vášho projektu.
• Zaujímať sa o nové trendy v bezpečnosti
• Nemusíte byť odborníkmi na bezpečnosť, to nechajte na druhých. Vy sa však aktívne zaujímajte o nové trendy, možnosti a spôsoby. Stačí, ak budete mať o nich predstavu. Na tej sa dá potom veľmi kvalitne stavať a viete si prioritizovať jednotlivé úlohy.
• Dať možnosť ľudom hlásiť objavené zraniteľnosti
• V zahraničí sa zoznam pravidiel umožňujúcim hlásenie zraniteľností nazýva “Disclosure Policy”. V našich podmienkach sú skôr výnimkou, ako pravidlom. Veľmi vhodné sú aj odmeny objaviteľom. Tých pár korún, či zľava na vaše produkty je minimálna “obeť” oproti tej, ktorú by ste museli priniesť pri zneužití zraniteľnosti hackerom a následným poškodením vašeho dobrého mena, ktoré ste roky budovali.
• Najať si odborníkov ako konzultantov
• Ak už máte rozbehnutý projekt, alebo začínate od úplného začiatku a máte dostatok finančných prostriedkov, investujte ich do odborníkov znalých bezpečnosti, ktorých si však najmite ako konzultantov a nie na tvorbu auditu. Audit vám pomôže odstrániť existujúce chyby, nedokáže vás však zbaviť zlých bezpečnostných návykov, ktoré máte a vďaka ktorým budete neustále robiť tie isté chyby.
• Naučiť sa byť zdravo paranoidný
• Tento bod často vyvoláva úsmev na tvári poslucháčov, pritom sa jedná o najdôležitejší bod celej sekcie. Byť zdravo paranoidný vám často môže zachrániť “kožu”. Nedôverujte nikomu, ani vlastným zamestnancom, neverte dátam zo žiadnych zdrojov, neverte ani vlastným serverom. Samozrejme len v miere zdravého rozumu, určite to nezačnite preháňať. Zdravá paranoja je taká, kým nejde na úkor, napríklad dobrých vzťahov v spoločnosti. Dávajte si pozor na správnu mieru, no nezanedbávajte ju a pestujte si ju.

Záver

Toto je asi všetko, čo som chcel doplniť k daným slidom, ktoré si môžete pozrieť na konci tohoto článku. Odporúčam všetkým, pre ktorých sú tieto informácie nové, aby si ich čítali častejšie a hlavne sa nad nimi zamysleli a uspôsobili si ich na mieru presne pre seba a svoj projekt. Ak budete mať akékoľvek otázky, pokojne sa pýtajte v diskusii pod článkom.

Web 2.0 Bezpečnosť

Web 2.0

Web 2.0 je dnes jeden z najpopulárnejších buzz slov (buzz word) vôbec. Pre väčšinu toto slovíčko označuje technológiu, ktorá určitým spôsobom nahrádza schopnosti a možnosti Flashu. Je to však veľký omyl. Táto technológia, nazývaná tiež AJAX(J), je len veľmi malou časťou celej skupiny Web 2.0. Patrí sem napríklad komunikácia cez API, už spomínaný AJAX, či SAAS (Software as a Service (Applications on demand)), či centralizovaný užívateľský obsah (sociálne siete, wiki, blogy, feedy, podcasty/videocasty) a mnoho iného. Asi najlepšie bude, ak si celý zoznam prezriete v prehľadnej logickej mape, ktorú vytvoril Petko D. Petkov.

• Čo všetko je Web 2.0? (prepis nižšie zobrazenej mapy)
• Užívateľsky sústredený (tvorený) obsah
• Obsah pre masy
• Weblogy
• Mikro Blogy
• Sociálne záložky
• Wiki
• Podcasty, Videocasty, Screencasty
• Feedy
• Sociálne orientovaný obsah
• Sociálne siete
• Komunity/Fóra
• Služby a API
• Flexibilne, Mixovateľné
• Orientované na užívateľov
• JavaScriptové Widgety
• JSON/AJAX
• Aplikačné spracovávanie
• Data in the cloud
• Applications on demand (Software as a Service)

Web 2.0 Zraniteľné miesta

Zraniteľných miest u Web 2.0 aplikácií (webov) je omnoho viac hlavne z dôvodu, že používajú omnoho viac vstupov ako bežné aplikácie (weby). Niekoľko základných bodov, ktoré odlišujú bežný web od web 2.0 z pohľadu zraniteľných miest.

• Dáta získavané na pozadí
• Štandardný princíp JSON/AJAX aplikácií, ktoré dáta získavajú na pozadí (nie je potrebné znovunačítanie celej stránky). Veľmi často nie sú práve tieto miesta ošetrované a stávajú sa častým terčom útoku.
• Využívanie dát tretích strán
• Rôzne widgety, gadgety, či iné doplnky a služby môžu znamenať závažné bezpečnostné riziko. Majte na pamäti, že spolu s widgetom prenášate na svoj web aj bezpečnostné opatrenia tohto widgetu a prakticky celého webu, z ktorého ste widget získali.
• Aktívnejšie zapájanie užívateľov do procesu tvorenia a úpravy webu
• Užívatelia majú dnes mnoho možností, ako aktívne zasahovať do tvorenia webu (napríklad môžu vytvárať vlastné doplnky, widgety, atď.) a ich bezpečnostné opatrenia sú následne prenášané aj na celý projekt. Výborným príkladom je FaceBook, ktorý sa už mnohokrát stal obeťou útoku vďaka zle naprogramovaným doplnkom.
• Aktívne využívanie cudzích kódov
• Dnes už len máloktorom blogu nenájdete doplnky tretích strán, či dokonca cudzie kódy, ktoré menia a upravujú správanie celého blogu, či jeho časti. Výborným príkladom je Google AdSense, ktorý zobrazuje na webe reklamu, ktorá pochádza zo serverov Googlu a nie priamo od majiteľa webu. Stále platí pravidlo, že spolu s týmito doplnkami preberáte bezpečnosť ich zdroja.
• Umožňovanie ďalším programátorom pracovať s kódom projektu
• V dnešnej dobe sú na tieto účely takmer výlučné využívané API, pred časom to však bol generovaný kód, ktorý mal určité pravidlá (nelíšil sa príliš od štruktúry API). API však môže znamenať rovnako veľmi veľké bezpečnostné riziko, pretože API často pracuje priamo s jadrom webu a obchádza vstupný filter (ak tam nie je samozrejme pridaný, na čo sa veľmi často zabúda).

Web 2.0 Spôsoby ochrany

Ako sa však chrániť proti týmto potencionálnym hrozbám? Spísal som niekoľko bodov, ktoré by vám mali dať na túto otázku jasnú odpoveď.

• Zavedenie jasných a striktných bezpečnostných pravidiel
• Veľmi často vznikajú bezpečnostné incidenty práve preto, že boli pravidlá príliš benevolentné. Pamätajte si, že kód robí len to, čo ste mu umožnili/zakázali. Preto je potrebné, mať jasne omedzujúce pravidlá, ktoré budú presne stanovovať možnosti narábania s dátami, jadrom a inými časťami webu (aplikácie).
• Používanie Whitelistov miesto Blacklistov
• Pravdepodobne každý programátor pozná rozdiel medzi white a blacklistom. Whitelist povoľuje časti, ktoré obsahuje, kdežto blacklist naopak zakazuje. Matematicky by sme to mohli vyjadriť asi takto:
  Whitelist = možnosti
  možnosti – Blacklist
  Viem že to nie je dokonalé znázornenie, ale ukazuje to, čo potrebujete pochopiť. Používaním Whitelistov jasne obmedzujete možnosti narábania (bod vyššie). Radšej zabudnite pridať niektorú z potrebných vlastností, ktoré potrebuje programátor používať a pridajte ju neskôr, ako nakoniec zistiť, že ste niekomu umožnili plný prístup k vaším dátam. Nikdy nedokážete zakázať úplne všetky možnosti, ktoré vás môžu ohroziť. Blacklisty sú vhodné na vyraďovanie sprostých slov, či vytváranie zoznamov nepovolených IP adriest, ktoré nemôžu vstúpiť k vám na web.
• Filtrovanie všetkých vstupných a výstupných bodov v aplikácií (na webe)
• K tejto problematike som sa vyjadroval už vyššie, preto si túto časť prečítajte znova. Pri Web 2.0 je potrebné mať na pamäti, že aj skryté prenosy dát sa môžu stať nosičmi nebezpečného kódu a že aj tie môže hacker úspešne infiltrovať. Je potrebné mať zvýšenú pozornosť na všetkých bodoch vstupu dát, nielen tých, ktoré užívateľ bežne vidí.
• Obmedzovať prácu priamo s kódom
• Nie je vhodné, ani vo vlastných projektoch, využívať kódy doslova cross-projektovo. Radšej používajte API aj na projektoch, ktoré sú vaše. Takto sa vyhnete infiltrácií všetkých projektov a zmiernite vzniknuté škody na možné minimum.
• Obmedzovať využívanie open-source kódov
• Snažte sa vytvárať vlastný kód a open-source nasadzovať len v miestach, kde je to najviac nutné. Aj keď je open-source často lepšie naprogramovaný ako váš vlastný kód (hlavne preto, že ho tvorí komunita a nie jednotlivci), môžete doplatiť na objavenú zraniteľnosť, či na neaktualizovaný kód.

Príklady z praxe

Príkladov z praxe by som vám vedel dať tisíce, ak ste však pravidelnými čitateľmi blogu iste ste už na niektoré z nich narazili. Dobrým príkladom môže byť aj naše fórum, kde neustále dopĺňame novo objavené zraniteľnosti naprieč Slovenským, i zahraničným webom.

• Zoznam príkladov z praxe:
• Eshopy – uvádzanie cien do skrytého poľa
• XSS v diskusiách, vyhľadávaní, administrácii
• SQL Injection v anketách, v kontaktných formulároch
• Absencia ochrany pred CSRF (Cross-site Request Forgery)
• Nefiltrované strojové spracovávanie nahratých súborov
• Zapnutý debbug na ostrej prevádzke

Web 2.0: Najlepšie spôsoby ochrany

Spôsobov ochrany je hneď niekoľko, no základom sú tie, ktoré som už spomínal vyššie pri najčastejších bezpečnostných chybách. K tomu by som ešte dodal tieto:

• Vyberať vhodné spôsoby zabezpečenia
• Aj keď som veľkým zástancom bezpečnosti, je vždy potrebné zvoliť vhodný typ ochrany a zbytočne nepreháňať. Vždy si dobre premyslite, či je potrebné obmedzovať ochranou samotných užívateľov, či nie je možné celú ochranu vytvoriť na strane serveru.
• Postupné vzdelávanie užívateľov a pracovníkov projektu
• Nielen vy by ste mali poznať bezpečnostné praktiky a obmedzenia. Mali by si ich osvojiť jak vaši zamestnanci/kolegovia, tak aj samotní užívatelia. Ak ich dokážete aktívne zapojiť do budovania bezpečnosti a dobre im odprezentujete jednotlivé bezpečnostné opatrenia, pomôžete k zvýšeniu bezpečnosti na internete čo v konečnom dôsledku pomôže aj vám.
• Voľte bezpečnostné prvky na strane serveru, nie na strane užívateľa
• Jedno z najdôležitejších pravidiel! Spoliehať sa na to, že užívateľ sa nepokúsi obísť zabezpečenie, je absolútne naivné. Bezpečnostné prvky musia byť zásadne vždy na strane serveru a len ich doplnky či časti môžu byť na strane užívateľa (napríklad captcha).
• Dodržiavať všeobecne zaužívané bezpečnostné zásady pri tvorení kódu
• Na internete sa doslova povaľuje obrovské množstvo bezplatného materiálu, ktorý vám pomôže s tvorením bezpečného kódu. Mnoho bezpečnostných výskumníkov spísalo zásady, ktoré je potrebné dodržiavať pri tvorení kódu. Stačí využiť Google a tieto materiály nájsť a preštudovať.
• Nikdy nikomu neverte!
• Ako som už spomenul vyššie, nikdy nikomu neverte, pestujete si zdravú paranoju.

Záver

Pevne verím, že vám aj časť o bezpečnosti pre Web 2.0 projekty bude nápomocná a že si časom osvojíte jednotlivé body. Ak budete mať akékoľvek otázky, kľudne ich položte v diskusii pod článkom.