OWSAP
OWASP: Top 10 Ways Your Company’s Web Security Sucks.
Ward M. Zahran
CYS Student at JU
You might have heard of the “OWASP Top 10” before but never really looked into it,
or you might have never even heard of it. Either way you are in luck, as today we will
be deep-diving into what OWASP is, what we mean when we say the “OWASP Top
10” ,and why it is so important for cyber security.
What Is a WASP And Who Put It Inside an O?
OWASP, short for Open Worldwide Application Security Project, is a non- profit,
community driven project dedicated to improving the security of software through
things like projects, tools, or documents, all of which are released as open source.
They also host events, conferences and even local chapters that anyone can attend to
learn more about software security. Basically, it is a group of people keeping track of
how we messed up in terms of security and how to fix those setbacks.
But they are perhaps most known for their top 10, a list of the top ten web security
vulnerabilities. According to the foundation, the information needed to construct the
list is gathered based on data obtained when working with organizations, as well as
industry surveys, the former shaping eight and the latter forming the remaining two.
The most recent list was released in 2021, and so, that is the list we will be covering
here in this article. However, they are starting to make the 2024 list which should be
done by the end of September, so if your organization wants to contribute, go
ahead! They are still in the data collection phase and I am sure they would be happy
with your contributions. And now without further ado lets get into the top 10.
The Top 10
We will briefly go through each point, but if you are hungry for the fully detailed
sweet knowledge, please visit their website as they have a lot of useful information.
And now here is the list:
- Broken access control: imagine you lock your house and then wake up in an 80s slasher film, somehow a serial killer got in (oh no!) but how, I hear you ask? probably because you were so busy closing the door that you did not notice that it had no hinges. Unhinged example aside (very funny I know), this isthe essence of broken access control! it is people gaining access to things they shouldn't be able to acquire. It is usually caused because of an oversight by the developers. For example, let’s say the URL of your account on some social media page looks like this: “https://example.com/account?account id=Ayob”. What if we replace the “Ayob” with something like admin! Aha we gained access into the admin account. While it is a simple example, it perfectly encapsulates what this type of vulnerability usually involves. Sometimes you might spend so much time trying to secure one method of entry (such as a login page) that you forget others exist.
- Cryptographic failures: think back to a government website that looks like it came straight out of the 90s (because it probably did) and wasn’t updated for years on end (because it wasn’t). S ometimes, such websites lack encryption (think about the padlock sign). This means that anyone can 4 intercept, read, or edit the traffic. In essence, cryptographic failures can be ca
- Injection: No there are no needles involved (thankfully). The easiest way to explain this point is by using an example, let's say you go into your profile and edit a couple of settings, but instead of being a Nice Guy TM , we put in our profile description some Javascript code. If the website doesn’t validate our input (meaning checks if the input is malicious) it could result in the code being executed in the browsers of the people visiting our profile. This is what we call an XSS (cross site scripting) attack, and here lies the dangerof this type of vulnerability. We could execute code on either the server itself or on clients of the server, one great example of this is the Samy worm, where an XSS vulnerability resulted in the message “but most of all, Samy is my hero” being plastered across MySpace profiles.
- Insecure design: While all of the previous points talk about implementation faults, this one is about the faults in the design itself. A good example of it is the usage of “questions and answers” as a mechanism for password recovery, which is fundamentally a bad design rather than a bad implementation.
- Security misconfiguration: Ah yes, the classic “we forgot to change the default password” problem. Security misconfiguration can be something as simple as forgetting to change default credentials to a misconfigured firewall or usage of weak passwords and everything in between. They are usually very simple details that one might miss while deploying something manually. Thisis why you should always have something like an automation script, or a way to deploy reproducible environments. Setting up servers manually will increase the chance that a misconfiguration will occur. One great example of this is Knight Capital Group. While not security related, it is an important lesson in why reproducible deployments are so important. The company lost 460 million dollars in 45 minutes due to a misconfiguration incident.
- Vulnerable and outdated components: this can be as simple as an outdated version of software such as a database, or it could be something more sinister. A lot of today’s software isn’t written from scratch (unless you work with embedded systems then god bless you). Instead we rely on libraries and components written by other people which opens the door for bad actors to inject malicious code into components you depend on, but it goes evendeeper than that. You might use a library that depends on another library which depends on another library and so on... without proper vetting, this can lead to someone inserting a backdoor that affects all applications that depend on a library. Just ask your local javascript developer about left-pad, faker.js or colors.js and they will probably experience a PTSD episode.
- Identification and authentication failures: authentication is in essence proving that you are who you say you are, therefore, a vulnerability of this kind includes thingslike password stuffing attacks, where the attacker tries passwordsleaked from other websites in order to try to gain access to an account, or things like brute force attacks where you try to exhaustively 5 guess the password or even the usage of leaked tokens which allows the attacker to hijack your session. This can be avoided through the usage of strong passwords, multi-factor authentication, and limiting the amount of times a user can try to login.
- Software and data integrity failures: have you ever wondered how your Playstation is able to differentiate an official game from a fake? well they use a so-called “digital signature”, which is a fancy way of ensuring the files originate from a specific party and that they haven’t been tampered with. Now , what does this have to do with security I hear you ask? Well, Insuring data hasn’t been tampered with is critical to security, but some developers often ignore such validation, for example some IoT devices have the ability to automatically update whenever a new version of the firmware is released, but sometimes they don’t use a digital signature meaning anyone can tamper with the update files and insert malicious code and compromise the device.
- Security logging and monitoring failures: logs are among the most important assets in the cyber security world. They allow us to detect attacks early and neutralize them or understand how a breach happened in case one actually occurs, so as you can guess, a lack of logs would be a catastrophe . This is why you should always enable logs, store them in a safe place and have an alert system in case someone is trying to attack your system.
- Server Side Request Forgery (SSRF): I think this one too is better explained by an example. Imagine you have a website that fetches the profile information of users, we supply it with the link to the profile (for example “https://example.com/account?account id=Majd”) and it returns the data. It does this by sending a request to the server specified by the link, fetches the information, and then gives it back to us. Sounds innocent enough right? Well who says we have to give it a link to a profile?or even a link at all! What if we instead tell it to go to something like “http://localhost/admin”? Well, if we tried visiting that ourselves it will probably result in an error, but what if the request came from the server itself? If there isn’t enough validation and the system is misconfigured, it might result in the admin page being sent back to the user, bingo! but then what else can we do? why not use something like a private IP address? For example “http://10.0.0.8/super duper secret files” and again! we got filesfrom other devices on the network! This kind of vulnerability can be treated by (again) validating input and segmenting the underlying network.
Conclusion
While the explanations are by no means exhaustive (and believe me I had to skim over
a lot of information) I hope it was a good appetizer for you and gave you some surface
level overview of what OWASP is and their top 10. If you enjoyed this article, please
go visit the OWASP website as they have a lot of goodies I wasn’t able to talk about.
