OWASP Top 10 Mobile Risks

  • 49,722 views
Uploaded on

T

T

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Hi guys,

    Could some one please suggest mobile apps security testing scenarios, test cases or implementation guidelines to me.I have an experience in web app security testing. I want to take initiate in implementing mobile app security testing as well. Could some one help in this regards. Please mail me-sarvaraju@gmail.com or call me @ 9391646333

    Regards,
    Pavan
    939164333
    Are you sure you want to
    Your message goes here
  • very good document
    Are you sure you want to
    Your message goes here
  • awesome presentation
    Are you sure you want to
    Your message goes here
  • Great presentation! I absolutely enjoyed reading it. Thanks.
    Are you sure you want to
    Your message goes here
  • This is an awesome presentation! This is just what i was intending to find when i searched the web for 'mobile security testing' :)
    Your work is amazing. Thanks a lot!
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
49,722
On Slideshare
0
From Embeds
0
Number of Embeds
18

Actions

Shares
Downloads
3,094
Comments
5
Likes
55

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Appsec USA
    Minneapolis, MN
    September 23, 2011
    OWASP Top 10 Mobile Risks
    Jack Mannino, nVisium Security
    Mike Zusman, Carve Systems
    Zach Lanier, Intrepidus Group
    OWASP Mobile Security Project
  • 2. 2
    Agenda
    Introductions
    Mobile Security Project
    Mobile Threat Model
    Top 10 Risks
    Wrap Up/Q&A
  • 3. 3
    Introductions
    Jack Mannino
    • nVisium Security
    • 4. CEO
    • 5. https://www.nvisiumsecurity.com
    Mike Zusman
    • Carve Systems
    • 6. Principal Consultant
    • 7. http://www.carvesystems.com
    Zach Lanier
    • Intrepidus Group
    • 8. Principal Consultant
    • 9. https://intrepidusgroup.com
  • 4
    Mobile Security Project
    • Began Q3 2010
    • 10. WhyUnique and different security risks
    • 11. Goal To build security into mobile dev. life cycle
    • 12. Interested? Contribute
    Threat Model
    Risks
    Controls
    Training
    Dev. Guide
    Secure Libraries
    Tools
    Methodologies
    Cheat Sheets
  • 13. Mobile Threat Model
  • 14. 6
    Mobile Threat Model
    • Platforms vary with mileage
    • 15. Very different from traditional web app model due to wildly varying use cases and usage patterns
    • 16. Must consider more than the ‘apps’
    • 17. Remote web services
    • 18. Platform integration (iCloud, C2DM)
    • 19. Device (in)security considerations
  • 7
    Mobile Threat Model
  • 20. 8
    Mobile Threat Model
  • 21. Top 10 Risks
  • 22. 10
    Top 10 Risks
    • Intended to be platform-agnostic
    • 23. Focused on areas of risk rather than individual vulnerabilities
    • 24. Weighted utilizing the OWASP Risk Rating Methodology
    • 25. https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
    • 26. Thanks to everyone who participated
  • 11
    Top 10 Risks
  • 27. 12
    M1- Insecure Data Storage
    • Sensitive data left unprotected
    • 28. Applies to locally stored data + cloud synced
    • 29. Generally a result of:
    • 30. Not encrypting data
    • 31. Caching data not intended for long-term storage
    • 32. Weak or global permissions
    • 33. Not leveraging platform best-practices
    Impact
    • Confidentiality of data lost
    • 34. Credentials disclosed
    • 35. Privacy violations
    • 36. Non-compliance
  • 13
    M1- Insecure Data Storage
  • 37. 14
    M1- Insecure Data StoragePrevention Tips
    • Store ONLY what is absolutely required
    • 38. Never use public storage areas (ie- SD card)
    • 39. Leverage secure containers and platform provided file encryption APIs
    • 40. Do not grant files world readable or world writeable permissions
  • 15
    M2- Weak Server Side Controls
    • Applies to the backend services
    • 41. Not mobile specific per se, but essential to get right
    • 42. We still can’t trust the client
    • 43. Luckily, we understand these issues well
    • 44. Existing controls may need to be re-evaluated (ie- out of band comms)
    Impact
    • Confidentially of data lost
    • 45. Integrity of data not trusted
  • 16
    M2- Weak Server Side Controls
    OWASP Top 10
    • https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
    OWASP Cloud Top 10
    • https://www.owasp.org/images/4/47/Cloud-Top10-Security-Risks.pdf
  • 17
    M2- Weak Server Side ControlsPrevention Tips
    • Understand the additional risks mobile apps introduce into existing architectures
    • 46. Leverage the wealth of knowledge that is already out there
    • 47. OWASP Web Top 10, Cloud Top 10, Web Services Top 10
    • 48. Cheat sheets, development guides, ESAPI
  • 18
    M3- Insufficient Transport Layer Protection
    • Complete lack of encryption for transmitted data
    • 49. Yes, this unfortunately happens often
    • 50. Weakly encrypted data in transit
    • 51. Strong encryption, but ignoring security warnings
    • 52. Ignoring certificate validation errors
    • 53. Falling back to plain text after failures
    Impact
    • Man-in-the-middle attacks
    • 54. Tampering w/ data in transit
    • 55. Confidentiality of data lost
  • 19
    M3- Insufficient Transport Layer Protection
    Real World Example: Google ClientLogin Authentication Protocol
    • Authorization header sent over HTTP
    • 56. When users connected via wifi, apps automatically sent the token in an attempt to automatically synchronize data from server
    • 57. Sniff this value, impersonate the user
    • 58. http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html
  • 20
    M3- Insufficient Transport Layer ProtectionPrevention Tips
    • Ensure that all sensitive data leaving the device is encrypted
    • 59. This includes data over carrier networks, WiFi, and even NFC
    • 60. When security exceptions are thrown, it’s generally for a reason…DO NOT ignore them!
  • 21
    M4- Client Side Injection
    • Apps using browser libraries
    • 61. Pure web apps
    • 62. Hybrid web/native apps
    • 63. Some familiar faces
    • 64. XSS and HTML Injection
    • 65. SQL Injection
    • 66. New and exciting twists
    • 67. Abusing phone dialer + SMS
    • 68. Abusing in-app payments
    Impact
    • Device compromise
    • 69. Toll fraud
    • 70. Privilege escalation
  • 22
    M4- Client Side Injection
    Garden Variety XSS….
    With access to:
  • 71. 23
    M4- Client Side InjectionPrevention Tips
    • Sanitize or escape untrusted data before rendering or executing it
    • 72. Use prepared statements for database calls…concatenation is still bad, and always will be bad
    • 73. Minimize the sensitive native capabilities tied to hybrid web functionality
  • 24
    M5- Poor Authorization and Authentication
    • Part mobile, part architecture
    • 74. Some apps rely solely on immutable, potentially compromised values (IMEI, IMSI, UUID)
    • 75. Hardware identifiers persist across data wipes and factory resets
    • 76. Adding contextual information is useful, but not foolproof
    Impact
    • Privilege escalation
    • 77. Unauthorized access
  • 25
    M5- Poor Authorization and Authentication
  • 78. 26
    M5- Poor Authorization and AuthenticationPrevention Tips
    • Contextual info can enhance things, but only as part of a multi-factor implementation
    • 79. Out-of-band doesn’t work when it’s all the same device
    • 80. Never use device ID or subscriber ID as sole authenticator
  • 27
    M6- Improper Session Handling
    • Mobile app sessions are generally MUCH longer
    • 81. Why? Convenience and usability
    • 82. Apps maintain sessions via
    • 83. HTTP cookies
    • 84. OAuth tokens
    • 85. SSO authentication services
    • 86. Bad idea= using a device identifier as a session token
    Impact
    • Privilege escalation
    • 87. Unauthorized access
    • 88. Circumvent licensing and payments
  • 28
    M6- Improper Session HandlingPrevention Tips
    • Don’t be afraid to make users re-authenticate every so often
    • 89. Ensure that tokens can be revoked quickly in the event of a lost/stolen device
    • 90. Utilize high entropy, tested token generation resources
  • 29
    M7- Security Decisions Via Untrusted Inputs
    • Can be leveraged to bypass permissions and security models
    • 91. Similar but different depending on platform
    • 92. iOS- Abusing URL Schemes
    • 93. Android- Abusing Intents
    • 94. Several attack vectors
    • 95. Malicious apps
    • 96. Client side injection
    Impact
    • Consuming paid resources
    • 97. Data exfiltration
    • 98. Privilege escalation
  • 30
    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/
  • 31
    M7- Security Decisions Via Untrusted InputsPrevention Tips
    • Check caller’s permissions at input boundaries
    • 99. Prompt the user for additional authorization before allowing
    • 100. Where permission checks cannot be performed, ensure additional steps required to launch sensitive actions
  • 32
    M8- Side Channel Data Leakage
    • Mix of not disabling platform features and programmatic flaws
    • 101. Sensitive data ends up in unintended places
    • 102. Web caches
    • 103. Keystroke logging
    • 104. Screenshots (ie- iOSbackgrounding)
    • 105. Logs (system, crash)
    • 106. Temp directories
    • 107. Understand what 3rd party libraries in your apps are doing with user data (ie- ad networks, analytics)
    Impact
    • Data retained indefinitely
    • 108. Privacy violations
  • 33
    M8- Side Channel Data Leakage
    Screenshots
    Logging
  • 109. 34
    M8- Side Channel Data LeakagePrevention Tips
    • Never log credentials, PII, or other sensitive data to system logs
    • 110. Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content
    • 111. Debug your apps before releasing them to observe files created, written to, or modified in any way
    • 112. Carefully review any third party libraries you introduce and the data they consume
    • 113. Test your applications across as many platform versions as possible
  • 35
    M9- Broken Cryptography
    • Two primary categories
    • 114. Broken implementations using strong crypto libraries
    • 115. Custom, easily defeated crypto implementations
    • 116. Encoding != encryption
    • 117. Obfuscation != encryption
    • 118. Serialization != encryption
    Impact
    • Confidentiality of data lost
    • 119. Privilege escalation
    • 120. Circumvent business logic
  • 36
    M9- Broken Cryptography
    ldc literal_876:"QlVtT0JoVmY2N2E=”
    invokestaticbyte[] decode( java.lang.String ) // Base 64
    invokespecial_libjava.lang.String.<init> // pc=2
    astore8
    private final byte[] com.picuploader.BizProcess.SendRequest.routine_12998
    (com.picuploader.BizProcess.SendRequest, byte[], byte[] );
    {
    enter
    new_libnet.rim.device.api.crypto.TripleDESKey
  • 121. 37
    M9- Broken CryptographyPrevention Tips
    • Storing the key with the encrypted data negates everything
    • 122. Leverage battle-tested crypto libraries vice writing your own
    • 123. Take advantage of what your platform already provides!
  • 38
    M10- Sensitive Information Disclosure
    • We differentiate by stored (M1) vs. embedded/hardcoded (M10)
    • 124. Apps can be reverse engineered with relative ease
    • 125. Code obfuscation raises the bar, but doesn’t eliminate the risk
    • 126. Commonly found “treasures”:
    • 127. API keys
    • 128. Passwords
    • 129. Sensitive business logic
    Impact
    • Credentials disclosed
    • 130. Intellectual property exposed
  • 39
    M10- Sensitive Information Disclosure
  • 131. 40
    M10- Sensitive Information DisclosurePrevention Tips
    • Private API keys are called that for a reason…keep them off of the client
    • 132. Keep proprietary and sensitive business logic on the server
    • 133. Almost never a legitimate reason to hardcode a password (if there is, you have other problems)
  • Wrap Up
  • 134. 42
    Going Forward
    • 60 day review period open to the public
    • 135. RC1 then becomes ‘Final v1.0’
    • 136. 12 month revision cycle
    • 137. Rapidly evolving platforms
    • 138. Stale data = not as useful
    • 139. If you have suggestions or ideas, we want them!
  • 43
    Conclusion
    • This is a good start, but we have a long way to go
    • 140. We’ve identified the issues…now we have to fix them
    • 141. Platforms must mature, frameworks must mature, apps must mature
    • 142. The OWASP Mobile body of knowledge must grow
  • 44
    Q&A
    Thanks for listening!
    • Jack Mannino jack@nvisiumsecurity.comhttp://twitter.com/jack_mannino
    • 143. Zach Lanier zach.lanier@intrepidusgroup.comhttp://twitter.com/quine
    • 144. Mike Zusmanmike.zusman@carvesystems.comhttp://twitter.com/schmoilito