Introduction to web hacking

Web applications are where majority of attacks are occuring now a days. Since past decade, we have seen an upward progression in the layers of insecurities where the attacks moving from Physical layer up to application layer of the OSI model ,we will talk about some of the most common web application attacks, along with some server-side attacking techniques and strategies. Let’s talk about web application attacks first. Almost every web application attack is due to unvalidated input: failure to validate input upon authentication, on form fields, or other inputs such as http headers and cookies. Web application hacking happens because either developers aren’t taught to validate inputs or they don’t pay much attention to it.

ATTACKING THE AUTHENTICATION

Authentication in web security is an application to verify if it’s the correct user that accesses the private/protected information. In this section, we will talk about authentication-based attacks.
Some of the common vulnerabilities against authentication are as follows:
 Credentials sent over HTTP. Since they are unencrypted, an attacker on LAN/WLAN can
launch an MITM attack.
 Default passwords.
 Weak or simple credentials that can be cracked with brute force or dictionary attacks.
 Bypassing authentication by using various vulnerabilities.
 Abusing reset forgotten password functionality.
 Passwords being stored in local storage, making it easy for an attacker to extract them by
using XSS vulnerability.

In this section, most of our focus would be on some of the commonly used vulnerabilities to
bypass authentication such as SQL injection and Xpath injection. But before that, let’s talk about some low-profile attacks.

USERNAME ENUMERATION

Sometimes it’s possible to check if a current user exists in the database or not based upon the error messages that the application displays. This could be very helpful in cases where you want to conduct a brute force attack or an attack against a particular user. It could also aid you when exploiting the password reset feature. Let’s take a look at an example of how this works.

INVALID USERNAME WITH INVALID PASSWORD

We have a popular website xyz.com. When we enter an invalid username with an invalid password, the following error is displayed:
“Username is invalid,” indicating that the particular username was not found in the website’s database.

VALID USERNAME WITH INVALID PASSWORD

When we enter a valid username with invalid password, the following error is displayed:
“Password is incorrect.” Not to mention, the website provided is well known; however, this isn’t a big issue for them because most of their usernames are already public in their forums, listings, and market places, but certainly, this can still be an issue in several other applications.

ENABLING BROWSER CACHE TO STORE PASSWORDS

Another bad security practice that is often followed is developers using autocomplete function for password fields, which enables the passwords to be saved in browser cache allowing an attacker to access the password if he can somehow access the browser cache.
We can check if autocomplete is enabled with the following command:
<input type=”text” name=”foo” autocomplete=”on”/>
To protect against this issue, it’s recommended that the autocomplete be disabled.

BRUTE FORCE AND DICTIONARY ATTACKS

In the Remote Exploitation post, we discussed how we can use brute force or dic-
tionary attacks to crack various services such as ftp, SSH, and RDP by using various tools such as hydra, Medusa, and ncrack.

TYPES OF AUTHENTICATION

Let’s talk about some of the authentication mechanisms and their insecurities before looking at brute force attacks. There are three types of HTTP-based authentication schemes used primarily:

HTTP BASIC AUTHENTICATION

HTTP basic authentication is one of the first authentication mechanisms that were introduced. It works as follows:
When we send a GET request to the protected resource, the webserver would respond with a
log-in screen, which would set a “WWW-Authenticate” header also known as the authorization header. Our credentials are then sent to the server via the authorization header in the base64- encoded form. Upon receiving the header, the server would decode the base64 string to plain text and compare it with the information stored in the authorization file.

Upon submitting a correct username and password, the client would get access to the protected storage, and a “401” “Unauthorized” response from the server if an incorrect username/password is submitted.

Now, obviously, the problem with this type of authentication is that an attacker could launch a man in the middle attack and easily decode the encoded base64 string containing the username and the password.
Let’s try analyzing it in our favorite web proxy called “burp suite.”

As we can see, a base64 string is being sent to the server, which the server would decode and match with the password set in .htaccess in case you are on an apache webserver. Let’s try sending the string to burp’s decoder.
In the decoder, you would see a drop-down menu, which would ask you for the type of string that is submitted as an input. We will select base64.

It would successfully decode the contents of the base64 string, which happen to be
admin:password in this case, where “admin” is the username and “password” is the password.