As we are already well introduced, any kind of web app is depending on the other layers of the technology stack which support it, and also including the application or the web server, networking infrastructure and the operating system. So, an attacker may attack any of these components. It is the fact that the technology on which the app depends usually enables the attacker to totally compromise the application itself. We will here focus on the ways leveraging defects at the app server layer from an Internet perspective to attack the web app running on it.
Before we start, I would like you to go and visit the information about the cyber security tips and internet security tips.
Vulnerable Server Configuration
We know that even those simplest web servers come with plenty of the configuration options which control its behavior. So, most of the web servers contain the administrative interfaces which may be publicly accessed. It may be located at the specific destination within the web root or it may run on a different port (8080 or 8443). But, there are many of the devices which use the interfaces which have default credentials (wireless, printer for an example).
Default Content
A numerous number of the application servers ship with a range of the default content and functionality which you may be able to leverage to attack either the server itself or the main target app. The default content that may of interest:
-debug and test functionality;
-sample functionality;
-powerful functions;
-server manuals.
Although some servers may look like they are totally secure, it is not the truth. There are two reasons for that:
1.There are many sample scripts which contain the security vulnerabilities which can be exploited for performing the actions which were not intended by the scripts’ author.
2.There are also many sample scripts which actually implement the functionality which is of the direct use for the attacker.
Directory Listings
Let’s go further. Imagine a situation where the web server receives a request for the directory, rather than in the actual file, and then it may respond in one of this three ways:
1.Returning a default resource within the directory (index.html.).
2.Returning an error (such as HTTP status code 403) which indicates that the request is not permitted.
3.Returning as a list of showing the contents of the directory.
Also, the important thing to mention is that there are the two categories why obtaining a directory listing may help you attack the app:
-most of the apps don’t enforce proper access control over their functionality and resources and they rely on the attacker’s ignorance of the URLs which are used for accessing the sensitive items;
-it is the fact that the files and the directories are most of the times unintentionally left within the web root of servers (logs, backup files, old versions of scripts etc.)
WebDAV Methods
This is a term given to a collection of HTTP methods which are used for the Web-based Distributed Authoring and Versioning. It is widely available since 1996. They are now adopted in the cloud storage and collaboration apps too. There, the user data needs to be accessed across systems using the existing firewall-friendly protocol (for an example HTTP).
These methods add numerous others which can be used for manipulating the files on the web server. So, how can this help for the attacker to provide him the effective event?
1.PUT-uploads the attached files to the specified location;
2.DELETE-deleting the specified resource;
3.COPY-copying the specified resource to the location which is given in the Destination header;
4.MOVE-moving the specified resource to the location which is given in the Destination header;
5.SEARCH-searching a directory path for the resources;
6.PROPFIND-retrieving the information about the specified resource (author, size and the content type).
Web Application Firewalls
There is plenty of the applications which are protected by an external component which is residing either on the same host as the app or on a network-based device. It can be categorized as performing either the intrusion prevention, like application firewalls, or the detection (conventional intrusion detection systems). There are the similarities how these devices identify the attack, so you need to treat them fairly interchangeably. It is the truth that many would argue about how having these is better than having nothing at all, but it is the fact that in many cases they can create a false sense of the security in the belief that an extra layer of defense implies the automatic improvement of the defensive posture.
So, we had a totally new topic today. Hope that I have interested you. We have so much more to learn, and we will never stop learning, because the tech’s world is always improving and changing, like the human brain through the history.
Are you ready to get more knowledge? I know you are. And in that case, you are at the right place!
Today we saw that as with the other components, on which the web app runs, the web server represents a significant area of the attack surface through which the application might be compromised. The defects in that app server may often and directly undermine an app’s security through giving the access to directory listings, sensitive configuration and runtime data, the source code for executable files, and also the ability for bypassing the input filters.
Locating the web server vulnerabilities often involves some reconnaissance and research because of the wide variety of app server products and version.