CRV2 FrameworkSpecIssuesASPTop10

Using OWASP TOP 10 as your guideline

The OWASP 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.	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
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 permissions
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
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
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