CSRF – Tech Notes

Verifying client identity is crucial in data transmission, commonly achieved through mutual Transport Layer Security (mTLS i.e. RFC 8705), where both client and server authenticate using digital certificates. However, obtaining client TLS certificates can be complex.

The DPoP (Demonstration of Proof of Possession – RFC 9449) specification, uses cryptographic key pairs instead of TLS certificates, simplifying the process. It securely links a token to a specific HTTP request and client by including a DPoP proof (typically a JWT with a cryptographic signature) with each access token request. This method enhances security against token theft and allows dynamic key generation, operating at the application level.

RFC 9449 vs RFC 8705

RFC 9449 (DPoP) simplifies authentication by letting clients generate a private and public key pair, eliminating the need for a TLS certificate. In contrast, RFC 8705 (mTLS) requires TLS certificates for bidirectional authentication, posing challenges in certificate distribution to clients.

Challenges with DPoP:

Securely storing and distributing public keys: Ensuring clients can register and update their keys securely without risk of unauthorized access or manipulation.

Feature	DPoP (RFC 9449)	mTLS (RFC 8705)	Token Binding (RFC 8471)
Authentication	Client-side signature using key pairs	Client-side TLS certificate	Client-side cryptographic token
Integration Layer	Application layer	Transport layer (HTTPS)	Application layer
Complexity level	Simpler key management	Requires TLS certificate infrastructure	Browser support is limited
Protection	Token theft, replay, unauthorized usage	Man-in-the-middle attacks, eavesdropping	Token theft, replay
Performance	Less overhead than mTLS	Some overhead due to TLS handshake	Negligible overhead
Flexibility	Can be used with various authentication flows	Tied to TLS-based connections	Can be used with different protocols

1. Client: Generate Key pair using Web Crypto API (https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API)

Private keys can be non-extractable for more security.
For demonstration purposes, the encryption algorithm is fixed, and the JWK format is not utilized.
You can execute code snippets in the browser console to view them in action.

const payload = { "key": "abcd" };
async function generateKeyPair() {
    const keyPair = await window.crypto.subtle.generateKey(
        {
            name: "RSASSA-PKCS1-v1_5",
            modulusLength: 2048,
            publicExponent: new Uint8Array([1, 0, 1]),
            hash: { name: "SHA-256" },
        },
        true,
        ["sign", "verify"]
    );
    return keyPair;
}
const keys =  await generateKeyPair()
console.log(keys);

2. Client: Sign a request using the Private key

//gen signature
async function signData(privateKey, data) {
    const encoder = new TextEncoder();
    const encodedData = encoder.encode(data);
    const signature = await window.crypto.subtle.sign(
        "RSASSA-PKCS1-v1_5",
        privateKey,
        encodedData
    );

    return signature;
}
const signature = await signData(keys.privateKey, payload);
console.log(signature);

3. Server: Signature Verification on the server side

//verify signature
const receivedPayload = { "key": "abcd" };
async function verifySignature(publicKey, signature, data) {
  const encoder = new TextEncoder();
  const encodedData = encoder.encode(data);

  const isValid = await window.crypto.subtle.verify(
    {
      name: "RSASSA-PKCS1-v1_5",
      hash: { name: "SHA-256" },
    },
    publicKey,
    signature,
    encodedData
  );

  return isValid;
}
const isValid = await verifySignature(keys.publicKey, sigV4, receivedPayload);
console.log(isValid);

4. Server: process data and send back requested data if the signature is valid

Defination: (Source:wiki)
Cross-site request forgery is an attack technique by which the attacker can trick an authenticated user into unknowingly executing actions on your website.
(or)
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the website trusts.
Prevention methods:

Check standard headers to verify the request from same origin or not
Check CSRF token and it’s validity against to user session Id.

AngularJS will support by default to avoid CSRF attacks, we need to send XSRF-TOKEN into browsers cookie, then angular will automatically pick and append X-XSRF-TOKEN as a header.

Cookie info:

AngularJS with a general $http promise will prepare header with X-XSRF-TOKEN, if one of the domain cookies contains a token with XSRF-TOKEN key name.
If we want to change HTTP header key name, with custom XSRF token we need to provide defaults.xsrfHeaderName so that angular will prepare with custom token key.
Please check below code snap from angularJS framework for better understanding of how it works:

var xsrfValue = urlIsSameOrigin(config.url) ?
     $$cookieReader()[config.xsrfCookieName || defaults.xsrfCookieName]
     : undefined;
if (xsrfValue) {
  reqHeaders[(config.xsrfHeaderName || defaults.xsrfHeaderName)] = xsrfValue;
}

And check out this working example, inspect HTTP headers via developer tools.

 var app = angular.module('csrf_example', []);
 app.controller('MainCtrl', function($scope, $log, $http) {
 document.cookie = "XSRF-TOKEN=sjdjsdjsdbjhfg";
 $http.get('path').then(function() {
 console.log('Network call done!');
 });
 });

Category: CSRF

How to Gain Server-Side Trust on the Client-Side? DPoP (RFC 9449)