Hacking Web Applications

What is a Web Apps?

A web Application is a piece of software running on the internet served to the client by a server. The client needs not to download the application. Still the client will be able to access all the features , directly via  the internet.

Hacking Web Applications

Web applications are basically pieces of codes , frontend and backend parts weaved together to build a fully functional application. hacking Web applications can be vulnerable in many different ways. so, An attacker can exploit the vulnerabilities to get into the backend of the webapp and can access any data. Or he can exploit a frontend side vulnerability and can damage or delete the aesthetics either temporarily or permanently!

Here are a few possible attacks on a webapps :

1. SQL Injection
2. XSS (Cross Site Scripting)
3. CSRF (Cross Site Request Forgery)
4. Bruteforce attack
5. Phishing attack
6. DDoS attack

We will now perform a few of the above-mentioned attacks on the already vulnerable web apps to demonstrate the effects of what if your app gets hacked!?

Prerequisites:

1. XAMPP Server
2. DVWA (Damn Vulnerable Web App)
3. Basic knowledge of SQL
4. BurpSuite Community Edition

DVWA: Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. however, Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment. also, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.

Performing CSRF Attack on DVWA:

LEVEL = LOW

1) firstly, Open DVWA on local host and set the module difficulty level to low.

2) Now open CSRF module and change the password once to capture , test and understand the request layout.

3) Now make a phishing page which will thus redirect to the URL, that DVWA CSRF module uses to change password.

The phishing page looks pretty authentic at first. But look at the code below :

Now compare it with DVWA’s change password source code :

Looking at both the codes , we observer that in phishing page , we have diverted the request to the change password module of the DVWA page.

Also comparing id’s, we note that in the phishing page, we have kept the id of password fields the same.

This will trick the backend database to process data and hit the query from the data we are sending from the phishing page and not from authentic DVWA page.

As the id’s of the password fields match , database will be triggered and process the backend query , which will ultimately change the password for what the user has entered in the phishing page.

One can easily collect logs from this and now can get access to authentic site via the changed password!!

Below is a demo of the same.

4) Opening the phishing page.

5) Filling up the details.

I have filled up the data as a normal user would , when promised a free giveaway upon credential updation. This phishing page basically tries to trick the user , to change/update the credentials of a website in which the user has account in , example gmail/facebook/Instagram and then promising them a free entry in name of CYBERSECURITY AWARENESS. The user would enter the details and the credentials would get update to the original site. But the hacker now knows the credentials by Hacking Web Applications and user’s security gets compromise.

6) When the user clicks submit , we get the request in burp.

Captured incoming request in BURP :

Passwords changed!!

XSS (DOM based):

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval() or innerHTML. This enables attackers to execute malicious JavaScript, which typically allows them to hijack other users’ accounts.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes execution of arbitrary JavaScript.

The most common source for DOM XSS is the URL, which is typically accessed with the window.location object. An attacker can construct a link to send a victim to a vulnerable page with a payload in the query string and fragment portions of the URL. In certain circumstances, such as when targeting a 404 page or a website running PHP, the payload can also be placed in the path.

DOM-Based XSS Vulnerabilities

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval() or innerHTML. This enables attackers to execute malicious JavaScript, which typically allows them to hijack other users’ accounts.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes execution of arbitrary JavaScript.

The most common source for DOM XSS is the URL, which is typically accessed with the window.location object. An attacker can construct a link to send a victim to a vulnerable page with a payload in the query string and fragment portions of the URL. In certain circumstances, such as when targeting a 404 page or a website running PHP, the payload can also be placed in the path.

Performing DOM based XSS on DSWA :

Inspecting the password element and running basic javascript alert(1) function :

Now viewing domain of the webpage on which it is hosted currently :

Now viewing the current cookie :

Writing on the current page :

Viewing the full URI of the webpage using DOM XSS :

We have to cover two most uncovered attacks that web apps are most vulnerable on.

Web-apps are mostly vulnerable to data parsed via the input fields, and most of the cheat sheets advise new programmers to keep the input fields sanitized to prevent the attacks.

written by: Priyansh Gupta

Reviewed By: Sayan Chatterjee

If you are Interested In Machine Learning You Can Check Machine Learning Internship Program
Also Check Other Technical And Non Technical Internship Programs