Securing Ajax requests in ASP.net through authenticated web forms

Question

I already read Securing AJAX requests using a GUID as well as Securing an ajax request . Now let me explain my script, below is a code snippet that can help explain the subject.

[WebMethod[EnableSession = True] [ScriptMethod] public static string CreateTitle(string strTitleName) { string strResult = "Custom jSon string"; if(Session["Authorized"] == "True" && !String.IsNullOrEmpty(strTitleName)) { String strTitle = Server.HtmlEncode(strTitleName); InsertRecordInDB(strTitle); strResult = "Custom jSOn string" + EncryptMD5("record id"); } return strResult; } 

and below is a javascript call to send parameters. btnCreateTitle_click is a click event on the client button side. txtTitle is a text field that takes a name. Validators are created on the page to check the text field too. CreateTitle is the page method that I call with the scriptmanager

 function btnCreateTitle_Click(evnt){ if(Page.ClientValidate()){ if($get("txtTitle")){ PageMethods.CreateTitle($get("txtTitle").value,success,failure,context); }}} 

The success of the function shows a message that the header was created, and shows a link with an encrypted record identifier as a url query string to view the details of the created header.

Now the burning question,

• Is it safe enough? What am I missing?
• How can I make the process safer and faster?

Answer 1

While it is trivial to restrict a method to authenticated and authorized users, when you set the db identifier in the query strings, you open the possibility that an authenticated and authorized user can look for access to records that they do not have. This is especially important when the db identifier is an integer or other frivolous identifier. Using guides as db identifiers can reduce the risk of this, although not entirely.

What you always need to remember DOES NOT ALLOW ENTRANCE. Security through obscurity (e.g., encryption, etc.) is not a reliable technique. Your service should always check if the current user is allowed to receive the requested records. This is sometimes called row-level security. This can only be done programmatically.

for example, instead of determining that someone is allowed to view the record, you need to make sure that they have access rights to the record they request.

This means that you need a way to bind records to an authenticated user.

BTW: any HTTP request is checked for potentially dangerous input.

Hope this helps,