2 ms·

How do you prevent against CSRF attacks (http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery) if you

How do you prevent against CSRF attacks (http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery) if you don't maintain any state server-side? The classic (and best) method for foiling these attacks is to store a special/randomized token in a server-side session, and require that token to be submitted from the client via a standard form, essentially making forged attacks impossible. Take away the ability to store these tokens in some sort of server-side session, and you open your site to attack?

sfg 18y ago
In his example, where the server maintains the state of the basket, all the requests from the user require a user name and password which will be used to authenticate the user and thus prevent identity forging.
JulianMorrison 18y ago
Give a ticket with each response, require a ticket with each request. Tickets are signed with HMAC, dated, and individualized to the user login. Creating a ticket, the server forgets it. Receiving a ticket, the server checks it, creates another, and forgets that.
- nuclear_eclipse 18y ago
  I don't quite understand how the server would validate the ticket if it's been forgotten. Wouldn't that just allow any forged request to generate a seemingly valid ticket and submit a request like that. Further, excuse my ignorance, but can you explain how HMAC would help in a more user-friendly language than what Wikipedia provides?
  - run4yourlives 18y ago
    From one of the articles linked in the wiki entry: Basically it’s done like this: 1. The server passes a random string to the client 2. The client performs a calculation on the password and the random string 3. The client passes the username (in plain text) and the result of the calculation to the server 4. The server performs the same calculation as the client did and compares the output to the output of the client. 5. If it’s a match, the client is authentic.
    - JulianMorrison 18y ago
      That's a HMAC password protocol, it's different. In the case of tickets, the one signing is "this server then" and the one checking is "this server now", with a period of amnesia (about the data, not about the password) in between.
      - run4yourlives 18y ago
        Ahh, my bad. I think I see where you're going with this now. You're basically just remembering the last visit a particular client makes on every request, and then resetting the ticket for the next request correct?
        JulianMorrison 18y ago
        Imagine a disposable photo-ID ticket marked "admit one authenticated client". The bouncer takes it, looks at it, looks at you, tears it in half, and lets you in. You get to make a request, and as you carry the response out of the exit door, a member of staff takes your photo and prints a fresh ticket.
  - JulianMorrison 18y ago
    To validate the ticket, it looks inside the ticket at the user ID, the timeout date and it checks the signature. HMAC is a lightweight symmetric-key signature. Symmetric keys are OK because the same person is generating and checking signatures. Data plus signature equals proof that "I earlier permitted this". I don't need to remember it in the interim. A forged request can't guess the HMAC key, and a forged request with an invalid key is refused. A replay is disallowed after the timeout. The server can also keep track of "spent" tickets until they would have timed out, preventing a replay even during the timeout period.
- newt0311 18y ago
  What about MITM attacks? Seriously, if you want security, use SSL.
  - JulianMorrison 18y ago
    SSL solves a different problem. Problem 1: protection from session hijack across a series of requests. Solution: tickets. Problem 2: protection from interception and alteration of the commands within one request. Solution: SSL. SSL (even in its most powerful form as a password-protected client-side CA-signed cert!) provides no protection against problem 1.
  - ajross 18y ago
    A man in the middle attack won't defeat a signed "cart" object stored in the client's browser. The signature's private key is stored on the server and never appears on the network. This requires no per-session state on the server, just a single key pair. SSL, on the other hand does nothing to prevent a cross-site attack. Anything that can run code in the client browser can in principle cause it to send a fraudulent shopping cart "securely" to the server.

sfg 18y ago

In his example, where the server maintains the state of the basket, all the requests from the user require a user name and password which will be used to authenticate the user and thus prevent identity forging.

JulianMorrison 18y ago

Give a ticket with each response, require a ticket with each request. Tickets are signed with HMAC, dated, and individualized to the user login. Creating a ticket, the server forgets it. Receiving a ticket, the server checks it, creates another, and forgets that.

nuclear_eclipse 18y ago
I don't quite understand how the server would validate the ticket if it's been forgotten. Wouldn't that just allow any forged request to generate a seemingly valid ticket and submit a request like that. Further, excuse my ignorance, but can you explain how HMAC would help in a more user-friendly language than what Wikipedia provides?
- run4yourlives 18y ago
  From one of the articles linked in the wiki entry: Basically it’s done like this: 1. The server passes a random string to the client 2. The client performs a calculation on the password and the random string 3. The client passes the username (in plain text) and the result of the calculation to the server 4. The server performs the same calculation as the client did and compares the output to the output of the client. 5. If it’s a match, the client is authentic.
  - JulianMorrison 18y ago
    That's a HMAC password protocol, it's different. In the case of tickets, the one signing is "this server then" and the one checking is "this server now", with a period of amnesia (about the data, not about the password) in between.
    - run4yourlives 18y ago
      Ahh, my bad. I think I see where you're going with this now. You're basically just remembering the last visit a particular client makes on every request, and then resetting the ticket for the next request correct?
      - JulianMorrison 18y ago
        Imagine a disposable photo-ID ticket marked "admit one authenticated client". The bouncer takes it, looks at it, looks at you, tears it in half, and lets you in. You get to make a request, and as you carry the response out of the exit door, a member of staff takes your photo and prints a fresh ticket.
- JulianMorrison 18y ago
  To validate the ticket, it looks inside the ticket at the user ID, the timeout date and it checks the signature. HMAC is a lightweight symmetric-key signature. Symmetric keys are OK because the same person is generating and checking signatures. Data plus signature equals proof that "I earlier permitted this". I don't need to remember it in the interim. A forged request can't guess the HMAC key, and a forged request with an invalid key is refused. A replay is disallowed after the timeout. The server can also keep track of "spent" tickets until they would have timed out, preventing a replay even during the timeout period.
newt0311 18y ago
What about MITM attacks? Seriously, if you want security, use SSL.
- JulianMorrison 18y ago
  SSL solves a different problem. Problem 1: protection from session hijack across a series of requests. Solution: tickets. Problem 2: protection from interception and alteration of the commands within one request. Solution: SSL. SSL (even in its most powerful form as a password-protected client-side CA-signed cert!) provides no protection against problem 1.
- ajross 18y ago
  A man in the middle attack won't defeat a signed "cart" object stored in the client's browser. The signature's private key is stored on the server and never appears on the network. This requires no per-session state on the server, just a single key pair. SSL, on the other hand does nothing to prevent a cross-site attack. Anything that can run code in the client browser can in principle cause it to send a fraudulent shopping cart "securely" to the server.