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-M1"

From OWASP
Jump to: navigation, search
m
Line 8: Line 8:
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anything that can send untrusted data to the web server, including both the application and users. Additionally do not discount users directly calling the web-site/API/web-service. </td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents include any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include: a user, malware, or a vulnerable app on the mobile device.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The attack vectors for the conglomeration that is Weak Server Side Controls include several easy to exploit vulnerabilities (like server side injection) that are high risk.</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The attack vectors correspond to the same attack vectors available through the traditional OWASP Top Ten.</td>
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
+
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order for this vulnerabiltiy to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary is able to feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Technical Impacts</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of this vulnerability corresponds to the technical impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
+
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category with a technical impact of moderate.</td>
 +
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of this vulnerability corresponds to the business impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.
 +
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category's business impacts.</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
 
{{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?
+
M1 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 a Top Ten lists for Web Applications? Don’t we have one for cloud too?
 
   
 
   
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):
+
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. After two rounds of data collection from some of the world’s top assessment teams, server side issues are so prevalent in mobile applications that we cannot ignore them in the Mobile Top Ten 2014 listing. Experience suggests that several factors have lead to a proliferation of server-side vulnerabilities.  These factors include:
 
   
 
   
* Rush to market
+
* Rush to market;
* Lack of security knowledge because of the new-ness of the languages
+
* Lack of security knowledge because of the new-ness of the languages;
* Easy access to frameworks that don’t prioritize security
+
* Easy access to frameworks that don’t prioritize security;
* Higher than average outsourced development
+
* Higher than average outsourced development;
* Lower security budgets for mobile applications
+
* Lower security budgets for mobile applications;
* Assumption that the mobile OS takes full responsibility for security
+
* Assumption that the mobile OS takes full responsibility for security; and
* Weakness due to cross-platform development and compilation
+
* Weakness due to cross-platform development and compilation.
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=2}}
 
{{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.
+
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.
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=2}}
 
{{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:
+
Below, you can see that there are many risks and vulnerabilities that you must mitigate in order to satisfy M1:
 
   
 
   
  
Line 39: Line 41:
 
=== The Worst Offenders ===
 
=== The Worst Offenders ===
  
While we cannot go over all of these, what we can do is list vulnerability types that we see most often within mobile applications:
+
Below is a list vulnerability types that OWASP sees most often within mobile applications:
 
   
 
   
  

Revision as of 23:35, 9 April 2014

Back To The Mobile Top Ten Main Page
Weak Server Side Controls


Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY
Prevalence
COMMON
Detectability
AVERAGE
Impact
SEVERE
Application / Business Specific
Threat agents include any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include: a user, malware, or a vulnerable app on the mobile device. The attack vectors correspond to the same attack vectors available through the traditional OWASP Top Ten. In order for this vulnerabiltiy to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary is able to feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server. The technical impact of this vulnerability corresponds to the technical impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device. For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category with a technical impact of moderate. The business impact of this vulnerability corresponds to the business impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device. For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category's business impacts.

Am I Vulnerable To Weak Server Side Controls?

M1 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 a Top Ten lists for Web Applications? Don’t we have one for cloud too?

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. After two rounds of data collection from some of the world’s top assessment teams, server side issues are so prevalent in mobile applications that we cannot ignore them in the Mobile Top Ten 2014 listing. Experience suggests that several factors have lead to a proliferation of server-side vulnerabilities. These factors include:

  • 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; and
  • Weakness due to cross-platform development and compilation.

How Do I Prevent Weak Server Side Controls?

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.


Example Scenarios


Below, you can see that there are many risks and vulnerabilities that you must mitigate in order to satisfy M1:


CloudTT thum.png WebTT thumb.png

The Worst Offenders

Below is a list vulnerability types that OWASP sees most often within mobile applications:


Poor Web Services Hardening
Logic flaws
Testing for business logic flaws
Business Logic Security Cheat Sheet
Weak Authentication
OWASP Top Ten Broken Authentication Section
Authentication Cheat Sheet
Developers Guide for Authentication
Testing for Authentication
Weak or no session management
Session fixation
Sensitive data transmitted using GET method


Insecure web server configurations
Default content
Administrative interfaces


Injection (SQL, XSS, Command) on both web services and mobile-enabled websites
Authentication flaws
Session Management flaws
Access control vulnerabilities
Local and Remote File Includes

References

References