Day 3/100 Hack and Improvement

4 minute read

Day 3 of 100daysofhackandimprove comes handy wirh Cross Site Request Forgery (CSRF) vulnerabilitis, and different ways to exploit it. Whil still reading chapter by chapter Real-World Bug Hunting, I cannot deny that the book provides a pretty good explanation for this kind of vulnerability. Also, in this post there will be an explanation related to Server Side Request Forgery (SSRF) where attackers can escalate this vulnearbility and attempts further attacks.

Cross Site Request Forgery (CSRF)

From Sam (CoffeeJunkie), Cross Site Request Forgery (CSRF) occurs when an attacker can make a target’s browser send an HTTP request to another website. The attack relies on the target being previously authenticated on the vulnerable website. Then, the action is submitted and occurs without the target’s knowledge. If the attack is successful, the attacker is able to modify server side information and it is even possible to achieve account take over. In order to understand this vulnerability, there must be some understanding about authentication.


CSRF attack usually take advantage of weakness in the process websites use to authenticate requests. Usually in different kind of websites it requires username and password to authenticate you. The site will store the authentication in the browser. It can be stored in the following ways:

  • Using an authentication protocol Usually with basic authorization happens when HTTP requests include a header similar to this.
    Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

    In this case, the basic authorization is base64 encoded.

  • Cookies

Cookies are small files that websites create and store in the user’s browser. Cookies have certain attributes that which are standardized pieces of information which its details tell browsers about the cookies and how to threat them. Cookies has different kind of uses, from which kind of settings the user has set in the site, to which domains the site is communicating to. There are certain cookies which can interact with HTTP and HTTPS, this depends the flag that has been set in the cookie.

CSRF with GET Requests

Taking as an example the usage of the HTML <img> tag will be useful to set this attack. Let’s say that the attacker wants to make a money transfer from the victim’s banking site. The attacker doesn’t know the victim’s cookies. In this case the HTML <img> comes pretty handy because the attacker can add the src attribute which will do the HTTP request. When the attacker uses src as the victim’s banking site, it will come with the victim’s cookies. A “normal” banking transfer in the victim’s site will look like this.

Then the malicious <img> tag would use this URL as its source value, as in the following tag:

<img src="">

Once the victim clicks in the attacker’s site. It will make a money transfer from the victim’s account to the attacker’s account.

CSRF with POST Requests

Following the same example from the bank, let’s say that the bank is using post requests to make a money transfer, therefore, the approach for the CSRF attack will be different. As the attacker cannot use the img tag, the attack will depend of the content of the POST request. Then, the content of the POST request would look something like this.

<iframe style="display:none" name="csrf-frame"></iframe>
<form method='POST' action='' target="csrf-frame"
<input type='hidden' name='from' value='Victim'>
     <input type='hidden' name='to' value='Attacker'>
     <input type='hidden' name='amount' value='500'>
     <input type='submit' value='submit'>

With the HTML code from above, the attacker is making a money transfer through a post request. As the attacker doesn’t want the victim to know the content of the request, the attacker use input type='hidden' which won’t be visible for the victim. As the final step, the attacker includes some JavaScript inside a <script> tag to automatically submit the form when the page is loaded. To note, POST requests in different cases might use different kind of content-type like in some cases might be json. Also, to make the attack successful, the attacker most be aware of the usage of csrf tokens which sometimes includes in the content of the POST request, or it can depends on the usage. This token is used in order to make the website understand that the content comes from the same site. There are some set of rules that define how websites an read the responses from each other, this is called cross origin resource sharing (CORS). If you want to know if the CSRF token has been well implemented, you can change the value, or delete it. In some cases CORS protections can be fooled by changing the content-type header to application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Write Ups and Explanations

Shopify Disconnect Twitter

The attacker could disconnect the account of the victim with the following PoC.

 <img src="">

When looking for CSRF vulnerabilities, look for GET request that can modify server-side data

Change Users Instacart zones

The attacker was able to change the zip code of any victim with a POST request, this is the PoC.

    <form action="" method="POST">
      <input type="hidden" name="zip" value="10001" />
      <input type="hidden" name="override" value="true" />
      <input type="submit" value="Submit request" />

Remember website API’s endpoints and its web pages.

Badoo Full Account take Over

So the attacker can add an account take over to any account with the following URL.<State_param_value>&code=<Code_returned_from_google>

The only protection that exists here is the rt parameter. The attacker found a way to bypass this finding the rt parameter with the following URLs
var url_stats = '<rt_param_value>';

Therefore, this is the PoC that allows the account take over bypassing the CSRF protection.

<title>Badoo account take over</title>
<script src=></script>
function getCSRFcode(str) {
    return str.split('=')[2];
window.onload = function(){
var csrf_code = getCSRFcode(url_stats);
csrf_url = ''+ csrf_code;
window.location = csrf_url;

Server Side Request Forgery

From Rajesh Ranjan, Server Side Request Forgery (SSRF) vulnerabilities let an attacker send crafted requests from the back-end server of a vulnerable web application. Criminals usually use SSRF attacks to target internal systems that are behind firewalls and are not accessible from the external network.

What an attacker achive with SSRF

SSRF to Reflected XSS So in this scenario, we can simply upload XSS payload on our server or we can use the brutelogic payload which is:

Lets suppose that, the vulnerable website is, then paste the payload link here, which will look like:

Write Ups

SSRF to Reflested XSS in Jira

So in this writeup, the researcher found that, the website was running the old version of Jira which was vulnerable to SSRF

Labs and Videos

Portswigger Labs for SSRF

Also nahamsec solved these all labs in one of his stream, click here to see the stream.


CSRF and SSRF vulnerabilities can be used for different kind of attacks that might cause an impact on the company, depending the skills of the attacker.

Leave a comment