Komentár z blogov: Web API a bezpečnosť

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. Web 2.0 je ako pestrý jedálny lístok v luxusnej reštaurácii, kde neviete, po čom dnes siahnuť, aj keď ste už všetko mali mnohokrát. Pre mňa najšťavnatejším kúskom 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 ide 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 k 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. Ide o dve rozdielne veci, i keď v podstate veľmi podobné.

Webové API skutočne umožnilo veľký rozmach rôznych služieb. Ako dobrá ilustrácia poslúži produkt Maps z dielne spoločnosti Google. 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 Blanchetta zo spoločnosti Trolltech, súčasti 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 k svojim 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 do bezpečnostnej zraniteľnosti. Takýchto API nájdete dnes tisíce.

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

Twitter 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 incidentmi 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č v 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
Sedemnásť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 zažil aj iné bezpečnostné incidenty, ale tie sa len málo alebo vôbec netýkali 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 na 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ší dosah nielen na Twitter samotný.

Čo však Twitter už neovplyvňuje, je bezpečnosť tretích aplikácií, teda aplikácií, ktoré naprogramovali iní programátori a ktoré vďaka API dokážu nahradiť celé webové rozhranie Twittera, 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 používateľa cez API, a to za pomoci HTTP autentifikácie (čo bol jeden z dôvodov, prečo bolo možné vytvoriť skript na získanie dát z API cez JavaScript bez vedomia používateľa). Dnes už Twitter podporuje aj oveľa lepší OAuth , v ktorom bola len nedávno objavená bezpečnostná zraniteľnosť , čo viedlo k dočasnému odstaveniu protokolu. Napriek tomu je tento protokol oveľa bezpečnejší a dáva používateľom väčšiu kontrolu nad tým, čo môže aplikácia s jeho dátami robiť. To, samozrejme, nie jediná výhoda OAuthu. Na rozdiel od bežnej HTTP autentifikácie nemusíte v OAuthe ako používateľ poskytnúť meno a heslo, čo viedlo k ďalším bezpečnostným problémom.

Toto je len časť bezpečnosti Twittera, 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 Twittera 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 používateľa s Twitterom. To znamená, že používateľ sa momentálne musí spoľahnúť nielen na bezpečnosť Twittera, ale aj na bezpečnosť danej aplikácie, ktorá má vďaka API takmer rovnaké možnosti ako Twitter. Ak sa teda nachádza bezpečnostná zraniteľnosť v takejto aplikácií, je používateľ rovnako zraniteľný, ako keby sa táto zraniteľnosť nachádzala na samotnom Twitteri. Samozrejme, tento celý koncept vychádza len z predpokladu, že použí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 tentoraz chyba programátorov mimo Twittera, ktorí sa spoliehajú na „čistotu“ dát, ktoré z Twittera dostali, a potom ich 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 použí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 ísť doslova o pandémiu a postihnuté môžu byť milióny používateľov.

Aj tu je, samozrejme, možnosť riešenia opäť na strane Twittera. S Avivom sme niekoľkokrá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 kusa 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 používateľovi, users/show .

Podstatou tohto 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é použí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 tým 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ávané 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 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 malwaru na dôveryhodné weby, ktoré tým prepožičajú svoje stránky útočníkom. Použí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. Azda 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.

Autor

Rastislav Turek je nezávislý bezpečnostný konzultant a člen organizácie OWASP. Prispieva na známy blog o bezpečnosti blog.synopsi.com.

Zdroj: blog.synopsi.com