Securing AJAX requests with a GUID

Question

I am writing a web application that will make requests through AJAX and wants to block these calls. After a little research, I am considering using some form of random token (string) that will be transmitted along with the request (GUID?). Here are the important parts of my algorithm:

• Assign a token to a JavaScript variable (server-side generated).
• Also save this token in the database and give it a valid period of time (i.e. 10 minutes).
• If the token is still not used and is within the valid time window, allow the call.
• Returns the requested information if it is valid, otherwise it registers the request and ignores it.

With security in mind, does this make sense? For the token, will the GUID work - should it be something else? Is there a good way to encrypt variables in a request?

EDIT:

I understand that these AJAX requests would not be truly “secure,” but I would like to add basic security in the sense that I would like to prevent others from using the service that I intend to write. This random token would be a basic, front-line defense against abusive calls. The data that will be requested (and even sent to create such data) would be very unlikely.

Maybe I'm mistaken in using a GUID ... what about a randomly generated string (token)?

Answer 1

If you do this to trust the code you sent to the client browser, change direction. You really don't want to trust user input, which includes calls from js that you sent to the browser. The logic on the server must be made so that nothing happens there. However, asp.net uses a signed field, you can go this way if absolutely necessary.

Bit extension: Asp.net tamper-proofs viewstate, which is sent as a html hidden field (depending on configuration). I am sure there are better links as a link, but at least it is mentioned on this: http://msdn.microsoft.com/en-us/library/ms998288.aspx

checks. This indicates a hashing algorithm used to generate HMACs to do ViewState and ticket authentication forms. This attribute is also used to indicate the encryption algorithm used for ViewState Encryption. This attribute supports the following parameters:

• SHA1-SHA1 is used to protect ViewState and, if configured, authentication forms from unauthorized access. When SHA1 is selected to test the attribute, the algorithm used is HMACSHA1.

The link for the .net class for this algorithm is http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx .

Update 2: To protect against unauthorized access, you want to sign data (do not encrypt). Note that when using cryptography in general, you should really avoid using a custom implementation or algorithm. As for the steps, I would stick with:

• Assign a token to a JavaScript variable (server-side generated). You include information to identify the request and the exact date and time it was issued. The signature will be verified by the server-side application that issued the data.
• Identify duplicate views, if necessary.

However, the reason asp.net checks the default view state is because developers rely on the information coming in there as they only process the application when they don’t. The same probably applies to your scenario, do not rely on this mechanism. If you want to evaluate whether someone can do something, use authentication + authorization. If you want to know that the ajax call only sends valid parameters, check them out. Do not expose the API at the level of detail than the one where you can allow actions accordingly. This mechanism is only an additional measure if something slips, and not real protection.

Ps. with HMACSHA1 above, you must create an instance using a fixed key

Answer 2

“Collateral” is a kind of vague term. What exactly are you trying to achieve? Using a GUID is a great way to prevent duplicate representations of the same query, but that’s all.

If the information transmitted between the client and server is really sensitive, you must do this via HTTPS. This is truly the only answer regarding ensuring actual communication.

Edit: To answer the question of whether the GUID is “right”, there is no right way to do what you offer. Using any token, be it a GUID or something from your own creation, will have no effect other than preventing duplicate representations of the same request. What is it.

Answer 3

It really depends on what you are trying to accomplish with security. If you mean to prevent the unauthorized use of HTTP endpoints, you can do very little because the user will have full access to the HTML and JavaScript used to make calls.

If you mean that someone might sniff data in AJAX requests, I would just use SSL.

The GUID used as you suggest really just invents a session identifier cookie.