Ontwikkelaar waarschuwt: iOS-apps kunnen inloggegevens onderscheppen

IOS-apps kunnen informatie onderscheppen die in een webview binnen een app wordt ingevoerd, zo waarschuwt een Amerikaanse ontwikkelaar. Daardoor zou een website bijvoorbeeld Twitter- of Facebook-logingegevens kunnen onderscheppen.

Apps hebben flink veel controle over wat er in de webview gebeurt, waarschuwt Craig Hockenberry, de ontwikkelaar van Twitterrific. Zo kunnen delen van de html-broncode worden gewijzigd, maar het blijkt ook mogelijk om de tekst die een gebruiker invoert te onderscheppen. De webview, waarvoor onderdelen van Safari worden gebruikt, wordt binnen apps onder andere ingezet voor het inloggen op diensten als Facebook en Twitter; in dat geval zou een app dus logingegevens van die site kunnen onderscheppen.

Hockenberry waarschuwt dat gebruikers nooit gevoelige persoonsgegevens moeten invoeren in de webview; volgens hem is die alleen geschikt voor het snel tonen van webpagina's, bijvoorbeeld vanuit een Twitter-app. Moeten er persoonsgegeven worden ingevoerd, dan is het beter om Safari te openen, benadrukt Hockenberry.

Volgens hem zou het ook veiliger zijn als inloggen bij bijvoorbeeld Twitter of Facebook vanuit een andere app niet binnen de webview zou gebeuren, maar via Safari. Apple keurt apps die dat doen echter af, omdat dat in de ogen van het bedrijf 'te ingewikkeld' is. Overigens zou een app die de logingegevens van gebruikers onderschept nog wel langs de controle van Apple moeten glippen.

Reacties (65)

Ik had toch gehoopt dat tweakers deze non-informatie eens een keer aan zich voorbij zou laten gaan.
Wat is het volgende bericht?
"Beveiligingsonderzoeker: Browserextensies kunnen ongemerkt surfgedrag monitoren"
of
"Expert concludeert: Google kan malafide code in Android verwerken"

Ik weet dat het kliks oplevert, maar dat iOS had sowieso in de titel weg gelaten kunnen worden. Dit werkt op deze manier op ieder OS.

[Reactie gewijzigd door NovapaX op 25 september 2014 09:35]

Huh? Non-informatie? Het gaat er toch om dat een app dat kan?
Dit is gewoon een flinke bug. Dit mag mijn inziens niet kunnen.

Edit: nu met uitleg..
Ik vind dat dit niet mag kunnen. Als je een webcontrol gebruikt in je app en je navigeert daarmee naar een site waar je credentials moet ingeven voor die betreffende site, mag de app dat niet kunnen achterhalen. Een wachtwoord-veld is herkenbaar door de webcontrol.

Als je een webcontrol gebruikt om je eigen pagina met invoervelden te maken is het een ander verhaal.

Edit 2:
Ik heb zojuist een Windows Phone app in elkaar gezet in soortgelijke constructie.
Het is me niet gelukt om key-up of key-down events (met de betreffende toetswaarden) af te vangen nadat ik naar twitter genavigeerd ben.
this.webcontrol.Navigate(new Uri("http://www.twitter.com"));

Documentatie: http://msdn.microsoft.com....ui.xaml.controls.webview
KeyUp en KeyDown not supported. Kennelijk is er bij Windows Phone (WebView control) wél over nagedacht. Volgende test of het met JavaScript eventueel kan.

Edit 3:
via InvokeScriptAsync() heb ik inderdaad toegang gekregen tot het wachtwoord veld en heb de waarde kunnen uitlezen. #bug.

[Reactie gewijzigd door geertdo op 25 september 2014 12:27]

Hoezo niet? Jij als app-ontwikkelaar embed die webview en gebruikt de publieke API's ervan om de HTML/JS/CSS uit te lezen of te bewerken. Het zou zotter zijn dat je nul invloed hebt op een embedded component. Er zijn prima use cases te bedenken dat dergelijke toegang gewenst is, bijvoorbeeld in hybride apps die native UI en HTML van een webapp combineren.

Dat in-app webviews voor logingegevens niet veilig zijn was allang bekend. De OAuth 2.0 draft specificatie waarschuwde er in 2010 al voor (edit: het bronartikel noemt zelfs 2008), of anders dit artikel uit 2011.

[Reactie gewijzigd door Rafe op 25 september 2014 10:14]

Microsoft heeft in Windows 8 voor modern apps daarom een speciale webview geintroduceerd die niet gemanipuleerd kan worden door de ontwikkelaar. Deze is specifiek bedoelt voor OAuth achtige koppelingen. Als je deze niet gebruikt voor zo'n koppeling wordt je app niet geaccepteerd.

Ah, daarom kom ik niet verder vermoedelijk

[Reactie gewijzigd door geertdo op 25 september 2014 12:28]

Nee, dit is geen bug. Hoe moet een app gebruik maken van een browser view als hij geen informatie in of uit die browser view kan halen?

Goed voorbeeld (op de desktop): de Steam client. Die opent bij het betalen een interne browser (bijv. voor je iDeal betaling). Reken er maar op dat de Steam client kan zien wat er in die browser gebeurt (dat merk je ook, want hij weet wanneer je betaling is afgerond). Dat is precies hetzelfde als wat apps kunnen (op elk platform, overigens).

Ik geef dan ook nog maar even de volgende "waarschuwing": "Apps die de camera gebruiken, kunnen naakt-selfies laten uitlekken".

Well, duh!

Een app moet niet het wachtwoord kunnen krijgen wat je binnen die app invult?
Het gaat hier er om dat je HTML content laat zien binnen een app, en die HTML content kan worden gemanipuleerd waardoor je er ook weer gegevens uit kan halen.

Als dit niet mogelijk moet zijn dan maken ze gewoon in C dezelfde interface aan als je zou krijgen wanneer je een webview zou gebruiken en kunnen ze op dezelfde manier je wachtwoord verkrijgen, omdat je m invult in de app. Dus hier hoeft niks te veranderen.

Ik vind dat dit wel anders moet. Als je een webcontrol gebruikt in je app en je navigeert daarmee naar een site waar je credentials moet ingeven, mag de app dat niet kunnen achterhalen.
Als je een webcontrol gebruikt om je eigen pagina met invoervelden te maken is het een ander verhaal.

Voor mijn thesis onlangs was ik bezig met dit probleem. Ik heb toen (in Android) een WebView versie gemaakt die via een http header de package naam meestuurde. Op die manier zou een website wel degelijk bepaalde apps kunnen restricten/toelaten. Een alternatief was dat de server een speciale header meestuurde die zei dat de pagina wel degelijk in een WebView geladen mocht worden.

Bij android zou deze aanval dan tegen gehouden worden. Ook het gebruik van een iFrame zou niet helpen aangezien je dan tegen de Same Origin Policy aanloopt.

Het is op zich dus wel mogelijk, maar niet practisch.

Dan wordt het lastig om uberhaupt een Webview te gebruiken om ook maar iets nuttigs binnen de app te doen. Uiteindelijk moet je een token o.i.d. krijgen om in te loggen, deze moet uit de Webview gehaald worden. Er is geen magische afbakening binnen een webpagina die er voor zorgt dat je de ene form input niet aan kan en de andere wel.
Het is structureel onhandig om uberhaupt dit soort logins via een webpagina te laten lopen, deze kunnen beter via (bijvoorbeeld) een extensie van een app lopen (zoals Facebook en Twitter nu al doen overigens).
Als ik in dien te loggen op een social media site via een webview heb ik dat altijd geweigerd, er zijn namelijk mogelijkheden om dat wel degelijk te laten lopen, gebruik die dan.

Overigens beperkt zich dit niet tot alleen iOS, maar ook Android en Windows Phone (en Windows) hebben hier last van. Het is inherent verweven in het gebruik van een embedded browser, dat het hier weer afgeschilderd wordt als iOS bug laat wel weer zien hoe diep de haat voor een bepaald platform bij sommige mensen zit... (best triest eigenlijk)

Een app die je toetsenbord uit kan lezen terwijl je de app gebruikt? Dat kan al sinds 2008. Heck, dat kan al sinds de introductie van browser extensies in elke browser die ooit bestaan heeft.

Gisteren is een bug van 20 jaar oud ontdekt (shellshock). Dat maakt het toch niet opeens toelaatbaar?

Uiteraard niet, maar dat is daadwerkelijk een bug. Dit is een implementatie van een webview, en als ontwikkelaar kun je bij de contents van een webview. Dit is niet anders dan hoe Android werkt, of hoe browser plugins werken, het is geen bug. Sterker nog: als jij adblock hebt geïnstalleerd, dan kan deze in theorie uitlezen wat jij intypt in je browser, ongeacht waar je bent. Shocker, right? Als je heel erg paranoïde bent, two factor authentication aan en klaar is kees.

[Reactie gewijzigd door t1mmy op 25 september 2014 10:14]

Dit laat alleen maar zien dat beveiliging momenteel iets belangrijks is. Net als privacy, want beide gaan deels hand in hand.

Ook slechte implementaties zoals bij de iCloud waar je gewoon kan blijven inloggen zijn gevaarlijk. Inlognamen zijn soms wel redelijk gemakkelijk achter te komen. Wachtwoorden ook als je gewoon brute force mag blijven proberen.

Ik kan me zelfs voorstellen dat het in de nabije toekomst onmogelijk wordt om in te loggen vanaf bepaalde locaties tenzij je zelf aangeeft waar je bent op je orginele locatie of trusted device.

Naja zeg. Hoe de app ook je wachtwoord verkrijgt, de app zal je wachtwoord verkrijgen als je er eentje moet invullen. Als de app zelf een wachtwoordveld presenteert, in plaats dat via een webcontrol te doen, denk je dat de app dan zelf geen toegang tot dat wachtwoord heeft?

Het is dus gewoon non-informatie.

Dat is toch ook niet nodig?
Je schotelt gewoon de twitter pagina voor en redirect je form input naar jezelf. Je app post vervolgens je input naar twitter.

+ As indicated in the Events table, WebView doesn’t support most of the user input events inherited from UIElement, such as KeyDown, KeyUp, and PointerPressed. A common workaround to this problem is to use WebView.InvokeScript (InvokeScriptAsync starting in Windows 8.1) with eval to use the HTML event handlers, and to use window.external.notify from the HTML event handler to notify the application using WebView.ScriptNotify.

Het kan dus ook direct via een work-around. Je events afvangen via javascript en die communiceren naar je app via ScriptNotify.

[Reactie gewijzigd door SoloH op 25 september 2014 11:55]

Het probleem heeft te maken met dat de ontwikkelaar graag de integratie simpel wil houden zonder dat er van applicatie gewisseld hoeft te worden. Een voorbeeld waarvoor je een browser nodig hebt is OAuth, wat je terug vindt bij bijvoorbeeld Facebook, Twitter maar ook Google, Github etc.

Het proces is als volgt:
- Applicatie gaat naar de OAuth pagina van een dienst en laat de gebruiker inloggen
- Als de gebruiker door de denst ingelogd is komt er een token terug
- Applicatie vangt token af en kan daarmee verzoeken doen aan de dienst

Normaal kan je dat prima oplossen door een applicatie URL te registreren, b.v.: voorbeeldapp://
Hierdoor kan je, als er in een browser wordt verwezen naar een URL als voorbeeldapp://token?tokenid=bladiebla informatie naar je app laten sturen.

Het proces is dan als volgt:
- Applicatie opent de OAuth URL van een dienst in de browser van het OS (die zie je als dat er geschakeld wordt naar de browser applicatie van je OS, b.v. Safari op iOS)
- Gebruiker logt in
- Na het inloggen geeft de dienst het token terug via de applicatie URL voorbeeldapp://token?tokenid=bladiebla (deze URL kan je opgeven in de confguratiepagina van de dienst).
- Door de applicatie URL te gebruiken wordt de applicatie weer geopend en krijgt deze het token door.

Het probleem hiermee is dat de gebruiker tijdens vlak voor het inloggen ineens een switch van applicatie ziet, de browser van het OS komt naar voren en daarin verschijnt de login pagina. Dat schakelen lijdt vaak tot verwarring bij de gebruiker en die vraagt zich af "Zit ik nu nog wel in de juiste applicatie?".

Om die applicatie switch naar de browser te vermijden maken veel ontwikkelaars gebruik van een webview binnen de app waarin de OAuth pagina wordt opgevraagd. Op die manier ziet een gebruiker niet de switch van applicatie naar browser naar applicatie. Gebruiker is niet meer verward. Echter heeft de applicatie wel controle over de code die in de webview gebeurt en kan b.v javascript code toevoegen om velden uit te lezen.

Het probleem is dus eigenlijk bij elk platform wel aanwezig, het is immers de ontwikkelaar die bepaalt hoe de applicatie met b.v. OAuth om gaat. Ik las hierboven dat Windows in de SDK een speciale webview heeft voor dit soort authenticaties en dat die perse gebruikt moet worden. Dat zou er bij Android en iOS ook ingebouwd kunnen worden.

Of: je zorgt dat je gebruikers snappen wat er gebeurt, want de switch naar de browser is dus eigenlijk wel het veiligste omdat de applicatie geen extra gegevens kan injecteren.

Edit: je hebt overigens bij een webview ook niet perse meer een app url nodig omdat je het token dan terug kan krijgen door de redirect URL af te vangen.

[Reactie gewijzigd door Myrdhin op 25 september 2014 12:04]

Ik dacht dat alle Apps in iOS in een soort van Sandbox mode werkte?

Ik dacht dat alle Apps in iOS in een soort van Sandbox mode werkte?

Doen ze ook, maar apps hebben wel toegang tot bepaalde onderdelen van Safari om snel een webpagina te kunnen tonen zonder dat Safari zelf geopened hoeft te worden (wat niet zo'n strak plan zou zijn gezien multitasking op iOS niet zo geweldig gaat). De app heeft geen toegang tot gegevens die de Safari-app heeft, maar heeft wel controle over de module die wordt geladen. En daarmee kan de app dus de pagina die je ziet wijzigen en eventuele invoer onderscheppen.

Een standaard toepassing voor deze in-app browser functionaliteit is als je een app toegang geeft tot je Twitter/Facebook/enz... account. Middels een authenticatie-systeem als OAuth moet je dan 1 keer inloggen op de website en de app toestemming geven, waarna de app zich kan aanmelden bij de dienst zonder je wachtwoord nodig te hebben, maar met een app-specifiek login-token.

In dit proces moet dus de website in een browser worden geopend. In iOS gebeurt dat binnen de app zelf en dit lek maakt het mogelijk voor, bijvoorbeeld, een Twitter-client om je Twitter wachtwoord te onderscheppen. Maar de toepassing blijft beperkt tot wat je in de in-app-browser invoert. Als je Safari gewoon apart start, dan is het niet minder veilig dan anders.

Als een ontwikkelaar gewoon gebruik maakt van bijvoorbeeld de Facebook SDK gebeurt de authenticatie via de Facebook App of wordt Safari geopend - je hebt dan verder (in eerste instantie) geen controle over de informatie die er wordt ingevoerd. Het zelf openen van een WebView en daar de authenticatie in doen kan op elk OS gedaan worden door de ontwikkelaar, dit is dus niet een specifiek iOS probleem.

Als je wil als ontwikkelaar zijnde kan je op elk willekeurig OS de input van de gebruiker binnen je App uitlezen. Je kan namelijk alle elementen binnen je app benaderen door de hierarchie van de views uit te lezen. Bij iOS en Windows Phone is er dan in elk geval nog de controle van Apple en Microsoft waar dit gefilterd kan worden.

Werken ze ook, maar de webview (UIWebView/WKWebView) is als component te gebruiken in een eigen app; alle content die je in een dergelijk webview toont kan je vanuit de app bepalen (maar ook ingevoerde gegevens zijn dus te onderscheppen).

Het is dus de app zelf die er misbruik van kan maken. Dat wil zeggen dat je dus niet zomaar apps kunt vertrouwen.

Maar dat wisten we eigenlijk ook al wel.

Inderdaad. Ook zonder die webview zou een app een dergelijke phishing attack kunnen uitvoeren, door simpelweg de UI van de website na te bouwen in de eigen app.

Wat je wel kunt zeggen is dat het met de genoemde methode een stuk gemakkelijker is om een dergelijke attack uit te voeren.

[Reactie gewijzigd door Anoniem: 415197 op 25 september 2014 11:29]

Exact. Daarom is dit weer zo'n artikel voor de hits. Meldt iOS en misbruik en je hebt weer heel veel hits, terwijl dit dus op elk platform mogelijk is.

Ja, maar wat er hier wordt bedoeld is dat je dus een webviewer hebt van bijvoorbeeld een mail-app en als je dus op een mail klikt (in de mail-app) waarbij moet inloggen op een site, dan kan de mail-app dus je inlog gegevens onderscheppen.

In-app browsers vind ik toch al rete irritant. Die gebruik ik dus niet .

Soms kun je niet anders, probeer jij een app als tweetbot of twitterific maar eens toegang te geven tot jouw twitter account zonder in-app webview.

Soms kun je niet anders, probeer jij een app als tweetbot of twitterific maar eens toegang te geven tot jouw twitter account zonder in-app webview.

Het hele idee achter het authenticatie-mechanisme dat deze apps gebruiken, OAuth, is dat de gebruiker inlogt op de webdienst via een kanaal dat apart staat van de app, zodat de app nooit toegang heeft tot de daadwerkelijke login-gegevens, maar in plaats daarvan een inlog-token krijgt wat alleen door die specifieke app te gebruiken is.

Dat betekent dat als je een in-app webview gebruikt, deze 100% dichtgetimmerd moet zijn. En dat, idealiter, de URL zichtbaar is. Maar dan nog blijft het een gammele oplossing. Een veel betere oplossing is om de login-pagina te openen in de reguliere browser van de gebruiker en nadat de authenticatie voltooit is, sluit de browser en keert de gebruiker automatisch terug naar de app. Dit is de aanpak die Android gebruikt en ik weet niet of iOS deze functionaliteit ondersteunt momenteel.

Ja... die functionaliteit wordt inderdaad ondersteund.
Zo wordt mijn iDeal betaling in de thuisbezorgd app geopend in de mobile safari app.
Bij voltooing van de betaling switcht hij automatisch weer terug naar de thuisbezorgd app.

Kan dat ook bij Android.

Klopt. Echter kun je in Android vanuit bv. Twitter makkelijk een link openen die in Chrome geopend wordt, en via de terugknop daarna weer snel terug naar Twitter. Dit zorgt ervoor dat de webview bijna niet gebruikt wordt in Android. Hierdoor zal dit probleem veel minder vaak voorkomen.

In iOS kan dit niet, en hierdoor krijg je vaak dat het normaal wordt om links in een webview te tonen (dit doet Twitter bijvoorbeeld).

Ja, maar als je een app wilt hebben die de gegevens onderschept, dan zorg je er natuurlijk voor dat het via een webview of vergelijkbaar in Android doet.

Dus leuk dit bericht maar niet echt nieuw en niet specifiek voor iOS.

Trouwens horen de diensten als Facebook en Twitter nu net via het iOS plaats te vinden. Dat is namelijk onderdeel van iOS. Inloggen moet je dus niet via safari of een webview, maar via het iOS.

In iOS kan dit niet, en hierdoor krijg je vaak dat het normaal wordt om links in een webview te tonen (dit doet Twitter bijvoorbeeld)

Een link openen in Safari kan in de meeste gevallen gewoon hoor, bijvoorbeeld in Tweetbot, door de link vast te houden en in de popup 'open in Safari' te kiezen. Ik snap de opmerking in het artikel dan ook niet dat Apple dit niet zou toestaan, want ik heb het al in meerdere apps gezien.

Ik denk dat men eerder bedoelt dat wat je in Safari uitvoert niet door de app kan gebruikt worden. Voorbeeld. je moet inloggen bij bij een dienst om de app te koppelen aan je account bij die dienst, dat gebeurt niet via Safari maar via een browser in de app.

Als je in Tweetbot Safari opent dan kan je geen informatie invoeren die effect heeft op het gebruik van Tweetbot. Je stapt dan gewoon uit de app.

Voor OAuth zou dit geen enkel probleem moeten zijn..

EDIT: OAuth en dergelijke

[Reactie gewijzigd door EraYaN op 25 september 2014 11:52]

Het is afhankelijk hoe de ontwikkelaar van de applicatie dit ingesteld heeft. Volgende keer eerst even wat bronnen raadplegen in plaatst te gaan screeuwen

Volgens het artikel wordt dit dus niet toegestaan aan de app-ontwikkelaars;

Apple keurt apps die dat doen echter af, omdat dat in ogen van het bedrijf 'te ingewikkeld' is.

Ja en eigenlijk komt het door facebook twitter ect...

Nee, het komt door de manier waarop apps een browser kunnen gebruiken en aan de geladen HTML zelf JavaScript toe kunnen voegen. Hetzelfde kan via iedere desktop browser, plugin of custom script in bijvoorbeeld Greasemonkey/Tampermonkey.

Dat is duidelijk, bedoel meer dat al die login toepassingen toelaten dat ze vanuit een webview geopend worden.

Het is gewoon een embedded browser control, waarom zou de verantwoordelijkheid daarvoor bij facebook en twitter moeten liggen? Welliswaar stuurt een webview een net iets andere user-agent dan de standaard safari, maar dan nog kun je niet verwachten van websites dat ze white- en blacklists bij gaan houden voor elke mogelijke user-agent string, vooral omdat de kwetsbaarheid ook niet ligt bij de website maar bij de app die in kan haken op de DOM elementen.

ja.

Ligt t nu aan mij of ligt Apple op t moment behoorlijk onder vuur. Ene naar t andere negatieve nieuws over apple,.

Als ik voor mezelf kijk hoevaak ik zonder controlle een app toegang geeft tot Facebook kan dit best grote impact hebben.

[Reactie gewijzigd door huntedjohan op 25 september 2014 09:46]

Zoals ik hier boven ook al aangaf, het is best triest dat de haat voor een bepaald platform bij sommige mensen zo diep gaat. Dit is namelijk ook prima mogelijk binnen Android, Windows Phone of Windows.

Het is geen bug, dit is letterlijk (en dat is ook echt zo) een feature, een app moet immers kunnen communiceren met de Webview, omdat er anders geen informatie uitgehaald kan worden. Dat de app dan ook de username en password er uit kan trekken is inderdaad zo, er is geen magische scheidingslijn tussen: dit wel, en dit niet!

Apple gebruikers horen liever niet dat hun iphone niet het veiligste ter wereld is. En blijkbaar voelen ze zich dan aangevallen...

Dat is altijd als er een nieuwe iPhone uitkomt, mijn iPhone 5 kon volgens nieuwsberichten van toen krom worden in mijn broekzak, is nooit gebeurd natuurlijk. Kreeg toen wel vragen of mijn iPhone ook al krom was....
Zoie het nieuws over kromme iPhone 6 van gisteren met 740 reacties....
Kwestie van hoge bomen. Nieuws (welk nieuws dan ook) moet je altijd met een korreltje zout nemen, er zijn zoveel nieuwsbronnen en die moeten op elkaar overschreeuwen om op te vallen.
Helaas doet Tweakers hier ook steeds meer aan mee, door soms suggestieve koppen te plaatsen.

hoevaak ik zonder controller een app toegang geeft tot Facebook

Zo jij hebt een hardwarematige Facebook controller, echte tweaker dus .

Hoge bomen vangen veel wind

Titel:

Ontwikkelaar waarschuwt: iOS-apps kunnen inloggegevens onderscheppen

Laatste zin:

Overigens zou een app die de logingegevens van gebruikers onderschept nog wel langs de controle van Apple moeten glippen.

Storm zoekt glas water...

Zonder exact te weten welke controles ze doen is het nog prima mogelijk. Laten ze code-analyse tools los die specifiek dit gedrag proberen te scannen? Monitoren ze het netwerkverkeer om te zien dat onderschepte inloggegevens naar een vage URL worden gestuurd?

Captain obvious? Het kan aan mij liggen, want ik heb vaker met webviews gewerkt, maar dat input binnen een applicatie (of het er nu uit ziet als een facebook inlog formulier of niet) onderschept kan worden is logisch toch? Als het goed is kan een gebruiker een webview niet eens herkennen, dus ook vanuit dat perspectief lijkt me dit niet de meest nuttige waarschuwing. Zelfs op Android waar er iets nettere oplossingen voor dit probleem (en sinds iOS 8 in theorie (niet praktijk) ook) door communicatie en intents tussen applicaties worden webviews nog steeds gebruikt, maar alsnog kan iedereen een fake facebook login maken als dat het doel is...

[Reactie gewijzigd door David Mulder op 25 september 2014 09:36]

App gaat naar phising webite, nagemaakt van de echte website, niemand die het opvalt en vult gegevens in.. what else is new?

Werkt het inloggen via FB niet vaak via de FB integratie van iOS zelf? Zie ook: https://developers.facebook.com/docs/facebook-login/ios. Dat lijkt me sowieso een veel nettere implementatie.

Deze bug vind ik sowieso een half verhaal. Als user weet je niet eens of de webview van FB wordt gebruikt, of een heel ander systeem (namaak inlogscherm, je ziet de URL niet!), waardoor het risico nog groter is.