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.

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