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 "Category:OWASP Source Code Flaws Top 10 Project Index"

From OWASP
Jump to: navigation, search
(→‎The OWASP Source Code Flaws Top 10)
 
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
{| border='1' cellpadding='2'  
 
{| border='1' cellpadding='2'  
 
|-
 
|-
−
|[[Source_Code_Flaws_Top_10_2009-C1|C1 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C1|C1 - Design Weakness]]
−
|XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
+
|A design weakness occurs when your business logic isn't strong enough to a threat modeling activity so it may be easy for an attacker to subvert your application behavior. Design is also about objects scope and visibility so extra care must be taken to what your program expose to others.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C2|C2 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C2|C2 - Architectural Weakness]]
−
|Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
+
|Your application at runtime is not a standalone part of the entire world, it depends over auxiliary system. An architectural weakness occurs when your code interact in a non safe way to auxiliary systems.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C3|C3 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C3|C3 - Missing input validation]]
−
|Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.  
+
|Actually, when a source code has been developed no defensive programming is used. Although defensive programming doesn't mean to provide always a secure code, it is a good idea not taking the user input and using it without any form of filtering or validation routine.
 +
Often the usage of not sanitized input can lead to very dangerous runtime vulnerabilities such as cross Site scripting, injection flaws, and others.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C4|C4 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C4|C4 - Insecure communications]]
−
|A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
+
|Web applications use TCP/IP stack to communicate to the world, no magic in this. An insecure communication vulnerability seen from the source code point of you is about how operating system provided abstraction layer (sockets, ...), communication layer provided by framework (java sockets, ...) are used. This is more than just checking about SSL usage, this is about how the communication code is written.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C5|C5 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C5|C5 - Information leakage and improper error handling]]
−
|A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
+
|Actually it is the same as the one listed in the original Top 10 just seen from a source code point of view. Every missing exception handling or a too verbose logging string in example, must be stored in this flaw category.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C6|C6 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C6|C6 - Direct object reference]]
−
|Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.  
+
|Actually is the same as the one listed in the original Top 10 just seen from a source code point of view.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C7|C7 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C7|C7 - Misuse of local resources]]
−
|Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
+
|Often people pretends that operating system provided resources are an infinite container of memory, disk space and cpu time. Well, it isn't. You must also consider that poorly designed local resource utilization, can lead an application to have poor response time and than it can lead to a denial of service if an attacker will try to consume all the resources.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C8|C8 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C8|C8 - Usage of potentially dangerous APIs]]
−
|Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
+
|Frameworks and libraries evolve in order to solve security issues. Often they leave backward compatibility routines in order to let developers enough time to change their code. More often developers simply forget to change their code using the potentially dangerous APIs even if deprecated.
 +
All the potentially dangerous routine calls fit this category
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C9|C9 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C9|C9 - Documentation weakness]]
−
|Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
+
|Source code must be documented in order to maintainable. If your code is not well commented, may be you won't be able to understand what did you write month ago, maybe you misunderstood your business logic flow then introducing some bugs or maybe you could not understand one of your colleague's work.
 +
Missing or not well documented code hit this flaw category.
 
|-
 
|-
  
−
|[[Source_Code_Flaws_Top_10_2009-C10|C10 - ]]
+
|[[Source_Code_Flaws_Top_10_2009-C10|C10 - Best practices violation]]
−
|Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
+
|This is the category that fits all generic best practices in source code development that are violated by the code. In this category it falls all the things that did not match any of the previous categories.
 
|}
 
|}
 
'''<center>Table 1: Top 10 Source code flaws for 2009</center>'''
 
'''<center>Table 1: Top 10 Source code flaws for 2009</center>'''

Latest revision as of 13:55, 15 December 2008

The OWASP Source Code Flaws Top 10

C1 - Design Weakness A design weakness occurs when your business logic isn't strong enough to a threat modeling activity so it may be easy for an attacker to subvert your application behavior. Design is also about objects scope and visibility so extra care must be taken to what your program expose to others.
C2 - Architectural Weakness Your application at runtime is not a standalone part of the entire world, it depends over auxiliary system. An architectural weakness occurs when your code interact in a non safe way to auxiliary systems.
C3 - Missing input validation Actually, when a source code has been developed no defensive programming is used. Although defensive programming doesn't mean to provide always a secure code, it is a good idea not taking the user input and using it without any form of filtering or validation routine.

Often the usage of not sanitized input can lead to very dangerous runtime vulnerabilities such as cross Site scripting, injection flaws, and others.

C4 - Insecure communications Web applications use TCP/IP stack to communicate to the world, no magic in this. An insecure communication vulnerability seen from the source code point of you is about how operating system provided abstraction layer (sockets, ...), communication layer provided by framework (java sockets, ...) are used. This is more than just checking about SSL usage, this is about how the communication code is written.
C5 - Information leakage and improper error handling Actually it is the same as the one listed in the original Top 10 just seen from a source code point of view. Every missing exception handling or a too verbose logging string in example, must be stored in this flaw category.
C6 - Direct object reference Actually is the same as the one listed in the original Top 10 just seen from a source code point of view.
C7 - Misuse of local resources Often people pretends that operating system provided resources are an infinite container of memory, disk space and cpu time. Well, it isn't. You must also consider that poorly designed local resource utilization, can lead an application to have poor response time and than it can lead to a denial of service if an attacker will try to consume all the resources.
C8 - Usage of potentially dangerous APIs Frameworks and libraries evolve in order to solve security issues. Often they leave backward compatibility routines in order to let developers enough time to change their code. More often developers simply forget to change their code using the potentially dangerous APIs even if deprecated.

All the potentially dangerous routine calls fit this category

C9 - Documentation weakness Source code must be documented in order to maintainable. If your code is not well commented, may be you won't be able to understand what did you write month ago, maybe you misunderstood your business logic flow then introducing some bugs or maybe you could not understand one of your colleague's work.

Missing or not well documented code hit this flaw category.

C10 - Best practices violation This is the category that fits all generic best practices in source code development that are violated by the code. In this category it falls all the things that did not match any of the previous categories.
Table 1: Top 10 Source code flaws for 2009

This category currently contains no pages or media.

Retrieved from "https://wiki.owasp.org/index.php?title=Category:OWASP_Source_Code_Flaws_Top_10_Project_Index&oldid=49010"