Mutt
Professional
- Messages
- 1,458
- Reaction score
- 1,296
- Points
- 113
Includes vulnerabilities such as SQL injection, OS command and SMTP injection, and other vulnerabilities where the attacker can inject custom commands into interpreters and the like.
Whoever has users must be able to identify them. This is called authentication, and any error in it allows an attacker to impersonate another user and/or unauthorized access to the web application.
Everything that can be configured can also be configured insecurely, e.g. if unsecure cryptographic procedures are used for TLS encryption or if an actually necessary password protection is forgotten, so that parts of the web application are freely accessible instead of only being open to certain users as planned.
This is a wide field. This includes unencrypted access data, which can then be eavesdropped on while on the move, or openly accessible files with confidential data.
If XML is used, it can be manipulated via XML External Entities.
Authentication ensures that you know who the user is. Equally important is access control or authorization: Is the user allowed to do what he wants to do at all?
The introduction of malicious JavaScript code into the web application allows all possible attacks, e.g. the user can be spied on or his computer infected with malware.
If data is stored in serialized form (complicated structures are simply written one after the other into a variable), they must be deserialized again later, i.e. converted back to the original data. An attacker can exploit a vulnerability to manipulate data.
Using Components with known Vulnerabilities:
If you integrate the demo application into your web application as a blog, you have this problem. This is really about using libraries with known vulnerabilities, for example. The problem is not so much the directly used components, which you hopefully know and can keep up to date. But what about third-party components that use those components you use? You can hardly do that, because you'd have to know which components they are, and if there's an update, check if you can just install it or if there's something that doesn't work with the component afterwards.
It's like the XXE. Since it is neither a vulnerability in the web application nor an attack, it doesn't really fit into the list. But it is very important, because if you don't notice that someone is trying to attack your web application, you can't defend against the attack.
For example, there are clickjacking and likejacking - attacks on like-button Facebook have suffered a lot. I could bet that Mark Zuckerberg would see clickjacking pretty high up in the top 10 vulnerabilities of web applications.