Slides from the Mobile Apps Security presentation at Over The Air 2011 - apologies for the PDF, but I use Keynote and I figure you'll probably want to have them in a format you can open!
1. IM IN UR CODEZ
Securing Mobile Apps
Sunday, 2 October 11
2. Hello!
My name’s Nick.
I work for Mobile Interactive Group
We’re going to talk about app security
...also cats
Sunday, 2 October 11
3. What this session is about...
Mobile application security
Developing apps defensively
...and what it’s not about
User-based vulnerabilities (tap-jacking, etc)
Mobile web security
Sunday, 2 October 11
5. Hardcoded passwords
SQL injection
In-app XSS
Insecure Data Transmission
Buffer overflows
Storing user data
Data leakage
API impersonation
Remote code execution
Sunday, 2 October 11
6. Web & Apps have similar problems...
...they just appear in different places
Sunday, 2 October 11
7. A fact (or two)
Your app will be reverse engineered
It’s only a matter of time
Obfuscation is not a be-all/end-all
Sunday, 2 October 11
8. You might think (comparatively) that your mobile
platform is not compromised...
...but how many rooted/jailbreaked phones are out there?
Assume your platform is compromised,
and your app will be reverse engineered
Sunday, 2 October 11
9. You must therefore strongly protect your APIs
and supporting application servers
Let’s look at three of the most common issues with apps
Two of these relate to API/server issues
Sunday, 2 October 11
11. We’re all pretty smart developers
(...hopefully!)
Sunday, 2 October 11
12. The chasm of misfortune
Your Goals Your App
We are all cats - we have good intentions...
...and sometimes can’t foresee the consequences
Sunday, 2 October 11
13. Your Goals Your App
Remembering Storing credentials insecurely
Banking App
Users
Not using SSL
Using an API Blogging App
Uploading Hardcoding your API keys
Content ?
UCG App
Sunday, 2 October 11
15. “API keys must be protected just like passwords.
This means they should not be [...] baked into non-obfuscated
applications that can be analysed relatively easily”
Cloud Security Alliance, April 18 2011
(...assume this means all mobile apps)
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
16. Demo time
Major paid for API
About 1,000,000 downloads
...let’s take a look!
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
17. Demo time
User: iPhone
Password: PnkFdrYRh75N
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
18. Consequences
The bad
A competing app uses your API key to exceed your rate limits
Your users get frustrated and leave
The ugly
Somebody pulls your S3 secret key and charges £££ to your account
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
19. This API is now compromised
I can use it in my own apps without paying the license fee
Because it’s hard-coded in the app it can’t be revoked
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
20. This API is now compromised
I can use it in my own apps without paying the license fee
Because it’s hard-coded in the app it can’t be revoked
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
21. Prevention
Use an alternative method to authenticate
Facebook, Amazon, and other large providers provide these
Don’t trust key verification
If you have an API that uses a key, don’t assume you can trust the user
Think permissions
If you do have to use keys, limit the damage that can be done with them
Have a plan
...think about the inevitable. What happens if your API is outed?
1 Keys and Secrets 2 leaking information 3 storing details
Sunday, 2 October 11
23. This shouldn’t need a slide
If you’re sending passwords in the clear, leave the room
...no, wait - come back! I forgive you!
People share passwords. All the time.
My Tumblr password might be my Facebook password
1 keys and secrets 2 Leaking Information 3 storing details
Sunday, 2 October 11
24. Specific shaming:
...but not the app!
1 keys and secrets 2 Leaking Information 3 storing details
Sunday, 2 October 11
25. “But Nick, everyone knows SSL/TLS is totally broken!”
“It’s the user’s fault for connecting to an insecure network”
“It’s too much effort / time-consuming to implement”
“My app isn’t important enough for this to be a problem”
1 keys and secrets 2 Leaking Information 3 storing details
Sunday, 2 October 11
26. Not using TLS is like leaving your house unlocked
Nobody is saying locks are going to stop you from getting burgled...
...but not locking your door is stupid.
1 keys and secrets 2 Leaking Information 3 storing details
Sunday, 2 October 11
28. Very popular!
Username and password in plain text!
1 keys and secrets 2 leaking information 3 Storing Details According to ViaForensics, June 2011
Sunday, 2 October 11
29. Obvious information
Passwords, usernames
Account numbers, etc
Overlooked information
Location information
Personal information (date of birth, address,
1 keys and secrets 2 leaking information 3 Storing Details
Sunday, 2 October 11
30. Consequences
The bad
You get some bad PR
People laugh at you as you walk down the street
The ugly
You store passwords or account information unencrypted
This compromises your app, and users information is leaked
You are fined by the ICO
1 keys and secrets 2 leaking information 3 Storing Details
Sunday, 2 October 11
31. In Summary
...we’re all smart developers...
(remember this bit? from earlier on?)
Sunday, 2 October 11
32. ...but so are the...
Bank of America, Citibank, National Rail Enquiries, Tumblr, AOL, Bump,
Flirtomatic, Foursquare, Groupon, LinkedIn, Mint, Skype, Wells Fargo,
WordPress, Match.com Yahoo! Messenger, and many many more...
...developers.
Nobody is perfect, no app is truly secure
(including me!)
Sunday, 2 October 11
33. Remember the cat*
*unlike the cat, your app will not survive a fall from height
Sunday, 2 October 11
34. Thanks :)
nick.shearer@migcan.com
(I don’t tweet - booo!)
Slides will be available on the OTA site soon!
Sunday, 2 October 11