Restrictions on external developments

Scope: managed applications, ordinary applications.

In addition to the configuration code, the application can also run third-party code through external reports, external data processors, configuration extensions, or add-ins (referred to as "external code"). A malicious user could attempt various harmful actions through this external code or indirectly by launching external applications, add-ins, and COM objects, potentially causing damage to user computers, server computers, and application data.

These security concerns are especially important when applications are running in SaaS mode. If malicious code gains access to the service, it could potentially access all applications of all service users.

1. Applications must not run any code on the 1C:Enterprise server that is not part of the application unless in safe mode. This rule does not apply to audited code or code running on the client side.

Here are some examples of unsafe execution of external code:

Attaching external code to a configuration through external reports and data processors (such as print forms), configuration extensions, add-ins, or similar features.
Using algorithms written in 1C:Enterprise language, query texts, or their fragments that users input interactively in 1C:Enterprise mode, which are then passed to the Execute or Eval global context methods (see Running Eval and Execute on the server)
Modifying data composition schemas in reports where external functions can be utilized. This functionality is not supported when using a standard report form. It restricts users from altering the data composition schema and prohibits the use of common module functions in custom fields. Importing data composition schemas from external files would also pose a risk.

For configurations that embed Standard Subsystems Library (SSL), you can only attach external code using the corresponding SSL subsystems:

For configuration extensions, use the "Core" subsystem.
For external reports and data processors, use the "Additional reports and data processors" subsystem.
For add-ins, use the "Add-ins" subsystem.
To launch external applications, see Opening external applications.

This will ensure compliance with the above requirement.

2. The interactive opening of external reports and data processors from the File – Open menu must be disabled by default for all user categories. See items 2.2 and 2.3 in Standard roles.
However, administrators should have the option to enable this feature in the application settings. If administrators allow users to open files interactively, users should be cautious and verify the sources of files before opening them. Make sure to inform users and administrators accordingly.

The relevant settings and alerts are already in place in configurations that include Standard Subsystems Library.

3. Administrators must be alerted to potential hazards before attaching any external code.

3.1. The warning message must clearly state that external code from untrusted sources could pose a risk to user computers, server computers, and application data. Administrators must be able to deny the import of external code or re-import it after conducting an audit.

These alerts are already in place in configurations that include Standard Subsystems Library.

3.2. Other users must not receive additional alerts when running external code that has been explicitly approved by the administrator.
To disable this feature programmatically, see Disabling the unsafe action protection in 1C:Enterprise Developer Guide.

For configurations that include Standard Subsystems Library:

Such alerts can be turned off within the respective subsystems.
It is not allowed to deactivate alerts for other unsafe operations.

4. If a configuration provides tools for updating (from .cf and .cfu files), restoring backups, or importing from .dt files in 1C:Enterprise mode, follow these guidelines:

Updates must only be accessible to users with the "System administrator" role.
Such updates must be performed interactively by the current user and not by a utility user with full privileges.
Before updating a configuration from a file or restoring it from a backup, administrators must be reminded to verify that the update file is obtained from a trusted source.
When updating a configuration online, a secure connection (see it. 7) and a trusted source must be used. Inform users accordingly when they set up connection parameters.

For configurations that embed Standard Subsystems Library, updates and restores should only be performed using the "Configuration update" and "Infobase backup" subsystems. This will ensure compliance with all requirements outlined in this section.

5. If a configuration includes file import tools, be aware that these files may contain malicious executable code.
To address this issue, provide the following:

Additional controls, such as a list of approved and restricted file extensions to import into the application (for administrators).
Locks on opening executable files from the application, even if they are allowed to be imported and stored.

Malicious code can also be present in non-executable files, like macro viruses in Microsoft Office documents. However, Microsoft Office applications already provide security alerts, so no additional protective measures are necessary in the configuration, except for opening via COM connection. For more information, see Accessing applications through public interfaces.

For configurations that embed Standard Subsystems Library, manage files using the "File management" subsystem only. This will ensure compliance with all requirements outlined in this section.

6. Add-in security

6.1. Add-ins that are not part of a configuration (not included in configuration templates) can pose a security risk. Obtain add-ins only from trusted sources. Do not allow add-ins to be imported, installed, or attached on the application server by users who do not have administrative privileges. Always prompt users to install an add-in on the client side.

Non-compliance with these requirements could have performance and security implications for the application, its servers, and user computers.

6.2. Store third-party add-ins in a catalog that only administrators can write to. Attach these add-ins using a URL to a catalog attribute that stores the add-in binary data.

Avoid attaching third-party add-ins by file name or application ID, as a malicious user could manipulate the file path or application ID to attach their own harmful add-in.

6.3. Store configuration add-ins in "add-in" templates. Do not localize this type of template.

6.4. For configurations that embed Standard Subsystems Library, employ methods for attaching library add-ins and refrain from directly using the following platform mechanisms:

AttachAddIn
BeginInstallAddIn
InstallAddIn
BeginAttachingAddIn
LoadAddIn

For client-side attachment from configuration templates, use:

CommonClient.AttachAddInFromTemplate

For server-side attachment from configuration templates, use:

Common.AttachAddInFromTemplate

To attach add-ins from the add-in storage (a catalog where add-ins can be updated independently of configuration updates), use the "Add-ins" SSL subsystem:

AddInsClient.AttachAddIn

7. When importing external code from remote sources into a configuration:

Use only trusted sources.
Transfer data through secure communication channels.

SecureConnection = New OpenSSLSecureConnection();
Connection = New HTTPConnection(Server,,,,,, SecureConnection);

For configurations that embed Standard Subsystems Library, use the NewSecureConnection function of the CommonClientServer common module:

SecureConnection = CommonClientServer.NewSecureConnection();
Connection = New HTTPConnection(Server,,,,,, SecureConnection);

See also: