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

From OWASP
Jump to: navigation, search
(→‎The OWASP Source Code Flaws Top 10)
Line 4: Line 4:
 
|-
 
|-
 
|[[Source_Code_Flaws_Top_10_2009-C1|C1 - Design Weakness]]
 
|[[Source_Code_Flaws_Top_10_2009-C1|C1 - Design Weakness]]
−
|A design weakness occurs when the logic used to create the application did not addressed 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.
+
|A design weakness occurs when the logic used to create the application did not addressed a threat modeling activity so it may be easy for an attacker to subvert your application behavior. Design also covers an objects scope and visibility, so extra care must be taken to limit what your program expose to others.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C2|C2 - Architectural Weakness]]
 
|[[Source_Code_Flaws_Top_10_2009-C2|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.
+
|Your application depends on many auxiliary system when it runs. It does not stand on its own. An architectural weakness occurs when your code interacts in a unsafe way with auxiliary systems.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C3|C3 - Missing input validation]]
 
|[[Source_Code_Flaws_Top_10_2009-C3|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.
+
|Any input to a program must be processed through filtering and validation functions to ensure that is what is expected and to reduce the risk of malicious data. Using incoming data that is not sanitized can lead to very dangerous runtime vulnerabilities such as cross Site scripting, injection flaws, and others.
−
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 - Insecure communications]]
 
|[[Source_Code_Flaws_Top_10_2009-C4|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.
+
|Web applications use the TCP/IP stack to communicate to the world. An insecure communication vulnerability in the source code concerns how the operating system provided abstraction layer (sockets, ...) and communication layer provided by the framework (java sockets, ...) are used. This covers more than just checking about SSL usage, it is concerned with how the communication code is written.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C5|C5 - Information leakage and improper error handling]]
 
|[[Source_Code_Flaws_Top_10_2009-C5|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.
+
|This is the same as the one listed in the original Top 10, just from a source code point of view. Missing exception handling or a too verbose logging string, for example, would be included in this flaw category.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C6|C6 - Direct object reference]]
 
|[[Source_Code_Flaws_Top_10_2009-C6|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.
+
| This is the same as the one listed in the original Top 10, just from a source code point of view.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C7|C7 - Misuse of local resources]]
 
|[[Source_Code_Flaws_Top_10_2009-C7|C7 - Misuse of local resources]]
−
|Often people thinks to the operating system provided resources as 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.
+
|Operating system resources like memory, disk space and CPU time can often seem unlimited, but they are not. A program should effectively manage these resources. Poorly designed local resource utilization, can cause an application to have poor response time. It can also make it vulnerable to a denial of service by an attacker that causes the program to consume one or more type of these resources.
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C8|C8 - Usage of potentially dangerous APIs]]
 
|[[Source_Code_Flaws_Top_10_2009-C8|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.
+
|Frameworks and libraries evolve to solve security issues. Often they leave backward compatibility routines to give developers time to change their code. Developers frequently forget to transition their code to the new interface, leaving calls to the potentially dangerous APIs even if they have been deprecated. All such potentially dangerous routine calls fit this category.
−
All the potentially dangerous routine calls fit this category
 
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C9|C9 - Documentation weakness]]
 
|[[Source_Code_Flaws_Top_10_2009-C9|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.
+
|Source code must be well documented to make it maintainable. Poor comments can make code hard to understand in the future, even after a short time.  It is easy to introduce security flaws or other bugs if the logic is not clear or even misunderstood.  Comments in the code must document anything needed to fully understand how the code works.
−
Missing or not well documented code hit this flaw category.
 
 
|-
 
|-
  
 
|[[Source_Code_Flaws_Top_10_2009-C10|C10 - Best practices violation]]
 
|[[Source_Code_Flaws_Top_10_2009-C10|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.
+
|This category includes all generic best practices in source code development that are violated by the code. Anything missing from the previous categories would fall in this category.
 
|}
 
|}
 
'''<center>Table 1: Top 10 Source code flaws for 2009</center>'''
 
'''<center>Table 1: Top 10 Source code flaws for 2009</center>'''

Revision as of 16:45, 30 April 2009

The OWASP Source Code Flaws Top 10

C1 - Design Weakness A design weakness occurs when the logic used to create the application did not addressed a threat modeling activity so it may be easy for an attacker to subvert your application behavior. Design also covers an objects scope and visibility, so extra care must be taken to limit what your program expose to others.
C2 - Architectural Weakness Your application depends on many auxiliary system when it runs. It does not stand on its own. An architectural weakness occurs when your code interacts in a unsafe way with auxiliary systems.
C3 - Missing input validation Any input to a program must be processed through filtering and validation functions to ensure that is what is expected and to reduce the risk of malicious data. Using incoming data that is not sanitized can lead to very dangerous runtime vulnerabilities such as cross Site scripting, injection flaws, and others.
C4 - Insecure communications Web applications use the TCP/IP stack to communicate to the world. An insecure communication vulnerability in the source code concerns how the operating system provided abstraction layer (sockets, ...) and communication layer provided by the framework (java sockets, ...) are used. This covers more than just checking about SSL usage, it is concerned with how the communication code is written.
C5 - Information leakage and improper error handling This is the same as the one listed in the original Top 10, just from a source code point of view. Missing exception handling or a too verbose logging string, for example, would be included in this flaw category.
C6 - Direct object reference This is the same as the one listed in the original Top 10, just from a source code point of view.
C7 - Misuse of local resources Operating system resources like memory, disk space and CPU time can often seem unlimited, but they are not. A program should effectively manage these resources. Poorly designed local resource utilization, can cause an application to have poor response time. It can also make it vulnerable to a denial of service by an attacker that causes the program to consume one or more type of these resources.
C8 - Usage of potentially dangerous APIs Frameworks and libraries evolve to solve security issues. Often they leave backward compatibility routines to give developers time to change their code. Developers frequently forget to transition their code to the new interface, leaving calls to the potentially dangerous APIs even if they have been deprecated. All such potentially dangerous routine calls fit this category.
C9 - Documentation weakness Source code must be well documented to make it maintainable. Poor comments can make code hard to understand in the future, even after a short time. It is easy to introduce security flaws or other bugs if the logic is not clear or even misunderstood. Comments in the code must document anything needed to fully understand how the code works.
C10 - Best practices violation This category includes all generic best practices in source code development that are violated by the code. Anything missing from the previous categories would fall in this category.
Table 1: Top 10 Source code flaws for 2009
Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Source_Code_Flaws_Top_10_Project_Index&oldid=59719"