Webové aplikácie dnes dokážu priam neuveriteľné veci, ktoré sme si pred niekoľkými rokmi ani len nevedeli predstaviť. Tí, ktorí si už začiatkom nového storočia užívali výsady byť na internete určite vedia o čom hovorím. Web 2.0 je ako pandémia a zachvátil už veľkú časť internetu.

Web 2.0 pre mňa nikdy nebol len prejazdným slovom. Tento názor som vyjadril už v začiatkoch tohoto blogu v článku Existuje Bublina 2.0? a trvám na ňom dodnes. Web 2.0 je ako pestrý jedálniček v luxusnej reštaurácii, kde neviete po čom dnes siahnuť, aj keď ste už všetko mali mnohokrát. Pre mňa najšťavňatejším sústom je určite webové API (Application programming interface). Pre tých, ktorí tento výraz nepoznajú, alebo nevedia čo znamená, je tu krátke vysvetlenie (upozorňujem, že sa jedná o vysvetlenie pre laikov, aby pochopili podstatu webového API).

API predstavuje akýsi most medzi aplikáciou a programovacím jazykom, ktorý nemá priamy prístup ku zdrojovým kódom webu, resp. k databázam (ktoré sú poväčšine najpodstatnejšie). Programátor, ktorý API vytvoril v ňom vie určiť všetky pravidlá pre prístup a nakladanie s dátami, pričom dokáže zároveň ochrániť svoje dáta v databáze, ako aj skripty na serveri.
Takto programátor, ktorý nie je priamym tvorcom projektu získa prístup k dátam, s ktorými vie narábať, ako napríklad čítať ich, posielať dáta späť aplikácii, atď.

Prosím, nemýľte si webové API s aplikačným. Jedná sa o dve rozdielne veci, i keď vo svojej podstate veľmi podobné.

Webové API skutočne umožnilo veľký rozmach rôznych služieb. Ako dobrá ilustrácia poslúži produkt z dielne spoločnosti Google, Maps. Tieto mapy pozná drvivá väčšina návštevníkov internetu. Ak si chcete umiestniť vlastné mapy na svoj web a do nich napríklad dopisovať, dopĺňať miesta, či vytvárať iné značky, na to všetko slúži API, ktoré vám toto všetko umožní. Jeden príklad za všetky slová.

V tomto článku by som sa rád zameral na bezpečnosť API ako systému. O návrhu API z pohľadu programátora písať nebudem. Ak máte o túto tému záujem, rád by som vám dal do pozornosti dokument od Jasmina Blanchette-a zo spoločnosti Trolltech, súčasť Nokie The Little Manual of API Design, ktorý je napísaný skutočne excelentne.

Bezpečnosť

API samozrejme poskytuje určitú formu ochrany samotnému tvorcovi webu, ktorý neumožňuje nikomu priamy prístup ku svojím dátam, ale všetky požiadavky si najskôr prefiltruje, aby jeho web nedostal “chrípku” vďaka niekoho šikovnosti. Mnoho vývojárov zabúda na bezpečnosť API. Mnohokrát som sa stretol s webom, ktorý mal relatívne slušne riešenú bezpečnosť, vrátane ochrany proti CSRF a XSS. Jeho API však umožňovalo vložiť dáta bez dodatočnej filtrácie, resp. bez dobrej dodatočnej filtrácie, čo vyústilo v bezpečnostnú zraniteľnosť. Takýchto API nájdete dnes tisíce.

Aby som však nepísal veľmi abstraktne, vezmem za vzor dnes jednu z veľmi populárnych služieb, ktorá stojí výlučne na svojom API, Twitter. Služba je dnes veľmi populárna a moderná s obrovskou hodnotou. Vďaka kvalitnému API sa služba rozšírila veľmi rýchlo medzi geekov a dnes dobíja srdcia aj mainstreamu.

Twitter si prešiel svojimi bezpečnostnými škandálmi, ktoré vyústili do veľmi výrazného zlepšenia bezpečnosti celého API. To je samozrejme veľmi dobrá správa. Aby sme si však pripomenuli, najväčšími bezpečnostnými incidentami boli asi tieto (samozrejme len tie, ktoré sa týkajú API, nie brute force útoku, phishingu, atď.)

• Not just social history, actual information from Twitter
  Dion Almaer upozornil na to, že ak ste sa autorizovali cez webový prehliadač u API, je možné za pomoci JavaScriptu veľmi jednoduchým spôsobom získať akékoľvek informácie, ktoré API poskytuje.
• Mikeyy worm
  17 ročný mladík, Michael Mooney, sa preslávil za niekoľko hodín vytvorením červa, ktorý zneužíval zlú filtráciu prichádzajúcich správ.

Twitter samozrejme zažil aj iné bezpečnostné incidenty, ale tie sa len málo, alebo vôbec netýkali samotného API. Ako som už spomenul, Twitter dal na radu odbornej komunity a prijal nového člena, ktorý sa dnes stará o bezpečnosť celého systému, vrátane návrhov pre správnu filtráciu správ. V tomto bode je Twitter relatívne bezpečný, až kým sa neobjaví nová technika, ktorá však bude mať globálnejší dopad, nielen na Twitter samotný.

Čo však Twitter už neovplyvňuje je bezpečnosť tretích aplikácií, teda aplikácií, ktoré neprogramovali iní programátori a ktoré vďaka API dokážu nahradiť celé webové rozhranie Twitteru, nájsť ľudí, ktorých by ste určite mali sledovať, alebo vypočítať pre vás štatistiky vašej aktivity. Takýchto aplikácií sú stovky a každý deň pribúdajú ďalšie. I tu Twitter narazil na určitý problém a to vo forme autentifikácie, ktorú používa/l. Donedávna Twitter umožňoval jedinú formu autentifikácie užívateľa cez API a to za pomoci HTTP autentifikácie (čo bol jeden z dôvodov prečo bolo možné vytvoriť skript pre získanie dát z API cez JavaScript bez vedomia užívateľa). Dnes už Twitter podporuje aj oveľa lepší OAuth, v ktorom bolo len nedávno objavená bezpečnostná zraniteľnosť, čo viedlo k dočasnému odstaveniu protokolu. Napriek tomu je tento protokol ďaleko bezpečnejší a dáva samotným užívateľom väčšiu kontrolu nad tým, čo môže aplikácie s jeho dátami robiť. To samozrejme nie jediná výhoda OAuth-u. Narozdiel od bežnej HTTP autentifikácie nemusíte v OAuth ako užívateľ poskytnúť meno a heslo, čo viedlo k ďalším bezpečnostným problémom.

Toto je len časť bezpečnosti Twitteru, keďže toto sú veci, ktoré vie Twitter ovplyvniť na svojej strane. Vďaka API sa objavili skutočne tisíce aplikácií, bez ktorých si niektorí dnes už ani nevedia fungovanie Twitteru predstaviť (resp. vie si vôbec niekto?). Práve v tom je “zakopaný pes”. Tisícky aplikácií robia tisícky programátorov s rôznymi znalosťami, skúsenosťami a teda aj rozdielnymi schopnosťami navrhnúť bezpečnú aplikáciu. Mnoho z týchto aplikácií vyžaduje niektorú z foriem autentifikácie užívateľa s Twitterom. To znamená, že užívateľ sa momentálne musí spoľahnúť nielen na bezpečnosť samotného Twittru, ale aj na bezpečnosť danej aplikácie, ktorá má vďaka API takmer rovnaké možnosti ako samotný Twitter. Ak sa teda nachádza bezpečnostná zraniteľnosť v takejto aplikácií, je užívateľ rovnako zraniteľný ako keby sa táto zraniteľnosť nachádzala na samotnom Twittri. Samozrejme, tento celý koncept vychádza len z predpokladu, že užívateľ využíva túto aplikáciu.

Dôsledky sa najlepšie ilustrujú na skutočnom príklade. Môj priateľ Aviv Raff nedávno napísal článok Cross-Web2.0 Scripting, v ktorom ukázal, akým jednoduchým spôsobom môže byť napadnutá populárna služba twitpic.com. Dôvodom je tentokrát chyba samotných programátorov mimo Twitteru, ktorí sa spoliehajú na “čistotu” dát, ktoré z twittru dostali a tie potom bez akejkoľvek úpravy (alebo opäť po nedostatočnej filtrácii) zobrazujú na svojom webe. Tento fakt môže mať za následok vznik nového červa, ktorý infikuje každého užívateľa zraniteľnej aplikácie. Ak sa útočníkovi podarí nájsť takúto zraniteľnosť na viacerých populárnych službách/aplikáciách, môže sa jednať doslova o pandémiu a postihnuté môžu byť milióny užívateľov.

Aj tu je samozrejme možnosť riešenia opäť na strane Twittru. S Avivom sme niekoľko krát preberali možnosť vytvorenia univerzálneho Web API Firewall, ktorý by vyhodnocoval prichádzajúce správy a snažil sa v nich nájsť škodlivé informácie, napríklad pokus o pridanie kusu JavaScriptového kódu do správy, atď. Tento nápad však má aj svoje muchy. Twitter dostáva každú minútu stovky tisíc správ a tak by asi bolo veľmi problematické vytvoriť takýto firewall, ktorý by dokázal spracovať také obrovské množstvo dát v reálnom čase za nízke náklady.

Je tu však aj iné riešenie, ktoré som už poslal tvorcom API a ktoré dúfam zapracujú. Celý tento bezpečnostný problém vyplýva z toho, že Twitter síce sanitizuje zobrazované dáta na svojom webe, ale pri posielaní cez API tak už nerobí. Občas je sanitizácia skutočne prekážkou a preto som navrhol takéto riešenie.

Ako príklad si vezmeme jedno z volaní, v ktorom Twitter ako odpoveď vracia informácie o užívateľovi, users/show.
Podstatou tohoto volania je poslať požiadavku na URL http://twitter.com/users/show.format spolu s niekoľkými povinnými a nepovinnými parametrami. Výsledkom sú dáta, ktoré užívateľ zadal do systému v neošetrenej podobe. Aby teda nedochádzalo k takýmto problémom, pridá sa ešte jeden nepovinný parameter, ktorý bude štandardne vedený ako TRUE a ktorý bude hovoriť o tom, či majú dáta byť ošetrené samotným API, alebo nie. Takto by sa predišlo veľkému množstvu bezpečnostných incidentov, ktoré môžu nastať.

Priamo súvisí aj bezpečnosť webov, ktoré zobrazujú zoznam vybraných twittov. Robia tak na základe Search API, ktoré im na základe požiadavky vracia len twitty, ktoré vyhovujú dopredu zadaným kritériám. Najčastejšie však tvorcovia týchto webov zabudnú na dodatočnú sanitizáciu prechádzajúcich správ a výsledkom je opäť bezpečnostná zraniteľnosť.

Opäť jedna skutočná ukážka, ktorá vám lepšie ozrejmí celú situáciu. Na screenshotoch na boku postupne môžete vidieť twitt, ktorý obsahoval HTML tag spolu s kľúčovým slovom, ktoré je vyhľadávane za pomoci Twitter Search API a zobrazované na konkrétnom webe.
Na druhom screenshote môžete vidieť už daný web, ktorý patrí projektu Eclipse Galileo a ktorý obsahoval túto bezpečnostnú chybu. Odoslaním twittu obsahujúceho HTML tag sa na samotnom Twitteri nič nestalo, ale na webe, ktorý tieto dáta získaval cez API bol tag inicializovaný (rovnako by bol aj JavaScript) a vykreslený prehliadačom.

Dôsledkom týchto chýb je prakticky výborná forma rozosielania malware na dôveryhodné weby, ktoré týmto prepožičajú svoje stránky útočníkom. Užívateľ je veľmi náchylný, ak sa objaví okno na vykonanie prakticky akejkoľvek interakcie na webe, ktorý dôverne pozná. Takto je možné infikovať doslova milióny ľudí a to vďaka len 140 znakom.

Snáď som zodpovedal rovnakú otázku tým, ktorí ma sledujú a čudujú sa, prečo z času na čas odošlem twitt s HTML tagom.

Záver

Bezpečnosť API by nemala byť ani trošku podceňovaná, pretože následky môžu byť veľmi nepríjemné. Ak zvládnete svoje API dostatočne ošetriť pre všetky formy útokov, budete mať v rukách silný nástroj, ktorý vám môže poľahky poraziť konkurenciu, alebo spopularizovať vašu službu.

Žiadne príbuzné články neboli nájdené.