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

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.

1

D ! D ! Danger! Danger! Your Mobile Applications Are Not Secure

Johannes B. Ullrich, Ph.D.SANS Technology Institute

Outline

• Challenge• Example Application• Proper Input Validation• Business Logic• Summary

2

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 i tenvironment

• “like native app” web application development

• Somewhat platform independentAccess to many sensors and other • Access to many sensors and other phone hardware features

3

Security Pitfalls

• Relying on on-device storage and iprocessing

• Trusting device to perform business logic (and access control)

• Client side input validationTrust in sensors (e g geo location)• Trust in sensors (e.g. geo location)

Application Walkthrough

• Application was developed for a non-fit ti profit preservation group

• Non-technical audience (easy of use)

4

Constraints

• No budget• Focus on iPhone• Had to work

reasonably well on iPhoneIntegrate with • Integrate with undocumented city APIs

“Inventory”

• Volunteers enter information about h th lk t thhouses as they walk past them

• More then 1,000 houses cataloged in less then 1month

• Has to be easy and fastProtection against bad data entry • Protection against bad data entry (intentional or accidental)

5

“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 • Integration with web services offered by city

“Forum”

• Off the shelf discussion forum• Used for authentication• Integrates with information about

houses

6

Data Entry Challenge

• Entering addresses on a phone is a ipain.

• 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 i tinto:– Number– Street Name– Direction– TypeType

7

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 ff b i f dd offer web services for address

normalization• Requires internet access, can be too

slow on mobile to compete with typing speedtyping speed

• Rely on outside feed. Or use (buggy) city data

8

On Device Storage

• HTML 5 enables significant on device tstorage

• Mostly used to cache data to reduce network traffic

• Cookies still primary source of authentication dataauthentication data

On Device Storage Validation

• Only data for which the client has i t d th d iaccess is stored on the device

• Assumption: One user per device• Data associated with time-to-live

(TTL) to avoid stale dataMost sessions < 30 minutes ( • Most sessions < 30 minutes (= default TTL)

9

Problems with HTML 5 storage

• No access control• Risk of cross-domain exposure via

XSS• Data leakage of confidential data• Accepted risks: authentication

cookie with limited lifetime cookie, with limited lifetime controlled by server

Image Acquisition

• Main limitations of (current) HTML 5 b i t web apps is no access to camera

• Workaround: submit images via e-mail

• Not easy, and needs to be revised once HTML5 Media Capture standard once HTML5 Media Capture standard becomes more ubiquitous

10

Image Submission via e-mail

• Parsing e-mail• Authentication based on “From”

address (INSECURE!)• Extracting images• Address in Subject

l d dd d• Validating address using EXIF 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

f b• Resize image for web• Manual approval

11

Outstanding issues

• Image feature is pretty much not d (t l t )used (too complex to use)

• Needs to switch to media capture API ASAP

• Media capture API needs to use based “file upload checklist”based file upload checklist

User Authentication

• User Authentication in mobile web i i ifi t blapps is a significant problem

• Typical username / password combination is not working well for mobile apps due to hardware limitationslimitations

12

Alternative User Authentication

• Use persistent cookies: Risky. Can l d t bl ith l lead to problems with poorly protected devices

• Use transaction authentication in addition to persistent cookies

• Add behavior detection• Add behavior detection

Authentication issue solution in sample app

• Use “Single Sign on” by leveraging h BB th ti ti ( d t phpBB authentication (user needs to

log in only once)• User persistent cookies for low risk

transactions• Watch user behavior for abuse• Watch user behavior for abuse

13

Example Abuse Cases

• Spam: user adds spam comments to it l d isite, or uploads spam images

• Data Pollution: user adds wrong data into application skewing results

• Data Harvesting: user harvests data from sitefrom site

Spam

• Simple “CAPTCHA” on first sign in• Content validation on posts• “speed limit” on posts• Unauthenticate user once bad

behaviour is detected.

14

Data Pollution

• First layer: similar to spam. Check at h t t d t i t d d what rate data is entered and

prevent bots from entering data via CAPTCHA

• Second Layer: use duplicate entries (data entered by several users about (data entered by several users about the same property) to determine submitter quality

Data Harvesting

• Not a huge problem in our case as d t i id d blidata is considered public

• But can have performance impact• Simple rate limiting works so far• Offer bulk data / API for more

efficient accessefficient access

15

Authentication Logic

• User connects to website and h th t i reaches page that requires

authentication• Redirect to PHPBB for login (if not

already logged in)• Mobile app uses PHPBB cookie to • 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 submissionsGeoscore: use GPS to verify • Geoscore: use GPS to verify submission was made in vicinity

16

suspect criteria

• More then 5 submissions in 5 i tminutes

• More then 3 submissions that do not agree with prior data

• More then 2 miles away from submitted locationsubmitted location

How to deal with “Suspects”

• Initially silently marking data for ireview

• If behavior persists, log out the user and ask to re-authenticate

17

Mobile Web App Checklist

• Do not store confidential data on the li tclient

• Do not send data to the client unless the client has access control (=access control on the server)

• Verify authentication token timeout • Verify authentication token timeout on server

Mobile App Checklist

• Sensible authentication: Take biliti d li it ti f d i capabilities and limitation of device

into account• Keep all authentication related

information on the server• Don’t trust sensors alone but use • Don t trust sensors alone, but use

them as a backup.

18

Thank you!

jullrich@sans.eduTwitter: johullrich

http://isc.sans.eduPlease ContributePlease Contribute

Daily Updates * Daily Podcast * Live Data Feeds

35