Secure Request Token Framework ( CSRF )
made by Easy Diffusion

Secure Request Token Framework ( CSRF )

CSRF is an attack which tricks an end user into executing actions on the web application in which he/she is currently authenticated on.    

Many operations in Content Server are a two stage process.        

  1. Identify and add/update/delete some data        
  2. Commit those changes to the database

 An example of a CSRF attack would be tricking an authenticated user into executing step 2 directly.

A simplified view of the Secure Request Token Framework is that it generates a token in the above step 1.  It then checks that token in step two.  If the token doesn't exist, has expired or contains a user other than the current one, the operation will not be allowed.


In general there three steps to using the framework

  1. Generate the Token in Handler1 and store it in a feature ( a variable accessible to the weblingo in step
  2. A handler is what responds to web requests in content server.  An example of Handler1 is when you try to delete a folder and get the confirmation page with the item you are deleting, a delete button and a cancel button. Handler1 in this example is Action-Delete.2.  Edit the weblingo to retrieve the token from the above feature and put this token in the html form as a hidden input.In the above example where Handler1 is Action-Delete, its associated weblingo would be delete.html.
  3. Validate the token in Handler2  In the above example, Handler2 would be Action-Delete2.  Action-Delete2 is responsible for actually performing the delete action against the database.

A typical user action with SRT Framework   

A request from a browser comes into Content Server handler1 takes that request, generates a token, does any required processing and returns the webpage with a form on it.  That token is embedded into the form as a hidden input.  User changes the data on the form and sumbits it. ( The token is submitted in the form) The submit request from the browser comes in to Content server   

Handler2 takes that request, validates the token and does any required processing of the form data ( assuming token is valid ) and then displays the results to the user.  If the token is not valid, no data is processed and an error page is displayed.


Handler 1 Create and save the token to a feature by adding the following to Handler1:

 // Set the secure request token  status = $WEBDSP.RequestHandlerUtils.CreateSecureRequestToken( parm.prgCtx, "Handler1" )    if ( status.ok == TRUE )     
response.data.secureRequestToken = status.callerToken  
else   
ok = FALSE   
err.message = status.errMsg  
end        

HTML Weblingo page Put the token into the request by adding the following to the Form inside the weblingo:

<INPUT TYPE="HIDDEN" NAME="secureRequestToken" VALUE="`.fResponse.data.secureRequestToken`">        

Handler2 Check the token by adding the following to Handler2. 

  //Check the Secure Request Token from Action-Copy   
result = $WEBDSP.RequestHandlerUtils.CheckSecureRequestToken( prgCtx, request.secureRequestToken, {"Handler1"} )
 if ( !result.ok )

  ok = FALSE   response.error.message = result.errMsg  end        


If you have more than one handler submitting to Handler2 put them all in the third parameter white list for CheckSecureRequestToken

Prototype

Add the following to the script that sets your handler2’s fPrototype setup script and then run it.

 { 'secureRequestToken', StringType, 'Secure Request Token', FALSE }, \        

 

To view or add a comment, sign in

More articles by Reiner Merz

Others also viewed

Explore content categories