Updated SHAKEN standard improves security

A new version of the ATIS SIP Forum SHAKEN standard has been published. It includes important procedures to improve the security of the SHAKEN ecosystem. Let’s have a look.

Security updates to the standard

The updated standards document describes security procedures that the STI verification service must follow. To better understand these procedures, we first define a term:

Dereference: to access a thing identified by a reference or pointer.

For example, the HTTP standard includes a message response, 303 See Other, that refers a retrieval request to another resource. This response provides information that might be useful but without implying that it represents the original target resource.

Suppose an application makes a GET request to an HTTP service, then receives a 303 See Other response. The application might be programmed to then make a GET request to the other resource. In this example, the application dereferenced the other resource provided by the response to its initial request.

Now, this next part might seem technical to some, but hang in there—it should make sense in the end.

In the revised SHAKEN standard, the STI Verification Service (STI-VS) shall not:

  1. Dereference URLS that use a scheme other than “https” or a port other than 443 or 8443;
  2. Dereference URLs that contain a userinfo subcomponent, query component, or fragment identifier component;
  3. Dereference URLs if the host resolves to a special-purpose IP address;
  4. Dereference URLs that appear to be part of a Server-Side Request Forgery (SSRF) attack;
  5. Make an HTTP HEAD request to check the Content-Type or other headers before making an HTTP GET request to dereference the URL;
  6. Follow HTTP redirections, i.e., the Location header of a 3xx HTTP response (like our 303 See Other example, above).

Okay, that’s a lot of “shall nots.” What’s going on here? We need to define one more term:

Server-Side Request Forgery (SSRF). This is when an attacker tries to make a public service server make a request, either to itself or another resource, in an attempt to bypass normal access controls. The attacker is trying to find a way to get the server to make requests on his behalf using the server’s access privileges.

Server-Side Request Forgery Attack

Figure 1. Server-Side Request Forgery Attack

In the SSRF attack illustrated in Figure 1, the attacker looks for a way to get the public service server to make a request on his behalf, either to the server itself or another target resource.

The “shall nots” added to the SHAKEN STI-VS specification are designed to prevent SSRF attacks by closing such vulnerabilities.

For more information, see the updated standard ATIS-1000074.v003 – ATIS Standard on Signature-based Handling of Asserted information using toKENs (SHAKEN).

complex computer program

TransNexus solutions

TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 20 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.

TransNexus SHAKEN solutions have been designed from the outset with the SSRF prevention measures listed in the revised SHAKEN standard.

Contact us today to learn more.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.