OWASP stands for Open Web Application Security Project. It is a non-profit organization whose mission is to improve software security. It is based on an “open community model,” thus, anyone can participate.
The OWASP community is well-known; I also refer to them in some of the articles I wrote.
OWASP started to publish a top 10 list of vulnerabilities way back in 2003. Since then, the list is updated every two or three years. The latest list was published in 2021. At the end of this article, I will provide a list of important pages on OWASP’s site.
By OWASP definition: The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
And, of course, as you can guess, this list is created by the community of developers specializing in security risks.
OWASP Top ten 2021 vulnerabilities:
- Broken access control
- Cryptographic failures
- Injections
- Insecure design
- Security misconfigurations
- Vulnerable and outdated components
- Identification and authentication failures
- Software and data integrity failures
- Security Logging and monitoring failures
- Server-Side Request Forgery (SSRF)
I will not focus on historical differences within the OWASP top 10. However, I wanted to mention that the difference between new versions of the list is mainly in categorization (often in adding new categories as new malicious attacks emerge), renaming, changing scopes, etc.
In my previous articles, I already covered some of the vulnerabilities from the OWASP list. In this article, I am going to focus more on Sensitive Data Exposure which is now known as Cryptographic failures. Now the focus of this category is cryptography failures that lead to sensitive data exposure.
Sensitive Data Exposure
When web applications accidentally expose sensitive information that should not be public, that vulnerability is called “Sensitive Data Exposure.” By sensitive data, I mean the data which should be protected by the GDPR. This includes personal data such as name, date of birth, credit card numbers, and even usernames and passwords. Unfortunately, if the website’s security is poor, sometimes, data can be found on the web server. But often, it is a case where attackers would perform the “man in the middle – MiTM” technique to try to hijack sensitive data.
This attack happens when the attacker places themself between the user and the web application. They would make a fake site, so the user thinks they went to their desired site but were redirected to the attacker’s fake site. Or for example, the attacker intercepts messages between the user and the server and gains control of that conversation. Basically, they control the flow of the request and the responses.
Exposing flat-file database
The database is often used to store all kinds of data, including sensitive data.
For this example, we will consider a small web application whose database is saved is saved as a single file on the disk of a computer (server).
The most common database engine used for this database type is SQLite.
In this case, the attacker would need to navigate and find the location of the database and then download it. They would then have access to the data in the database and could query it to get the results. Of course, it will probably not be easy if the data is encrypted, but the attack becomes a lot easier if the attacker downloads the database and has the file saved locally.
In one of my articles, I described one technique-Path Traversal, which attackers are using to navigate to a certain file. Check it out! I will not describe how to find the file and download it; if you read the mentioned article, you will have an idea about how it is done.
So, we are on the step when we download the database, and now, we want to check out the results in it.
As I mentioned, in this example SQLite queries are used. You can check out select and distinct syntax with SQLite here.
For example, if you are using Kali, sqlite3 is installed by default, so you can just refer to the man pages.
To access the database, you would issue a command like this:
sqlite3 targetDB
to see the list of tables:
.tables
To check out table info for the table:
PRAGMA table_info(users)
More info about pragma statements on this site.
Check out all user’s info:
SELECT * FROM users
Then, if the passwords are stored in this database, they would probably be hashed, and the next step would be to use some tool to crack the hash, for example, John the Ripper, Hashcat, or some other password-cracking tool.
When the attacker gets to the password, it is the beginning of the game for them! And the end of the game for the user.
Prevention steps Sensitive Data Exposure
When deciding on the storage type, it is very important to remember that you shouldn’t store sensitive data that is not required (store the least amount of data). If you need to store it, first figure out the safest location to store it and how to prevent the leakage of sensitive data.
When you store the data, you must encrypt it! I found this site you can check out if you are working with ASP .NET CORE and want to see how to encrypt/decrypt data using the interface IDataProtector!
Before you store the data, it should be safe at all times, especially in transit! For safe transit, use TLS, which would enable secure communication. If you are using ASP .NET check out how to enable TLS on this blog.
As I mentioned before, attackers often use the “man in the middle” technique; because of that, you might want to consider setting up something like HSTS(HTTP Strict Transport Security). If you are familiar with and want to use Angular to implement HSTS, there is a brief explanation on their official site.
While I mentioned ASP .NET and HSTS, if the application is in production you can modify startup class(or Program.cs if it is .NET 6)to use UseHttpsRedirection(HTTPS Redirection Middleware) and a also UseHsts(HSTS Middleware). If you want to use the mentioned Middleware, check out the official site!
Conclusion
I wanted to show you how many vulnerabilities from OWASP’s Top 10 list we covered through the previous articles and how many are left to be covered.
In the end, secure code is the cheapest code!
OWASP pages related to the topic:
Cover photo by Brett Jordan
#owasp #cryptographic-failures #top10
