Az alábbi cikket Ys. írta a 0x90 blogon, és mivel a cikksorozata kapcsolódik az iPhone-hoz, mi érdekesnek gondoljuk a számotokra is, így ezeket engedelmével egymás után át is emelnénk ide, a Szifonra. A 10. részben összesen az Apple saját, iOS Security témájú hivatalos leírásáról van szó pár mondatban, így azt átléptük.

***

Az iOS nagyon szigorú platform. Hiányzik belőle egy csomó minden, amiért például az Androidra írt appokat el szokták biztonságilag b könnyű beleágyazni a többi alkalmazás közé, és mondjuk három kattintással tudsz Viberen üzenetet küldeni egy instagramban készült fényképpel, vagy kigórni az egészet twitterre.

Az iOS-ben a processzek közötti kommunikáció eléggé mostohagyerek: alapból például forkolni se hagyja az oprendszer az alkalmazásokat (“one process must be enough for everyone”), a processzek közötti üzenetküldésre sincs túl sok támogatás. Az alkalmazások reagálhatnak egy sereg előre definiált eseményre és ezen kívül egy lehetőség van: a magyarul custom protocol handlernek nevezett állat, ami alapszintű üzenetküldést mégiscsak lehetővé tesz.

Amikor egy alkalmazás szeretne az előre definiált dolgokon túlmutató üzeneteket kapni a világból, akkor implementál egy protokollkezelőt az application:openURL függvény használatával. Ha egy app beregisztrálja a blah-blah://akármi típusú handlert, akkor az adott app fog elindulni (illetve a handlerje fog meghívódni), ha az iOS egy blah-blah:// protokollú URI-t akar megnyitni. Ezt a lehetőséget kezdik felfedezni a fejlesztők is: a http://handleopenurl.com/ oldalon például össze van gyűjtve egy csomó alkalmazás saját protokollhandlerje. Ugye, mennyivel egyszerűbb mindez Androidban?

Ez idáig pofonegyszerű, és tök jól beleilleszthető teljesen valószerű szkenáriókba. Teszteltem például olyan iPades appot, amiben egy webes felületen történő authentikációs felület 302 redirectelte a Safarit a blah-auth://<<sessioncookie>> URI-re, ami berántotta az adott alkalmazást, az app így tudta meg a sessioncookie értékét.

Lássuk például a Facebook alkalmazásának URI-jeit. Jó sok van belőlük, egy részét kihagytam:

white-iPhone:/var/mobile/Applications/[…] # strings Facebook.app/Facebook | grep “://” | grep -v “http”
fb://upload/actions/newalbum
fb://root
fb://birthdays
fb://messaging
fb://notifications
fb://requests
fb://publish
fb://publish/profile/(gatePublishWithUID:)

Az igazán fincsi biztonsági szempontból az, hogy a fejlesztők szeretik megbízhatónak feltételezni az ilyen módon beérkező adatokat. Az iOS API egyébként megmondja a hívott appnak a hívó app azonosítóját, viszont bármilyen ennél komolyabb validációt már a hívott appnak kell végrehajtani, a validációs logikát pedig bele kell fejleszteni.

Különösen vicces például a fentiekben említett “Safariban belépek, aztán a Safari egy protokollhandleren keresztül berántja a telepített alkalmazásomat”-sémát használni authorizációra (azaz amikor effektíve egy weboldal mondja meg az alkalmazásomnak, hogy a júzer hozzáférhet-e lokálisan valamihez), ugyanis mindössze egy http proxy kell ahhoz, hogy privilidzset eszkaláljunk vertikálisan meg horizontálisan, azaz júzert személyesítsünk meg. Akik már veszik a levegőt, hogy ez mekkora baromság – valóban az, de már láttunk ilyet.

Hasonlóan kacagtató péládul az, amikor a protokollhandlerben egy SQL query-t legóznak össze a fémvázas Matchboxok korából ismert stringkonkatenálós módszerrel, pl. a sessioncookie tárolására.

A tanulság: ne tessék vakon megbízni semmiben.