Kentico Xperience 13 documentation and ASP.NET Core

Most documentation about running Xperience applications under ASP.NET Core can be found in a dedicated section: Developing Xperience applications using ASP.NET Core. The rest of the documentation still applies, but some code samples and scenarios might need slight modifications for Core projects.

All major differences between the MVC 5 and Core platforms are summarized in Migrating to ASP.NET Core.

×

Special security permissions

The purpose of special permissions in Xperience is to prevent privilege escalation attacks. In this type of attack, a lower privilege user can gain access to functions only available for higher privilege users. For example, editors with permissions to edit only content elevate themselves to the global administrator level.

The special permissions cover the following areas:

Only the users with the Global administrator privilege level can configure these settings.

Editors and other users cannot grant or remove these special permissions. Even if you assign users to a role which is allowed to modify permissions, these special permissions will be disabled, which is indicated by a warning icon ().

SQL code in reports

When working with the Reporting application, users need to write SQL statements to get data from the database and display it in various reporting tools. This could also be dangerous because a user uses SQL code to elevate privileges or get sensitive data from the database.

The Edit SQL Queries permission for the Reporting module indicates whether a given role can edit SQL queries in reports.

Alternatively, you can change the connection string for reports. With that, you can create a special user account on the database level with limited permissions. For example, the database user will not be able to execute any UPDATE/INSERT/DELETE queries.

Another approach could be to separate the data into multiple databases. The first database would contain only reporting data, and the second database all other data including users. Then, the reporting module would be able to work only with the reporting data (and the user would not be able to execute malicious queries). Of course, in this scenario, you need to prepare a mechanism that ensures data synchronization.

Configuring multiple connection strings

  1. Edit your web.config file and specify a new connection string in the <connectionStrings> section. The name attribute must be unique.  
  2. Go to Settings -> Security & Membership.
  3. Select the new connection string as the Default report connection string in the Reporting category.  
  4. Open the Permissions application and configure the Set connection string permission of the Reporting module. 
    • Only users in a role with the permission and global administrators can change the connection string used by reports.

SQL code in the advanced export dialog

When performing an Advanced export of data from a listing page in the administration interface, users with sufficient privileges have the option to modify the exported data using an SQL Where condition or Order by clause.

Writing SQL code in the advanced export dialog is only available for users who have the Global administrator privilege level or belong to a role that has the Edit SQL code permission for the Design module.

Allowing code editing for site administrators

You can choose whether users with the Administrator privilege level are allowed to edit SQL code by default, or if they need to have a role with the permissions mentioned on this page.

  1. Open the Settings application.
  2. Select the Security & Membership category.
  3. In the Administration section, set the Enable code editing for site administrators option.
  4. Click Save.

Conclusion

From a security standpoint, the best practice is to:

  • NOT grant any of the permissions listed on this page to any roles
  • Not allow site administrators to edit code

If you do not follow this recommendation, you risk privilege escalation.


Was this page helpful?