Scribd Logo
Upload

Welcome to Scribd!

  • 99 views

    Engineering Mobile Security

    Uploaded by

    Shamiq Islam
    Mobile security at scale requires abstractions and tools to make code secure by default against threats like data theft, injection attacks, and man-in-the-middle vulnerabilities. The team uses techniques like permission-protected broadcast receivers, SQL injection prevention, and a custom SSL socket factory to safeguard user data across 100s of engineers and millions of lines of code. They also built Conceal, an encryption library optimized for Android, to securely store cached user data on internal and external storage.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Engineering Mobile Security

    Uploaded by

    Shamiq Islam
    99 views25 pages
    Mobile security at scale requires abstractions and tools to make code secure by default against threats like data theft, injection attacks, and man-in-the-middle vulnerabilities. The team uses techniques like permission-protected broadcast receivers, SQL injection prevention, and a custom SSL socket factory to safeguard user data across 100s of engineers and millions of lines of code. They also built Conceal, an encryption library optimized for Android, to securely store cached user data on internal and external storage.

    Original Description:

    Mobile Security for PDFs

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Mobile security at scale requires abstractions and tools to make code secure by default against threats like data theft, injection attacks, and man-in-the-middle vulnerabilities. The team uses techniques like permission-protected broadcast receivers, SQL injection prevention, and a custom SSL socket factory to safeguard user data across 100s of engineers and millions of lines of code. They also built Conceal, an encryption library optimized for Android, to securely store cached user data on internal and external storage.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    99 views25 pages

    Engineering Mobile Security

    Uploaded by

    Shamiq Islam
    Mobile security at scale requires abstractions and tools to make code secure by default against threats like data theft, injection attacks, and man-in-the-middle vulnerabilities. The team uses techniques like permission-protected broadcast receivers, SQL injection prevention, and a custom SSL socket factory to safeguard user data across 100s of engineers and millions of lines of code. They also built Conceal, an encryption library optimized for Android, to securely store cached user data on internal and external storage.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 25

    Engineering mobile security

    Subodh Iyengar Security Infrastructure

    Team

    Threat models

    Abstractions

    Managing user data

    Mobile development @ Scale


    100s of engineers > 150K les > 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

    Stealing user data


    User data can be stolen by intent hijacking
    Intent intent = new Intent(); Intent.setData(fb://url?secret=.);
    Facebook app

    startActivity(intent);

    Malicious app

    Stealing user data


    User data can be stolen by intent hijacking
    ! Simple rule: instead of using startActivity from Activity use startActivity from SecureContextHelper. ! Safe by default. ! Tools
    class SecureContextHelper { startActivity(); startExternalActivity(); }

    When you need to send private data

    Dont send private data

    Stealing user data


    XSS holes
    Native apps also have webviews
    Intent intent = getIntent(); Uri data = Intent.getData(); webview.load(data.getQueryParam(f))

    le scheme allows cross domain bypass in android webviews (old versions) Java => javascript bridges complicate matters

    f = javascript:alert(1);

    Stealing user data


    XSS holes
    Intent intent = getIntent(); Uri data = Intent.getData(); webview.load(data.getQueryParam(f)) } class SecureWebviewHelper { loadUrl();

    f = javascript:alert(1);

    Sanitizes all url loads

    Stealing user data


    SQL injection and Permission stealing
    class UserContentProvider extends ContentProvider { query(Uri uri, .) { SQLLiteQueryBuilder qb = new where = uri.getPath(1); qb.appendWhere(where); qb.query(); }

    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

    Stealing user data


    SQL injection and Permission stealing
    class SecureContentProvider { doQuery(); doInsert(); . }

    Secure wrapper, prevents permission stealing attacks from other applications Simple rule, instead of inheriting from ContentProvider inherit from SecureContentProvider This has prevented several bugs

    Stealing user data


    Leaking data via logs
    class Log { public void d(tag, message); } public void i(tag, message);

    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); }

    Stealing user data


    Communicating via broadcasts
    interface FbBroadcastManager { sendBroadcast(intent); }

    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

    ! CrossProcessFbBroadcastManager ! LocalFbBroadcastManager ! PermissionBasedFbBroadcastManager

    Network threats
    What causes MITM vulnerabilities?
    SSLSocketFactory factory = SSLSocketFactory.getDefault(); SSLSocket socket = factory.getSocket(); socket.getInputStream();

    Using different SSL stacks in different code paths

    Network threats
    What causes MITM vulnerabilities?
    deSslUrl(String uri) { uri.replace(https:, http:); }

    Using different SSL stacks in different code paths Code that really really doesn t want to use https

    Network threats
    What causes MITM vulnerabilities?
    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
    class SSLSocketFactoryHelper { getSocketFactory(); }

    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 Certicate pinning and logging People naturally migrated

    @interface FBRequester () <NSURLConnectionDelegate {

    Network threats
    SSLSocketFactoryHelper

    Moving to SPDY reduces the overhead of SSL even further Better connection reuse

    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
    Were open sourcing it. You can use it to keep data safe. Not a general purpose crypto library.
    http://facebook.github.io/conceal

    internal storage external storage

    You might also like