Practical Reflected XSS Example using Burp Suite - Revision history

NKirnbauer: gendering

2024-10-03T07:08:26Z

gendering

← Older revision		Revision as of 07:08, 3 October 2024
Line 36:		Line 36:
	**[[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 their 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.
Line 43:		Line 43:
	* 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]]


	== References ==		== References ==

NKirnbauer: fixed link

2024-09-25T10:43:01Z

fixed link

← Older revision		Revision as of 10:43, 25 September 2024
Line 11:		Line 11:
	* [https://portswigger.net/burp/communitydownload Burp Suite]		* [https://portswigger.net/burp/communitydownload Burp Suite]
	* In this example Firefox is used as web browser, but any browser that is compatible with Burp Suite can be used		* In this example Firefox is used as web browser, but any browser that is compatible with Burp Suite can be used
	* [https://sourceforge.net/projects/owaspbwa/~~ﬁles~~/ OWASP Broken Web Application Project]		* [https://sourceforge.net/projects/owaspbwa/files/ OWASP Broken Web Application Project]

	== Description ==		== Description ==

FVarli at 15:50, 21 November 2021

2021-11-21T15:50:51Z

← Older revision		Revision as of 15:50, 21 November 2021
Line 1:		Line 1:
	== Summary ==		== Summary ==

	~~In this~~ practical guide ~~it is shown~~ how to generate a proof-of-concept reflected XSS exploit using burp suite.		This practical guide shows how to generate a proof-of-concept reflected XSS exploit using burp suite.

	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 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 [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].		A more detailed explaination can be found [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].

FVarli at 15:50, 21 November 2021

2021-11-21T15:50:24Z

← Older revision		Revision as of 15:50, 21 November 2021
Line 1:		Line 1:
	== Summary ==		== Summary ==

	A practical guide ~~using burp suite and Firefox browser:~~ how to generate a proof-of-concept reflected XSS exploit.		In this practical guide it is shown how to generate a proof-of-concept reflected XSS exploit using burp suite.
	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 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 [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].		A more detailed explaination can be found [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].

FVarli at 15:49, 21 November 2021

2021-11-21T15:49:05Z

← Older revision		Revision as of 15:49, 21 November 2021
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]]

FVarli at 15:48, 21 November 2021

2021-11-21T15:48:08Z

← Older revision		Revision as of 15:48, 21 November 2021
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]]
	* 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]]
	* 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]]
	* 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]]
	* Click "Go"		* Click "Go"
	* The user can assess whether the attack payload appears unmodified in ~~the~~ 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]]
	* 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]]
	* 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]]

FVarli: Created page with "== 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 passi..."

2021-11-21T15:38:33Z

Created page with "== 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 passi..."

New page

== 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 [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].

== Requirements ==

* [https://portswigger.net/burp/communitydownload Burp Suite]
* In this example Firefox is used as web browser, but any browser that is compatible with Burp Suite can be used
* [https://sourceforge.net/projects/owaspbwa/ﬁles/ OWASP Broken Web Application Project]

== 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 [https://portswigger.net/burp/documentation/desktop/external-browser-config 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”
* Enter some appropriate input in to the web app and submit the request
* 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”.
* 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.
* Click "Go"
* The user can assess whether the attack payload appears unmodified in the response. In our case it is, which means the application is almost certainly vulnerable to XSS.
* Right click on the response and click “Show response in browser” to copy the URL.
* 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.

== References ==

* https://portswigger.net/burp/communitydownload
* https://sourceforge.net/projects/owaspbwa/
* https://portswigger.net/burp/documentation/desktop/external-browser-config
* https://portswigger.net/support/using-burp-to-manually-test-for-reflected-xss

[[Category:Documentation]]