Danger! Danger! Your Mobile Applications Are Not Secure


Published on

A new breed of mobile devices with sophisticated processors and ample storage has given rise to sophisticated applications that move more and more data and business logic to devices. The result is significant and potentially dangerous security challenges, especially for location-aware mobile applications and those storing sensitive or valuable data on devices. To counter these risks, Johannes Ullrich introduces and demonstrates design strategies you can use to mitigate these risks and make applications safer and less vulnerable. Johannes illustrates design patterns to: co-validate data on both the client and server; authenticate transactions on the server; and store only authenticated and access-controlled data on the client. Learn to apply these solutions without losing access to powerful HTML5 JavaScript APIs such as those required for location-based mobile applications. Johannes shares the source code of a location-based mobile application used to organize the cataloging of historic buildings.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Danger! Danger! Your Mobile Applications Are Not Secure

  1. 1.           BW8 Concurrent Session  11/7/2012 2:15 PM                "Danger! Danger! Your Mobile Applications Are Not Secure"       Presented by: Johannes Ullrich SANS Technology Institute                   Brought to you by:        340 Corporate Way, Suite 300, Orange Park, FL 32073  888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
  2. 2. Johannes Ullrich SANS Technology Institute As chief research officer for the SANS Institute, Johannes Ullrich is responsible for the SANS Internet Storm Center (ISC) (isc.sans.edu) and the GIAC Gold program. He founded DShield.org, which is now the data collection engine behind the ISC. Widely recognized for his work with the ISC, in 2004 Network World named Johannes one of the fifty most powerful people in the networking industry, and SC Magazine named him one of the top five most influential IT security thinkers in 2005. Prior to working for SANS, Johannes held positions as a lead support engineer for a web development company and as a research physicist.
  3. 3. Danger! Danger! D !D ! Your Mobile Applications Are Not Secure Johannes B. Ullrich, Ph.D. SANS Technology Institute Outline • • • • • Challenge Example Application Proper Input Validation Business Logic Summary 1
  4. 4. Mobile Web Application Challenge • Limited Connectivity – 3G/4G/5G… it never works as advertised – Data caps – Device processing and storage Mobile Web Application Opportunities • HTML 5 provides for a rich coding environment i t • “like native app” web application development • Somewhat platform independent • Access to many sensors and other phone hardware features 2
  5. 5. Security Pitfalls • Relying on on-device storage and processing i • Trusting device to perform business logic (and access control) • Client side input validation • Trust in sensors (e g geo location) (e.g. Application Walkthrough • Application was developed for a nonprofit preservation group fit ti • Non-technical audience (easy of use) 3
  6. 6. Constraints • No budget • Focus on iPhone • Had to work reasonably well on iPhone • Integrate with undocumented city APIs “Inventory” • Volunteers enter information about houses as they walk past them h th lk t th • More then 1,000 houses cataloged in less then 1month • Has to be easy and fast • Protection against bad data entry (intentional or accidental) 4
  7. 7. “Data Retrieval” • Most data is considered public • But some data only available to specific groups (e.g. a “boarding group” that will board open houses. Don’t want to advertise open houses) • Integration with web services offered by city “Forum” • Off the shelf discussion forum • Used for authentication • Integrates with information about houses 5
  8. 8. Data Entry Challenge • Entering addresses on a phone is a pain. i • Two solutions: – Enter number first, then show a list of valid street names that have a house with that number – Use geo location to show list of close addresses Address Validation • Addresses need to be broken down into: i t – Number – Street Name – Direction – Type 6
  9. 9. Difficult Addresses • • • • 7th Street vs Seventh Str. Boulevard Street Pearl Place vs Pearl Street W 7th Street vs. 7th Street West Solutions • Google/Yahoo solved the issue, and offer web services for address ff b i f dd normalization • Requires internet access, can be too slow on mobile to compete with typing speed • Rely on outside feed. Or use (buggy) city data 7
  10. 10. On Device Storage • HTML 5 enables significant on device storage t • Mostly used to cache data to reduce network traffic • Cookies still primary source of authentication data On Device Storage Validation • Only data for which the client has access is stored on the device i t d th d i • Assumption: One user per device • Data associated with time-to-live (TTL) to avoid stale data • Most sessions < 30 minutes ( (= default TTL) 8
  11. 11. Problems with HTML 5 storage • No access control • Risk of cross-domain exposure via XSS • Data leakage of confidential data • Accepted risks: authentication cookie, cookie with limited lifetime controlled by server Image Acquisition • Main limitations of (current) HTML 5 web apps is no access to camera b i t • Workaround: submit images via email • Not easy, and needs to be revised once HTML5 Media Capture standard becomes more ubiquitous 9
  12. 12. Image Submission via e-mail • Parsing e-mail • Authentication based on “From” address (INSECURE!) • Extracting images • Address in Subject • Validating address using EXIF d ld dd data • Manual validation Validating Images • Verify basic constraints (size…) • Check MIME type in e-mail headers • Check MIME type on server using “file” library • Extract EXIF data • Resize image f web for b • Manual approval 10
  13. 13. Outstanding issues • Image feature is pretty much not used (t d (too complex to use) l t ) • Needs to switch to media capture API ASAP • Media capture API needs to use based “file upload checklist” file checklist User Authentication • User Authentication in mobile web apps i a significant problem is i ifi t bl • Typical username / password combination is not working well for mobile apps due to hardware limitations 11
  14. 14. Alternative User Authentication • Use persistent cookies: Risky. Can lead to l d t problems with poorly bl ith l protected devices • Use transaction authentication in addition to persistent cookies • Add behavior detection Authentication issue solution in sample app • Use “Single Sign on” by leveraging phpBB authentication ( h BB th ti ti (user needs to d t log in only once) • User persistent cookies for low risk transactions • Watch user behavior for abuse 12
  15. 15. Example Abuse Cases • Spam: user adds spam comments to site, or uploads spam i it l d images • Data Pollution: user adds wrong data into application skewing results • Data Harvesting: user harvests data from site Spam • • • • Simple “CAPTCHA” on first sign in Content validation on posts “speed limit” on posts Unauthenticate user once bad behaviour is detected. 13
  16. 16. Data Pollution • First layer: similar to spam. Check at what rate data i entered and h t t d t is t d d prevent bots from entering data via CAPTCHA • Second Layer: use duplicate entries (data entered by several users about the same property) to determine submitter quality Data Harvesting • Not a huge problem in our case as data is d t i considered public id d bli • But can have performance impact • Simple rate limiting works so far • Offer bulk data / API for more efficient access 14
  17. 17. Authentication Logic • User connects to website and reaches page that requires h th t i authentication • Redirect to PHPBB for login (if not already logged in) • Mobile app uses PHPBB cookie to authenticate user • Mobile app creates session for user Session content • Number of entries made • Time of session • For each submission: If applicable, quality score compared to prior submissions • Geoscore: use GPS to verify submission was made in vicinity 15
  18. 18. suspect criteria • More then 5 submissions in 5 minutes i t • More then 3 submissions that do not agree with prior data • More then 2 miles away from submitted location How to deal with “Suspects” • Initially silently marking data for review i • If behavior persists, log out the user and ask to re-authenticate 16
  19. 19. Mobile Web App Checklist • Do not store confidential data on the client li t • Do not send data to the client unless the client has access control (=access control on the server) • Verify authentication token timeout on server Mobile App Checklist • Sensible authentication: Take capabilities and limitation of d i biliti d li it ti f device into account • Keep all authentication related information on the server • Don’t trust sensors alone, but use Don t alone them as a backup. 17
  20. 20. Thank you! jullrich@sans.edu Twitter: johullrich http://isc.sans.edu Please Contribute Daily Updates * Daily Podcast * Live Data Feeds 35 18