Log in to AnswerLog in to Follow
2022-03-03 22-15-30
Borislav Shumarov
22Views
7Comments
Solved
Interface: Aggregate using a parameter from another Data Action for permission check
Question
Best Practices

Hi all,

we observed the OutTracker application and we saw a design pattern. This is a screenshot from OutTracker by Outsystems:

A Data Action is being called first with a security check and then the rest of the Aggregates for the Screen are called, using an output parameter of this Data Action, to use as an input parameter to each Aggregate.

One question arises: it this secure? Meaning: could a user manipulate the parameter HasAccessToActivity in the browser JavaScript, setting it to true and thus loading the endpoint of the Aggregate and obtaining the data?

Thx in advance ;)

0
0
22 Feb

Hi! 

I' not a guru but what seams  to me is : 

The data action whose output is used for a security control of the data returned from other aggregates or data actions must be called EVERY TIME this aggregates are called;

The screen actions must ignore this information and go to the server to recheck the security situation. 

 What is your opinion?

Graça

See solution in context
0
0
23 Feb

EDIT: oh, I think I get what you mean. Yup it seems so to me, as well ;)

hm, could you elaborate? What do you mean by "The data action .. must be called EVERY TIME this aggregates are called" - why should it be called every time? It is called only once at start, until a Refresh Data Action is not called. 

Or did you mean something else?


0
0
23 Feb

Replying to Borislav Shumarov's comment on 23 Feb 2022 23:01:46

You're right, the data action is only called once at start and later if a refresh is applied.

The screenshot image is broken, I cannot see it. If your control variable is a local variable in the screen verified only in server calls your security is "guaranteed".

Regards

0
0
23 Feb

Replying to José Gonçalves' comment on 23 Feb 2022 23:09:31

Do you suggest, that it won't be exposed to the browser at all?

0
0
23 Feb

Replying to Borislav Shumarov's comment on 23 Feb 2022 23:18:37

ASPX files are generated and the DLLs are available in the server. I believe the code is not exposed at all.

But you can learn more and try to view the generated code by reading this topics:

https://www.outsystems.com/forums/discussion/13350/view-generated-code/

https://www.outsystems.com/forums/discussion/40860/is-it-possible-to-get-the-deployed-codesystem-generated-c-codes/

1
0
23 Feb

I explained to OutSystems what the issue is and I can confirm, that the pattern in the OutTracker application as described above is NOT secure.

This is the official response, that I got:


Hi Borislav,

When you fetch data from the server (queries or API calls), don’t use input parameters that have impact on the data that is returned. An attacker can change these values and fetch some other data.

For instance, if retrieving data about the current logged-in user, instead of using client-specific details consider using server-side logic to get that same information.
A common good practice is to place the GetUserId() inside the aggregate. The aggregate is running on the server, which is secured and the attacker can’t alter this query anymore to access data from other users.

This same best practice works for fetching data based on user roles or when you fetch data from the server and you send an identifier or another element that uniquely identifies an element as input parameter to the server.

We would suggest adding server-side checks to any server-side calls to make sure that the logged in user has the rights to the returned data.

See solution in context
0
0
06 Mar

Hi! 

I' not a guru but what seams  to me is : 

The data action whose output is used for a security control of the data returned from other aggregates or data actions must be called EVERY TIME this aggregates are called;

The screen actions must ignore this information and go to the server to recheck the security situation. 

 What is your opinion?

Graça

0
0
23 Feb

EDIT: oh, I think I get what you mean. Yup it seems so to me, as well ;)

hm, could you elaborate? What do you mean by "The data action .. must be called EVERY TIME this aggregates are called" - why should it be called every time? It is called only once at start, until a Refresh Data Action is not called. 

Or did you mean something else?


0
0
23 Feb

Replying to Borislav Shumarov's comment on 23 Feb 2022 23:01:46

You're right, the data action is only called once at start and later if a refresh is applied.

The screenshot image is broken, I cannot see it. If your control variable is a local variable in the screen verified only in server calls your security is "guaranteed".

Regards

0
0
23 Feb

Replying to José Gonçalves' comment on 23 Feb 2022 23:09:31

Do you suggest, that it won't be exposed to the browser at all?

0
0
23 Feb

Replying to Borislav Shumarov's comment on 23 Feb 2022 23:18:37

ASPX files are generated and the DLLs are available in the server. I believe the code is not exposed at all.

But you can learn more and try to view the generated code by reading this topics:

https://www.outsystems.com/forums/discussion/13350/view-generated-code/

https://www.outsystems.com/forums/discussion/40860/is-it-possible-to-get-the-deployed-codesystem-generated-c-codes/

1
0
23 Feb

I am almost sure, that it is not secure, since execution of the Data Action on the server side every time would add additional performance penalty and the other option would be some kind of a session mechanism (since Data Actions and Aggregates run async), that caches the results of the Data Action on server side and it uses this, if it is subsequently needed again on server side. 

But it would be great, if somebody with deep knowledge of how exactly these work under the hood could clarify..

0
0
23 Feb

I explained to OutSystems what the issue is and I can confirm, that the pattern in the OutTracker application as described above is NOT secure.

This is the official response, that I got:


Hi Borislav,

When you fetch data from the server (queries or API calls), don’t use input parameters that have impact on the data that is returned. An attacker can change these values and fetch some other data.

For instance, if retrieving data about the current logged-in user, instead of using client-specific details consider using server-side logic to get that same information.
A common good practice is to place the GetUserId() inside the aggregate. The aggregate is running on the server, which is secured and the attacker can’t alter this query anymore to access data from other users.

This same best practice works for fetching data based on user roles or when you fetch data from the server and you send an identifier or another element that uniquely identifies an element as input parameter to the server.

We would suggest adding server-side checks to any server-side calls to make sure that the logged in user has the rights to the returned data.

0
0
06 Mar
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.