This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Mobile Top 10 2014-M6"

From OWASP
Jump to: navigation, search
(Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}...")
 
Line 13: Line 13:
  
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=2}}
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=2}}
−
The M1 category is one that is always in heavy debate. It encompasses almost everything that a mobile application can do badly that does not take place on the phone. Which is exactly the argument… should it be listed at all? Don’t we have Top Ten lists for Web Applications? Don’t we have one for cloud too?
+
The M6 category covers the various ways that insecure cryptography is used within mobile applications.
−
 
−
In fact, we do. If we could be altogether sure that everyone who wanted information on mobile security also stopped by those projects… it would be a perfect world. Unfortunately, after two rounds of data collection from some of the world’s top assessment teams, we find that server side issues are so prevalent in mobile applications that we cannot ignore them in the Risk listing. While not statistically validated we feel that several factors lead to bad mobile application server code (and on a larger scale mobile insecurity in general):
 
−
 
−
* Rush to market
 
−
* Lack of security knowledge because of the new-ness of the languages
 
−
* Easy access to frameworks that don’t prioritize security
 
−
* Higher than average outsourced development
 
−
* Lower security budgets for mobile applications
 
−
* Assumption that the mobile OS takes full responsibility for security
 
−
* Weakness due to cross-platform development and compilation
 
−
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=2}}
 
−
Secure coding and configuration practices must be used on server-side of the mobile application. For specific vulnerability information refer to the OWASP Web Top Ten or Cloud Top Ten projects. We will try and link references to those projects and other OWASP projects that provide more robust descriptions.
 
−
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=2}}
 
−
 
 
−
 
 
−
If you look below, you can see that there is a ton of surface area to cover when thinking about M1:
 
 
   
 
   
 +
Insecure use of cryptography is common in most any application that uses encryption, and there are two mistakes in this area that lead to the most insecurity:
  
−
[[File:CloudTT_thum.png|border|350px]][[File:WebTT_thumb.png|border|350px]]
+
1. The Creation and Use of Custom Encryption Algorithms
−
+
2. Use of Insecure and/or Deprecated Algorithms
−
=== The Worst Offenders ===
+
2. Poor Key Management
−
 
 
−
While we cannot go over all of these, what we can do is list vulnerability types that we see most often within mobile applications:
 
−
 
  
−
;Poor Web Services Hardening
+
==Creation and Use of Custom Encryption Protocols==
−
: Logic flaws
 
−
:: [https://www.owasp.org/index.php/Testing_for_business_logic_(OWASP-BL-001) Testing for business logic flaws]
 
−
:: [https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet Business Logic Security Cheat Sheet]
 
−
: Weak Authentication
 
−
:: [https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management OWASP Top Ten Broken Authentication Section]
 
−
:: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet Authentication Cheat Sheet]
 
−
:: [https://www.owasp.org/index.php/Guide_to_Authentication Developers Guide for Authentication]
 
−
:: [https://www.owasp.org/index.php/Testing_for_authentication Testing for Authentication]
 
−
: Weak or no session management
 
−
: Session fixation
 
−
: Sensitive data transmitted using GET method
 
  
 +
There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.
  
−
; Insecure web server configurations
+
Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform.
−
: Default content
 
−
: Administrative interfaces
 
  
 +
==Use of Insecure and/or Deprecated Algorithms==
  
−
; Injection (SQL, XSS, Command) on both web services and mobile-enabled websites
+
Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:
  
−
; Authentication flaws
+
* RC2
 +
* MD4
 +
* MD5
 +
* SHA1
  
−
; Session Management flaws
+
==Poor Key Management==
  
−
; Access control vulnerabilities
+
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:
  
−
; Local and Remote File Includes
+
* Including the keys in the same attacker-readable directory as the encrypted content
 +
* Making the keys otherwise available to the attacker
 +
* Failing to use built-in encryption functionality
  
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
 
References
 
References

Revision as of 07:00, 27 January 2014

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY		 Prevalence
COMMON		 Detectability
EASY		 Impact
SEVERE		 Application / Business Specific
Threat Description Attack Vector Description Security Weakness Description Technical Impacts Business Impacts

Am I Vulnerable To Weak Server Side Controls?

The M6 category covers the various ways that insecure cryptography is used within mobile applications.

Insecure use of cryptography is common in most any application that uses encryption, and there are two mistakes in this area that lead to the most insecurity:

1. The Creation and Use of Custom Encryption Algorithms 2. Use of Insecure and/or Deprecated Algorithms 2. Poor Key Management

Creation and Use of Custom Encryption Protocols

There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.

Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform.

Use of Insecure and/or Deprecated Algorithms

Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:

  • RC2
  • MD4
  • MD5
  • SHA1

Poor Key Management

The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:

  • Including the keys in the same attacker-readable directory as the encrypted content
  • Making the keys otherwise available to the attacker
  • Failing to use built-in encryption functionality

References

References

Retrieved from "https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M6&oldid=166676"