Read other users orders via CDN Caching - New vulnerability in SAP Commerce (CVE-2023-37486)

This post will explain the process behind finding a security vulnerability in SAP Commerce (E-Commerce framework that many major shops are using) that allows to view orders of other users (including addresses, prices and possible other personal information). The finding was reported to SAP and fixed in the latest patch release.

So firstly: If you have your own SAP Commerce instance, be sure to update to Version 2205.14 or higher (on prem) or Version 2211.9 (in cloud).

Details on the vulnerability

SAP Commerce has a REST API to access various data, specially used for the SAP Composable Storefront (aka Spartacus - the Angular Frontend for SAP Commerce). One of the endpoints allows fetching all orders of the users. The endpoint is correctly secured to only be able to fetch the own orders. But let's take a look at a response:

GET https://<sap-commerce-server>/occ/v2/<some-base-site>/users/current/orders
> HTTP 200 OK
> cache-control: public, max-age=120
> cf-cache-status: HIT

The caching header of the response is very problematic if a CDN like Cloudflare is used. Because the response will be stored inside the CDN and shared across multiple users. So users can see other users orders, even as the endpoint is secured correctly, just by abusing the shared caching layer. The header is set like this in the Spring Controller:

@Secured("...")
@CacheControl(directive = CacheControlDirective.PUBLIC, maxAge = 120)
@RequestMapping(value = "/users/{userId}/orders", method = RequestMethod.GET)
public OrderHistoryListWsDTO getUserOrderHistory(...) {
    // validation code to check permissions
    // code to handle the request
}

The important part is the CacheControl annotation, which controls the response cache header and causes the problem. Private or None would be safe values here.

How can this vulnerability be used?

The usage of this vulnerability is quite simple: An attacker can fetch the REST endpoint above over and over and hope, that some real user has fetched the endpoint less than 120 seconds ago. This is the time that a response will be cached. The attacker does not even need a login, he can request the endpoint without authentication, which makes the detection even simpler: If the response is a HTTP Status 200, it is likely a cached response from someone else.

How can I protect myself?

If you use SAP Commerce, update to the latest patchlevel. As a quickfix, the response can be manually excluded from Caching in the shared cache like Cloudflare. See also the SAP security note for more information: https://me.sap.com/notes/3341934

What can be learned?

Caching Headers are also relevant for security. Be sure that a resource is really public if the Cache-Control header is set to public. If you have any API endpoint returning personal data, make sure to never set the "public" cache control header, always set it to "private" or "none".