OWASP is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. It is a single location to provide fail and real-world information about App Securities for individuals, corporations, government bodies, and other worldwide organisations. However, It does not endorse or suggest commercial products or services. It has its own Application security tutorial series.
What are the OWASP top 10?
Below are the top 10 Application Security Risks,
- A1 Injection
- A2 Broken Authentication and Session Management
- A3 Cross-Site Scripting (XSS)
- A4 Broken Access Control (As it was in 2004)
- A5 Security Misconfiguration
- A6 Sensitive Data Exposure
- A7 Insufficient Attack Protection (NEW)
- A8 Cross-Site Request Forgery (CSRF)
- A9 Using Components with Known Vulnerabilities
- A10 Underprotected APIs (NEW)
Let’s have detailed description for each of them,
A1- Injection
One of the best ways to check if an application is exposed to injection is to verify if all the resources have clearly split untrusted data from command or query, i.e., using bind variables in all statements and stored procedures in SQL
Below are the common factors of SQL Injection.
SQL Injection attacks are unfortunately very common, and this is due to two factors.
- The significant prevalence of SQL Injection vulnerabilities
- The attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).
To avoid SQL injection, flaws are given below,
- Stop writing dynamic queries.
- Prevent user supplied input which contains malicious SQL from affecting the logic of the executed query
Below are some more details,
Primary Defenses
- Option 1 - Use of Prepared Statements (with Parameterized Queries)
- Option 2 - Use of Stored Procedures
- Option 3 - White List Input Validation
- Option 4 - Escaping All User Supplied Input
Additional Defenses
- Also - Enforcing Least Privilege
- Also - Performing White List Input Validation as a Secondary Defense
- A2 - Broken Authentication and Session Management
Token or session ID binds the user authentication credential to the user HTTP traffic and appropriate access controls applied by the web application.
If session ID is getting captured it will lead to session hijacking and attacker will fully hack the user in the application.
Session Identifier (Session ID) is provided by applications for keeping authenticated state and tracking user progress at the time of session creation and it is exchanged by user and application.
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:
Session ID Name Fingerprinting
The name used by the session ID should not be extremely descriptive and it should not offer unnecessary details about the purpose and meaning of the ID.
It is highly recommended to change the default session ID name of the web development framework to a generic name, such as “id”.
Session ID Entropy
The session ID must be unpredictable (random enough) to prevent guessing attacks, i.e. it must be at least 64 bits of entropy.
Session ID Content (or Value)
Its content must not have any meaning, which will prevent attacks of information disclosure. However, Session ID must be created using cryptographically by using cryptographic hash functions.
Session ID Length
The session ID must be long enough i.e. at least 128 bits to prevent brute force attacks.
Session Management Implementation
It defines exchange mechanism that will be used between client and web application for sharing Session ID.
Built-in Session Management Implementations
It is recommended to use built in web development frameworks like as J2EE, ASP.NET, PHP, and others, provide their own session management features and associated implementation.