webhook 하나에서만 HMAC 불일치가 나요 (이름에 악센트가 들어간 것)

문제는 update()에 넘기는 인코딩이 아니라 JSON.parse → JSON.stringify 왕복이라고 봐요. 그래서 인코딩을 바꿔도 아무 변화가 없었던 거고요.

HMAC은 파트너가 서명한 바로 그 바이트에 대해 계산돼요. 파싱했다가 다시 stringify하면 파트너의 직렬화가 아니라 내 직렬화를 서명하게 돼요. 순수 ASCII에 compact 포맷인 페이로드는 둘이 바이트까지 똑같이 나오는 경우가 많아서, evt_2051이랑 evt_1001은 운 좋게 통과한 거예요. evt_2044에는 non-ASCII 문자가 있고, 직렬화기들이 갈리는 지점이 바로 거기예요. 파트너가 Zo\u00eb Ram\u00edrez처럼 이스케이프해서 보내면 (Java/PHP/Python 인코더 중에 기본값이 그런 것들이 있어요), JSON.stringify는 리터럴 Zoë Ramírez를 내놓고, 그래서 digest가 달라져요. 반대 경우도 있을 수 있어요. 키 순서, 공백, 숫자 포맷도 다를 수 있지만 지금 증상에는 악센트가 제일 잘 맞아요.

해결: delivery.raw를 손대지 말고 그대로 해시하세요.

const expected = crypto
  .createHmac("sha256", secret)
  .update(delivery.raw)   // string or Buffer, exactly as received
  .digest("hex");

JSON.parse는 서명이 확인된 다음에만 호출하세요. 전달 내용을 디스크에 저장해 뒀다면, 그걸 쓴 쪽이 텍스트를 다시 인코딩하거나 정규화하지 않았는지도 확인하세요. raw Buffer를 저장하는 게 가장 안전해요.

고치는 김에 digest 비교도 === 말고 crypto.timingSafeEqual로 하세요. 문서: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

도움이 됐으면 좋겠어요. raw로 하면 2044가 해결되는지도 알려 주세요.

const payload = JSON.stringify(body);

이 줄이 문제예요. 파트너는 자기네 바이트에 서명한 거지, 여러분의 JSON.stringify가 만든 걸 서명한 게 아니에요. 제 경험상 이런 문서에서 "the JSON payload"는 항상 raw body를 뜻해요. delivery.raw를 그대로 해시하고, 검증한 뒤에 파싱하세요.

https://nodejs.org/api/crypto.html

네, 그거였어요. delivery.raw를 해시하고 그다음에 파싱할게요. (다른 훅용 셸 스크립트는 이미 그렇게 하고 있어요.)

운이라는 말엔 동의하기 어려워요. 파트너 문서에 non-ASCII를 이스케이프한다고 나와 있으니까 2044는 어차피 실패할 수밖에 없었어요.

Stripe 스타일 웹훅에서 똑같은 일을 겪었는데, raw body를 해시하니까 해결됐어요. 문서: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

raw body를 해시해야 한다는 건 동의해요. 다만 "the JSON payload는 항상 raw를 뜻한다"는 말에는 좀 반대하고 싶어요. 문서에서 그 표현을 느슨하게 쓰는 경우가 정말 많고, 애초에 tess.p도 그것 때문에 걸렸던 거 아닐까요?

리플레이 체커에 한 가지 주의할 점이 있어요. 저장해 둔 전달 내용을 utf8 문자열로 읽었다가 다시 썼다면 BOM이나 CRLF가 바뀌어서 똑같이 digest가 깨질 수 있어요. 저라면 raw를 처음부터 끝까지 Buffer로 유지하겠어요. 그리고 나중에 Express 뒤에 두게 되면, 여러분이 body를 볼 때쯤엔 express.json()이 이미 파싱을 끝낸 상태예요. 돌아가는 방법은 두 가지예요.

// option A: keep the bytes next to the parsed body
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; },
}));

// option B: raw only on the webhook route, parse after verifying
app.post("/hooks/billing", express.raw({ type: "application/json" }), (req, res) => {
  // req.body is a Buffer here
});

저는 B 쪽으로 기울어요. 실수로 엉뚱한 걸 해시하기가 더 어렵거든요. 그래도 기존 앱에는 A가 덜 침습적이에요. 리뷰에서 어느 쪽을 변호할지는 잘 모르겠어요.

운이라는 건 통과한 쪽 얘기였지 실패한 쪽 얘기가 아니에요. 이스케이프로 2044는 설명이 되지만, 2051은 공백이랑 키 순서가 우연히 JSON.stringify와 같았기 때문에 맞은 것뿐이에요. 그게 보장된 건 아무것도 없었어요.