← Older revision
Revision as of 00:14, 10 April 2014
Line 7:
Line 7:
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
{{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>
−
<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>
+
<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.
+
+
The violation
of
a user's
confidentiality
may result in:
+
+
* Identity theft;
+
* Fraud
,
or
+
* Reputational Damage
.</td>
{{Top_10_2010:SummaryTableEndTemplate}}
{{Top_10_2010:SummaryTableEndTemplate}}
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=3}}
{{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?
# Are all connections, not just ones to servers you own, properly encrypted?
Line 32:
Line 40:
'''General Best Practices:'''
'''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.
* Use certificates signed by a trusted CA provider.
* Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
* 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
).
+
* 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
.
+
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.
'''iOS Specific Best Practices'''
'''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.
* 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, 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'''
'''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}}
{{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:
+
+
; 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
+
; 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;
+
; 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.
+
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=3}}
{{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]
* [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]