View source for CSRF: Practical example using Burp Suite and portswigger.net

== Summary == 

This article describes how the Labs of portswigger.net can be used to show how a CSRF attack is done. In contrary to other articles these labs don't need further installation of software except of the Burp Suite Tool. By using the labs on portswigger.net also different difficulties can be tried and therefore the usage of different defence methods against CSRF can be experienced practically.
By showing how the first lab can be solved this article also describes how the reconnaissance of a web application in order to find CSRF Vulnerabilities can be done.

== Requirements ==
* Software: Burp Suite Community Edition/ Professional

In order to run Burp Suite you need to fullfill the following requirements:

* CPU Cores/Memory:
** Minimum: 2x cores, 4GB RAM - This spec is suitable for basic tasks such as proxying web traffic and simple Intruder attacks. While Burp Suite may run on a machine with a lower specification than this, we do not recommend doing so for performance reasons.
** Recommended: 2x cores, 16GB RAM - This is a good general-purpose spec. 
** Advanced: 4x cores, 32GB RAM - This spec is suitable for more intensive tasks, such as complex Intruder attacks or large automated scans.

* Free Disk Space:
** Basic installation: 1GB
** Per project file: 2GB

* Operating system: 
** Windows (Intel 64-bit)
** Linux (Intel and ARM 64-bit)
** OS X (Intel 64-bit and Apple M1)


In order to install Burp Suite, you find a guide on their webpage [https://portswigger.net/burp/documentation/desktop/getting-started/download-and-install Installation of Burp Suite].
The following link [https://portswigger.net/burp/documentation/desktop/getting-started Getting Started] provides in general useful information about Burp Suite, How to use it and Tutorials.

== How to get to the labs ==

=== Login ===

The labs can be accessed after the user is logged in. Therefore a account must be made which can be done [https://portswigger.net/users here]. 
After the user created an account and is logged in the labs ob portswigger.net are accessible. 


[[File:Account_Creation.png | 600px]]

=== Find the lab ===

As the lab portion of portswigger.net is very high it is quite a task to find the right labs. As this article is about CSRF we are looking for th labs related to this topic. To avoid a long time searching them you can find them [https://portswigger.net/web-security/all-labs#cross-site-request-forgery-csrf here]. This page provides a listing of all available labs but is already focused on the CSRF part.


[[File:list_of_labs.png | 600px]]

== How the labs work ==

=== General Overview ===
As visible in the picture below the labs are basically structured in the same way. On top you find the name of the lab and just below is the description. 
There are three drop-down menus:
* Hint: The hint provides some additional information how the lab can be solved
* Solution: portswigger.net provides a text based solution of the lab.
* Community Solutions: Here are additional solutions crafted by the community listed.

To start the lab just click on the orange "Access the lab" button.


[[File:general_lab_screen.png | 600px]] 

=== The lab itself ===

After clicking the "Access the lab" button it takes some time for the lab to set up. 
As soon as the lab is set up you start on the page of a blog. As visible in the picture below you have several options what to do. On top of the page is the orange "Go to exploit server" button. With this button you switch to the (imaginary) exploit server of the attacker. The "Go back to lab description" button leads you back to the previous page. On the left site is a typical "Home" button which will lead you to the site you are actually. 


[[File:firstPage.png | 600px]] 


Beside the "Home" Button is the Login Button "My account". If you click here you will be sent to the login page where you can use the credentials provided in the lab instruction. In our case this is the user "wiener" with the password "peter". As visible this should represent a common web application. After logging in you have the possibility to change the email address.  


[[File:AccountPage.png | 600px]] 


If you click the "Go to exploit server" you change to the imaginary server of the attacker where the malicious web page with the CSRF exploit is running. For the labs that are discussed in this article mainly the body part is important as we will implement our malicious code here. 
At the bottom are Several Buttons:
* Store: With this button the code we enter above is saved.
* View Exploit: Here you can see how the exploit is working.
* Deliver Exploit to victim: With this button a delivery of the malicious link to the victim is simulated. If the exploit works with a script the interaction of the victim is also simulated.
* Access Log: As the name says here you can see who accessed the exploit server. 


[[File:ExploitServer.png | 600px]] 


== Burp Suite ==

After you started the lab you want to work out the next step is to start Burp Suite. This section will provide the most important information how to work with Burp Suite during the CSRF labs.
While in the Screenshots a professional Version of Burp Suite is shown, this guide provides the information how to work with the Community Edition. 

=== Configurations at the start ===

The first window of Burp Suite asks what kind of project you want to start. With the Community Edition only temporary projects are possible.


[[file:burpStart.png | 600px]]


Also the choices of the next page are limited to the use of Burp Default.


[[file:burpStart2.png | 600px]]


=== Burp Suite itself ===

After clicking on "Start Burp" in the previous Window Burp Suite will start. As the Software provides a huge pile of possibilities this article will only focus on the relevant parts which are needed for the following labs. If you want to lern more about Burp Suite and all of its ways to work with it you can find a good tutorial section [https://portswigger.net/burp/documentation/desktop/testing-workflow here]. Also this article will use the integrated Web Browser of Burp Suite therefore no configuration of proxy's are going to be done. If you want to use your normal Web browser while accessing the labs you can find an artcle with all the information needed [https://wiki.elvis.science/index.php?title=Practical_CSRF_example_using_Burp_Suite here].

Burp Suite always starts with the Dashboard. But as highlighted in the picture the to menu points "Proxy" and "Repeater" are those which we will use mainly.


[[file: burpTopMenu.png | 600 px]]


The proxy handles the incoming and outgoing traffic. With the menu point "Intercept you can decide wether Burp Suite will intercept the traffic. if you do so you can not only see what going on, you are also able to change the traffic before it is send to its endpoint. By clicking on the orange hoighlighted "Intercept is off" respective "Intercept is on" you can decide if you like to intercept the traffic. The traffic is only intercepted if you either set Burp Suite as your proxy (How to do this is mentioned above) or with the web brwoser of Burp Suite. To launch this Browser a simple click on the yellow highlighted "Open Browser" is needed. The green highlighted "HTTP history" leads to the HTTP history menu where all the captured traffic can be found.


[[file: burpProxy.png | 600px]]


When the intercept is set to on you intercept the whole traffic. If you want to safe a specific request or if you want to repeat it later the captured request can be send and if needed modified in the repeater.
You do this by right clicking into the intercepted request and then choosing "Send to Repeater".


[[file: sendRepeater.png | 600px]]


Now you can find the send request within the repeater. There you can modify it and send again to see the reaction of the endpoint. You can resend the request by clicking on the orange "Send" button on the left. Afterwards you will immediately get the response of the endpoint in the "Response" field of the Repeater and examine the information you need.


[[file: Repeater.png | 1000px]]



== Lab 1: CSRF with no defenses ==

=== Catch the traffic ===
The first Lab of portswigger.net shows the simple case if a web application has no defence mechanisms against CSRF. 
This guide shows how the CSRF Lab can be solved. Burp Suite is already running and the Browser of Burp Suite is in use to catch the traffic.

After starting the lab and logging into the provided account as described in Chapter 4 you can change the email of the account by using the form provided in the web application.


[[file: ChangeMail.png]]


But before you hit the "Update EMail" Button set the Intercept of the proxy in Burp Suite to on.
As wanted the traffic got intercepted by Burp Suite. Now you can send this request by right clicking on it to the Repeater. Afterwards you can set the intercept to off to allow the traffic to pass. 


[[file: Lab1catch.png]]


On the web application you can see that the email was changed.


[[file: Lab1ChangedMail.png]]


=== Gather information about the Web Application ===

The next step is to examine the cought request. For a CSRF attack we need to ensure that the web application is a valuable target. 
To examine this there are three key point so ensure that the Web application is a possible target for CSRF: 
* A relevant action
* Cookie-based session handling
* No unpredictable request parameters

Now lets check if the web application fulfills these key points.
As we can see in the picture of the request the web application does use cookie-based session handling (highlighted in green).
Also a relevant action can be performed as we can see that we can change the email (highlighted in yellow).
And last but not least there are no unpredictable request parameters (highlighted in orange). This request just looks for an email address which is easily predictable.


[[file: Lab1Request.png]]


=== Prepare the attack ===

With this information we now know that the web application is highly vulnerable to an CSRF attack. The professional Edition of Burp Suite has a PoC (Proof of Concept) Generator for CSRF integrated which could automatically generate the code we would need to attack the web application with CSRF. But as already stated this article describes a possible solution with the community edition so the next step is that we now need to generate the code we would need to attack the web page. In this article Visual Studio is used to do so but you can use every html-editor you prefer. There we need to write the following code:

  <html>
      <body>
          < h1>Hello World!< /h1>
          <iframe style="display:none" name="csrf-iframe"></iframe>
          <form action="https://0aed003f048f68e58139890200bd0094.web-security-academy.net/my-account/change-email" method="post" target="csrf-iframe" id="csrf-form">
              <input type= "hidden" name="email" value="haha@test.ca">
          </form>
          <script>document.getElementById("csrf-form").submit()</script>
      </body>
  </html>

The < h1> is a simple example of what the user would see when opening the web page.
The <iframe> attribute is used to hide the form underneath. 
The <form> contains the url of where the attacker wants to send the request. It is formed out of the two green highlighted information you can see in the picture below. The first part of the url is the Origin and the second part is the target of the request. In the <form> also the method is set to PUT as we can see it yellow highlighted in the original request. 
The <input> again contains the type hidden because the attacker does not want the user to see what is happening. It also contains the name and the value field. These two information where gathered in the orange highlighted section of the picture.
The last part of the malicious code is the <script>. Here the form is called and with .submit() it is automatically submitted. Without this part the user would have to click a button to ensure that the CSRF attack is started.

=== Launch the attack ===
<b>ATTENTION!</b>: As writting the code takes some time it is possible that your lab was closed in the Background. If you refresh the page and get the Error message as in the picture below thats what happened. This is not a big deal you just have to restart the whole lab. But you have to look for a detail. As the lab was restarted the url also changed so you will need to adapt the url in the code to the new one, which can be done by simply copying the url from the webbrowser.


[[file: BurpErrror.png]]


To launch the attack there are two ways to do it. The first way is to change to the exploit server, add the malicious code and start the attack. 
The second one is by launching a simple webserver (for example as it will be used in this article with python) and open the url of the launched webserver.

==== Using the Exploit Server ====

As already mentioned if you use the provided exploit server just switch to the server by clicking "Go to exploit server". Afterwards the page as shown in picture opens. Here you just have to copy the code written before in the body element. Then you click on the button "Store" for storing the code on the server and afterwards "Deliver exploit to victim". If your code is working you will receive the message "Congratulations, you solved the Lab!" on top of the page.  


[[file: FirstWay.png]]


==== Using a simple Webserver ====

As we are already in Visual Studio Code the most simple way to start our Webserver is by using the in-built terminal and the webserver capabilities offered by python3.
To launch the attack first open a new terminal and change the directory to the one where the html file is saved.
Afterwards with the command:
 python -m http.server 5555
a simple http webserver on the port 5555 is established.


[[file: StartWebserver.png | 800px]]


Now you just need to open a new browser window and open localhost:5555. This will lead the user to the set up Webserver and the exploit is going to be executed. You can test this when checking the email afterwards if it was changed.

* <b> First Step: </b> Open a new window in the web brwoser and get to localhost:


[[file: LocalhostURL.png]]


* <b> Second Step: </b> See the page delivered


[[file: LocalhostWebpage.png]]


* <b> Third Step: </b> Refresh the "My Account" Page and confirm the Email was changed

[[file: LocalhostChangedEmail.png]]

== Conclusion ==
With this step-by-step guide, it should be relatively easy for anyone to navigate and carry out the provided labs. Due to the variety of labs offered by [https://portswigger.net/web-security/all-labs#cross-site-request-forgery-csrf PortSwigger], one can excellently observe and test different implementations of protection mechanisms against CSRF.

== References ==
General reference for the Labs and BurpSuite:

* [https://portswigger.net PortSwigger]

References provided by ELVIS:

* [https://wiki.elvis.science/index.php?title=Practical_CSRF_example_using_Burp_Suite Another practical example]: The difference between the example provided here and the one of the link is the usage of another tools for the implemantation of the vulnerable web service.

* [https://wiki.elvis.science/index.php?title=Cross-Site-Request_Forgery_(CSRF) Theory of CSRF]: The theoretical background of CSRF can be found here.

[[Category:Documentation]]