Security against CSRF attacks via GET requests?

Question

I've built a stateless, JWT-based user authentication system on my web server, following the example of Stormpath (https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage).

The setup seems pretty secure against CSRF, but I'm wondering what about the GET requests.

I was able to model a CSRF attack on GET request by including an <img> tag on a page from a different domain. The server responds to the request with a full page with 200 status. While I don't change any data on GET requests, the pages may still contain some sensitive information, for example, <img src="https://example.com/account" /> may give out user's details, and or <img src="https://example.com/logout" /> could simply do something annoying, and I think there can be more examples.

Is this <img> attack considered harmless, because the browser will not disclose the repsonse it gets? Are there any other tricks with abusing HTML tags that could lead to disclosure of sensitive information by revealing the server output to a GET request?

I'm thinking to additionally include a hash of my JWT access token to the GET URL and have the server require that GET requests include that hash, and it must match the JWT token from the cookie. In this way the attacker will not be able to guess a valid GET URL, while also leaking such GET URL will not allow the attacker to get access to my server because he doesn't know the original JWT from cookies. Apart from minor usability issues, this setup looks like a good idea to me, but I haven't googled out anything similar, so I'm suspicious :)

Answer 1

​Concept of CSRF attack, it forces the authenticated user to perform unwanted actions on a web application to which he is authorized to. 

CSRF attacks ensures to introduce the state change for stateless servers, thefting of data is not involved as GET request would fetch the response to the victim not to the attacker, as victim is authorized to. There is no means that attacker can see the response to the forged request. 

A CSRF attack can bring the change to the state of the server but it can't see their results, it is forced to act blindly. 

Let's say, CSRF attack can tell the victim browser to request victim bank account balance, but the attacker can't see that balance. This is obviously a pointless attack.

But it is not pointless if, the attacker ask the victim browser to perform transfer of money from victim account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Attacker is not concerned about the response of success or failure​, his main concern lies he want money in his account.

If you are performing GET request to change the state of the server, it may turn out to be risky for you.

"GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1", if one such is your request. 

Which I believe it would not be.

So you must focus on POST request which should be monitored using CSRF token. 

Sharing the link for OWASP rules https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29 must go it once.