Skip to end of banner
Go to start of banner

How to secure use of SQL macros

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Description

When using SQL for Confluence on sites with untrusted users, you may need to employ security measures to control use. This describes some of the techniques for doing this. In some cases you may want to employ multiple techniques together depending on factors like database being accessed. For instance, macro security can be applied no matter what other technique you want to use. 


TechniqueDescriptionBenefits
Macro Security for ConfluenceContent using SQL macros can only be created or updated by trusted users while still allowing other users the ability to view the content. This is implemented by the Confluence administrator installing Macro Security for Confluence using UPM and configuring access.
  • Enables trusted users to provide important content.
  • Controlled at the user, group, and database level.
Database permissionsDatabase permissions for the user configured for the SQL data source can be restricted. For instance, view only authority. This is recommended when only subset of access is needed, especially for browse only.
  • Controls what database operations are allowed.
  • Ease concerns for database or security administrator.
Allow only SQL-query MacroSome databases (like PostgreSQL) enforce a JDBC remote access mode for read-only. The sql-query macro uses this support. This can be implemented by having the Confluence administrator disable the other sql macros in the UPM.
  • Restrict access to query only.
Allow only SQL-file Macro The sql-file macro only runs Confluence administrator controlled SQL. This can be implemented by having the Confluence administrator disable the other sql macros in the UPM. See How to securely run SQL queries without page edit restrictions.
  • Only pre-defined SQL can be run.
Role based securityUse database role security to control what data is available.
  • Data shown based on user id and role.
Use parameter markers

Prevent SQL injection attacks by using parameter markers. This in only necessary when the SQL statements are partially constructed from user input - for example, using the Run Self-Service Reports for Confluence. See Wikipedia: SQL injection. Parameter markers are supported by SQL for Confluence.

  • Prevent SQL injection attacks when users are allowed to provide statement construction input.

Confluence database access

If Confluence database access is defined via a application server data source, Confluence data can be accessed by the SQL macros using that data source unless other security techniques prevent access. This can be powerful in many circumstances, but should be access controlled just like other databases. Direct access to a database circumvents application level security, so should always be considered. Even if you want to provide some level of access to the Confluence database, it is strongly recommended to create a separate data source for this access. Either duplicate the application server data source definition that Confluence uses and provide a different name (preferred) or create a profile defined data source. To prevent access to the Confluence defined data source, either use Macro Security for Confluence to disallow access or define a profile defined data source with the same name as the application data source and override the values or re-direct to some other data source.

  • No labels