ncyoung.com
augmenting session based security with secret tokens (google this)
This entry is in the following categories:
Session based authentication can be supplemented with "secrets" or "tokens" embedded into the forms, link URLs and ajax calls from pages of a secure application.
The simplest thing to check for is the referrer. If the browser requesting your service reports your own page as a referrer, then you can send them the response. An attacker can fake the referrer in their own browser, but they don't have a session to ride. There's no way they can embed a request to your service in their page in such a way that it fakes the referrer in the browser of someone who visits their page.
The way you'd use a secret token is a little more complex, and it involves the cooperation of client side code.
An ajax application could increase security by using a secret token in the following way:
Assuming the user is logged in and has a session cookie:
1. When the server sends a page to the browser, it embeds the secret token in the page. On the server side, the token is associated with the session ID of the visitor
2. When the client side code in the page does a request (ajax) to the server, it includes the token as a parameter (and the session as a cookie automatically)
There are two kinds of leverage the server has at this point that it would not have had without the secret.
First, it can check what kinds of actions are valid for that token/session combination. For example, the token sent out with an "edit account details" page might allow for changing the first name of the person, but not manipulating their orders.
Second, the server can revoke the token under a variety of conditions:
- If the referrer is wrong
- if too much time has gone by
- if a new page has been requested
- if a request not allowed by that token is attempted, etc.
Dated: 04/13/2007
|
|
|