Scope: managed applications, ordinary applications.
In addition to the configuration code, the application can execute third-party code that can be attached using external reports, external data processors, configuration extensions, add-ins, or other means (hereinafter referred to as the "external code"). A malicious user can consider various destructive actions (both in external code and indirectly by starting external applications, add-ins, and COM objects), which can harm user computers, server computers, and application data. Example of such vulnerability: https://1c.ru/news/info.jsp?id=21537 (in Russian)
The listed security issues are especially critical when configurations operate in SaaS mode. For example, with service access, malicious code can gain access to all applications of all service users at once.
1. For applications, it is prohibited to execute any code in unsafe mode on the 1C:Enterprise server that is not part of the application (configuration). The restriction does not apply to audited codes and codes that run on the client.
Examples of invalid execution of "external" code in unsafe mode:
- External reports and data processor (print forms and other), configuration extensions, add-ins, and any other similar features, using which users attach external code to a configuration.
- Algorithms in 1C:Enterprise language, query texts, or their fragments that users interactively enter in 1C:Enterprise mode, which are then passed to the Execute or Eval global context methods (see Restrictions on the use of Run and Eval on the server).
- Changes made by users to data composition schemas in reports where external functions can be used (this feature is not available when using a standard report form: it does not allow users to change the data composition schema, and common module functions cannot be used from custom fields). Including the ability for users to import data composition schemas from external files.
When Standard Subsystems Library (SSL) is used in the configuration, you can attach external code only using the matching SSL subsystems:
- As configuration extensions – using the "Core" subsystem.
- As external reports and data processors – using the "Additional reports and processings" subsystem.
- As add-ins – using the "Add-ins" subsystem.
- To start external applications, see Application launch security.
The requirement specified in this clause will be met.
2. Interactive opening of external reports and data processors by clicking File – Open must be disabled by default in the configuration for all categories of users. See cl. 2.2 and 2.3 in Standard roles.
The application settings must include an option to allow this action again. If the administrator allows you to interactively open external reports and data processors, inform them and users that they should pay special attention to the file sources and not open files from untrusted sources.
If you use Standard Subsystems Library in a сonfiguration, you can disable interactive opening of external reports and data processors. Settings and warnings are already provided as well.
3. Warn administrators about hazard before attaching any external code.
3.1. The output information must include explicit information that external code from untrusted sources might be harmful to user computers, server computers, and application data. The administrator must be able to refuse to import external code (or import it again after audit).
If Standard Subsystems Library is available in a configuration, such warnings are already provided for administrators in the subsystems.
3.2. Other application users must not receive additional warning messages when executing external code whose attachment was explicitly confirmed by the administrator.
For application disconnection, see section 7.10.2. Disabling the mechanism of protection against dangerous actions in 1C:Enterprise Developer Guide.
If Standard Subsystems Library is used in a configuration:
- Warnings can be disabled in the subsystems similarly.
- It is prohibited to disable unsafe operation warnings in all other cases.
4. If a configuration includes tools for configuration update (from .cf and .cfu files), backup recovery, or import from .dt files in 1C:Enterprise mode, these operations must be executed in accordance with the following rules:
- Updates must be available only to users with the "System administrator" role.
- Such updates must be executed only interactively by the current user and not the internal user with full rights.
- Before updating a configuration from a file or restoring it from a backup, the administrator must be warned that they must make sure that the update file is obtained from a reliable source.
- When updating a configuration over the Internet, secure connection (see cl. 7) and a trusted source must be used. Users must be warned about it when they configure update source connection parameters.
If you use Standard Subsystems Library (SSL) in a configuration, update the configuration and restore it from a backup only using the "Configuration update" and "Infobase backup" SSL subsystems. In this case, all the requirements listed above in this clause will be met automatically.
5. If a configuration includes tools for importing arbitrary files into the application, note that they can contain malicious executable code.
In this case, the configuration must include:
- Additional controls, in particular, a list of allowed (prohibited) file extensions to import to the application (for administrators).
- Locks on opening of executable files from the application (even if it is allowed to import and store them in the application).
Note: in general, malicious code can be even in non-executable files, such as macro viruses in Microsoft Office documents. However, the required unsafe operation warnings are already provided in Microsoft Office applications. So, it is not required to take any other protective measures in the configuration. An exception is opening via COM connection. See Security of software called via public interfaces.
If you use Standard Subsystems Library (SSL) in a configuration, manage files using the "File management" subsystem only. In this case, all the requirements listed above in this clause will be met automatically.
6.1. Add-ins that are not part of a configuration (not placed in configuration templates) are potentially unsafe. Do not obtain them from untrusted sources for installation and attachment. Users without administrative rights should not be able to import, install, and attach add-ins on the application server. In this case, users must always be prompted to install an add-in on the client.
Failure to comply with these requirements may affect the performance and compromise the security of the application, servers it runs on, and the user computer.
6.2. Store third-party add-ins in a catalog where write access rights are granted only to the administrator. Attach third-party add-ins only via a URL to an attribute of the catalog where add-in binary data is stored.
Do not attach third-party add-ins by a file name or an application ID as a malicious user will be able to replace the file path or the application ID, and attach their own malicious add-in.
6.3. Store add-ins that are part of the configuration in templates of the "Add-ins" type. Do not localize this template type.
6.4. If you use Standard Subsystems Library in a configuration, use methods for attaching library add-ins and completely exclude direct usage of the platform mechanisms for attaching add-ins, such as:
- AttachAddIn
- BeginInstallAddIn
- InstallAddIn
- BeginAttachingAddIn
- LoadAddIn
To attach add-ins from configuration templates on the client, use:
CommonClient.AttachAddInFromTemplate
To attach add-ins from configuration templates on the server, use:
Common.AttachAddInFromTemplate
To attach add-ins from the add-in storage (a catalog where add-ins can be updated, regardless of configuration update), use the "Add-ins" subsystem in Standard Subsystems Library:
AddInsClient.AttachAddIn
7. When importing external code from remote sources to a configuration:
- Use only trusted sources.
- Transfer data only via secure communication channels.
SecureConnection = New OpenSSLSecureConnection();
Connection = New HTTPConnection(Server,,,,,, SecureConnection);
If you use Standard Subsystems Library in a configuration, use the NewSecureConnection function of the CommonClientServer common module:
SecureConnection = CommonClientServer.NewSecureConnection();
Connection = New HTTPConnection(Server,,,,,, SecureConnection);