OWASP Mobile Top Ten 2016 - Release Candidate Released!

[Jonathan Carter]

Hi Everyone,

The OWASP Mobile Top Ten 2016 has now been released for review and commentary.  We are asking OWASP members to briefly look at the list and fill out a quick survey to give feedback on what should change.

Check out the release candidate here --
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

Fill out the anonymous survey here --
https://goo.gl/1evB4e%7Cthis

After ~30 days, we will review the survey responses, update the list, and release it along with the final content for each item.

[Vijay Velu]

Jonathan, 

Survey link is broken?

Regards

Vijay

https://www.linkedin.com/in/vijayvelu

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

Regards
Vijay L|PT,E|CSA,C|EH,C|HFI
http://vijayvkvelu.blogspot.com
http://in.linkedin.com/in/vijayvelu
mailto:vijay...@gmail.com
" Mess with the Best , Die like the Rest"

[Anant Shrivastava]

Correct survey link is 

https://goo.gl/1evB4e

just removed some garbage accidentally added in his link.

[Javi D R]

Hi

In the last draft, m1 was realated lack of binary protection, which is now m9

What has changed?

Thanks

[Jonathan Carter]

Anant is correct; botched link. The correct link is indeed https://goo.gl/1evB4e - Please fill out and then tweet the link to your colleagues to gather as much feedback as possible.

[Anant Shrivastava]

Folks, 

i may sound repetitive but please bear with me on this one. Initial Mobile top 10's were marked a OWASP Mobile Top 10 Risk's. are will still following the norm or we are now considering OWASP Mobile Top 10 issues. The reason i ask, as per my understanding, when we say risk we are talking about a broader coverage which could be cause for multiple issues. where as when we talk about issues we get a bit more specific.

example, Injection flaws is a risk, where as XSS is a issue as its a specific type of Injection flaw. (but since owasp web top 10 is about issues they have it forked out as a separate entity). 

Right now mobile top 10 2016 has following issues.

1) M2, m3 m5 seems to meshed up in each other. either justify seggregation or combine them together (this could be simmilar to what happened with m2 and m4 of 2014) similarly is the case with m8 and m9.

2) We want it to be risk's or issues coz we keep swinging between the two. based on what we want we might want to rename the title to correctly reflect it.

3) Naming is seriously inconsistent, m9 is reverse engineering, where as initial once as lack of XYZ. if lack of something is a issue / risk, how reverse engineering becomes a risk or issue. the names need to be in sync.

#mytwocents

P.S. Just now realized we can view what everyone is submitting, and seems like this is common concern. for those who missed : https://docs.google.com/forms/d/14MtmtNVRjkIKoV5d1xkwct86wyDsleiHz1PJBgvkNfA/viewanalytics?usp=form_confirm link to see what comments are already recieved.

-Anant

[Daniel Miessler]

Hi. Hibernating project leader here…

This is long been an issue, and it’s why I’ve moved to a different naming structure for my other OWASP projects.

It’s a Top 10 list, but a top 10 what?

The truth is that it’s a top 10 list of things to avoid, and those could be risks, threats, or vulnerabilities.

The challenge is in either shifting everything on the list to be ONLY vulns or risks or threats, or to drop the specific name so that any of them can apply.

Maybe the name should just be “OWASP Mobile Top 10”, and then in the description it says, “The Mobile Top 10 is a collection of multiple issue types—some are risks, some are threats, and some are vulnerabilities. Suffice it to say, they’re all things to be avoided, so we advise consumers of the list to be too concerned with the specific type of issue.”

…something like that…

[Jonathan Carter]

I remember we all struggled to try and clean it up to one way or the other when we talked about what worked and didn't work for 2014.  At the end of the day, no one pattern consistency captured everything accurately or completely in a useful manner.

[Jonathan Carter]

I highly encourage you to send out the feedback form to everyone you know as we want to have a large volume of data around how we finalize things for 2016.

[Milan Singh]

Team,

We are getting good number of responses from Infosec Community :)

Lets wait for few more days before making any changes based on suggestions provided in Survey :)

[Er Pragati Singh (IBM)]

Team,

A big thank you to all those who have taken the time to answer the question provided in Survey. 

Those who haven't done so yet .. we want to hear from you!

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

For any further concerns or communication Kindly feel free to touch base on
the following contact details. 

Have a great day!
 
 Thanks & Regards 
  Pragati Singh    
 cell: +91-99999-37921,+91-95557-16841
 E-mail- er.prag...@gmail.com
 LinkedIn :-in.linkedin.com/in/erpragatisingh/

 http://viz.me/erpragatisingh

 " Positive communication makes difference.  It may not guarantee success, but helps to achieve it. "

                                                  
                   "Print this mail only if absolutely necessary. Save Paper. Save Trees."

[Paco Hope]

I hear your solution, and it makes sense from a certain point of view. But this is OWASP. We have a habit of setting the pace and setting the mark for a big hunk of the industry. If we are sloppy on our terminology, we will legitimize being sloppy and we'll do the whole industry a disservice. There's nobody else out there offering something along these lines. So if it becomes the OWASP Mobile Top Ten "bucket of bad stuff" then we set a precedent in the security industry for writing "buckets of bad stuff". And is this "risk" important enough to be in the bucket? How about that "vulnerability"? Once we turn it into the top 10 fruit basket, how do we know whether to leave out an apple so that an orange can be put in? Only 10 fruit can be in the basket. I'm not trying to mock it by giving the fruit example. I'm trying to illustrate that it makes the job harder, not easier, to include too many categories. If the list is limited to vulnerabilities or risks or threats, at least we could try to find the most important in a single category. But—in my mind anyways—once we're trying to take the 10 most important things from any of those 3 buckets, it's hard to figure out whether this 'threat' is more important than that 'risk'. What gets included and what doesn't?

I think this terminology stuff is important and worth the effort. What's difficult is the data. We are nominally talking about "risks", but we collected data on "vulnerabilities". Vulnerabilities can create risks. But it's a many-to-many relationship. (more than one vulnerability per risk, more than one risk per vulnerability). We could rename it Top Ten Vulnerabilities, but then we're limited by reporting bias. What people find often becomes "important". And sometimes what people find things often because it's both common and easy to find. (As opposed to common but hard to find)

And "risk" from whose perspective? Is it a risk to the app? ("another app on the same device can read data you're storing on the device, like passwords and session tokens") Is it a risk to the app developer/company ("all your users' passwords might be compromised if malware on the device reads user passwords out of device storage")? Is it a risk to the end user ("someone might be able to steal your identity if you use this app that stores passwords on the device in clear text')? In the first "you" are the app, in the second "you" are the company building an app, in the third "you" are the user of an app. I think it's important to figure out whose risks we're writing down.

So what category(ies) go into the bucket and from whose perspective? My answer has been consistently "risks from the app developer's perspective".

Paco

[Jonathan Carter]

This is one of those topics that gets rehashed all the time. After all the time spent on it within the 2014, I suspect it's never going to be a pure and consistent perspective. However, we do know that roughly 80% of the audience thinks we have improved the organization and clarity around the way things have been broken up in 2016.

[Milan Singh]

I agree with Paco, but even Jonathan has a valid point. Its really hard to choose what has to be added/rejected from Top Ten list.

But based on survey results till date, m sure we are driving things in right direction :)

Let's wait for survey deadline and then tweak things accordingly...!

Regards

Milan

[Paco Hope]

So I've done a bit of work to help out.

• I updated the scratchpad document to put the candidate categories front and centre. They're first and it's obvious what they are.
• I put a big red box at the top of that document telling people to take the survey
• I announced it on LinkedIn and on Twitter (for whatever good that does)
• I took names out of all the level 1 headings. I kept the "Owner: so-and-so" but just put it in text after the heading.
• I added a bunch of text to it. Some of the level 1 headings had practically nothing. So I wrote up some prominent characteristics and some risks and examples in a few places.
• I took out virtually all the "generic label" and "audience specific label" sections because they were empty. I left the 2 that were non-empty.
• I removed many uses of the letters "SSL" and replaced them with TLS.

FYI,

Paco

You can get a concise view of all my edits by looking at it this way:

https://www.owasp.org/index.php?title=Projects%2FOWASP_Mobile_Security_Project_-2015_Scratchpad&action=historysubmit&diff=211150&oldid=199394

[Jonathan Carter]

Thanks Paco!

[Er Pragati Singh (IBM)]

Hi Team,

A big thank you to all those who have taken the time to answer the question provided in Survey. 

Those who haven't done so yet .. we want to hear from you!

--

For any further concerns or communication Kindly feel free to touch base on
the following contact details. 

Have a great day!
 
 Thanks & Regards 
  Pragati Singh    
 cell: +91-99999-37921,+91-95557-16841
 E-mail- er.prag...@gmail.com

 LinkedIn :-https://linkedin.com/in/erpragatisingh

                  https://about.me/erpragatisingh

[Jonathan Carter]

We're up to 100 responses. I noticed there was a sharp spike in responses a few days ago. It might be that we hit the right social media profile... If you guys can reach out to the folks with lots of followers on social media and spread the word, that would help gather more feedback!

[Milan Singh Thakur]

Indeed we will...
M updating my 10,000+ followers on LinkedIn :)

Expecting lot for spikes coming week.

Regards
Milan Singh Thakur
OWASP Global Foundation

[Anant Shrivastava]

Let me also push the notification out over all my social media channels.

-Anant

--

[Paco Hope]

Thanks, all! That's helpful.

Think about LinkedIn groups that you might be part of (e.g., InfoSec groups) and mailing lists other than this one.

Paco

[Arbaz Hussain]

Indeed helpful, let me know the group name so that I can join :))

[Daniel Miessler]

Hey guys,

Love the energy in the project right now. 

My biggest issue with the list right now is that M2 through M6 are often examples of M1. 

In other words we have parent-child relationships in a list that, in my opinion, should contain only elements at the same node depth. 

Eager to hear if others have observed the same. 

Daniel

--

[Anant Shrivastava]

I have raised my concerns earlier in the same thread here https://groups.google.com/a/owasp.org/d/msg/owasp-mobile-top-10-risks/r5nK0O-ew4U/k0cd9SD3GQAJ

However what i feel is the major source of confusion. 

1) Incorrect naming or rather inconsistent naming.

2) Too broad overview, we need to detail each of them and then only we can understand what exactly was the reason for the specific naming or entity.

-Anant

[Paco Hope]

Anant,

You raise some good points. And now that you reminded us of these, let me take a stab at responding. I have some questions.

On 7 Mar 2016, at 22:21, Anant Shrivastava <an...@anantshri.info> wrote:

1) M2, m3 m5 seems to meshed up in each other. either justify seggregation or combine them together (this could be simmilar to what happened with m2 and m4 of 2014) similarly is the case with m8 and m9.

I think I can clearly disambiguate M2, M3, and M5. I have updated the text in the page since you sent this email, so you might try re-reading to see if I made it clearer.

Insecure Data is insecure data AT REST. (Not sure why people wanted to take the words "at rest" out, but that was the consensus some long time ago). This is when the app is trying to persist data on the device in some kind of long-term storage. Moreover, it's a situation where "don't store that data" is not a valid response. I.e., the app MUST store the data because it's part of what the app is trying to do in the first place. Let's imagine my app lets you take a photo, and I store that photo in the app's local storage on the device. For some reason, the photo's confidentiality and integrity are important. If that photo can be disclosed out of app local storage, or modified in app local storage without detection, then we're talking about an M2 problem. Now I might not be using any crypto here. I might be simply relying on app local storage. If I didn't use any crypto, it can't possibly be an M5 problem. If, however, I tried to use crypto and botched it, then it's probably an M5 problem and not an M2 problem.

M3 is data in motion. It's data as it moves from place to place. While it's on the wire, in the air, or in motion some other way. If I sniff your NFC, Bluetooth, WiFi, HTTP, or whatever and I attack the data as it goes in or out of the device, then it's an M3 problem. All the TLS stuff is M3. Back to my confidential photo app. Let's say I transmit photos to an online service, and I do it in the clear over HTTP. THAT problem (sending the confidential data in the clear over HTTP) is not an M2 problem because it doesn't have to do with persistence. It's not an M5 problem because there's no crypto in there at all (maybe there should be, but there isn't). It's an M3 problem because it's data in motion. The distinguishing difference is where the attack can occur. For M2, most of your attackers have to be on the device itself. Or they have to be able to get at the data stored by the app on the device. Most importantly, they're not leveraging some normal communications mechanism that the app uses. For M3, the app has some communications capability and the attacker can be outside the device and leverage that communications. 

M5 is crypto generally, except TLS. Yes, yes, TLS is full of crypto. But there's lots of crypto that isn't TLS. There's lots of encrypting, hashing, signature checking, randomness and so on that does not happen in TLS. This is where all those crypto-but-not-TLS things go. One could argue that TLS is so fundamentally crypto, that all the TLS stuff belongs in M5 as well. I argue differently. TLS is a means to get data from point a to point b securely. If TLS turned out to be insecure, we could use a different mechanism. A legitimate (but rarely valid) way to fix TLS is to stop using it entirely and use something else to secure data from point A to point B. I realise this is somewhat arbitrary. But we have to draw brightly coloured lines that delineate what issues belong in which buckets. I think clarity trumps purity of taxonomy. All the TLS stuff goes in one bucket and all TLS issues go in the same bucket. I really think M3 is the right answer. It could be M5. But we need to be really clear.

Back to our photo app. If I use a CRC32 checksum to try to do integrity on the photos and detect unauthorised changes, that's an M5 finding. I tried to do some "crypto", and it's really terrible insufficient crypto. 

2) We want it to be risk's or issues coz we keep swinging between the two. based on what we want we might want to rename the title to correctly reflect it.

while( horse.dead() ) {

  horse.flagellate();

  // wish we could break out of this loop. I completely agree with you.

}

Does that help?

Paco

[Anant Shrivastava]

I suppose M2, M3, and M5 are more clear now. but i still feel M5 could do a bit more explaining on the page itself. Problem is even we are strugling to put issues under M5 or M3/M2 buckets, we can't really expect everyone else to start using these terminologies correctly. This was exactly the issue with M2 and M4 of 2014 list. 

Even if we keep risk or issues discussion aside we still need to be consistent with wordings, M1 to M6 have a negative term in front clearly pointing to lack of a specific entity is causing this issue. But again with M7-M10 we kind of lose that touch. Naming them properly might help us in drilling the fact properly. 

and that brings me to another point which i raised. M8 and M9 are again very simmilar in description as well as name, i fear people will get confused with these two again and again. 

Also M10 if i get it right is around control bypasses, the details also suggest not about extra functionalities but rather a bypass around exisiting functionalities.

In Short I believe M7 - M10 can do with better naming and better descriptions.

-Anant

--

[Jonathan Carter]

Fingers crossed! :-)

[Er Pragati Singh (IBM)]

Thanks Team for you taking initiative in making more response. :)

[Essobi]

I'd be willing to assist in documenting, describing and possibly working on a complimentary document showing examples.

As far as terminology goes... There should be a dictionary of definitions used in the document, so there's no question over the vernacular used.

--SOB

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

Essobi

[Milan Singh Thakur]

Hi SOB,

It would be great to see your contribution.
If it is possible, then please share a draft of your work. So it will be better for us to decide where to put it in guide.

Also your idea will improve the user's way of picking meaning for words used in guide.

Regards
Milan Singh Thakur
OWASP Global Foundation

[Jonathan Carter]

Yeah, there's plenty of ways you could help out on these fronts and provide a dictionary of terms we use.

[Milan Singh]

We have plenty of responses now. 

This weekend I will start working on suggestions provided in Survey for our new Top Ten.

Please let me your thoughts too :)

[Andrew van der Stock]

On the risk versus weakness versus issue controversy. Let’s stick to the ISO 31000 definition of a risk:

A quantified likelihood x a quantified impact to the business = risk

A risk is related to the business concerned. I don’t think we should call any of our Top 10 things “risks" because each individual application and their users have different risks. Let’s think about this for a minute. User A uses Evernote to store her notes on current and past mergers and acquisitions, which if released will kill many deals worth millions and potentially open her up to contract breach lawsuits. User B uses Evernote to keep his list of books lent out to friends. The worst that can happen is for User B’s friends to be shamed about their reading choices.

If a direct object reference attack is discovered, it’s a High risk for User A and a low risk for User B for exactly the same code flaw. The risk - for the same application with the same control weaknesses - is completely different. .

In auditing, we have the concept of controls that are in place, in use, and effective. The lack of a control is a big thing, as is not using an effective control.

So I would suggest you harmonize the texts around the Mobile Top 10 Security Controls, such that you’re asking for a positive thing to be validated to be in place, in use, and effective to comply with your list. The negative approach does not work, which is why I stopped working on the OWASP Top 10 and started work on the ASVS.

My $0.02.

Andrew

[Er Pragati Singh (IBM)]

Yes Milan now the time to start work on that. Thanks Team for help in making Survey success.

 Those who haven't done so yet .. we want to hear from you!

Please share your thoughts. :) Have a great day.

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

For any further concerns or communication Kindly feel free to touch base on the following contact details. 

Have a great day!
 
 Thanks & Regards 
  Pragati Singh    
 cell: +91-99999-37921,+91-95557-16841

 LinkedIn :-https://linkedin.com/in/erpragatisingh

    Developing Microsoft Azure and Web Services

[Aaron]

Any chance there is an update on the results and feedback?

[Milan Singh Thakur]

Hi Aaron,

Results of the survey will be out by tomorrow.
Also we will study the feedback and tweak the upcoming Top Ten accordingly.

Regards
Milan

[Er Pragati Singh (IBM)]

Hi Team,

Greeting of the day.

yes Milan,

that would be great if we work accordingly.Hope we will do it today.

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

For any further concerns or communication Kindly feel free to touch base on the following contact details. 

Have a great day!
 

Thanks & Regards 
  Pragati Singh    

 OWASP Global Foundation
 LinkedIn :-https://linkedin.com/in/erpragatisingh

    Developing Microsoft Azure and Web Services

[Milan Singh Thakur]

Hi Team,

Have published the Survey Results on below link:

https://www.linkedin.com/pulse/survey-results-owasp-mobile-top-ten-2016-milan-singh-thakur

We are working on Suggestions....

Regards,

Milan Singh Thakur

Mobile Security Global Leader

AppSec INDIA Leader

OWASP Foundation

Mob: +91 9405901005

On Mon, Apr 25, 2016 at 11:09 AM, Milan Singh Thakur <milanth...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this topic, visit https://groups.google.com/a/owasp.org/d/topic/owasp-mobile-top-10-risks/r5nK0O-ew4U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to owasp-mobile-top-1...@owasp.org.

[Er Pragati Singh (IBM)]

Hi Milan,

i have gone through survey its look good. survey report all most positive.we need to work accordingly 

have a great day.

--

You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.

To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.

For more options, visit https://groups.google.com/a/owasp.org/d/optout.

--

For any further concerns or communication Kindly feel free to touch base on the following contact details. 

Have a great day!
 

Thanks & Regards 
  Pragati Singh    

 OWASP Global Foundation
 LinkedIn :-https://linkedin.com/in/erpragatisingh

    Developing Microsoft Azure and Web Services

[Milan Singh Thakur]

Yes Pragati.
Thanx to Our Owasp Team for quality work.

Mobile Guide will be big mark on our efforts.

[Er Pragati Singh (IBM)]

A big thank to all of you for making success of survey. :)

Great job Team..

[Er Pragati Singh (IBM)]

A big thank to all of you for making success of survey. :)

Great job Team..

<http://in.linkedin.com/in/erpragatisingh/>

[Jonathan Carter]

I am soon to release the final top ten based on internal feedback