페이퍼 세미나 · 결제 프로토콜 보안
HTTP 402 상태 코드를 부활시켜 API·콘텐츠·AI 에이전트가 온체인으로 마이크로페이먼트를 주고받게 하는 x402 프로토콜. 동기식 HTTP 인가와 비동기식 블록체인 정산이 만나는 지점에서 새로운 교차 계층(cross-layer) 공격면이 열린다. 이를 각각 다른 각도에서 파고든 두 편의 논문을 정리했다.
두 논문 모두 다음 3단계 흐름을 공격 분석의 기준으로 삼는다.
402와 함께 결제 조건(금액·수신 주소·네트워크 등)을 응답.X-PAYMENT 헤더를 붙여 요청을 재전송.Five Attacks on x402 Agentic Payment Protocol · Zelin Li, Qin Wang, Zhipeng Wang
이 논문은 x402를 형식적으로(formally) 분석한 뒤, 설계·구현 양쪽에서 실증한다. 다섯 공격은 인가(authorization)·바인딩(binding)·재전송 방어(replay protection)·웹 계층 처리(web-layer)의 약점을 각각 겨냥하며, 결과적으로 돈은 안 냈는데 서비스는 받거나(unpaid service), 반대로 돈은 냈는데 서비스는 거부당하는(paid-but-denied) 두 가지 결말로 이어진다.
확률적 다항시간(PPT) 공격자를 가정하며, 능력별로 나눈다: 네트워크 계층 공격자(메시지 지연·재정렬), 손상된 클라이언트, 비잔틴 facilitator, 유한성(finality) 범위를 지키는 블록체인 조작자, honest-but-curious 서버. 암호 프리미티브 자체는 안전하다고 전제한다.
서버가 블록체인 확정 전에 낙관적으로(optimistically) 리소스를 먼저 내준다. 이후 체인 재구성(reorg)으로 결제 트랜잭션이 사라지면 — 서비스는 이미 제공됐는데 돈은 없어진다.
5.18%의 의미: 저자들이 통제한 로컬 실험·분석 모델에서 확인 없이 즉시 발급(k=0), 블록 시간 2초, 주입된 reorg 확률 5%, 지연 400ms 조건으로 요청 5,000건을 실행했을 때 약 259건에서 서비스 발급 후 결제가 사라졌다. 이는 실제 Base 메인넷의 자연 발생률이 아니라 인위적으로 reorg와 지연을 주입한 조건부 결과다. Base Sepolia에서는 grant–finality 사이의 시간적 틈만 확인했으며 실제 reorg 확률은 추정하지 않았다.
공격자가 노출된 결제 인가를 복사해 먼저 정산하고 nonce를 소비한다. 피해 지불자는 실제로 결제하지만 정상 facilitator의 후속 정산이 revert되어 서비스를 받지 못한다. 일반적인 외부 공격자는 결제금을 가져가지 못하며, 주된 목적은 서비스 거부·방해다.
nonce 선점이란: X-PAYMENT에 든 서명된 결제 인가가 특정 facilitator 또는 정산 호출자에게 묶여 있지 않으면, 헤더를 본 프록시·미들웨어·악성 서버가 그 인가를 복사해 먼저 제출할 수 있다. nonce는 일회용이므로 공격자가 먼저 소비하면 정상 facilitator의 후속 정산은 “이미 사용된 nonce”로 실패한다.
재현 결과: EIP-3009 실험에서는 노출된 인가를 익명화된 Base Sepolia 엔드포인트의 정상 경로보다 먼저 테스트넷 USDC transferWithAuthorization에 제출했다. 0.0001 testnet USDC가 결제되고 nonce가 소비된 뒤, 엔드포인트의 정상 정산은 실패해 클라이언트가 HTTP 402를 받았다. Permit2에서는 x402ExactPermit2Proxy를 대상으로 관계없는 공격자 EOA가 관찰한 서명으로 settle()을 먼저 호출했고, 이후 정상 호출은 같은 nonce가 이미 사용돼 revert됐다.
누가 손해·이득을 보나:
한 줄 요약: 외부 공격자가 돈을 훔치는 공격이라기보다 “피해자는 결제, 서비스는 0”으로 만드는 paid-but-denied형 griefing이다. 단, 공격자가 악성 수신자·판매자라면 결제금을 갖고 서비스를 주지 않는 직접적 부당이득도 가능하다. 방어하려면 서명에 승인된 facilitator를 포함하고 컨트랙트에서 실제 호출자를 검사해야 한다.
settle(PP)를 프론트런해 선점 → 정당한 정산은 revert되어 지불자만 손해.이 공격은 모든 x402 구현에서 성립하지 않는다. 동일한 X-PAYMENT를 여러 요청으로 보내더라도 서버가 각 요청의 온체인 정산 결과를 끝까지 기다린 뒤 성공한 요청에만 리소스를 반환하면, 첫 요청만 HTTP 200을 받고 나머지는 nonce 중복으로 HTTP 402가 된다.
성립하지 않는 경우 — settle-before-grant: 요청 A가 settle()을 await해 결제에 성공한 뒤 리소스를 받는다. 요청 B부터는 같은 nonce의 정산이 revert되고 서버가 HTTP 402를 반환하므로, 구매자는 추가 리소스를 받지 못한다. 사용자가 지적한 흐름이 바로 이 안전한 pessimistic 경로다.
성립하는 경우 — grant-before-settle: 서버가 서명 검증(verify)만 통과하면 HTTP 200·리소스를 먼저 flush하거나, 정산을 분리된 비동기 작업으로 보내고 응답을 즉시 끝낸다. 여러 동시 요청이 정산 결과가 나오기 전 모두 verify를 통과해 리소스를 받고, 이후 온체인에서는 첫 정산만 성공하고 나머지가 revert된다. 이때는 실패가 확인돼도 이미 보낸 응답을 회수할 수 없다.
논문에서 확인한 구현 차이: SDK-B의 streaming 경로는 settle_payment 전에 응답을 완료했고, SDK-C의 optimistic 모드는 정산을 tokio::spawn으로 분리해 중복 grant가 발생했다. 반대로 SDK-C의 pessimistic 모드는 정산을 동기적으로 완료한 후 응답해 같은 재전송에서 grant가 1개로 제한됐다. 라이브 테스트에서는 한 결제 헤더를 1,000개 동시 요청으로 보냈고, 가장 강한 라운드에서 HTTP 200이 248개였지만 온체인 결제는 1건뿐이었다.
누가 손해·이득을 보나:
한 줄 요약: settle() 성공을 await한 뒤 리소스를 반환하면 이 replay로 추가 리소스를 받을 수 없다. 취약점은 정산 완료보다 HTTP grant가 먼저 나가는 구현에서 생기며, 서버는 settle-before-grant를 지키거나 발급 전에 (pay_id, resource_id)를 원자적으로 claim해야 한다.
n번 재전송했을 때, 서버가 정산 완료를 기다리지 않고 verify만으로 먼저 응답하면 Grant(n)이 나간다. 온체인 nonce 검사는 첫 정산만 허용하지만 이미 보낸 리소스는 회수할 수 없다. 반대로 settle 결과를 await한 뒤 응답하는 pessimistic 경로에서는 중복 요청이 402로 끝나 grant는 1개뿐이다.결제 헤더와 유료 응답이 일반 HTTP 프록시·CDN을 지나면서 결제 경계가 무너지는 공격이다. D1은 프록시가 헤더를 merge·truncate·재정규화해 서버가 클라이언트와 다른 결제 객체를 보게 만드는 경로이고, D2는 결제 후 응답을 공유 캐시에 저장해 다음 미지불 사용자가 공짜로 받는 경로다.
Cache-Control이 없는 nginx 캐시 실험의 미지불 요청재현 결과와 경계: 기본 nginx·Caddy는 실험 구성에서 X-PAYMENT를 변조하지 않았지만, 커스텀 MitM이 중복 헤더를 주입하자 Node/Express는 1,000건 모두 마지막 값을 선택했다. 이는 parser ambiguity를 확인한 것이며 단독 결제 우회까지 증명한 결과는 아니다. 반면 캐시 유출은 nginx에서 미지불 요청 1,000건 모두 재현됐고, Cache-Control: no-store, private를 붙이자 0건으로 감소했다. Caddy는 두 조건 모두 캐싱하지 않았다.
누가 손해·이득을 보나:
한 줄 요약: 실증된 핵심 이득은 미지불 사용자가 유료 응답을 공짜로 받는 것이다. 유료 응답에는 no-store 또는 private를 강제하고, 프록시가 결제 헤더를 합치거나 재작성하지 못하게 해야 한다.
PP → PP'로 바뀌어 서버가 402/파싱 불일치를 반환. D2 캐시 유출: no-store가 없으면 유료 응답이 프록시에 캐시돼, 미지불 Client B가 cache hit으로 콘텐츠를 공짜로 받는다.결제 전 디스커버리 단계에서 악성 판매자가 이름·설명·태그·신뢰 신호를 에이전트가 선호하도록 꾸미거나, 여러 Sybil 엔드포인트를 등록해 top-10 후보 목록을 점유한다. 지갑이나 정산 컨트랙트를 해킹하지 않고도 에이전트의 선택을 먼저 장악해 이후 결제 트래픽을 자신에게 보낸다.
재현 결과: 공개 x402 카탈로그를 이용한 통제된 디스커버리 모사에서 12개 카테고리·카테고리당 15개 질의·LLM 3종으로 총 2,160번의 선택을 측정했다. E1 메타데이터 조작은 공격 서버 하나만으로 MiniMax-M2.7 71.8%, GPT-5.3 69.4%, Sonnet 4.5 68.8%의 선택률을 보였다. E2 Sybil 공격은 서버를 1개에서 5개로 늘리자 3-LLM 평균 선택률이 27.5%에서 60.2%로 상승했다. 이는 실제 전체 x402 시장의 상시 공격 성공률이 아니라 top-10 선택 환경을 모사한 조건부 실험 결과다.
누가 손해·이득을 보나:
한 줄 요약: 공격자의 이득은 결제가 시작되기 전에 선택·매출 기회를 선점하는 것이다. 메타데이터 검증, 등록 비용·평판 기반 Sybil 저항성, 동일 사업자 노출 제한과 순위 다양화가 필요하다.
R*에 조작된 메타데이터를 등록해 상위에 올리고, E2는 다수의 Sybil 서버(R1*·R2*·R3*)를 등록해 목록을 도배함으로써 정직한 서버 Rh를 밀어낸다.no-store·private Cache-Control 부여k를 늘리면 RGP는 낮아지지만 grant까지 지연(Tgf)이 커지는 안전성-즉시성 트레이드오프.r=1·3·5). 경쟁이 적은 카테고리일수록 소수 Sybil로도 쉽게 상위 선점.When HTTP 402 Meets the Blockchain · Qinying Wang 외 (EPFL · Zhejiang University) · USENIX Security 2026
HexHive/x402scope의 README를 근거로 정리한 것이며, 정식 초록 공개 시 갱신 필요.
이 논문은 Paper 1이 "형식 분석 + 재현 테스트"에 무게를 뒀다면, 실제 라이브 facilitator와 온체인 데이터에 대한 대규모 실측(measurement)에 방점을 둔다. 도구 x402scope는 두 축으로 구성된다.
특징은 EVM(Base)뿐 아니라 Solana까지 실측 범위에 넣었다는 점, 그리고 데이터 파이프라인·규칙 위반 탐지기를 재현 가능한 프레임워크로 공개했다는 점이다. 코드: github.com/HexHive/x402scope
| 축 | Paper 1 · Five Attacks (arXiv) | Paper 2 · x402scope (USENIX) |
|---|---|---|
| 주된 방법론 | 형식적 분석 + 재현형 테스트베드 | 라이브 facilitator·온체인 대규모 실측 |
| 구조화 | 공격 5종을 계층별로 분류·명명 | 규칙 위반 탐지 + 통계적 계측 |
| 체인 범위 | EVM 중심 (Hardhat, Base Sepolia) | EVM(Base) + Solana |
| 대표 공격 | revert-grant, 정산 선점, replay, 캐시 유출, server-selection | free-shopping, ERC-1271/6492, Solana 토큰계정 악용 |
| 산출물 | 공격 분류 + 완화책 M1–M6 + SDK 3종 감사 | 오픈소스 도구 x402scope + 실측 데이터셋 |
| 공통점 | HTTP–체인 경계의 타이밍/바인딩 결함이 "무료 서비스" 또는 "지불 후 거부"로 이어진다는 문제의식 공유 | |
요약하면 Paper 1은 "무엇이 왜 깨지는가"를 체계적으로 분류·증명하고, Paper 2는 "실제 세상에서 얼마나, 어디서 깨지고 있는가"를 실측한다. 세미나에서는 두 논문을 이론적 분류 ↔ 경험적 계측의 상보 관계로 배치하면 이야기가 자연스럽다.