Difference between revisions of "Top 10 2013-What's Next for Organizations"

From OWASP
Jump to: navigation, search
(3 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
     |next={{Top_10_2010:ByTheNumbers
+
     |next=Note About Risks
              |1
+
              |year=2013}}
+
 
     |useprev=2013PrevLink
 
     |useprev=2013PrevLink
     |prev=Risk
+
     |prev=What's Next for Verifiers
 
}}
 
}}
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Start Your Application Security Program Now|number=whole|width=100%|year=2013}}
 
  
|{{Top 10:RoundedBoxBegin|year=2013}}A2–Broken Authentication and Session Management
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Start Your Application Security Program Now|number=whole|year=2013}}
 +
Application security is no longer a choice. Between increasing attacks and regulatory pressures, organizations must establish an effective capability for securing their applications. Given the staggering number of applications and lines of code already in production, many organizations are struggling to get a handle on the enormous volume of vulnerabilities.  OWASP recommends that organizations establish an application security program to gain insight and improve security across their application portfolio.  Achieving application security requires many different parts of an organization to work together efficiently, including security and audit, software development, and business and executive management. It requires security to be visible, so that all the different players can see and understand the organization’s application security posture.  It also requires focus on the activities and outcomes that actually help improve enterprise security by reducing risk in the most cost effective manner.  Some of the key activities in effective application security programs include:
 +
 
 +
 
 +
{| cellspacing="1" cellpadding="1" border="0" width="100%;"
 +
|{{Top 10:RoundedBoxBegin|year=2013}}<br/>Get Started
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or  exploit other implementation flaws to assume other users’ identities.
+
* Establish an application security program and drive adoption.
 +
* Conduct a capability gap analysis comparing your organization to your peers to define key improvement areas and an execution plan.
 +
* Gain management approval and establish an application security awareness campaign for the entire IT organization.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|-
|{{Top 10:RoundedBoxBegin|year=2013}}<br/>A3–Cross-Site Scripting (XSS)
+
|{{Top 10:RoundedBoxBegin|year=2013}}Risk Based Portfolio Approach{{Top 10:RoundedBoxEnd|year=2013}}
{{Top 10:RoundedBoxEnd|year=2013}}
+
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
+
* Identify and prioritize your application portfolio from an inherent risk perspective.
 +
* Create an application risk profiling model to measure and prioritize the applications in your portfolio.  
 +
* Establish assurance guidelines to properly define coverage and level of rigor required.
 +
* Establish a common risk rating model with a consistent set of likelihood and impact factors reflective of your organization's tolerance for risk.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|-
|{{Top 10:RoundedBoxBegin|year=2013}}<br/>A4–Insecure Direct Object References
+
|{{Top 10:RoundedBoxBegin|year=2013}}Enable with a Strong Foundation {{Top 10:RoundedBoxEnd|year=2013}}
{{Top 10:RoundedBoxEnd|year=2013}}
+
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
+
* Establish a set of focused policies and standards that provide an application security baseline for all development teams to adhere to.
 +
* Define a common set of reusable security controls that complement these policies and standards and provide design and development guidance on their use.
 +
* Establish an application security training curriculum that is required and targeted to different development roles and topics.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|-
|{{Top 10:RoundedBoxBegin|year=2013}}<br/>A5–Security Misconfiguration
+
|{{Top 10:RoundedBoxBegin|year=2013}}Integrate Security Into Existing Processes
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date.
+
* Define and integrate security implementation and verification activities into existing development and operational processes.  Activities include Threat Modeling, Secure Design & Review, Secure Coding & Code Review, Pen Testing, Remediation, etc.
 +
* Provide subject matter experts and support services for development and project teams to be successful.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|-
|{{Top 10:RoundedBoxBegin|year=2013}}<br/>A6–Sensitive Data Exposure
+
|{{Top 10:RoundedBoxBegin|year=2013}}Provide Management Visibility
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
Many web applications do not properly protect sensitive data, such as credit cards, tax ids, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
+
* Manage with metrics. Drive improvement and funding decisions based on the metrics and analysis data captured.  Metrics include adherence to security practices / activities, vulnerabilities introduced, vulenerabilities mitigated, application coverage, etc.
 +
* Analyze data from the implementation and verification activities to look for root cause and vulnerability patterns to drive strategic and systemic improvements across the enterprise.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|-
|{{Top 10:RoundedBoxBegin|year=2013}}A7–Missing Function Level Access Control
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
Virtually all web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access unauthorized functionality.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|{{Top 10:RoundedBoxBegin|year=2013}}A8-Cross-Site Request Forgery (CSRF)
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|{{Top 10:RoundedBoxBegin|year=2013}}A9-Using Components with Known Vulnerabilities
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
|-
 
|{{Top 10:RoundedBoxBegin|year=2013}}A10–Unvalidated Redirects and Forwards
 
{{Top 10:RoundedBoxEnd|year=2013}}
 
|{{Top 10:GrayBoxBegin|year=2013}}
 
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
 
{{Top 10:GrayBoxEnd|year=2013}}
 
 
|}
 
|}
  
Line 67: Line 53:
 
     |type={{Top_10_2010:StyleTemplate}}
 
     |type={{Top_10_2010:StyleTemplate}}
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
     |next={{Top_10_2010:ByTheNumbers
+
     |next=Note About Risks
              |1
+
              |year=2013}}
+
 
     |useprev=2013PrevLink
 
     |useprev=2013PrevLink
     |prev=Risk
+
     |prev=What's Next for Verifiers
 
}}
 
}}

Revision as of 22:37, 8 March 2013

[[Top 10 {{{year}}}-What's Next for Verifiers|← What's Next for Verifiers]]
2013 Table of Contents

2013 Top 10 List

[[Top 10 {{{year}}}-Note About Risks|Note About Risks →]]
Start Your Application Security Program Now

Application security is no longer a choice. Between increasing attacks and regulatory pressures, organizations must establish an effective capability for securing their applications. Given the staggering number of applications and lines of code already in production, many organizations are struggling to get a handle on the enormous volume of vulnerabilities. OWASP recommends that organizations establish an application security program to gain insight and improve security across their application portfolio. Achieving application security requires many different parts of an organization to work together efficiently, including security and audit, software development, and business and executive management. It requires security to be visible, so that all the different players can see and understand the organization’s application security posture. It also requires focus on the activities and outcomes that actually help improve enterprise security by reducing risk in the most cost effective manner. Some of the key activities in effective application security programs include:



Get Started
  • Establish an application security program and drive adoption.
  • Conduct a capability gap analysis comparing your organization to your peers to define key improvement areas and an execution plan.
  • Gain management approval and establish an application security awareness campaign for the entire IT organization.
Risk Based Portfolio Approach
  • Identify and prioritize your application portfolio from an inherent risk perspective.
  • Create an application risk profiling model to measure and prioritize the applications in your portfolio.
  • Establish assurance guidelines to properly define coverage and level of rigor required.
  • Establish a common risk rating model with a consistent set of likelihood and impact factors reflective of your organization's tolerance for risk.
Enable with a Strong Foundation
  • Establish a set of focused policies and standards that provide an application security baseline for all development teams to adhere to.
  • Define a common set of reusable security controls that complement these policies and standards and provide design and development guidance on their use.
  • Establish an application security training curriculum that is required and targeted to different development roles and topics.
Integrate Security Into Existing Processes
  • Define and integrate security implementation and verification activities into existing development and operational processes. Activities include Threat Modeling, Secure Design & Review, Secure Coding & Code Review, Pen Testing, Remediation, etc.
  • Provide subject matter experts and support services for development and project teams to be successful.
Provide Management Visibility
  • Manage with metrics. Drive improvement and funding decisions based on the metrics and analysis data captured. Metrics include adherence to security practices / activities, vulnerabilities introduced, vulenerabilities mitigated, application coverage, etc.
  • Analyze data from the implementation and verification activities to look for root cause and vulnerability patterns to drive strategic and systemic improvements across the enterprise.


[[Top 10 {{{year}}}-What's Next for Verifiers|← What's Next for Verifiers]]
2013 Table of Contents

2013 Top 10 List

[[Top 10 {{{year}}}-Note About Risks|Note About Risks →]]

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png
[[Category:OWASP Top Ten {{{year}}} Project]]