DOM Based Cross Site Scripting (XSS) Vulnerability
DOM based cross site scripting (XSS) is similar to both reflected and stored XSS. That is, they can be discovered and exploited similarly. The main difference is simply that DOM based XSS attacks occur entirely on the client side, meaning the payload is never sent to the server. The benefit to these types of attacks is that there are no logs, filters, and there is no server side protection to prevent them.
According to OWASP, DOM based XSS "is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment" (https://www.owasp.org/index.php/DOM_Based_XSS).
For this lab, the only tool used was a simple web browser and a free application used specifically for DOM based XSS practice (https://xss-doc.appspot.com/demo/3#1). The JavaScript running on this application never actually sends any code to a server as the images are already loaded on the page itself.
To begin, navigate to the site.
According to OWASP, DOM based XSS "is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment" (https://www.owasp.org/index.php/DOM_Based_XSS).
For this lab, the only tool used was a simple web browser and a free application used specifically for DOM based XSS practice (https://xss-doc.appspot.com/demo/3#1). The JavaScript running on this application never actually sends any code to a server as the images are already loaded on the page itself.
To begin, navigate to the site.
Right click on the image and inspect the code. The inspect tool should be open while you click on each image to see how the JavaScipt is actually responsible for loading the images.
To start, I tried to manipulate the URL by simply adding my name.
The site is looking for adam.jpg - a file that does not exist. What I did here was simply add a single quote at the end of adam.jpg and used the onerror method found on the OWASP cheat cheat. I appended this entire script to the end of the URL.
Once the URL was crafted, I simply refreshed the page, and voilà!
Comments
Post a Comment