[Owasp-leaders] OWASP Mobile Top Ten 2014 - M10 Datapoints

Jason Haddix jason.haddix at owasp.org
Tue Nov 4 21:53:07 UTC 2014

This was posted from Brad Hill (Sec Engineer at Facebook) to our MTT
mailing list, pasted verbatim:

"I won't be able to make the call, but wanted to provide some documented
feedback on the topic.

As currently written, multiple experts have expressed serious concerns that
M10 actually presents a sound security practice and reasonable goals.
Obfuscation systems that are practical to deploy for current mobile app
platforms can at best marginally increase the cost of attacking an
application.  At worst, they create a false sense of security.  For
sufficiently valuable secrets, determined attackers will find ways to
bypass any obfuscation possible with current techniques.  Encouraging the
idea that these are meaningful and effective protections therefore
propagates mistaken software architectures that promise things to users
they cannot deliver.  The recent attack against users of the Snapchat
service where malicious or insecure clients used API keys extracted from
the obfuscated genuine app is a great example of the kind of risks this bad
advice presents.

For client-server architectures that distribute identical binaries to all
clients, we have known the appropriate security practice for decades: do
not put secrets in the source code or binary.  (whether those secrets are
cryptographic keys or algorithms)  It is true that this makes distributed
systems with properties that many developers want either difficult or
impossible to build. (e.g. API endpoints that can remotely determine that
they are being called by "authorized" or "genuine" client software only)
 But if these are serious problems, they deserve serious solutions - we
shouldn't reduce the necessary market pressure on mobile platform and app
store vendors to provide provisioning methods with different security
properties by selling snake oil to developers who may not know better.

I think there are two salvageable categories that can be matched to the

1) Missing Anti-exploit Protections.  These are measures like ASLR that
increase the cost of exploitation from outside of the application's
security boundaries.
2) Embedded Shared Secrets.  Yes, the data will show that many apps are
vulnerable because of this.  The answer is simple: don't embed secrets in a
shared distribution.

This anti-jailbreak, anti-debug, anti-RE, secret obfuscation stuff has to

On Tue, Nov 4, 2014 at 1:32 PM, Andre Gironda <andreg at gmail.com> wrote:

> http://scmagazine.com/riskiq-platform/review/4304/
> This is not just about vendors, but technology choice. A prior work was
> presented at OWASP AppSecUSA in 2011 from Ryan W Smith on "STAAF: an
> Efficient Distributed Framework for Performing Large-Scale Android
> Application Analysis".
> Both the Mobile Top Ten and the ASVS mention binary-obfuscation technology
> and anti debugging/reversing for mobile apps. Should these mentions be
> removed? I want to say no but I am clearly less biased than Jonathan
> Carter. By the way, I would like to take credit for adding this material to
> the MT10. However, I did not add it to ASVS 2.0. Who did that and why?
> dre
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

Jason Haddix
OWASP Mobile Top Ten Project Leader
Mobile Security Researcher
(805) 698 2885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141104/57c24cc3/attachment.html>

More information about the OWASP-Leaders mailing list