SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Evangelist
    Join Date
    Jan 2005
    Posts
    502
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    CSRF token generation

    This is a question about generating CSRF tokens.

    Usually I'd like to generate a token based off of a unique piece of data associated with the user's session, and hashed and salted with a secret key.

    My question is in regards to generating tokens when there is NO unique user data to use. No sessions are available, cookies are not an option, IP address and things of that nature are not reliable.

    Is there any reason why I cannot include the string to hash as part of the request as well?

    Example pseudocode to generate the token and embed it:
    Code:
    var $stringToHash = random()
    var $csrfToken = hash($stringToHash + $mySecretKey)
    <a href="http://foo.com?csrfToken={$csrfToken}&key={$stringToHash}">click me</a>
    Example server-side validation of the CSRF token
    Code:
    var $stringToHash = request.get('key')
    var $isValidToken = hash($stringToHash + $mySecrtKey) == request.get('csrfToken')
    The string being used in the hash would be different on each request. As long as it was included in each request, the CSRF token validation could proceed. Since it is new on each request and only embedded in the page, outside access to the token would not be available. Security of the token then falls to the $mySecretKey being known only to me.

    Is this a naive approach? Am I missing some reason why this cannot work?

    Thanks

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    If there is no session, no user accounts or anything like that. CSRF is not an issue. CSRF is a means to exploit an active user's session. If there is no session and users there is nothing for CSRF to exploit.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    SitePoint Evangelist
    Join Date
    Jan 2005
    Posts
    502
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is a need to protect against the requests I am talking about. This is in regards to JSONP requests and cross-domain authentication. I want to ensure that these requests are made only from my sites.
    Last edited by Mr_Money; Dec 1, 2009 at 10:28. Reason: misspelling

  4. #4
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    CSRF are request from your site! To actually make this token system work, you need to have sessions. Every request must have a unique token. And every token must match to only one request.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  5. #5
    SitePoint Evangelist
    Join Date
    Jan 2005
    Posts
    502
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The approach posed in my question above does have unique tokens. Look at the pseudo-code provided.

    To clarify what I asked above. Instead of using some piece of information to generate the token that is known only to me, I am creating a random string and sending that along with the request as well. That random string is what is used in generating my token.

    The random string is hashed using my secret key. Basically the security of the token boils down to no others knowing what the secret key is. Essentially anyone could provide their own random string, but they would still not know how to generate the corresponding token.

    The difference from the usual approach is that I am not hiding the string used in generating the token.

  6. #6
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    And this is why it will not work. All an attacker has to do is copy and paste the link above. and maybe update it every so often if you change "$mySecretKey" there is no verification that in fact the token is unique to that request. Nor could you change "$mySecretKey" without a lengthy period of delay.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  7. #7
    SitePoint Evangelist
    Join Date
    Jan 2005
    Posts
    502
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You are right. The above code was a simplified version of what I was thinking - the random string would actually be something that could be decrypted and short-lived. You have slapped the sense into me though, and realize now this will not work.

    Thanks for your help


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •