Mobile Top 10 2014-M3 - Revision history

Barbarafox: spelling

2015-10-08T18:26:23Z

spelling

Ryan Dewhurst: Removed NSStreamSocketSecurityLevelSSLv3 recommendation as SSLv3 is deprecated

2015-04-23T17:12:14Z

Removed NSStreamSocketSecurityLevelSSLv3 recommendation as SSLv3 is deprecated

Ruiwangwarm at 18:23, 2 December 2014

2014-12-02T18:23:52Z

Stephencor at 07:02, 8 October 2014

2014-10-08T07:02:23Z

Jonathan Carter at 00:14, 10 April 2014

2014-04-10T00:14:17Z

Jason Haddix at 08:48, 27 January 2014

2014-01-27T08:48:32Z

Jason Haddix at 07:33, 27 January 2014

2014-01-27T07:33:26Z

Jason Haddix: Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COM..."

2014-01-27T04:59:30Z

Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COM..."

New page

{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-1-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>When designing a mobile application, commonly data is exchanged in a client-server fashion. 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. The following threat agents exist:

* Users local to your network (compromised or monitored wifi)
* Carrier or network devices (routers, cell towers, proxys, etc)
* Malware pre-exisiting on your phone
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carriers network is harder than that of monitoring a local coffee shops traffic. In general targeted attacks are easier to perform. </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Unfortunately, mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. In addition, the existence of transport security does not mean it is implemented to it's full potential.

Detecting basic flaws is easy. Just observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants.</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=3}}
The best way to find out if an application has sufficient transport layer protection is to look at the application traffic through a proxy. Find the answers to the following questions:

# Are all connections, not just ones to servers you own, properly encrypted?
# Are the SSL certificates in date?
# Are the SSL certificates self signed?
# Does the SSL use high enough cipher strengths?
# Will your application accept user accepted certificates as authorities?
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=3}}
'''General Best Practices:'''

* Assume that the network layer is not secure and may potentially be hostile and eavesdropping.
* Enforce the use of SSL/TLS for all transport channels in which sensitive information, session tokens, or other sensitive data is going to be communicated to a backend API or web service.
* Remember to account for outside entities like 3rd party analytics companies, social networks, etc, and use their SSL versions even when an application runs a routine via the browser/webkit. Mixed SSL sessions should be avoided and may expose the user’s session ID.
* Use strong, industry standard encryption algorithms and appropriate key lengths.
* Use certificates signed by a trusted CA provider.
* Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
* Do not disable or ignore SSL chain verification.
* Only establish a secure connection after verifying the identity of the endpoint server with trusted certificates in the key chain.
* Alert users through the UI if an invalid certificate is detected.
* Do not send sensitive data over alternate channels, such as SMS, MMS, or notifications.

'''iOS Specific Best Practices'''

Default classes in iOS handle SSL cipher strength and negotiation very well as of recent releases. The trouble comes when code is introduced to bypass these defaults to accommodate development hurdles. In addition to the above general practices:

* Ensure that certificates are valid and fail closed.
* When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
* After development ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
* Consider using certificate pinning by exporting your certificate, including it in your app bundle, and anchoring it for your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

'''Android Specific Best Practices'''

* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. This is equivalent to trusting all certificates.

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=3}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=3}}
* [http://h30499.www3.hp.com/t5/Fortify-Application-Security/Exploring-The-OWASP-Mobile-Top-10-M3-Insufficient-Transport/ba-p/5966473 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insufficient Transport Layer Protection]
* [https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet OWASP ][https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet IOS Developer Cheat Sheet]
* [http://blog.securemacprogramming.com/2011/12/on-ssl-pinning-for-cocoa-touch/ blog.securemacprogramming.com - SSL Pinning for Cocoa Touch]
* [http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security]
* [http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html Fortify VulnCat - A Taxonimy of Software Security Errors]

@@ Line 50: / Line 50: @@
 * Alert users through the UI if the mobile app detects an invalid certificate.
 * Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).
-* If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrytped data will provide a secondary defense against confidentiality violation.
+* If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation.
 Newer threats allow an adversary to eavesdrop on sensitive traffic by intercepting the traffic within the mobile device just before the mobile device's SSL library encrypts and transmits the network traffic to the destination server. See M10 for more information on the nature of this risk.

@@ Line 59: / Line 59: @@
 * Ensure that certificates are valid and fail closed.
-* When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
+* When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
 * After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
 * Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

← Older revision		Revision as of 18:23, 2 December 2014
Line 67:		Line 67:

	* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.		* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.
		+	* If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.

	{{Mobile_Top_10_2012:SubsectionAdvancedTemplate\|type={{Mobile_Top_10_2012:StyleTemplate}}\|number=3\|risk=3}}		{{Mobile_Top_10_2012:SubsectionAdvancedTemplate\|type={{Mobile_Top_10_2012:StyleTemplate}}\|number=3\|risk=3}}

@@ Line 9: / Line 9: @@
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device's carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it's traveling across the wire. The following threat agents exist:
-* An adversary that shares your local network (compromised or monitored wifi);
+* An adversary that shares your local network (compromised or monitored Wi-Fi);
-* Carrier or network devices (routers, cell towers, proxys, etc); or
+* Carrier or network devices (routers, cell towers, proxy's, etc); or
 * Malware on your mobile device.
 </td>
@@ Line 20: / Line 20: @@
 To detect basic flaws, observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. </td>
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This flaw exposes an individual user's data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>At a minimum, intception of sensitive data through a communication channel will result in a privacy violation.
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>At a minimum, interception of sensitive data through a communication channel will result in a privacy violation.
 The violation of a user's confidentiality may result in:
@@ Line 50: / Line 50: @@
 * Alert users through the UI if the mobile app detects an invalid certificate.
 * Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).
-* If possible, apply a seperate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrytped data will provide a secondary defense against confidentiality violation.
+* If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrytped data will provide a secondary defense against confidentiality violation.
 Newer threats allow an adversary to eavesdrop on sensitive traffic by intercepting the traffic within the mobile device just before the mobile device's SSL library encrypts and transmits the network traffic to the destination server. See M10 for more information on the nature of this risk.
@@ Line 72: / Line 72: @@
 ; Lack of Certificate Inspection
-: The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptable to man-in-the-middle attacks through a SSL proxy
+: The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a SSL proxy
 ; Weak Handshake Negotiation
-: The mobile app and an endpoint successfully connect and negotiate a ciphersuite as part of the connection handshake. The client successfully negotiates with the server to use a weak ciphersuite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint;
+: The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint;
 ; Privacy Information Leakage
 : The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.

← Older revision		Revision as of 08:48, 27 January 2014
Line 1:		Line 1:
		+	<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
	{{Top_10_2010:SubsectionColoredTemplate\|<center>Insufficient Transport Layer Protection</center>\|\|year=2014}}		{{Top_10_2010:SubsectionColoredTemplate\|<center>Insufficient Transport Layer Protection</center>\|\|year=2014}}
	{{Top_10_2010:SummaryTableHeaderBeginTemplate}}		{{Top_10_2010:SummaryTableHeaderBeginTemplate}}

@@ Line 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>When designing a mobile application, commonly data is exchanged in a client-server fashion. 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. The following threat agents exist:
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device's carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it's traveling across the wire. The following threat agents exist:
-* Users local to your network (compromised or monitored wifi)
+* An adversary that shares your local network (compromised or monitored wifi);
-* Carrier or network devices (routers, cell towers, proxys, etc)
+* Carrier or network devices (routers, cell towers, proxys, etc); or
-* Malware pre-exisiting on your phone
+* Malware on your mobile device.
 </td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carriers network is harder than that of monitoring a local coffee shops traffic. In general targeted attacks are easier to perform.  </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carrier's network is harder than that of monitoring a local coffee shop's traffic. In general, targeted attacks are easier to perform.  </td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Unfortunately, mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. In addition, the existence of transport security does not mean it is implemented to it's full potential.
+      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere.  This inconsistency leads to the risk of exposing data and session IDs to interception.
-Detecting basic flaws is easy. Just observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. </td>
+The use of transport security does not mean the app has implemented it correctly.
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants.</td>
+To detect basic flaws, observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. </td>
 {{Top_10_2010:SummaryTableEndTemplate}}
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=3}}
-The best way to find out if an application has sufficient transport layer protection is to look at the application traffic through a proxy. Find the answers to the following questions:
+To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:
 # Are all connections, not just ones to servers you own, properly encrypted?
@@ Line 32: / Line 40: @@
 '''General Best Practices:'''
-* Assume that the network layer is not secure and may potentially be hostile and eavesdropping.
+* Assume that the network layer is not secure and is susceptible to eavesdropping.
-* Enforce the use of SSL/TLS for all transport channels in which sensitive information, session tokens, or other sensitive data is going to be communicated to a backend API or web service.
+* Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
-* Remember to account for outside entities like 3rd party analytics companies, social networks, etc, and use their SSL versions even when an application runs a routine via the browser/webkit. Mixed SSL sessions should be avoided and may expose the user’s session ID.
+* Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.
-* Use strong, industry standard encryption algorithms and appropriate key lengths.
+* Use strong, industry standard cipher suites with appropriate key lengths.
 * Use certificates signed by a trusted CA provider.
 * Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
-* Do not disable or ignore SSL chain verification.
+* Always require SSL chain verification.
-* Only establish a secure connection after verifying the identity of the endpoint server with trusted certificates in the key chain.
+* Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
-* Alert users through the UI if an invalid certificate is detected.
+* Alert users through the UI if the mobile app detects an invalid certificate.
-* Do not send sensitive data over alternate channels, such as SMS, MMS, or notifications.
+* Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).
 '''iOS Specific Best Practices'''
-Default classes in iOS handle SSL cipher strength and negotiation very well as of recent releases. The trouble comes when code is introduced to bypass these defaults to accommodate development hurdles. In addition to the above general practices:
+Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:
 * Ensure that certificates are valid and fail closed.
 * When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
-* After development ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
+* After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
-* Consider using certificate pinning by exporting your certificate, including it in your app bundle, and anchoring it for your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.
+* Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.
 '''Android Specific Best Practices'''
-* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. This is equivalent to trusting all certificates.
+* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=3}}
-Example Scenarios
+There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's transport layer security:
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=3}}
 * [http://h30499.www3.hp.com/t5/Fortify-Application-Security/Exploring-The-OWASP-Mobile-Top-10-M3-Insufficient-Transport/ba-p/5966473 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insufficient Transport Layer Protection]

← Older revision		Revision as of 07:33, 27 January 2014
Line 1:		Line 1:
		+	{{Top_10_2010:SubsectionColoredTemplate\|<center>Insufficient Transport Layer Protection</center>\|\|year=2014}}
	{{Top_10_2010:SummaryTableHeaderBeginTemplate}}		{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
	{{Top_10_2010:SummaryTableValue-3-Template\|Exploitability\|DIFFICULT}}		{{Top_10_2010:SummaryTableValue-3-Template\|Exploitability\|DIFFICULT}}