OWASP top 10 web app vulnerabilities over time
The Open Web Application Security Project (OWASP) is a worldwide
a not-for-profit charitable organization focused on improving the security of software.
OWASP has the capabilities to provide impartial, practical information about AppSec to individuals, corporations, universities, government agencies, and other organizations worldwide. The main contribution of OWASP is, issuing software tools and knowledge-based documentation on application security.
OWASP tools, document, and code library projects can be organized into three categories.
- Tools and documents that can be used to find security-related design and implementation flaws.
- Tools and documents that can be used to guard against security-related design and implementation flaws.
- tools and documents that can be used to add security-related activities into the application-lifecycle-management (ALM).
One of the documentation provided by OWASP is the Top 10 web app vulnerabilities document. The OWASP Top 10 is a powerful awareness document for web application security.
OWASP has released Top 10 Web Application Security Risks periodically over the time in 2010, 2013 and finally 2017.
OWASP Top 10 Application Security Risks — 2010
- A1: Injection
- A2: Cross-Site Scripting (XSS)
- A3: Broken Authentication and Session Management
- A4: Insecure Direct Object References
- A5: Cross-Site Request Forgery (CSRF)
- A6: Security Misconfiguration
- A7: Insecure Cryptographic Storage
- A8: Failure to Restrict URL Access
- A9: Insufficient Transport Layer Protection
- A10: Unvalidated Redirects and Forwards
OWASP Top 10 Application Security Risks — 2013
- A1: Injection
- A2: Broken Authentication and Session Management (formerly 2010-A3)
- A3: Cross-Site Scripting (XSS) (formerly 2010-A2)
- A4: Insecure Direct Object References
- A5: Security Misconfiguration (was formerly 2010-A6)
- A6: Sensitive Data Exposure (2010-A7 Insecure Cryptographic Storage and 2010-A9 Insufficient Transport Layer Protection were merged to form 2013-A6)
- A7: Missing Function Level Access Control (renamed/broadened from 2010-A8 Failure to Restrict URL Access)
- A8: Cross-Site Request Forgery (CSRF) (was formerly 2010-A5)
- A9: Using Components with Known Vulnerabilities (newly introduced includes parts of 2010-A6-Security Misconfiguration)
- A10: Unvalidated Redirects and Forwards
OWASP Top 10 Application Security Risks — 2017
- A1: Injection
- A2: Broken Authentication
- A3: Sensitive Data Exposure
- A4: XML External Entities (XXE)
- A5: Broken Access Control
- A6: Security Misconfiguration
- A7: Cross-Site Scripting (XSS)
- A8: Insecure Deserialization
- A9: Using Components with Known Vulnerabilities
- A10: Insufficient Logging & Monitoring
Let’s have an overview of some of these security risks.
A1: Injection
This occurs when it is possible for an attacker to send hostile commands to an interpreter.
If the commands are executed in the interpreter without context-aware validation, injection flaws are possible.
Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries
More often we only consider SQL Injection, which is one type of popular browser injection to manipulate user data or retrieve unauthorized data.
There are many possible ways we can prevent Injection Flaws, one possible way is to do a static code analysis and discover the flaws. Scanners and fuzzers can help attackers find injection flaws.
Static Application Security Testing (SAST) Tools are designed to analyze source code and/or compiled versions of code to help find security flaws.
There are many tools available for this purpose like FindBugs
Google CodeSearchDiggity.
A2: Broken Authentication and Session Management
This occurs when there is,
- No proper session management
- Use of weak user credentials
- Application is not designed to prevent password brute forcing attacks.
Sessions are used to maintain user session state information for ease of re-login and preferences. If the session management is not implemented properly and it opens up a bunch of vulnerabilities.
- Session IDs are not properly invalidated upon logout or expiry period.
- Exposes Session IDs in the URL (e.g., URL rewriting).
- Session IDs not rotated properly after successful login.
Session Fixation Attacks are possible with improper session management. Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID.
When there is a use of weak user credentials attackers can crack it easily with the help of available knowledge-base they have.
If the Application is not properly designed to handle login attempts combined with weak passwords, attackers can use the application to brute force different password combination and eventually crack the credentials at some point.
A3: Cross Site Scripting (XSS)
This vulnerability is exploited when the attacker can send text-based attack scripts to the server embedded in the form of valid user data.
XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content.
There are two types of XSS flaws
- Stored XSS attacks (attack scripts are permanently stored in the server’s database)
- Reflected XSS attacks (attacks scripts reach the server from client request)
Also, we can have XSS flaws in Server side and Client side both.
Server-Side XSS happens when the untrusted user-supplied data is included in an HTML response generated by the server. Untrusted data can be a reflected data (supplied by the user through a request) Or stored data (already stored in the server’s database). We have Server-side Stored XSS and Server-side Reflected XSS attacks.
Client-side XSS happens when the untrusted user-supplied data is used to update the DOM with an unsafe JavaScript call. This attack doesn’t have any interaction with the server, browser-based. The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.
XSS attacks can be prevented easily in the Server-side by code analysis. To prevent XSS in Client-side we can use Java HTML sanitizers. We can use Content Security Policy(CSP) to defend against XSS across your entire site.
Thanks for reading the rest will be continued in the upcoming posts…
Please feel free to drop a comment.
