Home > attacks > Are CSRF Attacks Really Blind

Are CSRF Attacks Really Blind

May 14Hits:1

I'm new to CSRF attacks but don't see how they are always blind.

Let's say we are dealing with a site where the asset we need to protect is the HTTP response. Something like one's medical history. According to what I've read one shouldn't need to protect GET requests even though the response to these requests may contain sensitive information.

What prevents an attacker from making a CSRF Ajax request and then sending the response from that request as a POST or GET to another server?


The Same-Origin Policy makes it impossible for JavaScript on A.com to read content from B.com. However, Same-Origin Policy does not prevent JavaScript or HTML on A.com from sending an arbitrary request to B.com. In order to prevent this, you need a method of CSRF Prevention, such as a secret token which would not work if the system wasn't blind.

The point of CSRF is that it incurs a useful side-effect, like changing a user's password or adding an administrative account. Even if CSRF wasn't blind, (due to some magic, or perhaps a misconfigured CORS or crossdomain.xml rule-set) it wouldn't matter as the response would probably be discarded, all that matters is a useful side-effect.

It is very easy to send GET and POST requests cross-domain, if a GET request incurs a side-effect, then it is vulnerable to CSRF. A good example of this is a PHP application that uses $_REQUEST for all inputs.

Yes, they are blind. The same-origin policy prevents pages hosted in one domain using one protocol [and sometimes also port] to making arbitrary requests to a different domain/protocol. So, one attacker would not be able to make a "CSRF Ajax request" unless your server supports CORS. What makes CSRF attacks possible at all are the exceptions for the same-origin policy, i.e. the types of request any website is allowed to make to any host.

Most exceptions to the same-origin policy however does not allow you to do anything useful (including read) with the response:

  • You can set an image's src to another domain, but the response will either render correctly as an image for the user to see, or render nothing at all;
  • You can set a script's src to another domain, but it will either run or cause a syntax error or similar;
  • You can link to an external stylesheet, but can't programatically access its contents;
  • You can include another page in a frame ou iframe, but can't access its DOM contents due to the same-origin policy; etc.

That's why, as others already pointed out, the response is not what's interesting for an attacker, but the side-effects the request can have.

First of all, CSRF attacks do not require any JavaScript at all. You can forge arbitrary requests with pure HTML to send arbitrary GET or POST requests via simple images or simple forms.

JavaScript would only be helpful to automatically send the latter forms as are not send automatically like a request for an image would. But you could also style the form’s submit button to span the whole page and make it transparent so that it won’t be seen by the user but if he clicks somewhere on the page, the form will be send.

In most cases, sending the forged request is sufficient for the attacker as the intention is to simply trigger an action in behalf and session context of the victim. For this a simple HTML form is sufficient.

But with JavaScript, the Same-Origin Policy comes in play, which makes it much more difficult. The origin is determined on the document’s URI (i.e., the scheme, host, and port). Only if the origin of two documents or resources are identical, the two documents/resources are same-origin. If they are not same-origin, the Same-Origin Policy basically disallows any XHR requests or direct access via DOM (e.g. frames).

With the second version of XMLHttpRequest (XHR), the technology used with Ajax, cross-origin requests were permitted under certain circumstances defined in Cross-Origin Resource Sharing. The basic rules are that simple cross-origin requests are allowed while other require a preflight request before the actual request. That preflight is used to determine whether the server would accept the actual request. Only if that preflight request succeeds, the actual request is send.

However, even if it’s only a simple request and the request succeeds, the server may still disallow the browser to make the response available to JavaScript, again via certain response header fields defined in CORS.

As for CSRF attacks, especially the latter type of cross-origin requests are worthy as those would contain user credentials like HTTP authentication information, cookies, etc., which would be required to trigger privileged actions on the server. But unless the resource allows such cross-origin requests, the browser won’t allow JavaScript to send these.

So the conclusion is:

  • CSRF does not require JavaScript, however it makes automatic exploitation much easier.
  • Simple HTML based request forgery is much more promising due to the lack of conformance with the Same-Origin Policy, which JavaScript requires.
  • Reading the response is only possible with JavaScript but it requires the resource to allow it, especially if user credentials are required.

Related Articles

  • Are CSRF Attacks Really BlindMay 14

    I'm new to CSRF attacks but don't see how they are always blind. Let's say we are dealing with a site where the asset we need to protect is the HTTP response. Something like one's medical history. According to what I've read one shouldn't need to pro

  • Can CSRF attacks steal log in information?January 29

    Sorry very new to security. If a user is logged into a secure site (credentials are SSN and a password) and then is victim to a CSRF, can their log in information be at risk? --------------Solutions------------- A CSRF attack is a blind attack where

  • How should a web page respond to a CSRF attack?October 28

    I know that you use tokens to prevent CSRF, but how should the receiving page respond when it is attacked? Should it fail silently, pretending the transaction was successful? Display an error message? Log the attack? Please explain your reasoning for

  • Why can I read the response to this CSRF attack?August 27

    I have a website www.foo.com:8002 that I have resolve to in my hosts file. I have another (the main site) running at localhost:80 In www.foo.com:8002 the page looks like <form name="myform" action="http://localhost/bar&quo

  • CSRF attack - Set custom CSRF Header October 30

    For a REST-api it seems that it is sufficient to check the presence of a custom header to protect against CSRF attacks, e.g. client sends "X-Requested-By: whatever" and the server checks the presence of "X-Requested-By" and drops the r

  • Are RESTful sites safe against CSRF attacks?September 18

    I am having a debate with a coworker about whether our site is vulnerable to CSRF attacks. He is saying that since we are using RESTful AJAX requests for everything that CSRF is not possible. Say a request to update your account info looks something

  • Why doesn't XSS vulnerability from the site launching the CSRF attack make the Synchronizer Token Pattern insecure?

    Why doesn't XSS vulnerability from the site launching the CSRF attack make the Synchronizer Token Pattern insecure?October 8

    I was reading this question about using Synchronizer Token Pattern to protect against CSRF and the comments of the answer intrigued me. Of course, as the last comment says, if your site has an XSS vulnerability, then CSRF is not your biggest concern.

  • What is the need of security token to prevent CSRF attack?October 21

    I have a REST API which is running in one domain and I have a client in another domain. To prevent CSRF I have configured REST API to accept request originated from client application only. I have added proper encoding as per owasp XSS prevention che

  • CSRf attack in SharepointNovember 11

    How to prevent CSRf attack in Sharepoint 2010 . My master page is custom SharePoint:FormDigest is there, still CSRF attack is possible. Please provide me good detailed solution. --------------Solutions------------- Microsoft has some guidance for dea

  • Is data exposed in a CSRF attack?January 7

    I am wondering wether a CSRF attack, will disclose the information being sent back in a GET request. I need to send a social security number out, to the client a few times, and it is NOT anyone else should ever be able to receive. The data is guarded

  • Is a CSRF attack possible for an intranet site?February 27

    I am starting to learn web deployment on my own. I just downloaded an open source, alfresco and trying few things on my own. After so much reading I managed to hide the 8080 url from the site using apache as a proxy server for tomcat. Today I faced a

  • Preventing CSRF attacks against WebSocket communicationsDecember 24

    I have read the thread about CSRF attacks in websockets (Do websocket-powered web apps (e.g. "comet" apps) have to worry about CSRF?) and also some more material regarding websocket security, but none of them seem to address the following issue

  • csrf attack when the victim not logged inJanuary 16

    If an attacker sends a malicious code for state changing event to a victim and the victim opens that malicious link and clicks on the submit button, can the attack take place when the user is not logged in to the attacked web application? -----------

  • Can postMessage be used to forward data to hacker's iframe in CSRF attack?April 14

    Consider a user that has an open session to a legitimate site with a password on it. This page has no anti-CSRF token. A hacker creates a webpage with 2 hidden iframes. One iframe does a GET on the page with the password and sends this password via h

  • GET and POST request vulnerable to CSRF attack?May 25

    Are both GET and POST request vulnerable to CSRF? Should we use PUT instead? --------------Solutions------------- Yes, both GET and POST are vulnerable to CSRF. However, RFC 2616 states the GET and HEAD methods SHOULD NOT have the significance of tak

  • Does Webmin 1.760 have protection against CSRF attacks?November 30

    I've read a bit about CSRF attacks in securing web applications and in order to do so the application itself has to protect against it, in it's authorization code. Alot of the other applications I've looked at have a certain line which in the comment

  • Prevent CSRF attack using regular expression, session storage, and auth token?

    Prevent CSRF attack using regular expression, session storage, and auth token?December 19

    User login to my Web API Service using his user name and password. Web API Service response auth token to client browser. Client browser save auth token to session storage using JavaScript. Client page use regular expression to validate every user's

  • What CSRF attacks will 'First-Party-Only' cookies protect against?February 3

    The new 'First-Party-Only' cookie attribute: ... allows servers to assert that a cookie ought to be sent only in a "first-party" context. This assertion allows user agents to mitigate the risk of cross-site request forgery attacks, and other rel

  • How to prevent CSRF attack in asp c# 4.0 without using master page step by stepFebruary 10

    I am using iframe in my asp .net c# website.problem is that csrf attack is possible in my website now i wanted to restrict the csrf attack as i really not aware about the csrf in asp

  • Accessing Admin-only button using CSRF attack

    Accessing Admin-only button using CSRF attackFebruary 16

    I have got an assignment which says the following: "Transfer 1000 rubles to a user called cpa" The problem is, the transfer button is accessible only to admin. A screenshot of the website: I figured out that a CSRF attack should be used by sendi

Copyright (C) 2018 ceus-now.com, All Rights Reserved. webmaster#ceus-now.com 14 q. 0.537 s.