"Hide-a-key-in-a-neon-pink-plastic-rock-next-to-the-front-door" storage:
This appears to be the most prevelant issue by far that I've come across. Insecure implementations include:
1) Storing plain-text credentials in a SQLite database
2) Storing XML files that contain plain-text credentials or other sensitive account details
3) Storing plain-text credentials in a system wide database (e.g. - accounts.db/Android)
Moral of the story is, if a mobile device is lost or stolen (happens way more often than it should), credentials are ripe for the picking. Physical access is not always required of course. Anyway, pretty much anyone who has spent 2 minutes on "The Googles" can find out where you are storing your metaphorical "house keys". There are solutions to this problem, for instance, I've heard great things about Android-SQLCipher and don't forget about platform API solutions as well (if your not a fan of third party libraries).
Crappy session handling:
I don't think this title will ever make its way on to an OWASP Top 10 but it certainly reflects the issue accurately. Not to say this is limited only to Mobile Apps & Web Services, far from it, it is just very common amongst them.
Examples -
So, here is a fun one, pure basic-authorization schemas . You typically see this in a SOAP-service-to-Mobile-App architecture but obviously the two aren't mutually exclusive. For those not familiar with basic-authorization, it means the user's credentials are sent in the standard basic-auth format (Base64 encoded user:password). The problem occurs when, instead of leveraging a session handling schema, the user/password combo is sent with every request to the web-service as a means to authenticate the user for the requested resource. There are many disadvantages. Namely, if SSL isn't in play, you've increased the likelihood that the credentials will be stolen (ahhh....... lattes, croissants and good ol' packet sniffing). Additionally, because you haven't a session to destroy, there is no inactivity lock-out. Typically the creds are stored (plain-text of course) on the device, retrieved by the app and then sent in the request on a per-request basis. This means, the person on that device may not be the person you intended to view potentially sensitive information.
Another big session-related issue is leveraging device identifiers or good old client-side data to control privileges of a user. Imagine the classic parameter tampering (userid=100 becomes userid=101) but this time with the UUID of an iPhone device. The classic session identifier -> user map -> role enforcement still works so it is unnecessary to build your schema in this way.
API Keys, Test Accounts and Dirty Laundry
From test account credentials along with the test URL, which provided juicy insight into the inner workings of an architecture to the personal email addresses of developers (think - social engineering/username enumeration), the list of things put into the source code can still be fairly surprising.
These applications are reversible. Especially Android apps, between dex2jar/apktool/jd-gui.......its pretty easy to see things not intended for your eyes. Developers need to scrub sensitive data prior to sending the code out for production and treat data like its a public blog post......everyone can read it. Oh, and make sure you aren't hard-coding API or encryption keys!
Okay, so those titles will never end up on a Top 10 but the content has! I would encourage those interested to check out the OWASP Mobile Top 10 Risks and please, don't forget the project always needs additional collaborators.
Cheers,
Ken
