This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

CRV2 FrameworkSpecIssuesASPTop10

Jump to: navigation, search

Using OWASP TOP 10 as your guideline

The OWASP TOP 10 ( 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.
  • SQL queries are parameterized and that any input used in a SQL query is validated.
  • Look for implementation of Parameter collections
  • If using Stored procedures that GRANT proper permissions and avoids using unfiltered content from user
  • If using LDAP services , check that clear text passwords and authentication is not used in the code
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.
  • No use of encryption to save passwords
  • Clear-text credentials in web.config files
  • 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
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 RequestValidator method
  • proper escape of characters
  • Implementation of Microsoft Anti-XSS library
  • If using MVC, make sure you implement HtmlEncode method
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.
  • Filtering Requests and URL rewriting in IIS configurations
  • Check configuration of Trust levels and Code Access security permission
  • Check Authorization and Authentication settings

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:

  • Proper authorization and authentication configuration in web.config,Machine config , ApplicationHost.config

SQL (server) code:

  • GRANT permissions for executing store procedures
  • Privilege of application SQL account to authenticate into database

Protect assemblies:

  • Implementation of Obfuscation for assemblies
  • 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
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.
  • Encryption of sensitive data in config files
  • Salting passwords
  • 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"

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.
  • Proper configuration of Machine level/User level RSA key container
  • Proper Trust Levels configurations
  • Use of Strong named assemblies
  • Use of Assembly Attributes
  • Proper configuration of folder/ CRUD access permissions of web content files
  • Search for the use of asserts, link demands, and allowPartiallyTrustedCallersAttribute (APTCA).
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.
  • Use of Anti-forgery Helpers, Html.AntiForgeryToken() and the filter [ValidateAntiForgeryToken]
  • Implementation of Log Out functionality
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.
  • Check version of .NET framework
  • Check for found vulnerabilities in the Framework used on the application
  • If using components such as .NETNuke or NuGEt libraries check for vulnerabilities in these.

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.
  • Simply avoid using redirects and forwards
  • MVC1 and 2 are vulnerable for redirections,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.