I think it's very important that everyone is aware of the possible dangers they might face when creating their first web project or when stepping foot in the cybersecurity industry. While i believe OWASP did a great job with their investigations, i would like to add a few points and write them in a better to comprehend format. Hopefully I can entice you investigate how vulnerable you are in regards to these issues if you are a manager, developer or software tester.
Whenever a website gets more dynamic and starts to do things like request data from databases or starts including login systems, it's not only the code that gets more complex but also the security requirements. These login systems for example are often handled by what we call LDAP (https://nl.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol ) and while this functionality is great, it also opens up the application for attackers as they can inject their own code into the login system to give them rights they are not supposed to have for example. That would be called LDAP injection, however it is not the only type injection we have. As we need to grab data from databases, we use what is known is SQL queries or noSQL just to name a few. An attacker might inject their own code into these types for queries which can lead to very bad things such as the dumping of the entire database or even worse, the deletion of it. There are many types of injections and we have only covered a few here, besides even the OWASP guide is a bit outdated as new technologies arise almost every month it seems, so do the possibilities for injection. GraphQL for example is a way to query an API which is also open to injections but not yet covered in the OWASP web top 10.
We already went over how to abuse these vulnerabilties a little bit but it's important to know that what an attacker needs is some way to control the data going into these systems. There has to be user input involved in a query for example, otherwise it can not be vulnerable. This can be as easy as a user inputting their username into a system which would trigger a SQL query in the background. It can also be a bit harder to spot however and the user input might reside in things such as cookies (which are used to track information across a website) and headers (which contain information the server needs).
An example we have not really looked at yet is OS command injection. This is a very harmful vulnerability and also falls under this category. It occurs when user controllable input is send to a command that directly interacts with the operating system. This all seems quite abstract so I will give a small example. Imagine a system that backs up files but to do this, it needs to read the filename and it will send a "cp file1 backupfile1" command. This command will backup the original file to a backup file. The attacker can control the first files name however and end the current command, inserting their own. This could lead to all kinds of consequences including a full takeover of the infrastructure of an organisation.
From the previous chapter we've seen that user input is the key to pulling off a succesful attack, now of course avoiding the usage of this input in things such as queries is the best solution but we do not live a world where everything can be perfect so the second best option is to sanitise that incoming user input in every location and to make sure no malicious code can enter our systems. This may seems easy but seeing as this user controllable input can come from anywhere, you can see how this gets complex very fast. This is why it is very important to index those ways a user can input data so we can refer back to it but also to perform regular pentesting to find any user input that might have been missed.
When browsing the web, dynamic websites often serve up resources such as images or information to certain people only. This will be the people who have access to this information and are authorised but even before this process, we need some way of telling the server who we are. Usually a password and username system is being used where you log in by entering your credentials, this is authentication and of course someone invents something, someone else finds a way to break it.
When we want to access certain resources, we often need to be authenticated and hackers know this all too well. They have come up with some ingenious strategies to beast developers that did not implement their authentication properly. Hackers can do this for example by simply preforming content discovery (The act of guessing the name of content such as directories or pictures) and trying to look for pages that have not enjoyed the proper protection mechanisms yet. Of course this is only one way, another example is by pretending our request comes from a trusted server by setting the "x-forwarded-for" header. Even simply being able to brute force login names and passwords by not implementing proper rate limiting can be seen as broken authentication so as you can see there is a host of possibilities.
The simplest thing you can do is by enforcing a proper password policy that requires the user to reset their passwords on a regular basis to ensure the impact of a compromise is more limited in time. That being said, this is useless as attackers can eavesdrop in on the communication so we need to ensure that we prevent this by sending data over unencrypted channels. Last of all we should never give the user more information than is strictly required when it comes to any authentication processes. This includes for example not naming if the username or password is the data the user entered but instead presenting them with a generic error message.