Receiver Validation HTTP - Enhance Your Security b...

thomas_weiss · ‎2024 Dec 31

Introduction and Overview

SAP recommends receiver validation to control destination usage in outgoing HTTP(S) connections. This new feature improves your security by helping to prevent the insecure practice of destination sharing - that is many applications using the same destination. Just use an application destination - instead of a classic SM59 destination - and set up your outbound HTTP communication via communication targets (CoTas) to profit from receiver validation. This new feature is supported as of release 2408 in SAP BTP ABAP Environment and SAP S/4HANA Cloud Public Edition for HTTP(S) connections from these platforms to other ABAP and non-ABAB platforms.

In the future, support of receiver validation HTTP is also planned:

In SAP S/4HANA and SAP S/4HANA Cloud Private Edition.
For other protocols, such as RFC and ABAP push channel (APC).
With destination service destinations instead of application destinations.

In this weblog you will get to know,

Why destination sharing – though it is convenient – is insecure and generally comes with highly privileged users on the server.
How receiver validation supports you in having control on destination use and helps you to prevent destination sharing.
The two main entities that bring about receiver validation: application destination and CoTa.
The additional benefits of an application destination over a classic SM59 destination.
How to have an application destination generated by creating and saving the respective entities in the usual tools for outbound communication management.
How to set up an HTTP connection via CoTas (that is with receiver validation).

Why Destination Sharing Is Insecure

You might ask yourself why you should use receiver validation, which helps to prevent HTTP-destination-sharing, if this practice seemingly saves you a lot of time. Maybe so far, you have been used to sharing destinations among many applications that call different HTTP services in the same remote system and therefore you might be hesitating to drop this habit. In fact, unless you are an IT security expert, at first sight, it might not be obvious to you that this practice is insecure and risky. But once the risk becomes real, the incurred damage might be huge in comparison to the effort needed to avoid destination sharing. So let us unpack piece by piece how destination sharing facilitates attacks on your server and how receiver validation helps prevent these risks. Surely once you have understood how insecure destination sharing is, you will be interested in using receiver validation HTTP and avoiding this insecure practice:

Let us suppose that we have many applications that each call distinct HTTP services in the same remote system using the same destination. Often in such a situation, each HTTP service accesses different protected resources and performs operations on them, which means that each HTTP service requires its own distinct permission set. Since the same destination is used to access all these HTTP services, the respective user must have the combined permissions of all these permission sets, which, in general, makes this user highly privileged. You will better understand why such a highly privileged user is insecure once you grasp that, in an important respect, permissions in a program function like physical keys for a lock: Just as a particular permission may give access to digital resources such as a table of your employees’ master data, a physical key may unlock a room and, for example, give access to a storage of expensive integrated circuits.

So how risky is the following situation? Since it is convenient for a large company to use the same key for lots of different rooms on its premises, from the highly secured room that contains the company’s most valuable documents, the production control room, and its backup power supply room to the fitness room, the bike room and the storage room for postal parcels, the same key gives access to all of these rooms. They have copied this key many times and distributed it to all persons who need to access any of these rooms: not only to the company’s authorized representatives, its production control room operators and security officers, but also to all your company’s bike commuters and fitness room users and also to the externa parcel delivery men.

Still, (at least) on second thought, we all agree that this company takes unnecessary risks: For example, external parcel delivery men only need a key to the parcel storage room to do their job. There is no need to give them access to any other room, let alone to highly secured areas such as the emergency power supply room. The same is true analogously for all the different rooms and groups of employees mentioned in this example. So why should an employee or external service provider have access to any rooms on a company’s premises that he does not need to enter in order to do his job? The more employees and external staff possess and use a particular key, the higher is the probability it might get lost or stolen. And once this happens, the risk of serious harm is very high, because whoever gets into possession of this key has access to a lot of rooms including highly secured ones. This is why it is insecure, when different groups or persons use the same key to access many different rooms.

The same is true of permissions to access digital resources and to perform specific operations on them: It is insecure to bundle the permissions needed for many different HTTP services, because they are called from different applications with the same user: Usually, permission needed for distinct HTTP services differ in their criticality, and it would be unnecessarily insecure to map a client-side user - who only needs to call an HTTP service which requires less critical permissions on the server - to a server user with far more wide-reaching and critical permissions. For example, just because all these HTTP services on the same host mentioned below are called by applications running on the same client system, there is no reason to give all users who only need permission for the HTTP service “retrieve_menus_of_the day” (which includes read access to uncritical data) also permission for the HTTP service “CHANGE_GROCERIES_ ORDERS” (which requires permissions for more critical resources and operations on them), let alone permission for the HTTP service “CHANGE_CANTEEN_EMPLOYEE_SALARY”.

Having a user with the combined permissions required for all the HTTP services called by many different applications that use the same destination is particularly dangerous if some of the relevant permissions required for some of these services include access to very critical data and operations on this data. If an intruder gains access to the relevant system and impersonates a highly privileged user with a comprehensive permission set, this attacker might, for example, be able to easily delete millions of your company’s most valuable data sets or steal the cutting-edge results of its most proficient research teams.

Receiver Validation Helps to Prevent Destination-Sharing

One way to make attacks like this more difficult is to avoid highly privileged users with bloated permissions. Just give each user only the permissions he needs to do his job, which is called the principle of least privilege. In terms of destination usage, ideally, this principle would require you to have a destination for each application that calls HTTP services in a particular system or even a destination for each of these HTTP services. Then each user on the server needs only permissions for the HTTP services called by a specific application or even only the permission for one of the HTTP services called by an application. Under real-world conditions, you should at least keep the overview of the applications using a specific destination and keep their number as low as possible so that the respective user on the server side does not accumulate too many permissions

While SAP does not deliver a tool to control the usage of SM59 destinations, this is possible, if you use receiver validation’s application destinations. This feature enables an application developer to completely prevent an application destination from being used by applications from other software components and to keep the overview of the applications that actually use a destination. Before we look into the underlying mechanism of how this is achieved, you need to know more about receiver validation’s two basic entities.

Communication Target and Application Destination

Communication target (CoTa) and application destination are the main entities that bring about receiver validation and other benefits, which are explained below in the section "Additional Benefits of CoTa and Application Destination".

The application developer creates, changes, and deletes a CoTa in ADT and when you save it, a CoTa transport object and a CoTa class are created at the same time.
In the CoTa you can define a path-prefix, which is optional, and whether the respective CoTa can have exactly one or many assigned application destinations, which is mandatory.
An application destination, as it is currently supported in SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition, always is a client-specific configuration object that encapsulates information about target system, authentication method etc. It is generated once you create and save a suitable communication arrangement that is one (indirectly) related to a CoTa. (You find more on this relationship at the end of the section "Create an HTTP Request Using a CoTa and an Application Destination".)
While each application destination is uniquely assigned to a CoTa, a CoTa can be assigned to several application destinations, which means, there is a one-to-many relationship between CoTa and application destination.
At runtime, you need both objects to set up an HTTP connection with receiver validation: You need an application destination to instantiate the CoTa class, and you use a method of this CoTa instance to create an instance of CL_WEB_HTTP_CLIENT client, which draws the information about the properties of the respective HTTP connection from this CoTa instance.

With this information about CoTa and application destination at hand, you have all you need to understand how validating the receiver works.

How the Receiver Gets Validated

The CoTa transport object and the CoTa class are part of a package, which in turn is contained in a main package that is a software component. When an application wants to use an application destination, it needs to access the CoTa assigned to the respective application destination. The CoTa class needed to instantiate the HTTP client in your application program can only be accessed from within the same software component, unless this CoTa class is exposed in the respective software component’s interface: If you try to access it from other software components, in standard ABAP such an access violation results in a warning, in ABAP for cloud development such a violation even leads to an error. This means, in ABAP for cloud development, a CoTa class cannot be used by programs from other software components as picture 1 shows.

Picture 1: Receiver validation via package access control

Now you know

How the receiver is validated by this framework.
That receiver validation means to check whether or not an application is allowed to use a specific CoTa and thereby the application destination(s) assigned to this CoTa.
That, principally, in ABAP for cloud development – which you have to use when writing code as a customer in SAP BTP ABAP Environment or SAP S/4HANA Cloud public edition –, usage of a CoTa and its assigned application destinations is strictly forbidden: The violation of these restrictions leads to a runtime error.

In contrast, there is no such control on the usage of SM59 destinations.

Additional Benefits of CoTa and Application Destination

Above access control by the main package interface, there are more benefits to using application destinations:

Since the CoTa is a development object, you have a where-used list for this entity. Because of the close relationship between CoTa and application destination, with this list you can also keep the overview of the applications using a specific application destination and control that the number of these application does not become too large.
While all SM59 destinations are cross-client entities, in SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition, all application destinations are client specific, because, on these platforms, basically each customer is confined to his own client.
For the first time, there is a clean separation between transportable properties (defined in the development object CoTa) and local configuration properties (belonging to the configuration object application destination).
Therefore, in the CoTa an application developer can predefine relevant destination properties such as the HTTP path prefix and whether this CoTa can have exactly one or many application destinations assigned to it and have these definitions transported to other systems.

Note: The semantics of the property “path-prefix” in receiver validation is the same as in transaction SM59, which means – depending on the relevant code of your program in the client system – , the value of the path-prefix can be used as a proper prefix or as a complete path – without host name and port – to the relevant target service.

Create an HTTP Request Using a CoTa and an Application Destination

Now, let us see what you have to do as a customer in SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition with developer extensibility in order to create a program with outbound HTTP communication via CoTas from scratch. As you already know by now, in contrast to the world of classic SM59 destinations, in which these entities are created and configured only by an administrator, with receiver validation, developer and administrator both participate in entering information about the connection to the target system. The overview drawing below shows the entities to be created and managed by the developer in green, the ones in orange whose creation and management is the administrator’s job, and also the entities provided or generated by the framework or its developers. The numbers on each box signify a suitable order in which to create these entities.

Picture 2: CoTa, application destination, and other relevant entities and their relationships in outbound communication via CoTas

Let us now go through the different tasks to be performed by a customer who creates all these entities so that a program running in a global company’s central system is able to retrieve the result of some complex tax calculation from the http service CALC_TAX_DEDUC in different country-specific systems. Naturally, each country has its own specific tax laws, and therefore each country-specific system has its own specific implementation of this service, while its name and path are the same in all these systems. In this situation, you as a developer create:

(1) A CoTa of type HTTP in ADT and start by entering its name. As you know by now, in SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition, a CoTa is always client-specific, and, for the time being, there are only CoTas of type HTTP. This being so, the input fields are read-only. In our imagined scenario, path and name of the HTTP service CALC_TAX_DEDUC is the same in each country-specific system, but each of these systems has a different host name. Therefore, you specify the complete path in the field “path-prefix”. Since you need to reach the relevant HTTP service in different country-specific systems, you define that this CoTa can have many assigned application destinations.

Note: As for each development object in ABAP, you must enter the name of a package and assign it to a transport request or make it a local object when you create a CoTa, an outbound service, and a communication scenario.

(2) An outbound service in ADT: In addition to the usual properties, just choose the new type “Communication Target”, enter the name of your CoTa and decide to synchronize (means “to keep”) the path-prefix passed from the CoTa instead of overwriting it.

(3) An outbound communication scenario in ADT: In addition to the scenario name itself, you enter the name of the respective outbound service. Again, you synchronize the path-prefix.

(4) A customizing table: Since, in our scenario, there are different country-specific target systems, you need one application destination for each country and a location where to keep the name of each of them so that the application can dynamically select one of these names as it is needed. (A detailed code example of how to set up such a customizing table for application destinations can be found in the SAP Help documentation Calling an HTTP Service via Communication Targets in the example section under the header “Create a customizing table to store the name of the application destination”. This code shows the syntax required to handle the case of a CoTa with several application destinations, but, of course, its semantics is not the same as in our example in this weblog.)

(5) Some code to automatically insert the name of an application destination into the customizing table each time such a destination is created. To achieve this, you implement the after-deployment BAdI communication_management so that it retrieves the relevant application destination’s name and stores it in your customizing table with a suitable country key. (Again, there is a detailed code example for this in the SAP Help documentation Calling an HTTP Service via Communication Targets in the example section , this time under the header “Retrieve the name of the relevant application destination”.)

(6) The application’s program code including a dynamic select of the relevant country-specific application destination by country from our customizing table. (You will find some more details on this this below in the section "The Code Needed for an HTTP Request That Uses an Application Destination" including a link to a code example in SAP Help documentation.)

Note: In our example scenario, we work with a customizing table with a column for the country to store the different application destinations, but you could also persist these destinations somewhere else, for example in a file, and use a different way to specify their country.

Now the developer’s job is completed. The other two tasks are to be performed by an administrator, who needs to create:

(7) A communication system for each country by entering, among other things, a name for this entity, a host name, username and password (in the target system) because, to keep things simple in this example, we use basic authentication on the server.

(8) For each country a specific communication arrangement assigned to the respective country-specific communication system – created at bullet point 7, above – and the communication scenario – created at bullet point 3, above. It is common to create the communication system using forward navigation from the communication arrangement, we have a separate bullet point for the creation of the communication system so that it is easier to distinguish the different entities.

Note: In the outbound service, in the communication scenario, and in the communication arrangement, you can choose whether or not to keep the path prefix provided that it has been set. If you – as in our example – set a path prefix in the CoTa-ADT-tool and keep – that is “synchronize” - it in all these entities, the generated application destination inherits this property from the CoTa.

When you save such a communication arrangement, the framework generates an application destination and stores it in the database. You might also say that the communication system gets instantiated as an application destination. And this happens because the respective communication arrangement and communication system assigned to it are indirectly related to a CoTa. This means: The communication arrangement is assigned to an outbound communication scenario that references an outbound service of type “Communication Target” which means that this outbound service has a reference to a CoTa. Picture 3 below illustrates this relationship.

Picture 3: The (indirect) relationship between application destination and communication target

In SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition you configure the application destination in the communication system, with the exception of the path prefix, which can be predefined in the CoTa, but also be overridden in the communication service, the communication scenario, and the communication system.

Note: If you create many communication arrangements – each with a different communication system assigned to it - for a communication scenario that is related to a CoTa, there is a one-to-many relationship between CoTa and application destination, which means: You get many application destinations assigned to this CoTa. If you have just one communication arrangement – and only one assigned communication system instantiated as an application destination -, you have a one-to-one relationship between CoTa and application destination.

The Code Needed for an HTTP Request That Uses an Application Destination

Basically, in your client program you need to perform three steps to set up an HTTP connection via CoTas, if, as in our example, the relevant CoTa is assigned to several application destinations:

Write a SELECT statement to pick the name of the application destination of the relevant country you need from your customizing table.
Instantiate your CoTa class by passing the application destination name to the constructor.
Create your instance of cl_web_http_client by calling the method create_web_http_client() on the CoTa instance and call the usual instance methods to set up an HTTP request.

(Again, if you want to know more code details, have a look at a code example in the SAP Help documentation Calling an HTTP Service via Communication Targets in the example section under the header “HTTP Service Call”.)

Summary and Outlook

Now you know:

Why sharing destinations among different applications is insecure.
How receiver validation helps you to control applications’ access to a CoTa and its assigned application destinations and to prevent destination sharing.
Receiver validation’s basic entities CoTa and application destination as well as relevant properties of these two entities.
Additional benefits of using receiver validation such as the option to predefine the path prefix in the CoTa and to have it transported to other systems.
How to generate an application destination by creating and saving the respective entities for outbound communication management – provided the respective outbound service is of Type “Communication Target”.
How to configure an application destination in the communication system.
The code needed to create an outbound HTTP(S) connection via CoTas, that is a connection that uses an application destination and thereby enables receiver validation.

For the future, it is planned to support receiver validation also:

In SAP S/4HANA and SAP S/4HANA Cloud Private Edition, and to support there – in contrast to SAP BTP ABAP Environment and SAP S/4HANA Cloud public edition - both cross-client and client-specific applications destinations.
For other protocols, such as RFC and ABAP push channel (APC).

With destination service destinations instead of application destinations.

In a nutshell, receiver validation HTTP improves your security by helping you to prevent destination sharing among different applications and to control the use of application destinations. Therefore, SAP recommends using receiver validation wherever it is possible.