Server API security

   

Scope: managed applications, mobile applications, and ordinary applications.

In managed application mode, a client application (thin or web client) accesses the 1C:Enterprise server through an open HTTP connection. This means that third-party applications can also access the 1C:Enterprise server, exposing it to the risk of unauthorized access to user data and potentially compromising server security.

1. Unauthorized client calls to the server-side code.

1.1. All server-side procedures and functions available from the client code are potential security threats. They constitute the 1C:Enterprise server API and typically include:

• Export procedures and functions in common modules with the "Server" and "Server call" flags selected. These can be called directly from the client side.

For more information, see Common modules: Server call property

• All procedures and functions in object form modules with compilation directives &AtServer and &AtServerNoContext. Even if these procedures and functions are not export ones, they can still be called from the client context after a form has been successfully received. This allows code to be called in a context not intended by the developer.
  
  For example, the Catalog.Employees.ItemForm form module contains the following code:

&AtClient

Procedure DismissEmployee(Command)

If DismissalRegistrationDate > PeriodEndClosingDate Then

RegisterDismissal();

EndIf;

EndProcedure

&AtServer

Procedure RegisterDismissal()

...

EndProcedure

Consider how calling the server procedure directly can bypass the check provided by the developer in the DismissEmployee procedure:

FormParameters = New Structure("Key", SelectedEmployee)

Form = GetForm("Catalog.Employees.ItemForm", FormParameters);

Form.RegisterDismissal();

1.2. In general, server-side procedures and functions of form modules should only handle client/server interaction or form attribute processing and should not contain any business logic.

1.3. Pay special attention to server-side procedures and functions stored in common modules flagged as Privileged, and to those that use privileged mode.

2. Risk of unsafe code infiltrating the server.

Security risks are posed by any configuration functionality that allows external code or queries not part of the application to be executed on the server.

External reports and data processors, COM objects, and add-ins also pose risks. For example, external data processors can directly access common modules with the "Server call" flag cleared, object modules, and object manager modules, and attempt to switch to privileged mode.

Such functionality can degrade server performance by introducing incorrect or malicious code. This can lead to problems like data corruption or theft, process hangs or stops due to looping, memory leaks, and resource-intensive operations and queries.

For more information, see Restrictions on external developments

3. The client application (thin client or web browser) does not guarantee the security of data transferred to the client side. Malicious software on the client computer could intercept and read this data easily.

Server procedures and functions must return only final calculation results to the form. Avoid sending any initial or intermediate data to the form, as this could expose sensitive business process information.