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.

Imagine button after clicking which browser sends XHR http request with GET method. Characteristics:

  • after executing request sensitive action is performed
  • sensitive information is sent in GET parameters
  • HTTP headers X-Requested-With: XMLHttpRequest and X-CSRF-Token with large enough PRG token are sent and are necessary to have the action executed
  • option to Copy link location isn't accessible when rightclick the button as it's a form

Normally XHR is used with GET but here it's used with GET. It's the only difference from normal XHR requests.

Does this design lead to any security vulnerability?

Edit: Some answerers and commenters tell that:

  • User may copy or bookmark url. However, the only place from where user may copy url is the source code of page because this url isn't exposed in browser address bar, rightclick menu because of button is a form). Also parameters are added into request by browser itself so user can't copy full url from source code.
  • User may copy part of browser window. However, url isn't exposed in browser window
  • It may become part of Referer header. However, it's XHR and doesn't change url in Referer header of next requests

So the only valid vulnerability seems to be that GET parameters may be logged in webserver logs (they won't be logged at proxy because of using TLS). If those logs are accessible to attacker, then he will have sensitive information.

share|improve this question
    
copy link location inaccessible is useless. If someone wants to get the url, he will be able to, no matter what. –  Cyril N. May 17 '12 at 12:32
    
@cx42net It isn't clear why the OP thinks it is necessary, or even useful, to prevent the legitimate user from copying the URL. What is the threat model here? –  curiousguy May 17 '12 at 19:43
    
@Curiousguy I'm not sure to understand what you are asking. It's not about a threat (my comment) but an useless act. –  Cyril N. May 17 '12 at 20:22
    
@cx42net "It's not about a threat (my comment) but an useless act." so, there is no threat model here? –  curiousguy May 17 '12 at 21:20
    
Change the method from GET to POST and you're fine. The whole point of CSRF is to trick a user into executing some state change that they are already allowed to make (but not intending to make). You shouldn't use GET requests to change state, so you shouldn't need CSRF protection on GET requests. –  mehaase May 18 '12 at 1:43
show 3 more comments

2 Answers

I wouldn't rely on this design. The HTTP specification states:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

More generally speaking I would never recommend using CSRF tokens in GET requests since they may become available in various log files (vulnerability if the anticsrf token is not properly disposed of after one use.), they may become part of the referrer header, users may bookmark them and this will lead to either a security leak or to invalid bookmarks. This may have negative impact on the SEO too. Etc, etc.

So I think that GET+CSRF+ANY_OTHER_SENSITIVE_DATA=bad idea.

share|improve this answer
    
+1 Some users will post a copy of the browser windows to forums, revealing the URL (I have seen it). Some users will actually post the URL as text (I have actually witnessed that a few times). Many users do not understand that a URL sometimes contains sensitive information. –  curiousguy May 17 '12 at 19:41
add comment
  • Issue 1: Sensitive data in the URL.
  • Issue 2: CSRF token in URL Anything you put in the URL will be logged in browser history, proxy logs, webserver logs ....
  • Issue 3: You can't prevent user from viewing the link/url by disabling the right click options, anything you sent to browser will be accessible to the user, one way or other

DO NOT USE GET for posting data and requests which change the state.

I don't see any problem in putting the CSRF token in the header, additional things you need to consider are not opening your server to HTML5 CORS requests . If you need to allow CORS then there additional things you would need to consider.

share|improve this answer
    
-1. Issue 1 is irrelevant as this url doesn't even appear in browser address bar. Issue 2 is incorrect as I haven't specified that CSRF token is in url. It's submitted as XHR and anti-CSRF header exists. Issue 3 is irrelevant as I haven't disabled 'Copy link location'. It's a button after clicking which XHR request is sent using GET. So all your "issues" are absolutely irrelevant. Also server isn't opened to CORS. –  Andrey Botalov May 17 '12 at 17:14
    
@AndreyBotalov even if it doesn't appear in URL it will be logged by web server and proxy server ... along with all your params. And issues 3 : whatever you send to client is wide exposed one way or other... view source , check javascript, intercept own request there are numerous ways. You really need to get your fundamentals right before calling the issues irrelevant ... –  Sachin Kumar May 18 '12 at 8:27
add comment

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.