After years of experience in penetration testing, I can say that one of the best things that can happen during a penetration test is to find a security misconfiguration. Unfortunately, when you look for these vulnerabilities on Google all that you get is theories or discussions and explanations of such types of vulnerabilities which is not enough especially for a penetration tester. Therefore, here is a list of security misconfiguration vulnerabilities:
In this blog post, I will try to explain each of the previous vulnerabilities while explaining their impact on your website. Moreover, a detailed explanation of how you can fix each one of them will be presented. In addition, more detailed blog posts will follow this article to explain each misconfiguration vulnerability in every web component. So if you are interested in knowing
The security misconfiguration vulnerabilities have the ability to accelerate drastically the penetration testing and make it easier. This fact is due to the amount of information that a penetration tester would get from a misconfiguration.
Penetration testing is mainly based on collecting information about the audited systems and exploiting that information to get access. Therefore, with a security misconfiguration, a lot of critical information like passwords, usernames, and more could be leaked to the attacker while simplifying the penetration test for him.
The first vulnerability I would like to discuss with you is the directory listing. The Directory listing vulnerability happens when the web server, displays the content of the web application folders. Many people think that this vulnerability is not really that important and that it could be left without fixing even if the fixing does not take too much time to be done.
However, this vulnerability can be destructive for a whole business, as it will help the attacker to get access to some juicy information and use them against the app. In the following paragraphs, I am going to give you some real examples where having this vulnerability will be very critical to you and might lead to law pursuit.
Let’s suppose that you have an application that requires a photo of the user’s passport before it validates his account. This image is then saved with a random name in a folder called uploads. The attacker could then perform the same action and upload a fake Passport or just a simple image to exactly locate that folder. Once the folder is located, all he needs to do is to visit that folder and he will get a list of all the passports already uploaded.
Even if we change the name of the file and make it unguessable, the directory listing will show all the files, and no need for a brute-force to find the other files.
It might sound like it is not realistic, but trust me I have found way more critical documents than this due to directory listing problems.
When performing a penetration test against a web application, some of the tasks that consume too much time is directory and files brute-forcing. This attack is necessary as it reveals a lot of information about the app structure.
In some cases, when developers perform a backup action for their website they forget a copy of the source code or the database on a publicly accessible folder. In general, if the directory listing vulnerability is not present, then it is hard to discover those files, as their name is generated by a tool.
However, when this vulnerability exists, then finding and downloading those files becomes as easy as navigating through the different listed folders of the server.
In general, when the file is left in the root folder of the application like this www.example.com/bakup.zip it is really difficult to discover it as most of the time an index.html file is present in this folder and it is a way to protect against the directory listing.
To fix the directory listing vulnerability you can:
Options -IndexesOne of the most popular security configuration vulnerabilities on the web is using default passwords. You should know that the first thing that an attacker tries in your application is a password brute-force. Therefore, if the application has a default password, then penetrating it is just a matter of seconds.
Most of the time, those vulnerabilities happen when the application is directly cloned from a development environment to the production. As an experienced developer, I really understand this. When developers or even network administrators, try to build something, the main object is not to secure it, the main idea is to make it work.
When there is a deadline, it is even worst as you need to make it work and in the time frame, you get not after. This kind of stress pushes the developers and the administrator to use easy and quick words to make a password and test the app or the network.
Unfortunately, once the app or the network is implemented correctly in the production environment, the developers do not take the time to change the default or the easy passwords used. I think that that this also comes from the fear of breaking something in the app or the network that is working and starting all over again. I know that this is not a realistic reason to leave those things in the network, but trust me if you were a developer or a network admin you would have felt this at least once.
Therefore, to solve the default passwords vulnerability, you can:
The impact of this vulnerability really depends on the functionalities that the attacker would get once he guesses the password for that user. For example, if you use a simple password for the WordPress admin user, then the attacker gets the ability to perform even a remote code execution. This is feasible because WordPress offers the ability to make changes on the WordPress theme right from the web application dashboard.
Displaying errors is also one of the most common and critical security configuration vulnerabilities. Unfortunately, a lot of peoples does not take this vulnerability seriously. This is happening because developers tend to leave error displaying even in the production environment to quickly debug and fix errors while the app is on production.
However, you should know that displaying errors to the attacker is one of the best things that could happen to him. First, it makes detecting vulnerabilities easier, by showing the exact behavior of the app due to the sent request. Second, it makes exploiting it even easier, for the same reason. Third, some error tracing mechanism in some frameworks displays even the database password, which is the case for Laravel.
In a lot of situations where I was performing penetration testing, error displaying was a very helpful tool. In some cases, it was even a source of some other critical vulnerabilities like XSS and others.
To prevent the error displaying vulnerability you can:
php_flag display_errors offdisplay_errors = OffCall for the following function in the very beginning of your source code file:
error_reporting(0);For more details visit the following link
The HTTP protocol provides many verbs so that the web browser communicates correctly with the server. The most used verbs are GET and POST. However, in some cases, developers require the use of other verbs like PUT, DELETE, TRACE to perform some specific actions on the app.
I’ve noticed that those verbs are usually used in API development or web application developed using NodeJS technology. That does not mean you won’t find those verbs enabled in other technologies, but in my experience, that was the most common place where I find those verbs.
Unfortunately, some of those verbs could be very destructive and could even lead to remote code execution. For example, the PUT Verb gives the attacker the ability to upload a file to the web application server. The DELETE verb gives the attacker the ability to delete any file on the server, which may lead to some serious DOS attacks. Some of those verbs create other critical vulnerabilities like XSS in the case of the TRACE verb.
Therefore, disabling unnecessary HTTP verbs will help reduce both attack surface and risk. To disable those verbs all you have to do is:
By adding the following lines:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|PUT|DELETE)
RewriteRule .* - [F]Sending security headers to the client web browser could sometimes save your users from potential vulnerabilities in your web applications. Before I go deeper into this subject, I want you to know that by no means, this technique could replace the right fixing of vulnerabilities. This technique can only help you increase the security level of your website, and make it harder but not impossible for an attacker to exploit a vulnerability in your website.
The X-XSS-Protection header adds a layer of protection to your application by protecting it from some types of XSS vulnerabilities. This header stops the browser from loading the content whenever a malicious javascript code is detected in the HTTP request.
In general this technique is a little bit efficient when dealing with reflected XSS vulnerabilities. However, in most cases, it is not capable of protecting your app against the XSS stored and DOM-based. If you want more details about those vulnerabilities, I have written a detailed blog post about how to detect and fix this vulnerability in its three types, how to prevent XSS in PHP?
To enable this header you should add the following line:
Header always set X-XSS-Protection “1; mode=block”
Into httpd.conf file: /etc/httpd/conf/httpd.conf
Then you should restart the server.
The X-Frame-Options protect your visitors or client from a type of attack called ClickJacking. In this attack, the malicious person tries to trick the legitimate user into clicking something they are aware of. By implementing this header you are ordering the browser to not include your website into an ifram.
To enable this header here is the configuration line you should add to the httpd.conf file:
Header always append X-Frame-Options DENY
Software updates are one of the most critical security configuration problems you should deal with as soon as you can. Having an outdated web application or service in your server means that you have an open door that can be exploited to get access to your website or server at any moment.
Outdated software usually means a vulnerable app, and a vulnerable app means there is an exploit either a private exploit or even worst, a public exploit. This kind of vulnerabilities usually happens for popular applications that get used by millions of people around the world.
Therefore, if you are using a web application that is developed from scratch, then the probability that you are using a vulnerable or having outdated application remains low. However, most modern development technologies, start to use already development components in their “from scratch” applications. This technique was able to reduce the development time of application but has also increased the number of outdated software being used.
Following the discovered vulnerabilities and fixing them one by one, is a hard and time consuming process. Therefore, having a tool with a good database and feed will help you do it in the correct way.
Frameworks also offer a nice set of security configurations that you can enable while in the production environment. These configurations can significantly reduce the number of vulnerabilities in your application. Here is a list of what some PHP frameworks offer:
What I have listed here is just some examples of what can a framework offer. Therefore, if you are interested in a specific framework security configuration, you can take a look at its documentation.
Web servers usually offer both protocols one secured which is HTTPS and one without security HTTP. This situation usually happens when the web application is hosted in a mutual hosting server where some application uses HTTP and other uses HTTPS. In this situation, you should configure your application to only use HTTPS requests rather than giving the visitor the ability to choose.
Forcing HTTPS protocol can be configured using the .htaccess file by adding the following configuration to it:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Displaying the server version and details is a functionality offered by the used web server and not a vulnerability in itself. However, this information can be used by attackers to look for publicly documented vulnerabilities about your server and find the right exploit to get access.
Therefore, hiding this information could be considered as a good enhancement for the security of your server. For example, if your server is outdated this technique could make it harder for the attacker to find the right exploit to use against your server. This does not mean you can forget about updating your web server. Updating the server is the only reliable action to successfully fix the issues.
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).
After starting to use the object-oriented development concept, new types of vulnerabilities were born. Insecure deserialization vulnerabilities were one of those vulnerabilities. Therefore, what is an Insecure Deserialization vulnerability, and ...
Undoubtedly, ChatGPT stands out as one of the most remarkable inventions of 2021. Its wide-ranging capabilities and applications have opened up endless possibilities for human interaction and problem-solving. Furthermore, certain [...]
Post comments (0)