The vulnerability of a site is a weak or incorrectly configured site code or web application, which allows an attacker to get some level of control over the website, and possibly the hosting server.
Most vulnerabilities are exploited by automated means—for example, vulnerability botnets and scanners.
Cyber-scammers create specialized tools that scour the Internet for specific platforms, such as WordPress or Joomla, looking for common and advertised vulnerabilities.
Once these vulnerabilities are discovered, they are used to steal data, spread malicious content, inject spoilage, and spam into the vulnerable site.
Here we will look at some of the most common web security vulnerabilities that attackers often exploit.
1. Injection Flaws
Injection errors are the result of a classic non-trusted input filter failure. It can happen when you transfer unfiltered data to an SQL server (SQL injection), browser (XSS – we will talk about this later), LDAP server (LDAP injection), or anywhere. The problem here is that an attacker can enter commands to these entities, resulting in data loss and interception of client browsers.
Everything that your application receives from untrusted sources must be filtered out, preferably according to a whitelist.
It would be best if you rarely used a blacklist as it is difficult to obtain and usually easy to bypass. Anti-virus software products usually provide star examples of unsuccessful blacklists.
2. Broken Authentication
It is a collection of many problems that can occur during an authentication hack. However, not all of them stem from the same root cause.
Assuming that someone still wants to roll out their authentication code in 2020 (what are you thinking??), I don’t recommend doing that. It’s challenging to do it right, and there are countless possible pitfalls. Here are just a few of them:
- The URL may contain a session ID and leak it to someone else in the arbitrator’s header.
- Passwords may not be encrypted either during storage or during transmission.
- Session identifiers can be predictable; therefore, gaining access to them is trivial.
- Session fixing may be possible.
- Session hijacking may be possible. Timeouts are not implemented correctly or using HTTP (no SSL security)
3. Cross-Site Scripting (XSS)
When this login is returned to the user without disinfection, the user’s browser executes it. It can be as straightforward as creating a link and convincing the user to click on it or something even more sinister.
When a page is loaded, a script runs and can be used to send your cookies to an attacker.
4. Insecure Direct Object References
It is a classic case where the user trusts the input and pays the price for the resulting security vulnerability.
A direct link to an object means that an internal object, like a file or database key, is exposed to the user. The problem is that an attacker can provide this link, and if authorization is either not forced (or broken), the attacker can gain access or do something that can be denied.
For example, there is a module download.php in the code that reads and allows the user to upload files using the CGI parameter to specify the file name (e.g.,download.php?file=something.txt).
Either by mistake or because of laziness, the developer missed authorization from the code. An attacker can use this to download any system files that a PHP user has access to, such as the application code itself or other data left on the server, such as backups.
Another typical example of a vulnerability is the password reset function, which relies on the user to enter the password to determine whose password we reset.
After clicking on a valid URL, an attacker can change the username field in the URL to say something like “admin.”
5. Security Misconfiguration
Applications and web servers that have been misconfigured are much more vulnerable than those that have been appropriately configured. It could be because there is no shortage of ways to mess things up.
These are some examples:
- Launching the application with debugging enabled in production
- They are enabling the list of directories on the server, which leads to the leakage of valuable information
- Running outdated software
- Presence of unnecessary services running on the machine
- Do not change the default keys and passwords. (It happens much more often than you think!)
- Detecting error handling information, such as stack traces, to crackers.
6. Sensitive Data Exposure
This web security vulnerability is crypto protection and resource protection. Confidential data must be encrypted at all times, including during transport and at rest.
There are no exceptions. Credit card information and user passwords must never be moved or stored in unencrypted form, and passwords must always be hashed.
Session identifiers and sensitive data should not be roamed over URLs, and sensitive cookies should have a security flag enabled. It is imperative and cannot be overstated.
7. Missing Function Level Access Control
It’s just a login malfunction. It means that the proper authentication was not performed on the server when the function was called.
Often, developers rely on the server-side to generate the user interface, and they think that the client cannot access functionality that the server does not provide.
It’s not that simple, because an attacker can always fake a request for “hidden” functionality and will not be constrained since the UI does not make that functionality readily available.
Imagine that there is a /admin panel, and the button is only present in the user interface if the user is an administrator. Nothing prevents an attacker from discovering this functionality and using it for the wrong purpose if there is no authorization.
8. Cross-Site Request Forgery (CSRF)
It is a good example of an intricate attack on the deputies. The browser is created by some other party to abuse its powers. A third party site, for example, could force a user’s browser to abuse its credentials to do something for an attacker.
In the case of CSRF, the third-party site makes requests to the target site (such as your bank) using your browser with your cookie/session. If you are, for example, logged on to one bookmark on your bank’s home page and they are vulnerable to this attack, another bookmark may cause your browser to abuse its accounts on behalf of the attacker, resulting in a confusing problem with the alternate.
The alternate is a browser that is abusing its credentials (session cookies) to do what the attacker told it to do.
9. Using Components With Known Vulnerabilities
The name says everything. It can be classified again as more of a maintenance/deployment problem. Before you enable the new code, do some research, perhaps an audit.
Using code that you get from a random person on GitHub or some forum can be very convenient, but not without the risk of serious web security vulnerabilities.
For example, when sites got owned (i.e., when an outsider gained administrative access to the system) not because the programmers lacked experience, but because third party software remained unavailable for years in production. It happens all the time, especially with the help of WordPress plugins.
The lesson here is that the development of the software does not end when the application is deployed. There should be documentation, tests, and plans to maintain and update it, especially if it contains third-party or open-source components.
10. Unvalidated Redirects And Forwards
Again, this is an input filtering problem. Suppose the target site has a redirect.php module that accepts the URL as a GET parameter. By manipulating the parameter, you can create a URL on targetite.com that redirects the browser to another website, which is malwareinstall.com.
As the user sees the link, they will see targeting.com/etc., which the user believes is trusted and safe to click.
It is unlikely that they know this will take them to the malware drop-down page (or any other malicious page). Alternatively, an attacker can redirect the browser to targetite.com/deleteprofile?confirm=1.
It should be noted that stuffing an unsanitized user input into an HTTP header can lead to header injection, which is quite bad.
To Sum Up
The main conclusion here is that the age-old practice of software exists for a reason, and what was used in the past to buffer overflow is still used for pickled strings on Python today. Security protocols help to write (more) correct programs to which all programmers should aspire.
To minimize the risk of malicious intrusion, container security, which combines operating system elements with application code, should be considered. In contrast, another bit of code called Dockerfile usually defines how containers are built.
Even the most experienced CIO and web security expert should be vigilant and guard against the bad guys. No one can be safe without knowing what to look out for.