At its F8 conference earlier this year, Facebook unveiled an open-source, cross-platform app linking program called App Links. The idea behind App Links is that developers can link mobile users directly to their app rather than having to fool with mobile browsers.
Mobile e-mail client Mailbox was one of the first adopters of the tool. The company offered up the following example of how it works.
Let’s say someone sends you a Pinterest pin via e-mail. If you have the Pinterest app on your phone, simply tapping the link in the e-mail will open it in your Pinterest app instead of your mobile browser.
This is often preferred as mobile apps obviously are designed for mobile devices and typically offer a better user experience compared to their web counterparts.
Web developer Jon Smajda, however, recently stumbled across a dirty little secret with the way Facebook App Links operates that – at the very least – is a major security concern.
As outlined in a blog post on the matter, Smajda has been using django-nopassword which uses a one-time code for authentication instead of a password. With it, users can submit their e-mail address and a link is sent to said address. The link contains a special login code that logs you into whatever site you’re trying to access then deactivates the code so it can’t be used again.
Basically, it’s a one-time use password that can be used once and only once. After it deactivates, the link will instead direct you to a 404 Not Found page. As Smajda explains, it’s not useful for all situations but for something like an admin panel, it’s handy when users need one-time access, etc.
But something unusual recently occurred when he tried clicking links through Mailbox on his iPad. Safari would open but he’d be taken directly to a 404. After digging into his server logs, he figured out the problem: every link clicked through Mailbox (and presumably, any other service that uses Facebook App Links) was first being routed through Facebook.
In Smajda’s case, Facebook was using his single-use click of django-nopassword to check for App Links support. By the time Safari attempted to get to the URL, it was already deactivated. Theoretically, Facebook was logging into his site in his place. Yeah, that sounds like a problem.
The web developer points out that there is no setting in Mailbox to enable or disable this “feature” nor was he logged into Facebook via iOS (he didn’t even have Facebook installed on his iPad). Fortunately for him, Smajda was able to code his way around it.
If nothing else, his experience lets everyone else know exactly how Facebook App Links works behind the scenes
.
.
0 comments:
Post a Comment