Your SlideShare is downloading. ×
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Danger! Danger! Your Mobile Applications Are Not Secure
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Danger! Danger! Your Mobile Applications Are Not Secure

88

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 …

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
88
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
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.           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. 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. 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. 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. 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. 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. “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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Thank you! jullrich@sans.edu Twitter: johullrich http://isc.sans.edu Please Contribute Daily Updates * Daily Podcast * Live Data Feeds 35 18

×