Dutch mobile conference


Published on

Presentation from the Dutch Mobile Conference 2013 in Amsterdam. The slide deck presents the OWASP Top 10 Mobile Risks for mobile apps.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Dutch mobile conference

  1. 1. Mobile App Security Best PracticesDutch Mobile Conference 2013 - AmsterdamErwin Geirnaert: CEO & Application Security Expert
  2. 2. Agenda• About me• OWASP Top 10 Mobile Risks• Best practices
  3. 3. About me
  4. 4. Security tester• Penetration testing• Security testing applications– Web/mobile/thick• Code review• Risk analysis• Web application firewall in the cloud(ZIONSECURED)
  5. 5. OWASP Top 10 Mobile Risks
  6. 6. • https://www.owasp.org/index.php/Category:OWASP_Top_Ten_ProjectOWASP Top 10
  7. 7. OWASP Top 10 Mobile Risks
  8. 8. M1- Insecure Data Storage• Sensitive data left unprotected• Applies to locally stored data +cloud synced• Generally a result of:• Not encrypting data• Caching data not intended for long-termstorage• Weak or global permissions• Not leveraging platform best-practicesImpact• Confidentiality ofdata lost• Credentialsdisclosed• Privacy violations• Non-compliance
  9. 9. M1- Insecure Data Storage
  10. 10. iPhone app – plist file
  11. 11. M2- Weak Server Side Controls• Applies to the backend services• Not mobile specific per se, butessential to get right• We still can’t trust the client• Luckily, we understand theseissues well• Existing controls may need to bere-evaluated (ie- out of bandcomms)Impact• Confidentially ofdata lost• Integrity of datanot trusted
  12. 12. M3- Insufficient Transport LayerProtection• Complete lack of encryption fortransmitted data• Yes, this unfortunately happens often• Weakly encrypted data in transit• Strong encryption, but ignoringsecurity warnings• Ignoring certificate validation errors• Falling back to plain text after failuresImpact• Man-in-the-middle attacks• Tampering w/data in transit• Confidentialityof data lost
  13. 13. M3- Insufficient Transport LayerProtection•Real World Example: Google ClientLoginAuthentication Protocol• Authorization header sent over HTTP• When users connected via wifi, appsautomatically sent the token in an attemptto automatically synchronize data fromserver• Sniff this value, impersonate the user• http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html
  14. 14. Zendesk HTTPS
  15. 15. M4- Client Side Injection• Apps using browser libraries• Pure web apps• Hybrid web/native apps• Some familiar faces• XSS and HTML Injection• SQL Injection• New and exciting twists• Abusing phone dialer + SMS• Abusing in-app paymentsImpact• Devicecompromise• Toll fraud• Privilegeescalation
  16. 16. M4- Client Side Injection• Garden Variety XSS…. With access to:
  17. 17. M5- Poor Authorization and Authentication• Part mobile, part architecture• Some apps rely solely onimmutable, potentiallycompromised values (IMEI, IMSI,UUID)• Hardware identifiers persist acrossdata wipes and factory resets• Adding contextual information isuseful, but not foolproof• Back-end API does not check ifrequest is from mobile deviceImpact• Privilegeescalation• Unauthorized access
  18. 18. M5- Poor Authorization and Authentication
  19. 19. M6- Improper Session Handling• Mobile app sessions are generallyMUCH longer• Why? Convenience and usability• Apps maintain sessions via• HTTP cookies• OAuth tokens• SSO authentication services• Bad idea= using a device identifieras a session tokenImpact• Privilegeescalation• Unauthorized access• Circumventlicensing andpayments
  20. 20. M7- Security Decisions Via Untrusted Inputs• Can be leveraged to bypasspermissions and security models• Similar but different dependingon platform• iOS- Abusing URL Schemes• Android- Abusing Intents• Several attack vectors• Malicious apps• Client side injectionImpact• Consumingpaidresources• Dataexfiltration• Privilegeescalation
  21. 21. M7- Security Decisions Via Untrusted Inputs•Skype iOS URL Scheme Handling Issue• http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/
  22. 22. M8- Side Channel Data Leakage• Mix of not disabling platform features andprogrammatic flaws• Sensitive data ends up in unintendedplaces• Web caches• Keystroke logging• Screenshots (ie- iOS backgrounding)• Logs (system, crash)• Temp directories• Understand what 3rd party libraries inyour apps are doing with user data(ie- ad networks, analytics)Impact• Dataretainedindefinitely• Privacyviolations
  23. 23. M8- Side Channel Data Leakage
  24. 24. Spotify console• Jun 7 18:16:34 iPhone-van-egeirnaert Spotify[17118] <Warning>: STATERESTORE: {• playstate = {• paused = 1;• repeat = 0;• showNowPlaying = 0;• shuffle = 0;• };• userinfo = {• username = 116703001;• };• version = "";• viewHierarchyRepresentation = {• children = (• {• children = (• {• URI = "spotify:search:digweed";• "active-tab" = 2;• class = SearchViewControllerIPhone;• "current-context" = 0;• query = digweed;• }• );• class = SPNavigationController;• "current-context" = 0;• },• {• children = (• {• URI = "spotify:app:discover";• class = OpenBrowseViewControllerIPhone;• "current-context" = 0;• }• );• class = SPNavigationController;• "current-context" = 0;• },•
  25. 25. M9- Broken Cryptography• Two primary categories• Broken implementations using strongcrypto libraries• Custom, easily defeated cryptoimplementations• Encoding != encryption• Obfuscation != encryption• Serialization != encryptionImpact• Confidentialityof data lost• Privilegeescalation• Circumventbusiness logic
  26. 26. M9- Broken Cryptographyldc literal_876:"QlVtT0JoVmY2N2E=”invokestatic byte[] decode( java.lang.String )invokespecial_lib java.lang.String.<init> // pc=2astore 8private final byte[]com.picuploader.BizProcess.SendRequest.routine_12998(com.picuploader.BizProcess.SendRequest, byte[], byte[] );{enternew_lib net.rim.device.api.crypto.TripleDESKey
  27. 27. M10- Sensitive Information Disclosure• We differentiate by stored (M1) vs.embedded/hardcoded (M10)• Apps can be reverse engineeredwith relative ease• Code obfuscation raises the bar, butdoesn’t eliminate the risk• Commonly found “treasures”:• API keys• Passwords• Sensitive business logicImpact• Credentialsdisclosed• Intellectualpropertyexposed
  28. 28. M10- Sensitive Information Disclosure
  29. 29. Best Practices
  30. 30. M1- Insecure Data Storage• Store ONLY what is absolutely required• Never use public storage areas (ie- SD card)• Leverage secure containers and platform provided fileencryption APIs• Do not grant files world readable or world writeablepermissionsControl#Description1.1-1.14 Identify and protectsensitive data on themobile device2.1, 2.2,2.5Handle passwordcredentials securely on thedevice
  31. 31. M2- Weak Server Side Controls• Understand the additional risksmobile apps introduce intoexisting architectures• Leverage the wealth ofknowledge that is already outthere• OWASP Web Top 10, Cloud Top10, Web Services Top 10• Cheat sheets, developmentguides, ESAPIControl#Description5.1-5.8 Keep the backend APIs(services) and the platform(server) secure
  32. 32. M3- Insufficient Transport LayerProtection• Ensure that all sensitivedata leaving the device isencrypted• This includes data overcarrier networks, WiFi, andeven NFC• When security exceptionsare thrown, it’s generallyfor a reason…DO NOTignore them!Control#Description3.1.3.6 Ensure sensitive data isprotected in transit
  33. 33. M4- Client Side Injection• Sanitize or escape untrusted databefore rendering or executing it• Use prepared statements fordatabase calls…concatenation isstill bad, and always will be bad• Minimize the sensitive nativecapabilities tied to hybrid webfunctionalityControl#Description6.3 Pay particular attention tovalidating all data receivedfrom and sent to non-trusted third party appsbefore processing10.1-10.5Carefully check anyruntime interpretation ofcode for errors
  34. 34. M5- Poor Authorization and Authentication• Contextual info canenhance things, but onlyas part of a multi-factorimplementation• Out-of-band doesn’t workwhen it’s all the samedevice• Never use device ID orsubscriber ID as soleauthenticatorControl#Description4.1-4.6 Implement userauthentication/authorization and sessionmanagement correctly8.4 Authenticate all API calls topaid resources
  35. 35. M6- Improper Session Handling• Don’t be afraid to makeusers re-authenticate everyso often• Ensure that tokens can berevoked quickly in theevent of a lost/stolendevice• Utilize high entropy, testedtoken generation resourcesControl#Description1.13 Use non-persistentidentifiers4.1-4.6 Implement userauthentication/authorization and sessionmanagement correctly
  36. 36. M7- Security Decisions Via Untrusted Inputs• Check caller’s permissions atinput boundaries• Prompt the user for additionalauthorization before allowing• Where permission checkscannot be performed, ensureadditional steps required tolaunch sensitive actionsControl#Description10.2 Run interpreters at minimalprivilege levels
  37. 37. M8- Side Channel Data Leakage• Never log credentials, PII, or other sensitive data tosystem logs• Remove sensitive data before screenshots aretaken, disable keystroke logging per field, andutilize anti-caching directives for web content• Debug your apps before releasing them to observefiles created, written to, or modified in any way• Carefully review any third party libraries youintroduce and the data they consume• Test your applications across as many platformversions as possibleControl#Description7.3 Check whether you arecollecting PII, it may notalways be obvious7.4 Audit communicationmechanisms to check forunintended leaks (e.g.image metadata)
  38. 38. M9- Broken Cryptography• Storing the key with theencrypted data negateseverything• Leverage battle-testedcrypto libraries vice writingyour own• Take advantage of whatyour platform alreadyprovides!Control#Description1.3 Utilize file encryption API’s2.3 Leverage securecontainers
  39. 39. M10- Sensitive Information Disclosure• Private API keys are called that for a reason…keepthem off the client• Keep proprietary and sensitive business logic onthe server• Almost never a legitimate reason to hardcode apassword (if there is, you have other problems)Control#Description2.10 Do not store anypasswords or secrets inthe application binary
  40. 40. Want to learn more?• https://github.com/denimgroup/Pandemobium• https://www.owasp.org/index.php/OWASP_iGoat_Project
  41. 41. References• OWASP Top 10 Mobile Risks.pptx
  42. 42. Questions?erwin.geirnaert@zionsecurity.com@ZIONSECURITYwww.zionsecurity.comblog.zionsecurity.com