There’s an old saying in the military that “generals always fight the last war, especially if they have won it.” Quite simply it means that when preparing for the next kind of threat, one should resist looking too closely at past wars fought at different times with different technologies and circumstances. The French were overrun despite the Maginot Line – the perfect defense against further aggression by the Germany of World War I, but practically useless against the German Blitzkrieg of World War II.
So it is with app security. Early in the era of web security, there was still a strong fear of classic desktop vulnerabilities like stack smashing and buffer overflows. Now that we’re in the era of mobile apps, the security world is still stuck in the realm of web security. Despite the fact that it’s been over two years since the OWASP group released the top 10 vulnerabilities for mobile, few mobile developers think to security test their apps.
Last week, researchers revealed yet another vulnerability type for iOS applications. By using a man-in-the-middle approach, an attacker can trick an iOS app into communicating with a web API on a malicious URL, not just once but forever after the fact. Ars Technica has the details of the attack, discovered by the security group Skycure, but the summary is simple.
As it turns out, many iOS apps do not have strong protections against malicious 301 redirects for API calls. A 301 redirect is basically a web command that says, “This thing isn’t here anymore. It’s over there instead.” Web masters use it when moving content from one place to another so that links work smoothly even when the content address has changed. But if I can interfere with your app’s communications and say “your API is really over here on my malicious server,” then I can theoretically intercept or even modify content used by your app. Because the 301 code signals a permanent redirect, your app will continue to use my malicious server long after I have stopped directly interfering.
The fix is simple. Make sure your app uses SSL instead of communicating in plaintext. It’s odd to think that in this day and age anyone would use an unencrypted API, but here’s the perfect reason to do so. By going the extra step to encrypt your API’s traffic, you’re also making sure that your users only see the right content and not something malicious or bogus. SSL certificates are cheap compared to the cost of your app losing its reputation because of security problems.