개발자 도구 · UUID 생성기
순차 ID로 인한 비즈니스 데이터 유출: 공개 API가 UUID를 노출하는 이유
· 그것이 중요한 이유
uuid 암호화 브라우저 API
자동 증가 ID는 외부인에게 귀하가 받는 주문 수를 알려주고 모든 기록을 열거 가능하게 만듭니다. 이 게시물에서는 UUID 노출로 수정되는 사항, 수정되지 않는 사항, 마이그레이션 없이 이를 도입하는 방법에 대해 설명합니다.
귀하의 송장 번호는 경쟁업체에 귀하의 거래량을 알려줍니다. — /orders/10482의 정보 유출
/orders/10482을 반환하는 API 엔드포인트는 외부인에게 주문 세부정보 자체보다 더 많은 정보를 알려줍니다. 숫자 식별자는 귀하가 최소 10,000개 이상의 주문을 처리했음을 나타내며 성장률에 대한 정보를 암시하고 모든 주문을 추측할 수 있게 만듭니다. 일련 번호를 통한 간단한 루프는 인증이나 권한 확인 없이 모든 레코드를 검색합니다. 이 패턴은 단일 기록을 보기 위해 시스템에서 인증이 필요한 경우에도 URL, 데이터베이스 키, 송장 번호, 거래 ID 등 모든 곳에 나타납니다. 보고 및 분석 과정에서 문제가 더욱 복잡해집니다. /orders/1, /orders/2,를 가져오고 /orders/10482을 통해 계속할 수 있는 공격자는 주문 내역 및 추세에 대한 포괄적인 보기를 얻습니다.
열거 및 스크래핑 — 순차 ID가 하나의 노출된 레코드를 모든 레코드로 변환하는 방법
순차 패턴은 주문 도착 시기, 언급된 제품, 가격 패턴 등의 추세를 나타냅니다. 관찰자는 귀하의 비즈니스가 성장하거나 축소되는 속도를 배웁니다. ID 열거에서만 파생된 해당 정보는 경쟁 전략을 알리고, 사회 공학을 안내하거나, 다른 공격의 타이밍을 알릴 수 있습니다. 노출은 발견하는 데 비용이 들지 않으며 URL, 브라우저 기록, 캐시된 페이지 및 서버 로그에 표시됩니다. 이는 이론적인 것이 아닙니다. 경쟁력 있는 정보 회사와 호기심 많은 엔지니어는 공개적으로 열거 가능한 ID에서 비즈니스 지표를 정기적으로 추출합니다. 주문 번호 샘플은 데이터를 수집하고 기본 분석을 수행할 만큼 동기가 부여된 모든 사람에게 생산 속도와 총량을 보여줍니다.
한 단락으로 된 독일 탱크 문제 - 일련 번호 샘플에서 총계 추정
열거는 통계 분석을 적용하여 총 볼륨을 추정하고 시간적 패턴을 추적합니다. 알려진 날짜에 첫 번째 주문이 발생했고 일주일에 걸쳐 10개의 주문이 분산되어 있다는 증거를 캡처하는 경우 평균 간격은 전체 비율을 추정합니다. 경쟁사, 투자자 및 공격자는 ID 이외의 고객 데이터에 액세스하지 않고도 속도를 얻을 수 있습니다. 순차 식별자는 현재 숫자보다 큰 모든 ID가 향후 주문을 예측하도록 보장합니다. 샘플의 최소값보다 낮은 모든 ID는 이전에 작업이 더 작았음을 확인합니다. 과거 데이터 포인트는 성장 타임라인을 생성하고 예측을 가능하게 합니다. 이와 동일한 원칙은 금융 거래, 배송 주문, 의료 기록 및 순차 ID를 노출하는 모든 시스템 등 산업 전반에 적용됩니다.
UUID 수정 사항 — 추측할 수 없는 참조 및 ID 자체에 성장 신호 없음
무작위로 생성된 UUID에는 RFC 9562이 버전 4에 대해 지정하는 대로 암호화된 보안 소스에서 생성될 때 122 비트의 엔트로피가 포함됩니다. 식별자는 추측할 수 없고 열거할 수 없으며 외부 관찰자에게 성장률이나 규모에 대해 아무 것도 알려주지 않습니다. /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60을 알고 있는 공격자는 다음 주문의 UUID을 예측할 수 없으며 합당한 확신을 가지고 과거 ID를 통해 역방향으로 이동할 수 없습니다. UUID 자체는 고유하지만 완전히 불투명한 참조가 됩니다. 무작위 배포는 여러 쿼리가 API를 모니터링하는 외부 관찰자에게 패턴, 진행 및 속도 정보를 나타내지 않음을 의미합니다.
UUID가 수정하지 않는 것 — 추측할 수 없는 ID는 인증이 아니며 모호함은 여전히 그 뒤에 있는 액세스 확인이 필요합니다.
공개 API에서 순차 ID를 UUID로 바꾸는 것은 운영상 간단하며 시스템 간의 복잡한 조정이 필요하지 않습니다. 주문 테이블에 UUID 열을 추가하고, 새로운 주문마다 열을 생성하고, 응답에 UUID을 노출하고, 점차적으로 숫자 키를 사용하지 않게 됩니다. 내부 시스템은 성능과 단순성을 위해 정수 기본 키를 계속 사용할 수 있습니다. 공개 인터페이스만 변경됩니다. 이전 순차 ID는 참조 또는 감사 추적을 위해 데이터베이스에 남아 있지만 고객과 제3자는 UUID만 볼 수 있습니다. 이 이중 키 접근 방식은 불투명 식별자를 외부에 노출하면서 기존 인덱스 성능을 유지하는 모범 사례입니다.
작업된 예 — 내부 정수 키와 함께 공개 UUID 열을 추가하고 전자만 노출
UUID은 비밀번호가 아니고 모호함은 보안 제어가 아니기 때문에 이 접근 방식은 실제 인증과 다릅니다. /orders/{their-uuid}에 대한 합법적인 액세스 권한이 있는 고객은 이를 볼 수 있어야 하지만 /orders/{someone-elses-uuid}는 여전히 액세스 확인에 의해 거부되어야 합니다. UUID은 일반 검사에서 주문 번호를 숨기고 열거를 통한 통계 분석을 방지하지만 인증 및 권한 부여 논리는 여전히 애플리케이션 코드의 책임입니다. 보호는 계층화되어 있습니다. UUID는 식별자 자체에서 정보 유출을 막고 액세스 제어는 해당 식별자에 대해 조치를 취할 수 있는 사람을 강제합니다.
여기서 다루지 않는 내용 — 별도의 게시물에서 논의되는 임의 키의 인덱스 성능 균형
UUID는 ID 자체의 정보 유출을 수정하지만 액세스 제어 메커니즘을 대체하지 않기 때문에 운영 경계가 중요합니다. 고객에게 API 키와 충분한 권한이 있는 경우에도 시스템에 요청할 수 있습니다. 액세스할 수 있는 범위는 ID 형식이 아니라 권한 모델과 역할 정의에 따라 결정됩니다. UUID의 이점은 순전히 식별자가 이를 관찰할 수 있는 누구에게나 볼륨, 순서 및 성장 데이터를 방송하는 것을 중지한다는 것입니다. 잘 설계된 시스템은 UUID 불투명성과 API에 대한 모든 요청에 대한 명시적인 액세스 제어 검사를 결합합니다.
요약: 내부 키와 공개 참조를 분리합니다. ToolAcre 생성기는 공개 측에 CSPRNG 지원 UUID를 제공합니다.
실용적인 마이그레이션에서는 두 형식을 점진적으로 지원하여 플래그 데이를 방지합니다. 엔드포인트 버전을 지정하면 v1 API는 계속해서 정수 ID를 반환할 수 있고 v2는 UUID를 반환할 수 있습니다. 클라이언트는 조정된 컷오버 없이도 자신의 속도에 맞춰 전환합니다. 내부 데이터베이스 쿼리는 변경되지 않은 채로 유지됩니다. 인덱스가 해당 열에 구축되고 외래 키가 이를 참조하기 때문에 여전히 정수 ID로 필터링됩니다. 클라이언트에 반환된 데이터만 변경됩니다. ToolAcre UUID 생성기는 사용할 버전-4 형식을 생성합니다. 각 출력은 저장, 배포 및 점진적 마이그레이션 시나리오에 적합한 올바른 RFC 9562 UUID입니다.