Preventing unauthorised access to data via Ajaxcall.ashx

  • 8 February 2017
  • 8 replies
  • 73 views
L
Badge +2

Hello all

 

I have a form and on my form is a list view. The view retrieves data about the logged-in user and displays it.

The data is stored in a SQL database, which is exposed via a standard SQL broker SmartObject to K2.

 

I need to ensure that users cannot view each other's data. This means being careful with use of Form and View parameters which can easily be modified by the user via the querystring. So I ensure my SmartObject 'List' method takes username as a parameter, and set the value when the method is called in my form's Initialize rule by dragging 'Current User/FQN' into the appropriate Input Property.

 

Inspecting the traffic which occurs when the form loads, I see a call to AjaxCall.ashx which contains an XML request payload containing my username. If I use a tool like Fiddler to manipulate this request payload, by changing the username I can then request the data for any user.

 

I'm sure I must be missing something here, but how should I make this setup fully secure against malicious users?

 

For context, in the full system the data is highly personal and the application is exposed to the internet, with access open to anyone in the world who requests an account.

8 replies

K
Badge +10

Setup your list to Initialized with Filter based on the credentials of the Authenticated User, this way nobody will modify the running time params to try to retrieve some other data since the filter will always run that from the List View directly and is not expecting any other parse data. regardless of Malicious Users or not =)

 

Tipically I create a SQL SMO for UserRoles and here I can put an Admin, User or Auditor, when the form start execute the query to capture the role. based on the role and the authenticated user will initialize the view. and will be using those params.... since the list view will parse the role and the user that is what is used in the list to filter and display.

 

Good Luck !!!

L
Badge +2

Hi K2CaveMen,

 

Thanks for your reply.

 

I have modified my Initalize rule so when it executes List, as well as passing the parameter in the Input Mapping I have also added a Filter which filters on the 'UserFQN' field in my SmartObject, using the value Current User / FQN from the Context Browser.

 

 This just means that the call to Ajaxcall.ashx has got the logged-in user's name in twice, once as a parameter and again as a filter. I can still modify both of these using Fiddler and run the web service call with another user's login. I then get that user's details (not in the actual list view, you understand, but in the XML response from the web service).

 

 

K
Badge +10

If the list run the filter from Initialize based on the Environment authenticated user, regardless of whatever you inject in the URL, how will that be changed by Fiddler.

 

I have K2 as service account and always return the correct recods.

 

Additionally you can add an outbound previous rule that only certain users can execute and this can limit only to specific users to be granted to the List if you are not part of the chosen list rediret to a 404 because is considrered un-trusted, and if you are part of the list let the filter show only the entries he is part or access is granted. again regardless of whatever you inject in the URL with Fiddler, CURL or some other script tool.

 

Hope this helps !!!.

L
Badge +2

"If the list run the filter from Initialize based on the Environment authenticated user, regardless of whatever you inject in the URL, how will that be changed by Fiddler"

 

 Because when the form loads, the authenticated user is evaluated, and then a client side web service call happens which passes the username back to the K2 web service Ajaxcall.ashx.

 

With Fiddler we can replay that web service call using a different value for the username parameter, and see all the returned data for the other user.

 

So, we are not injecting into the form/view URL but modifying the request header in the subsequent call to the web service.

 

 

N
Badge +3
You should use row level security on your source system (for example mssql).
Sql broker should impersonate user when make query and you should filter data on mssql based on user name.

Bacause of havy client side logic on Smartforms, solution is using RLS on source.

More details can provide k2 support.
L
Badge +2

Hi Nagorskiy, thanks for your reply.

 

The logged-in user is using an external user manager based on a table of users in a SQL database, so these are not Windows users. The external user accounts are created via a web form which just adds them to the table of users. I don't think impersonation will work in this case, will it? The user needs to have a type of credential that SQL Server understands, and the user will need permission to log on to SQL server. Is that right, the solution will need re-architecting to support RLS?

N
Badge +3
We get from k2 support patch for sql broker.
So it works under k2 service account, but for every query its set CONTEXT_INFO . So you can get real username from stored proc from CONTEXT_INFO .
M
Badge +11

Just to clarify the situation with this patch for SQL broker which enable SQL SI to work under K2 service account context, but for every query set CONTEXT_INFO to impersonated user, we now have this OOB:


 


- In K2 4.7, with K2 4.7 August 2017 Cumulative Update FP13 (https://help.k2.com/kb002081) and newer


- In K2 Five with FP1 (https://help.k2.com/kb002108) and newer

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings