Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 already by HTTPS, but I know that won't stop a CSRF attack.

The request itself will not change anything in the application, but the data must not leak.

How can this be exploited? And what measures can I take to prevent it?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

A CSRF attack means that a website tricks a user into making a page request on another website they didn't want to make. This can be used to trick the user into performing an action on that website they don't intended to perform.

I could, for example, ask you to click this amazing link (really, it's cool!), and accidently cause you to delete your account on example.com (just an example - there is no such script on example.com). When I would have more control over this website, I could use a script- or HTTP redirect, so no social engineering would be necessary. But any response to that action would be sent to you, not to me. That means when the action is non-destructive and only reads information without changing it, a CSRF would be pointless. In the worst case the user would wonder why they are suddenly redirected to the website showing their social security number.

But there is one way for a website to gain information from a different website in the context of the user: xmlHttpRequest. Normally, same origin policies apply and prevent xmlHttpRequests from crossing domain-borders. But this restriction can be overridden by the Cross-Origin Resource Sharing settings on your webserver. When you accidently enable CORS for the other website (or all websites), they can send requests in the context of your users to your website and read the response. When you want to know how to check or change the CORS configuration on your webserver, refer to its documentation.

share|improve this answer
    
Thank you very much for a great and detailed answer, I am aware of what a CSRF attack is, but I wasn't sure if the attacker had any means of getting access to the data that was returned. Maybe in an iframe, or some other means, like JSONP request. –  André Snede Hansen Jan 7 at 15:46
    
@AndréSnedeHansen JSONP only works when the URL which inlcudes your SSN would be a valid javascript file. And iframe's which embed a different domain are restricted by same-origin policies and don't allow the embedding website to access their content (unless CORS is enabled, of course). –  Philipp Jan 7 at 16:03
    
Yea thats what I thought :) –  André Snede Hansen Jan 7 at 16:49
    
All this is assuming there isn't a same origin policy exploit available on that users browser. Exploiting same origin policy makes it a cross site scripting attack. –  ewanm89 Jan 8 at 1:25

CSRF generally would not be a threat here since CSRF attacks are session-riding exploits that wouldn't involve the attacker. However, if the CSRF attack involves changing the users' passwords the attacker would be able to access much more than the SS#. Further, if the CSRF attack could be used in combination with a XSS attack, in some cases this could very much reveal sensitive information.

Either way, general CSRF protections (nonces or double-submitted cookies), XSS protections (input and output filtering), and proper redirects if applicable would prevent this. The fact that it is a GET request limits exposure but by no means guarantees it is secure.

share|improve this answer

CSRF is not possible, but there used to be JSON Hijacking to worry about. However, this hasn't been an issue for a long time and is no longer possible in modern browsers.

From 2:-

Chrome 2.0.172.31 and Firefox 3.0.11 were both vulnerable to this.

This is where the JavaScript array and object setters were redefined in the page before a JSON request was made to the remote domain. When the JSON was returned, the code defined in the new setters would be executed and leak the data to the remote page.

Have a look at this post for some tips if you want to secure your code for use on old browsers or rare browsers that may be vulnerable.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.