i
This is not the latest version of this document; to access the latest version, click here.
Official Content

A common practice used to be for the Start event of the What is a Master Page to include a code for verifying if the user was authenticated or authorized to execute a web page. And consequently, the execution of user events did not include any security check, because it always followed the execution of the Start event where the security had already been checked.

This is the common scenario for KBs which do not use GeneXus Access Manager (GAM).

However, programming security checks in the Start event is not a good security solution for applications generated to use Web Smooth UX, and this is due to the Event Execution Scheme. In such cases, we must consider a different solution.

Despite the fact that using GAM is the best solution for this, GeneXus introduces an automatic solution to help those who haven't Integrated Security in their Kbs, and are converting from versions prior to GeneXus Evolution 3 to a Smooth model.

Challenge

When Web User Experience property  = Smooth, the Start, Refresh and Load Events are not triggered in the execution of a user event, as explained in the Event Execution Scheme.

This means that this code is vulnerable as far as security is concerned:

Event Start
        &context = LoadContext()
        if (not &context.IsAdministrator)
                  NotAuthorized.Link()
        endif    
Endevent

Event 'RemoveData'
    RemoveData.call()
Endevent

Note that, in a Smooth model, the execution of user event 'RemoveData' is separated from the Start event. So, the security check inside the Start event is not triggered when the user event is executed.
This security problem only occurs in KBs which do not use GAM, have Web User Experience property= Smooth, and delegate the security checks only to the Start or Refresh Event.

If security checks are included in every user event, then the problem will not exist.

However, there is no need to consider the change of user events code because an automatic solution is available to solve such security issues.

Solution

To avoid delegating the responsibility of this task onto the GeneXus user, a solution has been implemented to automatically prevent intruders from executing the user event without being logged in at least once.

This solution is for cases where GAM is not active in the KB, or when it is active - Enable Integrated Security property = True, but the Integrated Security level is none at the object level:

Only when the user has logged in the application (having executed the web panel for the first time) a token will be granted to be used in executing the page's user events. The token is valid only for the web page executed.

The security solution scope is as follows:

1. Allow execution of user events when the user is authenticated, and not for non-authenticated users.
2. Allow execution of a web object only when an authenticated user has permits to execute it.

As since GeneXus 15, the JWT standard is used for the implementation of the token mechanism. 

Restrictions to the solution

  • The security token will remain valid while the end user is executing a web page, even if a permit for that user is revoked or if the user is deleted. So, depending on the application's strictness and features, we might need to program the security checks for each user event.

Note

In addition to the solution described above, an automatic security check is also available for each HTTP Post, for detecting whether the read-only data has been changed. In case it has, a 403 Forbidden Error is informed. A more detailed explanation of this mechanism is explained in Security Web Development tips.

Last update: February 2024 | © GeneXus. All rights reserved. GeneXus Powered by Globant