Browsers binnen apps zijn niet veilig, zegt de ontwikkelaar van Twitterrific. Hij heeft daarom een veiliger manier gevonden, maar Apple moet er nog even aan wennen.
Taalfout gezien of andere suggestie hoe we dit artikel kunnen verbeteren? Laat het ons weten!
Artikelcorrectie, spelfout of -aanvulling doorgeven?
Reacties: 7 reacties
memyselfandikke
Zoals de browser in de iculture app 😉
Wesley de groot
Uhm het is geen twitter page want die geeft niet aan “suck it up” tevens kan je via een eigen pagina een JavaScript de ingevoerde text laten terugsturen, dit is nodig voor bijvoorbeeld webview input velden, dus zodra je oplet en je niet laat scammen (hang op, klik weg, bel de bank principe) opletten wat je doet, altijd!
Jasper
Zorgen dat apps je naar safari kunnen sturen en dat er dan een balkje boven in beeld komt met ‘terug naar app x’
Een beetje jammer dat in het artikel niet wordt vermeld wat er dan precies is veranderd in Twitteriffic, want daar was ik juist in geïnteresseerd. Overigens heeft Hockenberry hier wel een punt!
-edit- Hockenberry’s oplossing blijkt het gebruik van OAuth te zijn.
@Wesley de groot: Dit is gewoon de inlogpagina van Twitter zelf. Je ziet eerst de normale tekst in de button staan, maar die wordt direct overschreven met “SUCK IT UP”. Hoogstwaarschijnlijk om aan te geven dat geen enkele informatie op de pagina veilig is, ondanks dat je op de officiële pagina bent. Hiervoor wordt vermoedelijk een MITM-attack gebruikt.
Marty
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 op Tweakers 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.
PS. 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.
Zoals de browser in de iculture app 😉
Uhm het is geen twitter page want die geeft niet aan “suck it up” tevens kan je via een eigen pagina een JavaScript de ingevoerde text laten terugsturen, dit is nodig voor bijvoorbeeld webview input velden, dus zodra je oplet en je niet laat scammen (hang op, klik weg, bel de bank principe) opletten wat je doet, altijd!
Zorgen dat apps je naar safari kunnen sturen en dat er dan een balkje boven in beeld komt met ‘terug naar app x’
Alles is onveilig
Een beetje jammer dat in het artikel niet wordt vermeld wat er dan precies is veranderd in Twitteriffic, want daar was ik juist in geïnteresseerd. Overigens heeft Hockenberry hier wel een punt!
-edit- Hockenberry’s oplossing blijkt het gebruik van OAuth te zijn.
@Wesley de groot: Dit is gewoon de inlogpagina van Twitter zelf. Je ziet eerst de normale tekst in de button staan, maar die wordt direct overschreven met “SUCK IT UP”. Hoogstwaarschijnlijk om aan te geven dat geen enkele informatie op de pagina veilig is, ondanks dat je op de officiële pagina bent. Hiervoor wordt vermoedelijk een MITM-attack gebruikt.
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 op Tweakers 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.
PS. 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.