Difference between revisions of "Projects/OWASP Mobile Security Project -2015 Scratchpad"
(→Conclusions Drawn From Data)
(→M10: Lack of Binary Protections)
|Line 130:||Line 130:|
==M10: Lack of Binary Protections ==
==M10: Lack of Binary Protections ==
Revision as of 10:57, 3 March 2015
This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.
- 1 What is It?
- 2 Who is it For?
- 3 Comments on Submitted Data
- 4 Other Questions
- 5 Conclusions Drawn From Data
- 6 Top Ten Scratchpad
- 6.1 M1: Weak Server Side Controls
- 6.2 M2: Insecure Data Storage
- 6.3 M3: Insufficient Transport Layer Protection
- 6.4 M4: Unintended Data Leakage
- 6.5 M5: Poor Authorization and Authentication
- 6.6 M6: Broken Cryptography
- 6.7 M7: Client Side Injection
- 6.8 M8: Security Decisions Via Untrusted Inputs
- 6.9 M9: Improper Session Handling
- 6.10 M10: Lack of Binary Protections
What is It?
This is the "Mobile Top Ten" what? It's the top 10 "stuff people tend to screw up", but here are some important questions.
- Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."
- Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.
- What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps do care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
- If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
- If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
- If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
- If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.
Who is it For?
Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?
(Paco's opinion) We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.
Comments on Submitted Data
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).
I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.
We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?
They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?
I can imagine a heuristic like this:
- did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
- Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.
Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?
Conclusions Drawn From Data
These are conclusions proposed from the 2014 data.
At Least One New Category Is Needed
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.
The Bottom 5 Categories account for 25% Or Less
The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):
- M8: Security Decisions Via Untrusted Inputs
- M7: Client Side Injection
- M9: Improper Session Handling
- M6: Broken Cryptography
- M1: Weak Server Side Controls
Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.
The Existing Buckets are Hard To Use
A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.||MetaIntelli||M3 and M9|
|Contains URLs with not valid SSL certificates and/or chain of trust||MetaIntelli||M3 and M5|
|Authentication cookies stored in cleartext in sqlite database||BugCrowd||M9 - Improper Session Handling|
|Blackberry app stores credentials in plaintext||BugCrowd||M2 - Insecure Data Storage|
|Credentials and sensitive information not secured on Windows Phone app||BugCrowd||M5 - Poor Authorization and Authentication|
Some Topics that Show Up But Are Hard To Place
There are a few things that show up in the contributed data that do not have a good category to go into.
Code Level Findings
If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).
Top Ten Scratchpad
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.
M1: Weak Server Side Controls
M2: Insecure Data Storage
M3: Insufficient Transport Layer Protection
M4: Unintended Data Leakage
M5: Poor Authorization and Authentication
M6: Broken Cryptography
M7: Client Side Injection
M8: Security Decisions Via Untrusted Inputs
M9: Improper Session Handling
M10: Lack of Binary Protections
(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.