Embed Size (px)
Citation preview
Engineering mobile security
Subodh Iyengar Security Infrastructure
Managing user data
Abstractions
Threat models
Team
Mobile development @ Scale
100s of engineers > 150K files
> 100K commits
3 security engineers
Abstractions t0ols make code secure by default
Software Engineers passionate about security
Threat models
Malicious apps and websites
Network attackers
User data can be stolen by intent hijacking
Stealing user data
Intent intent = new Intent(); Intent.setData(“fb://url?secret=….”); startActivity(intent);
Malicious app
Facebook app
User data can be stolen by intent hijacking
Stealing user data
class SecureContextHelper { startActivity(); startExternalActivity(); }
When you need to send private data
Don’t send private data
• Simple rule: instead of using startActivity from Activity use startActivity from SecureContextHelper.
• Safe by default.
• Tools
XSS holes
Stealing user data
Native apps also have webviews
file scheme allows cross domain bypass in android webviews
(old versions)
Java => javascript bridges complicate matters
Intent intent = getIntent(); Uri data = Intent.getData(); webview.load(data.getQueryParam(“f”))
f = javascript:alert(1);
XSS holes
Stealing user data
Intent intent = getIntent(); Uri data = Intent.getData(); webview.load(data.getQueryParam(“f”))
class SecureWebviewHelper { loadUrl(); }
f = javascript:alert(1); Sanitizes all url loads
SQL injection and Permission stealing
Stealing user data
Content providers are not safe unless protected by a permission (older android versions)
SQLLiteQueryBuilder is a SQL injection bug
Permission stealing would compromise Content providers entirely
class UserContentProvider extends ContentProvider { query(Uri uri, ….) { SQLLiteQueryBuilder qb = new … where = uri.getPath(1); qb.appendWhere(where); qb.query(…); } }
SQL injection and Permission stealing
Stealing user data
Secure wrapper, prevents permission stealing attacks from other applications
Simple rule, instead of inheriting from ContentProvider inherit from SecureContentProvider
This has prevented several bugs
class SecureContentProvider { doQuery(); doInsert(); …. }
Leaking data via logs
Stealing user data
Other apps can inspect app logs (in older android versions)
Dynamically decides whether or not to enable logging
Prevents unintentional logging class BLog { public void d(tag, message); public void i(tag, message); }
class Log { public void d(tag, message); public void i(tag, message); }
Communicating via broadcasts
Stealing user data
Other apps can intercept implicit broadcasts, thus we need to safeguard them
Simple rule: if you want a broadcast, use one of these
These cover 99% of use cases, thus not reinventing the wheel
Make it hard to get an unsafe broadcast receiver
interface FbBroadcastManager { sendBroadcast(intent); }
• CrossProcessFbBroadcastManager
• LocalFbBroadcastManager
• PermissionBasedFbBroadcastManager
What causes MITM vulnerabilities?
Network threats
Using different SSL stacks in different code paths SSLSocketFactory factory =
SSLSocketFactory.getDefault(); SSLSocket socket = factory.getSocket(); socket.getInputStream();
What causes MITM vulnerabilities?
Network threats
Using different SSL stacks in different code paths
Code that really really doesn’t want to use https
deSslUrl(String uri) { uri.replace(“https:”, “http:”); }
What causes MITM vulnerabilities?
Network threats
Using different SSL stacks in different code paths
Code that really really doesn’t want to use https
When we think of SSL. We need to make it faster and easier to use
Network threats
SSLSocketFactoryHelper makes SSL faster and secure
One place to get SSL sockets
Abstracts platform differences
Enables features like session tickets, SNI in all android versions
Certificate pinning and logging
People naturally migrated
@interface FBRequester () <NSURLConnectionDelegate … {
class SSLSocketFactoryHelper { getSocketFactory(); }
Network threats
Moving to SPDY reduces the overhead of SSL even further Better connection reuse
SSLSocketFactoryHelper
SPDY
Storing user data Caching is mandatory.
For many typical users, storage is limited.
Expandable storage
We store images on SD card.
SD card is world readable.
internal storage
external storage
Conceal Existing libraries use memory and are slow.
Conceal uses certain encryption algorithms from OpenSSL
Made for Android, tries to manage memory usage.
Faster than system provided libraries.
Uses AES-GCM authenticated encryption.
internal storage
external storage
Conceal We’re open sourcing it.
You can use it to keep data safe.
Not a general purpose crypto library.
internal storage
external storage http://facebook.github.io/conceal
