내 에이전트가 헛돈을 날렸습니다: x402 결제에 대한 6가지 공격 - Ishween Kaur, SoFi

Highlights

• X402 프로토콜은 기계 간 소액 결제 문제를 해결하기 위해 HTTP 402 상태 코드를 활용하여 온체인 결제 방식을 제공합니다.

• 구매자가 등록된 가격과 판매자가 헤더를 통해 마지막 순간에 변경한 가격을 코드로 비교하는 가드를 적용하면 가격 조작 공격을 차단할 수 있습니다.

• 온체인에서 결제 번호는 고유하므로, 공유 스토리지를 활용해 중복 결제 번호를 관리하면 동일한 요청에 대한 중복 청구와 데이터 노출을 방지할 수 있습니다.

• 판매자 측에서 성능 향상을 위해 공개 URL에 데이터를 캐시할 경우 다른 구매자가 비용 없이 데이터를 얻을 수 있으므로, 캐시 제어에 'no store' 헤더를 설정하거나 유료 장벽 뒤에 두어야 합니다.

• 사칭 사이트나 도메인 변경에 대응하기 위해 허용 목록과 차단 목록뿐만 아니라 신규 판매자를 검토하는 수습(Probing) 목록을 함께 운영해야 합니다.

• 프롬프트 인젝션으로 인해 에이전트가 프리미엄 요약 비용을 추가 지출하는 문제를 막기 위해 특정 턴에서의 호출 횟수 제한 규칙을 적용할 수 있습니다.

Timeline

1. 00:00 - 04:05

   X402 프로토콜과 에이전트 결제의 배경

   인터넷 초기부터 존재했던 HTTP 402 상태 코드는 결제가 필요하다는 표시였으나 구체적인 결제 방법을 제공하지 않았습니다. X402 프로토콜은 구매자, 판매자, 촉진자, 체인이라는 네 가지 주체를 통해 기계 간 소액 결제 공백을 메꿉니다. 에이전트가 시장 데이터 조회 등을 위해 수 센트 단위의 결제를 빈번하게 수행하므로, 높은 수수료의 신용카드 대신 온체인 거래가 확장성을 보장합니다.

   • 소프트웨어가 직접 구매 주체가 되는 에이전틱 결제 환경에서 X402 프로토콜은 기계가 결제하는 방법을 정의합니다.
   • 신용카드는 소액 결제 시 수수료가 더 비싸지기 때문에 온체인 기반의 소액 결제 시스템이 필수적입니다.
   • 에이전트가 자율적으로 결제 기능을 수행할 수 있지만, 예기치 않게 비용을 낭비하는 상황을 막기 위해 보안성 검토가 필요합니다.
2. 04:05 - 07:03

   가격 조작 및 중복 결제 취약점

   디렉토리에 등록된 가격과 실제 결제 헤더에 담긴 가격이 다를 때 가드를 추가하지 않으면 에이전트가 더 높은 금액을 여러 번 지불하게 됩니다. 구매자와 판매자 측 모두에서 등록 가격과 실제 청구 가격을 코드로 비교하는 검증이 필요합니다. 또한 동일한 결제 번호로 여러 번 데이터를 요청하는 경우, 공유 스토리지를 통해 이미 처리된 건임을 확인하고 409 충돌 에러를 반환하여 자원을 보호해야 합니다.

   • 판매자가 헤더를 통해 마지막 순간에 가격을 임의로 변경할 경우 가드 코드가 없으면 초과 지불이 발생합니다.
   • 온체인에서 결제 번호는 고유하므로 동일한 번호로 여러 번 요청하더라도 정산 단계에서 거부됩니다.
   • 공유 스토리지를 두어 결제 번호와 요청 상태를 관리하면 중복 청구와 기밀 데이터 유출을 방지할 수 있습니다.
3. 07:03 - 09:13

   공짜 쇼핑과 캐시 취약점

   유효 신호가 떨어졌을 때 데이터를 바로 전송하면 지연 시간은 줄어들지만 결제가 최종 취소될 경우 공짜 쇼핑 리스크가 생깁니다. 비싼 기밀 데이터의 경우 정산이 완료될 때까지 기다리는 것이 안전합니다. 아울러 판매자가 성능 향상을 위해 결과를 공개 캐시에 저장하면 다른 사용자가 유료 장벽을 우회할 수 있으므로, 캐시에 'no store' 헤더를 적용하거나 캐시 저장 전 가격 확인 과정을 거쳐야 합니다.

   • 정산 단계가 완료되기 전에 데이터를 먼저 전송하면 잔고 부족 등으로 결제가 취소되어 공짜 쇼핑이 발생할 수 있습니다.
   • 동일한 보고서를 제공하는 무료 엔드포인트가 존재할 경우 유료 장벽 우회 문제가 발생합니다.
   • 판매자 측 캐시가 공개 URL에 저장되면 다른 구매자가 무료로 데이터를 가져갈 수 있으므로 캐시 제어 설정이 필요합니다.
4. 09:13 - 11:43

   다중 페이지 불일치와 악의적인 검색

   판매자가 여러 개의 독립된 유료 페이지를 운영할 때 동일한 결제 건이 양쪽 모두에 유효한 것으로 처리될 수 있습니다. 이를 막기 위해 공유 스토리지에서 청구 번호와 페이지 매핑을 함께 관리해야 합니다. 또한 실제 판매자를 모방한 사칭 사이트를 에이전트가 선택하는 것을 방지하기 위해, 신규 발견 판매자를 수습 목록에 임시로 등록하고 제한 시간을 두어 검증하는 체계가 요구됩니다.

   • 서로 소통하지 않는 여러 유료 페이지에 동일한 결제 번호를 보내면 각각 데이터를 전달하는 문제가 생깁니다.
   • 유사한 도메인과 지갑을 가진 사칭 사이트로 인해 에이전트가 악의적인 판매자에게 비용을 지불할 수 있습니다.
   • 허용 목록 외에 수습 목록을 두어 신규 판매자를 일정 시간 동안 제한하고 사람이 검토할 수 있도록 해야 합니다.
5. 11:43 - 16:35

   프롬프트 인젝션과 프로덕션 배포 전략

   판매자 응답에 프리미엄 요약을 보라는 텍스트가 포함된 경우 언어 모델을 사용하는 에이전트는 추가 비용을 지불하고 이를 가져오려 시도합니다. 필터 단어 지정이나 모델 판단 외에도 특정 턴에서 호출 횟수 규칙을 세우면 공격 발생 횟수를 줄일 수 있습니다. 프로덕션 환경에 적용하려면 단일 결제 ID로 추적 정보를 남기고, 20~25개의 데이터셋으로 섀도우 단계를 거쳐 보호 장치와 알림을 지속적으로 조정해야 합니다.

   • 판매자 응답 내의 텍스트 유도(프롬프트 인젝션)로 인해 에이전트가 프리미엄 요약에 불필요한 비용을 지출할 수 있습니다.
   • 특정 턴에서의 호출 횟수 제한 규칙을 적용하면 프롬프트 인젝션으로 인한 추가 지출을 차단할 수 있습니다.
   • 단일 결제 ID로 전체 시퀀스를 로깅하고 섀도우 단계를 거쳐 오류 분석 및 보호 장치를 강제 집행해야 합니다.