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 "CRV2 FrameworkSpecIssuesASPTop10"
From OWASP
| (13 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
! OWASP TOP 10 risk !! Description !! What to look for in the code | ! OWASP TOP 10 risk !! Description !! What to look for in the code | ||
|- | |- | ||
| − | | '''A1 Injection''' || Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.|| | + | | style="width: 200px;" | '''A1 Injection''' || style="width: 350px;" | Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.|| |
*SQL queries are parameterized and that any input used in a SQL query is validated. | *SQL queries are parameterized and that any input used in a SQL query is validated. | ||
*Look for implementation of Parameter collections | *Look for implementation of Parameter collections | ||
| Line 21: | Line 21: | ||
*Clear-text credentials in web.config files | *Clear-text credentials in web.config files | ||
*Clear connectionstrings without encryption | *Clear connectionstrings without encryption | ||
| + | *Proper implementation of <Authentication> en <Authorization> property in web.config files | ||
| + | *Never use "none" for the <protection> attribute within <Forms> property in web.config file | ||
| + | *Form element Encryption property: ASP.NET encrypts the cookie, but is not validate it. This may leave your application open to attack. | ||
| + | *Form element Validation: ASP.NET validates the cookie, but does not encrypt it. This can uncover information to an attacker. | ||
| + | *Look for failure to limit database access and inadequate separation of privileges | ||
| + | *Connectionstrings without setting a password such as | ||
| + | Server=.\SQLExpress;AttachDbFilename=|DataDirectory|database.mdf;Trusted_Connection=Yes; | ||
|- | |- | ||
| '''A3 Cross-Site Scripting (XSS)''' || 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 || | | '''A3 Cross-Site Scripting (XSS)''' || 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 || | ||
| − | *Check for implementations of | + | *Check for implementations of RequestValidator method |
| − | |||
*proper escape of characters | *proper escape of characters | ||
*Implementation of Microsoft Anti-XSS library | *Implementation of Microsoft Anti-XSS library | ||
| Line 39: | Line 45: | ||
|- | |- | ||
| '''A5-Security Misconfiguration''' ||Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. || | | '''A5-Security Misconfiguration''' ||Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. || | ||
| − | IIS configurations: | + | '''IIS configurations:''' |
| − | *Proper authorization and authentication configuration in web.config | + | *Proper authorization and authentication configuration in web.config,Machine config , ApplicationHost.config |
| − | Machine config , ApplicationHost.config | ||
| − | SQL (server) code: | + | '''SQL (server) code:''' |
*GRANT permissions for executing store procedures | *GRANT permissions for executing store procedures | ||
*Privilege of application SQL account to authenticate into database | *Privilege of application SQL account to authenticate into database | ||
| − | Protect assemblies: | + | '''Protect assemblies:''' |
*Implementation of Obfuscation for assemblies | *Implementation of Obfuscation for assemblies | ||
*Prevention of Round tripping | *Prevention of Round tripping | ||
| + | *Always check the MD5 hashes of the .NET Framework assemblies to prevent the possibility of rootkits in the framework. . Checking the MD5 hashes will prevent using altered assemblies on a server or client machine. See File:Presentation - .NET Framework Rootkits - Backdoors Inside Your Framework.ppt | ||
|- | |- | ||
| Line 56: | Line 62: | ||
*Salting passwords | *Salting passwords | ||
*Proper implementation of Secure Encryption algorithms | *Proper implementation of Secure Encryption algorithms | ||
| + | *Look for hard-coded secrets in code by looking for variable names such as "key", "password", "pwd", "secret", "hash", and "salt" | ||
| Line 66: | Line 73: | ||
*Use of Assembly Attributes | *Use of Assembly Attributes | ||
*Proper configuration of folder/ CRUD access permissions of web content files | *Proper configuration of folder/ CRUD access permissions of web content files | ||
| + | *Search for the use of asserts, link demands, and allowPartiallyTrustedCallersAttribute (APTCA). | ||
|- | |- | ||
| Line 71: | Line 79: | ||
|| | || | ||
*Use of Anti-forgery Helpers, Html.AntiForgeryToken() and the filter [ValidateAntiForgeryToken] | *Use of Anti-forgery Helpers, Html.AntiForgeryToken() and the filter [ValidateAntiForgeryToken] | ||
| + | *Implementation of Log Out functionality | ||
|- | |- | ||
| Line 84: | Line 93: | ||
|| | || | ||
*Simply avoid using redirects and forwards | *Simply avoid using redirects and forwards | ||
| − | *MVC1 and 2 are vulnerable for redirections | + | *MVC1 and 2 are vulnerable for redirections,therefore proper implementation of validation in returnUrl parameters is essential |
| − | therefore proper implementation of validation in returnUrl parameters is essential | ||
*If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user. | *If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user. | ||
|} | |} | ||
Latest revision as of 07:43, 24 July 2013
Using OWASP TOP 10 as your guideline
The OWASP TOP 10 (https://www.owasp.org/index.php/Top_10_2013-Top_10)is a detailed list of the highest security risks web application faces. It help us identify the most critical security threats facing organizations. Performing a Code review efficiently requires using a model or framework that help us identify these issues quickly. Consequently, OWASP TOP 10 is one of these guides that provides us with the necessary information to implement proper Code Review.
Applying OWASP TOP 10 to ASP.NET code review
The following table contains OWASP TOP 10 - 2013 guideline and how you can apply this during your code review
| OWASP TOP 10 risk | Description | What to look for in the code |
|---|---|---|
| A1 Injection | Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
|
| A2 Broken Authentication and Session Management | Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities. |
Server=.\SQLExpress;AttachDbFilename=|DataDirectory|database.mdf;Trusted_Connection=Yes; |
| A3 Cross-Site Scripting (XSS) | 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 |
|
| A4 Insecure Direct Object References | 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. |
|
| A5-Security Misconfiguration | Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. |
IIS configurations:
SQL (server) code:
Protect assemblies:
|
| A6-Sensitive Data Exposure | The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit. |
|
| A7-Missing Function Level Access Control | Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack. |
|
| A8-Cross-Site Request Forgery (CSRF) | 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. |
|
| A9-Using Components with Known Vulnerabilities | Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. |
|
| A10-Unvalidated Redirects and Forwards | 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. |
|
