Bezpečnost API mikroblogovacích systémů

Diskuse u minulého článku sklouzla k otázce bezpečnosti a jako mantra v ní zaznívá: "Posílám své heslo někomu..." Pojďme se podívat, jak je to s posíláním hesla mikroblogovacím systémům při použití jejich API.

Nabídnout API je fajn věc, snad nejpříjemnější projev Webu 2.0. Cizí služby tak můžou využít nejen lidé, ale i programy, a mohou tak nabízet mnohem vyšší, lepší, komplexnější apod. funkcionalitu. Na druhou stranu je právě API (ostatně jako spousta novinek ve Web2.0) místem, kde rády vznikají bezpečnostní díry.

Tvůrci webů se pomalu učí oštetřovat speciální znaky u vstupů z webového rozhraní, ale zapomínají na ošetření jiných míst. Špatně navržené API nemusí znamenat problém jen pro službu, ale i pro jejího uživatele. Vezměme si konkrétní případ, a to API mikroblogovacích systémů (mám s nimi čerstvou zkušenost) a jejich citlivost na odposlechnutou komunikaci. Rozdělme si pak jednotlivá API do tří úrovní zabezpečení:

  • 0 – pokud někdo odposlechne komunikaci, získá plný přístup k účtu na cílovém systému
  • 1 – odposlechnutí komunikace může znamenat nepříjemnost (typicky třetí strana může poslat text pod falešnou identitou), ale nezíská plný přístup k účtu
  • 2 – odposlechnutí komunikace s API nepředstavuje bezpečnostní riziko tohoto typu

Při hodnocení bezpečnostního rizika mikroblogovacích služeb počítám i s ekonomickým hlediskem, tedy zda se "vyplatí" vynaložit intenzivní práci na prolomení případné ochrany. Vyšel jsem z toho, že "účet na mikroblogu" není tak důležitý, aby kvůli němu někdo prolamoval SSL komunikaci či AES šifru nebo hledal MD5 kolize, a považuji tedy např. použití SSL za "dostatečné".

Když chce vzdálený program poslat text na mikroblog, musí zároveň poslat nějakou autentizační informaci, aby systém věděl, který uživatel text posílá a zda je to opravdu on. Jak to řeší jednotlivé služby?

Twitter předává tyto údaje standardní autentifikační cestou, kterou nabízí protokol HTTP, konkrétně Auth-Basic. Pokud na takovou stránku vleze prohlížeč, vyhodí známý dialog o zabezpečené stránce a požaduje jméno a heslo. Obojí pak pošle serveru v hlavičce HTTP požadavku, a to tak, že pošle řetězec "jméno:heslo", ošetřený pomocí Base64. Pokud takovou komunikaci někdo "uprostřed" odchytí, tak získává plný přístup na Twitter pod falešnou identitou. Úroveň zabezpečení: 0 – Výjimka: U Twitteru LZE použít přístup k API přes protokol https (tedy s použitím šifrovaného SSL kanálu). Jeho použití zvýší úroveň bezpečnosti ve sledované oblasti na úroveň 2. (Pro hnidopichy dodávám, že náklady na případné prolomení SSL komunikace jsou nesrovnatelné se ziskem hesla na mikroblog.)

Tumblr API je otevřené dokořán. Jméno i heslo je posíláno v těle HTTP požadavku (POST) v otevřeném textu a podle mých testů nelze pro přístup použít SSL. Úroveň zabezpečení komunikace: 0

Pownce API umožňuje dva způsoby autentifikace, buď HTTP Basic (jako Twitter) nebo nově i OAuth. U OAuth neznám technické podrobnosti, budu tedy doufat, že se jedná o bezpečnou metodu (nakolik jsem koukal, tak používá šifrování a výměnu klíče metodou Diffie-Hellman). V případě použití HTTP autentifikace platí totéž jako u Twitteru, s tím rozdílem, že Pownce dle testů nepodporuje použití SSL. Úroveň zabezpečení 2 / 0 (podle typu použité autentifikace)

Jaiku používá kombinaci "jméno + API KEY", takže případné prozrazení znamená v zásadě jen to, že útočník může poslat příspěvek vaším jménem. Neměl by mít možnost přihlásit se do systému, tu máte vy a můžete si změnit heslo, čímž se změní i API KEY. Bohužel, jejich stránky s popisem API (mají adresu devku.org) jsou nějako nefunkční, takže nemám možnost zjistit případné informace o jiných metodách a způsobech. SSL dle testu nepodporují. Úroveň zabezpečení: 1

Teidu API používá poněkud odlišný způsob, který je založen na hashovací funkci. S každým požadavkem je poslán ověřovací klíč, který je vytvořen jako hash posílaného textu a řetězce P. Řetězec P je hash jména a hesla uživatele. Jako hashovací funkce je použita MD5, která je v takovémto případě dostatečně bezpečná (i přes existenci algoritmů pro hledání kolizních zpráv). Princip je trošku podobný HTTP Digest autentifikaci. Úroveň zabezpečení: 2 s výhradou (až do doby, než bude nalezena metoda pro úplnou rekonstrukci částečně známé zprávy z MD5 hashe – pokud už je, prosím o informaci. Rozlomení pomocí bruteforce pak představuje nalezení 128bitového řetězce a praktická realizace něčeho takového je stále z říše pohádek). Ani Teidu nepodporuje SSL přístup k API.

Pointa: Pokud tedy připravujete nějakou dvanula službu a chystáte se nabídnout API (to chválím!), tak se trošku zamyslete nad bezpečností údajů, které přes API půjdou. Snažte se minimalizovat rizika, která z toho vyplývají, a vyvážit poměr "užitek ze strojového přístupu ku bezpečnostnímu riziku". Jak ukazuje příklad i poměrně známých služeb, není výjimkou, že jméno a heslo poletuje po síti v otevřeném textu.

Ostatně dodneška se stejně chová naprostá většina blogovacích systémů s XML-RPC protokolem založeným na MovableType/Blogger API (malý příklad).

Pointa pro hnidopichy: Ano, existují metody hledání kolizních řetězců hashových funkcí. Ano, je možné s vynaložením nějakého úsilí prolomit SSL komunikaci. Ano, zavirovaný počítač může poslat heslo kamkoli. Ano, nejbezpečnější je počítač, který není připojený k síti (k té elektrické, samosebou). Ano, ano, ano. Spokojeni? Jestli stále ne, tak to prosím napište na své stránky, ne na moje, nemám náladu se u podobného populárně-naučného článku dohadovat o jemných nuancích Klíma vs Wangová ani o tom, že ta diskuse u předchozího článku byla o něčem trošku jiném. Díky, že to respektujete.

PS pro Davida Grudla a potenciální ostatní komentátory: Ačkoli už v titulku článku píšu o API mikroblogovacích systémů a přesto, že v textu několikrát zmiňuji to, že píšu právě o API, tak píšu ve skutečnosti opravdu o posílání hesla přes API! Až budu psát o obecné problematice posílání hesel, upozorním na to. Dnes to ale nebylo mým tématem a ani mým záměrem, dnes bylo mým záměrem opravdu jen popsat některé aspekty autentizace u API. A i když jde o problematiku docela příbuznou běžnému "přihlašování", tak je přeci jen trošku odlišná. Proto prosím neřeš webové přihlašovací formuláře, s tématem to nesouvisí. Děkuji

Dne 5.07.2008

Twittni

Přidej do: asdf.sk StumbleUpon Toolbar Stumble It!

Komentáře

[1] (David Grudl - WWW) 05.07.2008, 22:00:00 [X] [D]
Důležité je, že i přihlašovací formulář na stránce http://twitter.com jede přes HTTPS. Twitter v tomhle příjemně překvapil.

[2] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 23:09:55 [X] [D]
[1] Co má přihlašovací formulář společného s API (a s tématem článku), že to v tomto kontextu označuješ za "důležité"?

Ale jinak souhlasím, Twitter tímhle příjemně překvapil, asi proto, aby vyvážil ta nepříjemná překvapení :)

PS: Tvou reakci jsem smazal, vysvětlení jsem doplnil do textu.