Client side securing token vulnerability circular dilemma

112 views Asked by At

I am sorry but this question needs to be long so you can understand the problem and it is absolutely relative the size of my problem, I am seeking web security experts opinion so thank you for your time in advance.

I) CONTEXT

My problem in the same context of Google Analytics, the main goal is to collect data from front end but I have no access to the front end, and there's a JavaScript script loaded from a remote server to the front end by adding in the front end by my clients (like Google Analytics). This script posts data to an API but put in mind that there is no authentication process on the front end( Imagine the front end as a tutorial web page for example). My goal is to secure these post requests, but I've encountered a challenge.

The issue is that HTTP-only cookies (HTTP-only docs ), which are typically used for authentication and security, require an initial authentication process to set the cookies for a token for example. This means that the data and tokens I want to secure may still be visible on the client side before any authentication takes place. This is a significant vulnerability because it means that anyone with access to the front end, including potential attackers, can see and potentially exploit this data.

The fact that I have no control over the front end makes it even more challenging to implement security measures, such as authentication or authorization, on the client side.

enter image description here

II) WHAT HAVE BEEN DONE

a) Token-Based Authentication and Source URL Filtering

In light of these resource limitations, I have implemented a short-lived token-based authentication system for my web clients. This approach restricts client interactions to a specific API endpoint, thereby enabling control and monitoring of client requests. Additionally, I employ source URL filtering to validate incoming requests based on their origin.

b) Identity Access Management Systems

In my pursuit of a robust security solution, I have explored Identity and Access Management systems as a potential avenue. Among the options I've considered, Keycloak has emerged as a promising solution. However, I've encountered a recurring challenge within this context.

Keycloak, like other IAM systems, requires the inclusion of sensitive data within the application. For example, the initialization of Keycloak necessitates the provision of configuration details, as illustrated below:

import Keycloak from 'keycloak-js';

const keycloak = new Keycloak({
   url: 'http://keycloak-server${kc_base_path}',
   realm: 'myrealm',
   clientId: 'myapp'
});

try {
   const authenticated = await keycloak.init();
   console.log(`User is ${authenticated ? 'authenticated' : 'not authenticated'}`);
} catch (error) {
   console.error('Failed to initialize adapter:', error);
}

You'll find all you need about it in the documentation

This situation has presented me with a recurring conundrum, as I find myself in a somewhat circular dilemma. While IAM systems like Keycloak offer security enhancements, they also necessitate the inclusion of sensitive data within the application code, which, in turn, introduces security concerns.

III) PROBLEMS AND LIMITATIONS ENCOUNTERED

a) Lack of Resources for Enhanced DDoS Security

In the context of mitigating DDoS attacks, I have encountered resource limitations, such as the absence of cloud-based infrastructure, which restrict my ability to implement certain security measures. Specifically, the option to clone the API multiple times as a means of distributing traffic and reducing the impact of DDoS attacks is not currently feasible due to resource constraints.

b) Vulnerabilities with Source Domain Name Filtering

However, it's crucial to acknowledge that this approach is not without vulnerabilities. The primary concern is that it relies on the source Domain Name as a means of filtering requests. While this method can be effective in normal circumstances, it remains susceptible to a specific type of threat.

c) Vulnerability Scenario

The vulnerability lies in the fact that an adversary, with the intent to compromise the system, could potentially create a counterfeit server that mimics my clients front end by using an identical Domain Name. In doing so, they could craft and send requests that mimic legitimate client interactions. The absence of a robust authentication process, combined with the reliance on source URL filtering, creates an opening for exploitation.

I would welcome further discussions with individuals who are interested in this topic. Together, we may explore potential solutions that align with the specific challenges I am facing.

Thank you for your time

1

There are 1 answers

0
HTTP 410 On

Threat Model

If I'm reading the question correctly, the majority of your threat model concerns abuse of the trust between the application front-end and the API. Some examples of these threats include spoofing attacks, man-in-the-middle attacks, and replay attacks.

Potential Solution

If my interpretation is correct, then I suggest you look into mutual TLS (mTLS) as a potential solution for your threat model.

How It Works

Normally in TLS, the server has a TLS certificate and a public/private key pair, while the client does not. So the typical TLS process works like this:

  1. Client connects to server
  2. Server presents its TLS certificate
  3. Client verifies the server's certificate
  4. Client and server exchange information over encrypted TLS connection

Normal TLS

But TLS also offers client-to-server authentication using client-side X.509 authentication. Both the client (in this case the app's front-end server) and server (in this case the API server) have a certificate, and both sides authenticate using their public/private key pair. Compared to regular TLS, there are additional steps in mTLS to verify both parties (additional steps in bold):

  1. Client connects to server
  2. Server presents its TLS certificate
  3. Client verifies the server's certificate
  4. Client presents its TLS certificate
  5. Server verifies the client's certificate
  6. Server grants access
  7. Client and server exchange information over encrypted TLS connection

Mutual TLS

How It Prevents Threats

Mutual authentication can prevent spoofing attacks because the server will authenticate the client as well, and verify that it has the correct session key before allowing any further communication and access.

Mutual authentication can prevent MITM attacks because both the sender and recipient verify each other before sending their message keys.So if one of the parties is not verified to be who they claim they are, the session will end.

Mutual authentication can prevent replay attacks because timestamps are a verification factor that is used in the protocol. If the change in time is greater than the maximum allowed time delay, the session will be aborted. Also messages can include a randomly generated number to keep track of when a message was sent.