CFObjective Notes: Mobile but Secure - Bilal Soylu

May 18, 2013

Mobile but Secure - Bilal Soylu

Insecure Data Storage
we have all these files for storage - sql lite database, log files, xml, cookie stores, etc
how sure am i that NO other application can read it?
confidentially of data is lost
Credentials disclosed
if i have a mobile version of something on my desktop, they should NOT use the same credentials. don't want someone hacking the mobile app to be able to break into the web app too
caches can be read too
if you have to store stuff, store it in the right way, in the right place
use the right kind of encryption
assign permissions to the files that your app generates

Weak Server Side Controls
all the pipes to the back end need to be secure
trust needs to be established
Autenticate, Authorize, Type, and Content

Know Your Basics
OWASP Top 10 list changed in 2013
injection
broken auth and sees
xss
insecure direct object refs
security misconfigs
sensitive data exposure
etc, etc

Thoughts
so you THINK you know all the stuff, you've read the blogs, etc.
we're still trying to learn today how mobile fits into everything

Common API Pattern (bad)
REST API
call comes in via REST, you authenticate and validate, and can request whatever you want
now i do the SOAP api on top, do i do the same thing on top?
now a socket on top of that
...and now i have THREE areas people can attack me thru

Improved Surface Attack
think about a channel as kind of a "transport layer" into our app
normalize the layers
regardless of how the data came in, normalize what goes into your system
then i have ONE service layer to secure, instead of 3 or 4 different ones
REST may be good for convenience, but maybe not good for minimizing attack surfaces
easier to control "1 door" than "many doors"

Insufficient Transport Layer Protection
transporting things OUTside of https isn't a good idea
many transports combine plain text with sensitive data
poor planning about security
ignore errors
-- certificate warnings and expirations

at the airport, make your laptop a hotspot
name it the SAME as the airport wifi
then install Charles
and bam...can sniff everyone's connections. they'll all connect to YOU instead of the real airport wifi. people don't think about this when connecting to wifi

Impact
when you have sensitive data, use SSL
in your mobile app you should "question your connections"
don't ignore errors
even tho it's painful, let's make the app "right"
make sure the servers we're hitting are proper, don't use self-signed certs in Production, etc.

Client Side Injection
Our old friends -- XSS and XHTML injections
SQL injections
normally in XSS the intent is to hit some other user
still may be the case in your mobile apps.

XSS new target is your device
target is not the server but the app running on the client

Mitigation
how can we get better?
sanitize or escape all inputs
once data has left the server, never ever ever trust it
white lists are good techniques
we aware of the inputs you use
if i'm expecting GPS input, does the data LOOK like GPS input?

XSS via HTML5 forms
HTML5 is cool, but makes some exploits easier
new form elements
form action can be exploited, in banner ads, etc.

XSS via HTML5
check 3rd party code that you display
use reliable partners
the "form action" thing was supposed to be an HTML5 -feature- but features can be exploited too.

how long do people use your application if it's not convenient?
need to strike a balance in convenience and security

multi-factor author is a good idea
out of band does not work if everything is on the same device
if i have a man in the middle attack on my phone, then logging in and calling my phone for auth doesn't solve anything -- it's all the same channel, it's not "OUT of bound"

Improper session handling
difference in sessions on mobile / desktop
sessions on mobile are much LONGER
which increases the chances for it to be insecure

Don't use Device IDs

sometimes you have to ask for re-authentication
-- set expirations for use
build active revocation into your sessions so stolen devices can quickly be disabled
use proper token generation techniques
build a way to DISABLE sessions into your apps

Security Decisions via Untrusted Inputs
some mobile apps introduce extra features, can be invoked by URL schemes,
if I can use the Skype protocol via URL, could i make a phone call just by building that URL?
so i could have an app that just makes phone calls or sends text....without consent!

Side Channel Data Leakage
Don't log credentials or sensitive data
remove sensitive data and screenshots
if you have debug libraries in your app, what are they doing?
review 3rd party libraries
-- what data do they use / transmit
are you taking screenshots with Weinre? With passwords in the screenshots? Or other sensitive data?
remember to delete those screenshtos when you don't need them any more, so they're not on the device for other apps to see and exploit

Apple and iOS - when they started logging where people were in GPS, that data went into a log file. Irritated a LOT of people.

Broken Cryptography
Encoding, Obfuscation and Serialization are NOT encryption
broken encryption = you used short keys rather than proper length keys,, etc. stuff that can be easily bypassed.
do not store keys on the same media you use them on
-- storing the key WITH the encrypted data...bad idea
use proven cryptography libs (don't write your own. it's hard).
-- there are enough libraries out there that do it RIGHT
take advantage of platform libs if possible

Sensitive Information Disclosure

don't store sensitive info on devices
don't transfer them TO the device either
never hardcode passwords
don't store passwords in code -- that's plain text!

Indicating Trust Within Your Code

Keep current with updates
so you're not as easy of a target

Stay vigilant!

Resources:
OWASP www.owasp.org
Security Vendors - Symantec, etc