As a software developer turned security engineer, I continue to follow current development technologies, as it makes me more of an effective tester. One of the articles that I was reading contained an interview with one of the applications developers that had a question to the tune of “How do you ensure you keep your software secure?”. The response contained something that I see constantly: “We guard against the OWASP Top 10...” There was more to the answer than that, but the key phrase in there is “OWASP Top 10”. It’s common, and those of us in the security field know what this means, but I thought I would take a minute to go over what the “OWASP Top 10” is in a little more detail for those that might not be 100% certain what they are.
OWASP (Open Web Application Security Project) is a global organization that focuses on the security of software and training individuals and organizations on security best practices. Specifically, this organization works with and through its members on defined projects. These projects track software security trends, provide guidance on how to best address/defend against those found and provide tooling for testing and training. One of their most recognized projects is a listing of the ten most common vulnerabilities in web applications – which is dubbed the “OWASP Top 10”. As web applications evolve over time, so do the list of vulnerabilities.
The most recent list was compiled in 2017 and consists of the following risks:
|
1. Injection 2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control |
6. Security Misconfiguration 7. Cross-Site Scripting (XSS) 8. Insecure Deserialization 9. Use of Components with Known Vulnerabilities 10. Insufficient Logging & Monitoring |
Although these are not the only vulnerabilities that exist, these are the most common areas that web applications are subject to attacks. Below is a brief definition of each one.
Injection
Injection is where an attacker can manipulate parts of the application (such as a query string parameter or web form field) to execute a command that was not intended by the applications developers. This command could become a malicious database query (SQL Injection) or trigger a malicious command to run on the server (Command Injection). Exploiting this type of vulnerability can greatly impact the stability of the application and data within.
Broken Authentication
Most web applications have a concept of an unauthenticated vs. authenticated user (think: a user that is signed out, vs. one that is signed in). When the elements surrounding how the changing of this state are attacked and exploited, its referred to as broken authentication. Examples here would include allowing default, weak or well-known passwords for user accounts, down to how the user’s authentication state is tracked within the application.
Sensitive Data Exposure
These types of exploits occur when sensitive data (financial or medical information would be an example of this) is either stored on a server or exchanged with the application. This is more common with API’s but occurs in web applications as well. When the application fails to properly encrypt this data at its storage location or transmit insecurely (which can still occur even over HTTPS), data can be exposed which otherwise should not be. A great example of this would be retrieving user information as part of an API call and returning a cleartext password (not hashed or encrypted) in the results.
XML External Entities (XXE)
Of the items in the top ten, this item is one that is more a deep dive item. This type of exploit involves abuse of a vulnerable XML processor that allows external (remote) content to be successfully loaded within an existing XML object. For more information about this, give us a call and we can provide more information about it.
Broken Access Control
Exploits in this area involve abuse of an existing authenticated session. These types flaws enable an attacker to access files or data they otherwise should not be able to or change the privilege on their account from a standard user to one with elevated permissions.
Security Misconfiguration
This is one of the more common vulnerabilities that are discovered as part of a web application penetration test. Typically, this is a function of the configuration of the server and not as much the code. Examples of this type of exploit are misconfigured server settings or detailed error messages (which include stack traces) which leak more data than necessary to a user’s browser. This leaked information can identify technologies in play which will dramatically narrow the scope for the attacker.
Cross-Site Scripting (XSS)
These types of flaws arise from not properly encoding data in the application and is another common finding. This category of vulnerability has two forms, persisted and reflected. Persisted means that malicious content can be saved to a central location (like a database) and is potentially going to be shown to more than one user. Reflected means its only rendered to the current user. Of the two, reflected carries high risk because it can potentially impact more than one user. By exploiting this, an attacker can execute their own scripts on your web application that can potentially hijack sessions from existing users, deface the application, or redirect a user completely away from your application in general.
Insecure Deserialization
This is another area that gets a little deeper than the others but can lead to some devastating scenarios. If an attacker can craft an attack payload which the server executes by inspecting it these can result in remote code execution. Again, if you have questions on this item, please reach out to our team to get more information.
Use of Components with Known Vulnerabilities
Most web applications depend on third party components to function properly. These include things like server-side frameworks (like PHP or ASP.NET) or client-side libraries (like jQuery or AngularJS). While your application may not be vulnerable by itself, if it utilizes a library with known vulnerabilities, the library itself can still be exploited which, depending on the vulnerability, could lead to data loss or even the complete compromise of a server.
Insufficient Logging & Monitoring
Sometimes attacks will go unnoticed because there was not sufficient logging to take place. This is the type of information that we would work with your team to verify. If we were able to successfully exfiltrate a significant amount of data during a penetration test, one step we would take would be to report it to ensure you were able to see the data that we were pulling from your environment. If the application under test did not have adequate logging, it may be possible to continue to remove data without you being aware.
Now that you know what the OWASP Top 10 list is, are your curious how your application stacks up to them? Contact us to schedule a web application penetration test. As part of this test, our engineers will test for all the above items and more to ensure the security of your application.
