OWASP

OWASPMobile Security Project

Murat Lostar

About me• Murat Lostar

• 1986 – Software development• 1992 – Network and systems • 1998 – Information security

• 2009 – ISACA-Istanbul Founding President• 2013 – Cloud Security Alliance – Turkey Founding

President• Have/had many certifications: Microsoft, Sun, IBM, Cisco, ISACA, ISC2

About my company• Lostar Information Security

• Established in 1998• Appx 15 pax. Two teams

• Technical: Pen tests, technical design, etc• Process: Focus on people and processes

• Based on ISO 27001, ISO 20000, ISO 22301, COBIT, etc• Services only (does not distribute, resell

products)

About OWASP• Open Web Application Security Project

(owasp.org)• Worldwide, not-for-profit• Mission: Make software security visible

• so that individuals and organizations worldwide can make informed decisions about true software security risks

• (All) Materials free and open software license• 36,000+ Participants (worldwide)• Has chapters! (Not yet in Malta)

Why this title?

http://www.cnet.com/news/snapchat-update-to-close-loophole-after-mass-hack/



OWASP Mobile Security Project• Branch of OWASP• Focused on securing mobile applications• Compiled list of top ten mobile security

threats

• owasp.org/index.php/OWASP_Mobile_Security_Project

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project

Overview (OWASP Mobile Security)

Focus: • Mobile Apps, Server

Side Infrastructures.

Purpose: • Taking precautions on

mobile platform and carrier inherent risks when threat modeling and building controls. Primarily at the application layer.

Target Profile: • Developers.

Scope (OWASP Mobile Security)• Top 10 Mobile Risks• Top 10 Mobile Controls• Mobile Tools• Mobile Cheat Sheet Series• Secure Mobile Development• Mobile Threat Model (BETA)

Top 10 Mobile Risks - Methodology• Exploitability : Taking advantage of a

situation• Prevalence : Commonness• Detectability : Ease of discovery• Impact : Potential effect

• owasp.org/index.php/OWASP_Risk_Rating_Methodology

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

Top 10 Mobile Risks Exploitabili

ty Prevalence Detectability Impact

10 Lack of Binary Protections Medium Common Easy Severe

10. Lack of Binary Protections• An adversary could use an automated tool to

reverse engineer the code of application and modify it.

• To prevent lack of binary:• Jailbreak Detection Controls• Checksum Controls• Certificate Pinning Controls• Debugger Detection Controls




9 Improper Session Handling Easy Common Easy Severe

9. Improper Session Handling• It’s similar to poor authentication. Once you are

authenticated and given a session, that session allows one access to the application. Therefore, sessions must be protected just as carefully as like authentication mechanism.

• To protect sessions:• Invalidate Sessions on the Backend• Timeout Protection• Properly Rotate Cookies• Secure Token Creation





8Security Decisions Via Untrusted Inputs

Easy Common Easy Severe

8. Security Decisions via Untrusted Inputs• In most cases, mobile applications accept data

from Inter Process Communication (IPC) mechanism.

• In general, should be adhered to the following design patterns:• Restrict access to a trusted applications.• Sensitive actions should require user interaction.• All IPC entries should be validated.• Do not pass any sensitive information through IPC.







7 Client Side Injection Easy Common Easy Moderate

7. Client Side Injection• Client-side attacks and particularly code injection

at the client, might be the first thing a threat agent try.

• To prevent from injections, see below titles:• SQLite Injection• JavaScript Injection (XSS, etc)• Local File Inclusion• Intent Injection/Fuzzing(Android)

• XML Injection (iOS)

• Format String Injection(iOS)

• Classic C Attacks(iOS)







7 Client Side Injection Easy Common Easy Moderate

6 Broken Cryptography Easy Common Easy Severe

6. Broken Cryptography• Insecure use of cryptography is common in most

any application that uses encryption. There are several mistakes in this area:• The Creation and Use of Custom Encryption Algorithms• Use of Insecure and/or Deprecated Algorithms• Poor Key Management



5Poor Authorization and Authentication


5. Poor AuthZ and AuthN• Authenticating a user locally can lead to client-

side bypass vulnerabilities.• Ensure all authentication requests are performed

server-side.• Persistent authentication should never be

implemented by storing password on the device.





4 Unintended Data Leakage Easy Common Easy Severe

4. Unintended Data Leakage• This includes all manner of vulnerabilities that

can be introduced by the OS, frameworks, compiler environment, new hardware, etc, all without a developers knowledge.

• It is especially important to discern what a given OS or framework does by default. By identifying this and applying mitigating controls, you can avoid unintended data leakage.






3Insufficient Transport Layer Protection

Difficult Common Easy Moderate

3. Insufficient Transport Layer Protection• When this data is exchanged it traverses both the

carrier network and the internet. For sensitive data, if the application is coded poorly, threat agents can use techniques to view this sensitive data while it's travelling across the wire.• Enforce the use of SSL/TLS for all transport channels for

sensitive data.• Use valid certificates signed by a trusted CA provider.• Do not send sensitive data over alternate channels, such

as SMS, MMS, or notifications.








2 Insecure Data Storage Easy Common Average Severe

2. Insecure Data Storage• Lost/stolen or exploit/malware involved phones threat for

this risk.• A malicious agent hooks up an unprotected device to a

computer with commonly available software, and can see sensitive information.

• Never store credentials on the phone file system. • Where storage or caching of information is necessary use

encryption library (CommonCrypto, javax.crypto, setStorageEncryption).








2 Insecure Data Storage Easy Common Average Severe

1 Weak Server Side Controls Easy Common Average Severe

1. Weak Server Side Controls • Including both the application and malicious users

could send insecure data to server.• Weak controls could cause several easy to exploit

vulnerabilities (like server side injection) that are high risk.

• Secure coding and configuration practices must be used on server-side of the mobile application.

Top 10 Mobile Controls10 Avoid / Safely Use

Interpreters 5 Secure Services and Server

9 Secure Application Distro / Update 4 Strong AuthN, AuthZ and

Session Management

8 Protect For Pay Services 3 Protect Data in Transit

7 Collect Consent for Use of User Data 2 Protect Authentication

Credentials

6 Secure 3rd Party Integration 1 ID & Protect Sensitive Data

1. ID & Protect Sensitive Data

Use ‘javax.crypto’ library.Use ‘setStorageEncryption’ API.Avoid using MODE_WORLD_READABLE shared preferences properties.

Use ‘CommonCrypto’ library.Use ‘Keychain’ API.Use SQLcipher for SQLite encryption.Avoid using NSUserDefaults.

• Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure.

2. Protect Authentication Credentials• Use the latest versions of the authorization

standards.• Encrypt the tokens in transit (using SSL/TLS).• Be sure, authentication requests are performed

server-side.• If you save password on device, encrypt it and

use key-store mechanisms provided by the mobile OS.

• Ensure passwords and keys are not visible in cache or logs and dont store them inside the binary.

3. Protect Data in Transit• Sensitive data passing through insecure channels

could be intercepted.• Enforce the use of SSL/TLS• Avoid using mixed SSL sessions.• Use certificates signed by trusted CA providers.• Ensure certificates are valid.• SMS, MMS or notifications should not be used to send

sensitive data

4. Strong AuthN, AuthZ and Session Management• Require appropriate strength user authentication to the

application.• Ensure that the session management is handled correctly

after the initial authentication.• Use unpredictable session identifiers with high entropy.• Use context to add security to authentication (IP Location).• Where possible, use additional authentication factors for

giving access to sensitive data or interfaces (voice, fingerprint etc.).

• Use authentication that ties back to the end user identity.

5. Secure Services and Server• Carry out a specific check for data transferred between the

mobile device and web-server back-ends and other external interfaces.

• Backend services for mobile apps should be tested for vulnerabilities periodically.

• Ensure that the backend platform is running with lastest security patches.

• Ensure adequate logs are retained on the backend.• Employ rate limiting and throttling on a per-user/IP basis.• Test for DoS vulnerabilities.

6. Secure 3rd Party Integration• Data leakage. Users may install applications that

may be malicious and can transmit personal data for malicious purposes.• Vet the security/authenticity of any third party

code/libraries used in your mobile application.• Track all third party frameworks/APIs used in the mobile

application for security patches.• Pay particular attention to validating all data received

from and sent to non-trusted third party apps before processing within the application.

7. Collect Consent for Use of User Data• Unintentional disclosure of personal or private

information, illegal data processing.• Create a privacy policy.• Check whether your application is collecting PII.• Audit communication mechanisms to check for

unintended leaks.• Keep a record of consent to the transfer of PII.

8. Protect For Pay Services• Logs should be protected from unauthorised

access.• Check for anomalous usage patterns in paid-for

resource usage and trigger re-authentication.• Consider using a white-list model by default for

paid-for resource addressing.• Authenticate all API calls to paid-for resources

8. Protect For Pay Services• Ensure that wallet API callbacks do not pass

cleartext account/pricing/ billing/item information.• Warn user and obtain consent for any cost

implications for app behaviour.• Implement best practices to minimize signalling

load on base stations.

9. Secure Application Distro / Update• Applications must be designed and provisioned to

allow updates for security patches.• Most app-stores monitor apps for insecure code

and are able to remotely remove apps at short notice in case of an incident.

• Provide feedback channels for users to report security problems with apps.

10. Avoid / Safely Use Interpreters• Run interpreters at minimal privilege levels.• Define comprehensive escape syntax as

appropriate.• Fuzz test interpreters.• Sandbox interpreters.

Mobile Tools• iMas: • Research project from the MITRE Corp.

Focused on open source iOS security controls.

• Research outcomes include an open source secure application framework, including an application container, developer and validation tools/techniques.

• github.com/project-imas/about

http://github.com/project-imas/about

Mobile Tools• iGoat: • Learning tool for iOS developers. It has a

similar conceptual flow to WebGoat.• Purpose is learning about security

weaknesses in iOS by breaking things as well as fixing them.

• code.google.com/p/owasp-igoat/

https://code.google.com/p/owasp-igoat/

Mobile Tools• DVIA:• Damn Vulnerable iOS Application project

started by Prateek Gianchandani which gives mobile testers and developers an iOS application to practice attacking/defending skill sets.

• damnvulnerableiosapp.com

http://damnvulnerableiosapp.com/

Mobile Tools• GoatDroid: • A fully functional and self-contained

training environment for performing security testing against Android application.

• The Project has 2 application:• FourGoats• Herd Financial

• github.com/jackMannino/OWASP-GoatDroid-Project

https://github.com/jackMannino/OWASP-GoatDroid-Project

Mobile Tools• Androick: • Research project from PHONESEC Ltd.

This tool allows any user to analyze an Android application.

• sourceforge.net/projects/androick

http://sourceforge.net/projects/androick/

Mobile Tools• MobiSec: • Project is a live environment for

testing mobile environments, including devices, applications, and supporting infrastructure.

More on OWASP• Mobile Threat Model

More on OWASP…• Mobile Threat Model

• Mobile Application Architecture• Mobile Data• Threat Agent Identification• Methods of Attack• Controls

Thank You

References• Technical examples:

http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks

• www.owasp.org /index.php/OWASP_Mobile_Security_Project




http://www.owasp.org/



OWASP Top 10 – 20131. Injection2. Broken Authentication and

Session Management3. Cross-Site Scripting (XSS)4. Insecure Direct Object

References5. Security Misconfiguration

6. Sensitive Data Exposure7. Missing Function Level

Access Control8. Cross-Site Request

Forgery (CSRF)9. Using Known Vulnerable

Components10. Unvalidated Redirects

and Forwards

Mobile Application Architecture• The mobile application architecture should, at the

very least, describe device specific features used by the application, wireless transmission protocols, data transmission medium, interaction with hardware components and other applications. Applications can be mapped to this architecture as a preliminary attack surface assessment.

Mobile Data• This section answers these basic two

question:• What data does the application store and

process? • What is the business purpose of this data and

what are the data workflows?

Threat Agent Identification• This section defines threats to the app and threat

agents. Also outlines the process for defining what threats apply to the app.

• Identifying process:• Take the list of all sensitive data.• Make a list of all the ways to access this data.• The medium used to access the same listed in S2

Methods of Attack• This section defines methods that an attacker can

use to reach the data (sensitive information or sensitive to the app itself).• Carrier Based Methods• Endpoints based methods• Wireless interfaces based methods• OS and application level methods• Miscellaneous Methods

Controls• This section asks questions to define controls to

prevent attacks.• What are the controls to prevent an attack? • What are the controls to detect an attack? • What are the controls to mitigate/minimize impact of an

attack?• What are the controls to protect users private

information?• What are the controls to based method of attacks?

Date post:	24-Feb-2016
Category:	Documents
Upload:	kaycee
View:	74 times
Download:	0 times

OWASP

Documents