Listing supported Http methods is a crucial step in the process of auditing web servers.
It allows system administrators and penetration testers to gain insight into the configuration and software
of web servers, as well as identify potential security risks associated with a certain Http methods.
By leveraging the power of Nmap, an open source network scanning tool, this task becomes efficient
and effective when it comes to Http methods.
Web servers can support a wide range of options, each serving a specific purpose.
However, it's important to note that the certain methods can introduce vulnerability and vulnerabilities,
if not properly secured.
For instance, methods like Trace.
Let's actually write it down on the notepad.
Methods like trace.
And so the.
Will.
An.
Um, result in vulnerabilities.
If not properly.
Secured.
Right.
So these are the methods, for instance, Trace.
Connect.
Hot.
And delete these methods.
These Http methods have been known to pose potential security risks, especially the connect one here,
when misconfigured or exploited by malicious actors to identify the supported Http methods on a web
server, we can use the Nmap scripting engine again and see which provides a collection of scripts specifically
designed for network scanning and security assessments.
One such script is the Http method script developed by the Bernd Strauss Newberg, which allows to enumerate
the supported methods of a web server.
So let's dive into the practical steps of using Nmap with the Http method script to list the Http methods
supported by a Target web servers.
Now let's open your terminal or command prompt and enter this command.
Firstly, we will use sudo here.
We will add ports here, ports 80 http and 443 SSL, TLS the Https and we will also use the script here,
script Http methods and here we will also add script arguments which we will test all so script.
Arguments, http methods that test all and here we will make it equal true.
And after that you will enter your target system.
In this case, we will test it in two systems.
One is web server, just a WordPress installed on it.
This is just a web hosting server and another is our Metasploitable virtual machine.
So let's actually use with code Silicom Firstly, and here we have problem because we didn't write it.
Nmap here.
Sorry Nmap that's it.
And here we will enter our pseudo password and we are waiting for it.
As I said, you can use your arrow keys to print the results.
In this case it was quick here, so here and let's actually explain this command first.
In this command, the P 80 comma, p 443 specifies the ports to scan.
In this case, the port 80 and port 443, which these are commonly used for Http and Https communication,
as I said.
So the Http methods script is invoked using this script option and the Http methods test.
All true argument ensures that all supported methods are tested and once the scan is complete and map
will present you with the comprehensive report that includes the supported methods for each web server
detecting on detected on Port 80 and port 443.
For example, the output will this will look like this here.
So here we have in port 80, we have get hit post options methods and here we have options hit get post.
So now what we're going to do is we will scan that on our metasploitable vulnerable virtual machine.
In this case, our the machine is on my local IP here.
Let's actually first scan it here.
Ipconfig it was uh, the most exploitable IP address was the last digits was 141 here.
Uh, the fifth.
Yeah.
13 141.
And that's it.
And here, as you can see here, we also have get hit post options and that's it.
So we will first actually let's scan here.
A nmap is V, We will scan this, we will scan the services available and we will we can also use another
protocols like instead of Http and Https, we can use FTP and.
So there is a lot of protocols, as you know.
So here it might take some time.
And here we have a lot of here.
So let's actually now try the FTP 2021 and we also have 20 Sorry, Yes, 21 right now.
We will test it on the we will also add 21 here.
21.
And here in 21, we don't have any Http methods.
And as you can see here, we have Http methods that test all.
So we don't have Http methods here because the Port 21, the Http server is not active here.
As you can see, the service is different, right?
But if you have some client that uses different ports for this Http ports here instead of eight, it
might use 8080 or another kind of ports here.
You might try this here scan and then you will see the service information here so you can select your
port accordingly.
So here in this example, in this example, actually, let's that scan that.com again.
And here we the output reveals that the web server supports common methods like get hit post options.
And it also highlights the presence of the potential risk if you have one.
In this case, the potential risk method is connect method.
But in this case, the connect method is actually not working here because it might be for the security
reasons or another reasons here.
So and it's important to emphasize that the presence of a method in the list of supported methods doesn't
actually doesn't automatically imply accessibility or imply security vulnerabilities.
Additional factors such as configuration settings and firewall rules can impact method availability.
Therefore, it's crucial to interpret the results in the broader context of the Web server's security
posture.
For more granular analysis, you can individually check the status code and responses for each method
using the Http method Retest script argument.
You can simply just add after the script arguments.
You can use the Http method retest all through here and here we will to provide more practical example.
And as you can see here, we have this here.
And here we will also do another two.
For connect method here and as you can see here.
Let's actually use that localhost now.
And as you can see, Http, it doesn't have any methods because it's not a service, right?
And now we will do another method.
So we will just delete the ports here.
Instead, instead of ports, we will use the lowercase and uppercase V here.
And here we have script arguments and so on and we have Http methods.
Retest all here or Http methods just retest here.
It's going to be okay.
And after that we will enter the target IP address or domain here.
In this case it's dot com and here you can use arrow keys to watch the.
Timing.
And here we have 30s remaining.
So here in this example, you will see something different here.
Might take some time because we are now scanning the most commonly used parts here.
I'll stop the video right here and here.
This is the output we are seeing now that the service fingerprint.
And we have that.
Here.
We have a lot of information going down here.
We have this pure ftpd XML, smtpd, ISC bind and lightspeed.
And here in Http methods we have the get hit post options and the http server header is lightspeed.
We have also finger fingerprint strings.
We have the four for get request and the Http options.
Here we have forbidden contact line is 93 catch control, no catch and so on.
So here this is our output could select that.
Com.
So in this example the output reveals that the um.
To connect method is not supported actually.
And it returns a 400 bad request code.
The finding suggests a potentially might be misconfigured or insecure setup here, so to customize the
base path for each Http methods test, you can utilize the Http methods that your URL path argument.
For instance, this here.
After that we will use the in script arguments after script arguments, we will use Http methods and
here we will use.
URL path and my path.
After that you will enter the your code.com or your target.
Uh, domain or IP address.
And it might also take some time for now because it will test almost all of the ports here.
Instead.
Let's actually use that in this time.
We will use the our web server.
Another 41.
That's it.
It will do more quick here.
And as you can see, it's almost done.
That's it.
Here we have the information about that and that's it.
As you can see here, we have openSUSE, Linux, Telnet and so on.
We have potentially risky methods here.
It's trace.
As I said, the connect and trace mode is potentially risky methods here on Http, but it doesn't mean
that it's 100% vulnerable, but you can, uh, check to make sure of it.
And here we have samba SMB.
And so these are the most exploitable, uh, services.
And here we are almost in the Http server header.
We have supported methods, get hit post plot, delete trace options and we have a potential risk methods
here.
Pod delete and trace.
And we also can see the Mac address.
Sort of a central host metasploitable local domain and so on.
Unix Linux.
Linux kernel.
And here.
That's it.
So here.
Other Nmap options.
Script here.
This instruct Nmap to execute a methods script when a web server is detected.
So here the Http method script built on a predefined list of Http methods performs tests to determine
the supported methods on the target server.
And it's important to emphasize that the presence of a Http method in the list of supported methods
doesn't automatically mean that it means the security of doesn't automatically mean that it's vulnerable
100%.
So as I said, additional factors such as configuration settings and firewall rules can impact method
availability, and therefore it's crucial to interpret the results in the broader context of the web
server security posture.
And in conclusion, and also by selecting the a different base paths such as in this case we use use
the my path.
Yeah, my path.
Uh, you can explore web applications residing in various folders and access the availability and responses
of Http methods within these specific contexts.
In conclusion, listing support at Http methods using Nmap Http Methods script provides valuable insights
into the into web servers, configuration and potential security risks by understanding which methods
are supported, system administrators and penetration testers can make informed decisions to strengthen
the security posture of their web application.
Remember to interpret the results in the context of the server's configuration and to consider additional
security measures beyond the presence of a supported methods.
Stay vigilant and ensure that your web servers are adequately protected against potential vulnerabilities.