Difference between revisions of "Practical Reflected XSS Example using Burp Suite"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
Line 27: Line 27:
* Visit the page of the website you want to test for reflected XSS vulnerability. In this example we used the “DNS lookup” page.
* Visit the page of the website you want to test for reflected XSS vulnerability. In this example we used the “DNS lookup” page.
* Return to Burp and switch the turn “Intercept is off” to “Intercept is on”
* Return to Burp and switch the turn “Intercept is off” to “Intercept is on”
[[File:Intercepton.PNG]]
**[[File:Intercepton.PNG]]
* Enter some appropriate input in to the web app and submit the request
* Enter some appropriate input in to the web app and submit the request
[[File:Testcom.PNG]]
**[[File:Testcom.PNG]]
* You should see that the web page is “stuck”. This is because we turned on the interception In Burp suite. The HTTP request is now captured by Burp, which can be viewed in the Proxy “Intercept” tab. Right click on the request and click “Send to Repeater”.
* You should see that the web page is “stuck”. This is because we turned on the interception In Burp suite. The HTTP request is now captured by Burp, which can be viewed in the Proxy “Intercept” tab. Right click on the request and click “Send to Repeater”.
[[File:Requestinburp.PNG]]
**[[File:Requestinburp.PNG]]
* Go to the “Repeater” tab. Here you can input various XSS payloads in the input field. We edit the “value” of the parameter. In this example we use a payload, that tries to perform a pop up in our browser.
* Go to the “Repeater” tab. Here you can input various XSS payloads in the input field. We edit the “value” of the parameter. In this example we use a payload, that tries to perform a pop up in our browser.
[[File:Alert(1).PNG]]
**[[File:Alert(1).PNG]]
* Click "Go"
* Click "Go"
* The user can assess whether the attack payload appears unmodified in his response. In our case it is, which means the application is almost certainly vulnerable to XSS.
* The user can assess whether the attack payload appears unmodified in his response. In our case it is, which means the application is almost certainly vulnerable to XSS.
[[File:Alertzeile.PNG]]
**[[File:Alertzeile.PNG]]
* Right click on the response and click “Show response in browser” to copy the URL.
* Right click on the response and click “Show response in browser” to copy the URL.
[[File:Show_response_in_browser.PNG]]
**[[File:Show_response_in_browser.PNG]]
* In the window, that popped up, click “Copy” and paste it into your browser's address bar.
* In the window, that popped up, click “Copy” and paste it into your browser's address bar.
* You are now  able to produce a proof of concept for this vulnerability.
* You are now  able to produce a proof of concept for this vulnerability.
[[File:Resultvonxssvulnerability.PNG]]
**[[File:Resultvonxssvulnerability.PNG]]





Revision as of 15:49, 21 November 2021

Summary

A practical guide using burp suite and Firefox browser: how to generate a proof-of-concept reflected XSS exploit. A Reflected XSS vulnerability is when a passing parameter in an HTTP request of a web application is re-integrated unfiltered into the response HTML page. If an attacker were to insert HTML or JavaScript code, for example, into the transfer parameter, this would be included in the response page and executed. A more detailed explaination can be found here.

Requirements

Description

Setup

First the user needs to download Burp Suite.

Next, the user needs to download OWASP’s Broken Web Application Project to follow this tutorial. The example uses a version of "Mutillidae II" taken from OWASP's Broken Web Application Project. As this Web Application has a lot of vulnerabilities, it should only be started using VMNets with "host only” due to security reasons.

To run and configure Burp Suite, the author recommends to follow Burp Suites Browser Configuration Tutorial, since its very precise and easy to follow. It is also advised to install and import Burp Suites Certificate, since the user won’t be able to use Websites that use HTTPs as Protocol. The tutorial can be found here.

Tutorial

Steps:

  • Visit the page of the website you want to test for reflected XSS vulnerability. In this example we used the “DNS lookup” page.
  • Return to Burp and switch the turn “Intercept is off” to “Intercept is on”
    • Intercepton.PNG
  • Enter some appropriate input in to the web app and submit the request
    • Testcom.PNG
  • You should see that the web page is “stuck”. This is because we turned on the interception In Burp suite. The HTTP request is now captured by Burp, which can be viewed in the Proxy “Intercept” tab. Right click on the request and click “Send to Repeater”.
    • Requestinburp.PNG
  • Go to the “Repeater” tab. Here you can input various XSS payloads in the input field. We edit the “value” of the parameter. In this example we use a payload, that tries to perform a pop up in our browser.
    • Alert(1).PNG
  • Click "Go"
  • The user can assess whether the attack payload appears unmodified in his response. In our case it is, which means the application is almost certainly vulnerable to XSS.
    • Alertzeile.PNG
  • Right click on the response and click “Show response in browser” to copy the URL.
    • Show response in browser.PNG
  • In the window, that popped up, click “Copy” and paste it into your browser's address bar.
  • You are now able to produce a proof of concept for this vulnerability.
    • Resultvonxssvulnerability.PNG


References