XSS Payloads
XSS can deliver multiple types of payloads. Javascript is powerful and flexible and therefore is capable of delivering a wide range of malicious payloads. Some of the payloads include;
1. Pop up alerts
2. Hijacking session identifiers
3. Downloading and installing software
4. Redirecting to a different URL
5. Installing a keylogger
4. Invoking a reverse shell such as the Metasploit meterpreter
5. Launching client side attacks
Types of XSS
XSS is often divided into at least two types;
1. Reflective or Non Persistent
2. Persistent or Stored
Reflective XSS usually involves code that is "reflected" back to the web page and does not persist after one use. Persistent or Stored XSS, as the name implies, is stored within the application and can be run multiple times by multiple users.
In this tutorial, we will be using the DVWA to demonstrate these attacks and vulnerabilities.
Step #1 Connect to the DVWA
To start, boot up a system running DVWA. I'm using Metasploitable, but you can use any system with DVWA installed. Then, connect to the DVWA with your browser from your Kali system.
Step #2 Set Security to Low
In this tutorial, we will be using some simple XSS that is usually sanitized by modern secure web applications. For demonstration purposes we are disabling that sanitizing process. For that reason, we need to set the security level on our DVWA to "low".
Step #3 Reflected XSS Attacks
To perform a Reflected XSS, the victim must perform some action such as clicking on a link, doing a search or some other functionality. The victim must also be logged into the application when they click on the link.
To start, navigate to the Reflected XSS page in DVWA as seen below.
Now, go ahead and enter your name. I entered my name in the form "Occupytheweb".
As you can see above, the application comes back and greets me "Hello Occupytheweb" after hitting Submit.
This time we will enter some script and see whether we can get the application to execute it. The script to enter is;
<script>alert("Hello Hackers-Arise ") </script)
A cursory examination of this script reveals that we are triggering an alert box and having the alert box say "Hello Hackers Arise"
So, instead of entering our name into the form, let's enter this script.
Now, hit Submit.
As you can see, the script was executed and an alert box was triggered with the message "Hello Hackers-Arise". Clearly, this application is vulnerable to a Reflected XSS attack!
Reflected XSS is a one-time attack. Whoever clicks on the link will have the script executed in their browser.
Step #4 URL Address Bar Attack
When we ran the Reflected XSS, you can see that the URL created by the attack changed. We could use this URL that was created to execute the attack. The attacker could send this link to the victim to execute the attack. To demonstrate, simply copy and paste the URL and enter it into another tab in your browser.
As you can see, it works equally well to trigger the Reflected XSS attack.
Step #5 Attacking Session Cookies
Although generating a pop-up alert box is interesting and proves the concept, it really does not provide the attacker anything of value. What if we could have the alert box grab the session cookie of the victim? In this way, the attacker could then use the cookie to authenticate against the app as the legitimate user.
In this case, we will create a script that generates an alert, grabs the session cookie and displays it.
The following script should do just that.
<script>alert(document.cookie)</script>
As you can see, when we run this script, the application grabs and displays the users session ID that then could be used to authenticate the attacker to the application!
Step #6 Persistent or Stored XSS Attacks
The persistent or stored XSS is very different from the Reflected XSS attack. Most importantly, the attacker does not need to social engineer the victim to click on a URL, but rather stores the malicious code into the application. In this way, every one who visits the malicious web page will fall victim to this attack.
Persistent XSS attacks are far more malicious and damaging than reflected attacks. They are capable of attacking numerous victims and implanting malware or other payloads into the target system.
Let's start by clicking on the DVWA Stored Cross Site Scripting app.
This app represents a "Guest Book" of a web app where each user can enter their name and comments. Obviously, a Guest Book will store the information entered into a back-end database (MySQL in this case). If we can send a script to that back-end database, our script will be stored there and run time and time again as people visit and use the Guest book.
Let's begin by entering our name, OTW. Then let's enter a bit of Javascript.
<script>alert("Hackers-Arise is BEST")</script>
If this script runs, it will open an alert box stating the obvious "Hackers-Arise is BEST".
When we click "Sign Guestbook", an alert box opens stating what we all know to be true.
As the application stores this information into the back-end database, we may be able to get that script to run whenever anyone logs into the Guestbook.
Let's test that by entering as a different Guest and enter a different message. In this case, I will enter as "John Doe" and leave a message "I'm so happy to be here".
When John Doe clicks to "Sign Guestbook" they get the same message that "Hackers-Arise is BEST". Our XSS has persisted in the database and every guest will now be greeted with our message!
Cross Site Scripting (XSS) is one of the most important and malicious vulnerabilities in web applications. These attacks are capable of injecting any number of malicious payloads into the victim's browser and ultimately into their computer system.
Sinhalen danna baida
ReplyDeleteMewa kohomada sinhalen danne.no way.
Delete