[Owasp-leaders] OWASP Mobile Top 10 - potential conflict of interest in M10

Neil Smithline neil.smithline at owasp.org
Tue Nov 4 15:42:10 UTC 2014


I think the difficulty here is that the sort of protection that obfuscation
provides is hard to pin down. Us security guys like to say "Add this
control to block this attack." In that sense, obfuscation is not a security
control as it tends to makes things harder but not block them.

We all know that you can't have security by obscurity so arguing that
obfuscation adds security feel inherently wrong.

I like to use the word "safety" to describe the benefits of obfuscation. It
makes some attacks harder and greatly reduces the risk of accidental data
disclosure that can happen when, for example, a curious but benign user
eyeballs page source.

Using my vernacular, we can definitively say that obfuscation is not a
security control, only a safety control.

The question now becomes: do we include a control that provides lots of
safety but not security in the T10? We have to remember that a T10 may be
the only security guide a developer will look at.

My thought is that obfuscation is too critical to mobile apps' security
(and possibly their IP protection and performance) to be ignored
altogether. That said, obfuscation ain't security. So including it but
adding some notes about how it is not really security but too important to
be omitted is the best compromise.


Neil Smithline
408-634-5764
http://www.neilsmithline.com

On Tue, Nov 4, 2014 at 10:19 AM, Jack Mannino <jack.mannino at owasp.org>
wrote:

> So I think the original intention for what that category was supposed to
> represent and what it "became" are two different things.
>
> https://www.owasp.org/index.php?title=Mobile_Top_10_2014-M10&action=history
>
> I think we can all agree that the last iteration wasn't up to snuff. At
> the same time, there was very minimal community involvement except for
> either smallish consultancies or large software companies and more
> post-mortem griping than intelligent, constructive debates along the way.
> Pick your poison.
>
> I'm respectfully bowing out of the next iteration, but I'd encourage any
> of you that see flaws to contribute when they put out their next call for
> contributors. I fully respect Jason Haddix' integrity as he moves the
> project forward.
>
> On Tue, Nov 4, 2014 at 9:46 AM, Gunnar Peterson <gunnar at arctecgroup.net>
> wrote:
>
>> To add onto to Erwin's point I do think there is something to be said for
>> obfuscation. Its totally true that even if its worth considering- its
>> security, but not as we've known it, Jim.
>>
>> However, I think Mobile clients are different from defending servers. The
>> good ol' DMZ model where we do not trust clients does not give us much to
>> work with on mobile clients. My take is that we need a new playbook for
>> mobile clients and that requires a different mindset from the DMZ. I
>> propose Moscow Rules, from the old Cold war rules to operate behind enemy
>> lines(1). The DMZ assumed a level of separation that is not possible on the
>> client side. Instead of separation we need to do things like vary our
>> pattern.  Which brings us back to obfuscation.
>>
>> Its security 101, that obfuscation is only a speed bump. But there is one
>> additional benefit that we can get from it, and that is limiting failure.
>> If client code is obfuscated on a per instance or per user basis, then any
>> single client can be busted, but getting a single attack to work across an
>> array of many clients with unique obfuscation routines is substantially
>> more difficult. Sort of like RAID, redundant array of inexpensive of
>> obfuscated speed bumps. There is some value worth considering for defenders
>> to limit the reach of any single attack against all your users. Or said
>> differently, the speed bump does not protect the instance itself so much as
>> the combined effect limits the break of one app cascading across all the
>> apps and all the users.
>>
>> -gunnar
>>
>> 1. Moscow Rules stuff is in the middle -
>> http://1raindrop.typepad.com/1_raindrop/2014/05/cloud-security-defending-the-new-corporate-perimeter.html
>>
>> On Nov 4, 2014, at 1:58 AM, Erwin Geirnaert wrote:
>>
>> > Hi Andrew,
>> >
>> > If mobile code is not obfuscated it can be a starting point to detect
>> hard-coded secrets.
>> > Code that is not obfuscated can also be easily abused to create rogue
>> malicious apps, especially for Android.
>> >
>> > So I think it should be there.
>> >
>> > Best regards,
>> >
>> > Erwin
>> >
>> > -----Original Message-----
>> > From: owasp-leaders-bounces at lists.owasp.org [mailto:
>> owasp-leaders-bounces at lists.owasp.org] On Behalf Of Andrew van der Stock
>> > Sent: 04 November 2014 08:07
>> > To: owasp-leaders at lists.owasp.org
>> > Subject: [Owasp-leaders] OWASP Mobile Top 10 - potential conflict of
>> interest in M10
>> >
>> > Hi folks,
>> >
>> > I've had some feedback on Twitter about the OWASP Mobile Top 10.
>> > Number 10 includes a control that I don't believe is a sound security
>> control (security through obfuscation). Coupled with the nature of the
>> employers of those who contributed, all of whom have some form of
>> obfuscation product, I'm really not comfortable that M10 is a sound control
>> or the risk of binary analysis is so high that requires it (no other OWASP
>> standard contains it!), and more to the point M10 has a strong appearance
>> of conflict of interest.
>> >
>> > I know many of those involved in the project, and don't doubt for a
>> second their honest desire to create actionable advice, but I am very
>> concerned that the Mobile Top 10 has an obfuscation control written in by
>> folks who sell obfuscation controls.
>> >
>> > Can we please see the research that demonstrates that binary analysis
>> is one of the top threats to well written mobile code? I use it as a way to
>> improve my client's apps, and obfuscation just makes my job harder, not the
>> code safer.
>> >
>> > thanks
>> > Andrew
>> > _______________________________________________
>> > OWASP-Leaders mailing list
>> > OWASP-Leaders at lists.owasp.org
>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> > _______________________________________________
>> > OWASP-Leaders mailing list
>> > OWASP-Leaders at lists.owasp.org
>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> >
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141104/d26bd865/attachment-0001.html>


More information about the OWASP-Leaders mailing list