개발자 도구 · UUID 생성기
HTTP 페이지에서 crypto.randomUUID()가 실패하는 이유: 보안 컨텍스트 설명
· 작동 방식
uuid 암호화 브라우저 API
crypto.randomUUID는 로컬 호스트 및 HTTPS에서 작동한 다음 일반 HTTP 스테이징 호스트에서 사라집니다. 이 게시물에서는 해당 동작 뒤에 있는 보안 컨텍스트 규칙과 해당 규칙이 적용되는 경우 UUID을 안전하게 생성하는 방법을 설명합니다.
준비 시 TypeError, 다른 곳에서는 괜찮음 — 증상 및 이를 유발하는 환경 차이
개발자가 localhost:3000에서 자신의 작업을 확인하면 UUID 생성기가 완벽하게 작동합니다. http://staging. 내부의 스테이징에 배포됩니다. 예. com(회사 LAN의 일반 HTTP)이며 코드에서 TypeError: crypto.randomUUID는 함수가 아닙니다. https://example. com의 프로덕션에서 동일한 코드가 정상적으로 작동합니다. MDN 문서를 읽을 때까지 불일치는 당황스럽습니다. crypto.randomUUID는 보안 컨텍스트로 제한됩니다. 보안 컨텍스트는 HTTPS 또는 localhost입니다. LAN의 일반 HTTP 원본은 네트워크가 비공개인 경우에도 브라우저 규칙에 의해 안전하지 않습니다. 해결 방법은 수동 비트 작업과 함께 crypto.getRandomValues를 사용하거나 스테이징 서버를 HTTPS로 업그레이드하는 것입니다. 민감한 API가 암호화되지 않은 연결로 유출되는 것을 방지하기 위해 보안 컨텍스트 규칙이 도입되었습니다.
보안 컨텍스트란 무엇입니까? HTTPS 원본 및 로컬 호스트에 대해 특정 API를 예약하는 브라우저 규칙입니다.
일반 HTTP를 통한 페이지는 네트워크 공격자가 가로챌 수 있습니다. 이러한 페이지에 암호화 API를 노출하면 공격자가 손상된 API를 사용하여 식별자를 생성할 수 있습니다. HTTPS는 네트워크의 공격자가 코드를 가로채거나 수정할 수 없도록 페이지와 모든 API 통신을 암호화합니다. Localhost는 로컬 시스템에만 존재하고 네트워크를 통해 가로챌 수 없기 때문에 본질적으로 안전한 것으로 간주됩니다. 다른 모든 HTTP 원본(LAN 주소, HTTPS가 없는 공개 도메인, HTTP로 전달되는 역방향 프록시)은 정의상 안전하지 않습니다. Web Crypto API는 보안 컨텍스트로 제한된 crypto.randomUUID와 보안 및 비보안 컨텍스트 모두에서 사용 가능한 crypto.getRandomValues의 두 가지 기능으로 분할됩니다. 둘 다 동일한 운영 체제 CSPRNG를 사용합니다.
웹 암호화의 어느 부분이 제한되는지 — crypto.randomUUID 및 crypto.subtle에는 보안 컨텍스트가 필요하지만 crypto.getRandomValues에는 보안 컨텍스트가 필요하지 않습니다.
차이점은 getRandomValues가 암호화를 사용하고 있다는 사실을 숨기지 않는다는 것입니다. 이를 사용하는 페이지는 명시적으로 임의 바이트를 요청해야 합니다. randomUUID 기능은 보안 컨텍스트도 적용하는 편의 기능입니다. 애플리케이션이 비보안 페이지에서 UUID를 생성해야 하는 경우 getRandomValues를 사용하고 버전 및 변형 비트를 수동으로 설정해야 합니다. RFC 9562은 비트 작업을 지정합니다. byte 6을 (byte6 & 0x0f)로 설정 | 버전 4의 경우 0x40, 바이트 8 ~ (byte8 & 0x3f) | RFC 변형의 경우 0x80입니다. ToolAcre 라이브러리는 RandomUUID를 사용할 수 없을 때 대체적으로 이 작업을 수행합니다. 실패 재현: 잠재적으로 신뢰할 수 있는 것으로 간주되지 않는 일반 HTTP 원본에서 간단한 페이지를 제공합니다. randomUUID가 노출되었는지 확인한 다음 Web Crypto 참조가 안전하지 않은 컨텍스트에서 허용하는 getRandomValues를 비교하세요.
getRandomValues에서 v4 UUID 빌드 — randomUUID가 누락된 경우 CSPRNG를 유지하는 마스킹 및 형식화 폴백
HTTPS를 통해 제공되는 파일의 동일한 코드는 RandomUUID를 노출할 수 있습니다. 프로덕션에서 "randomUUID가 함수가 아닙니다"라고 보고하는 경우 먼저 원본이 보안 컨텍스트인지 확인한 다음 브라우저 지원과 다른 스크립트가 암호화 개체를 대체했는지 확인하세요. 해결책은 HTTPS이거나 UUID 비트를 명시적으로 설정하는 getRandomValues 구현일 수 있습니다. Math.random 폴리필은 동등한 폴백이 아닙니다. 암호화 소스 계약을 삭제하면서 모양을 재현합니다. 대시와 버전 숫자만 확인하는 테스트에서는 해당 대체가 누락되므로 소스 경로와 결과 문자열을 검토하세요.
작업된 예 — http:// 원본에서 오류를 재현하고 수정 사항 확인
그러나 이제 식별자를 예측할 수 있습니다. 시스템에서 몇 개의 UUID를 캡처하는 공격자는 다음 UUID를 예측할 수 있습니다. 애플리케이션이 이러한 식별자를 무기명 자격 증명으로 실수로 처리하는 경우 예측 가능성은 외관상 결함이 아니라 인증 실패가 됩니다. 올바른 전략은 서버를 HTTPS로 업그레이드하거나(인증 또는 민감한 데이터가 있는 모든 페이지에 대해 항상 올바른 이동) 명시적인 비트 작업(더 많은 코드가 필요하지만 암호화적으로 건전함)과 함께 getRandomValues를 사용하는 것입니다. 보안 컨텍스트는 브라우저에 의해 시행됩니다. 구성이나 환경 변수를 사용하여 이 문제를 해결할 수 없습니다. ToolAcre 생성기는 HTTPS를 통해 배포되므로 crypto.randomUUID를 사용할 수 있습니다. 도구에서 UUID을 생성하면 RandomUUID(보안 컨텍스트 검사를 통과한 경우) 또는 비트 작업과 함께 getRandomValues(일반 HTTP를 사용하는 경우, 드물지만)가 사용됩니다.
Math.random으로 폴리필을 하면 안되는 이유 — 유혹적인 지름길과 보안 비용
두 경로 모두 Math.random으로 대체되지 않습니다. 자체 UUID 생성기를 구축하고 비보안 원본을 대상으로 하는 경우 getRandomValues를 사용하고 비트 작업을 직접 수행하세요. HTTPS와 localhost를 모두 테스트하여 randomUUID가 작동하는지 확인한 다음 http:// 원본에서 테스트하여 getRandomValues 폴백이 올바른지 확인하세요. 보안 컨텍스트 제한을 이해하면 배포 전략을 설계하는 데 도움이 됩니다. 애플리케이션이 HTTPS 없이 사설 LAN(레거시 인프라, 임베디드 시스템)에서 실행되어야 하는 경우 getRandomValues 폴백이 경로입니다. 선택할 수 있는 경우 모든 곳에서 HTTPS로 업그레이드하세요. Let's Encrypt를 사용하면 무료이며 전체 애플리케이션에 대한 보안에 대한 투자가 회수됩니다. localhost에서의 개발에는 제한이 없으므로 프로덕션에 배포하기 전에 localhost 및 HTTPS 스테이징에서 UUID 생성기를 테스트하세요. 프로덕션은 항상 HTTPS여야 합니다.
여기서 다루지 않는 내용 — 보안 컨텍스트 규칙 없이 API를 노출하는 Node.js 및 Deno와 같은 서버 런타임
제한은 버그나 성가신 것이 아닙니다. 사고를 예방하고 암호화에 대해 생각하게 만드는 보안 기능입니다. 더 넓은 패턴은 웹 암호화 API가 보안 컨텍스트에 의해 제어된다는 것입니다. crypto.getRandomValues, 암호화. 미묘한. 암호화하다, 암호화하다. 미묘한. generateKey 및 기타 모든 중요한 작업에는 HTTPS 또는 localhost가 필요합니다. 예외도 없고 재정의도 없고 검사를 비활성화할 방법도 없습니다. 안전하지 않은 페이지 하나가 사용자에 대한 보안 보장을 깨뜨립니다. 특정 페이지에서만 암호화 API를 사용하도록 주의를 기울이더라도 실수(또는 UUID 생성기를 포함하는 종속성)로 인해 암호화되지 않은 페이지에 임의성 생성이 유출될 수 있습니다. ToolAcre 생성기는 코드 수준에서 이를 시행합니다. 즉, randomUUID를 사용할 수 없는 경우(비보안 컨텍스트) getRandomValues를 사용합니다. getRandomValues는 사용 가능하지만 코드 검토자에게 비정상적인 일이 발생하고 있음을 알립니다.
요점: 생성기가 아닌 원본 수정 — ToolAcre는 HTTPS를 통해 제공되므로 생성기는 설계상 안전한 컨텍스트에서 실행됩니다.
더 좋은 점은 보안 컨텍스트를 실제로 사용할 수 없는 경우 식별자 생성을 거부한다는 것입니다(getRandomValues도 사용할 수 없는 환경에서는 드물지만 이전 시스템이나 임베디드 시스템에서는 가능함). 보안 암호화 API를 지원하기 위해 기존 시스템을 HTTPS로 마이그레이션하는 것은 일반적인 프로젝트입니다. UUID가 생성된 원본(인증 서버, API 백엔드 또는 주요 애플리케이션 서비스)부터 시작하세요. TLS 인증서를 획득하세요(Let's Encrypt에서 무료로 제공). 기본적으로 HTTPS를 제공하고 HTTP 요청을 HTTPS로 리디렉션하도록 웹 서버를 구성합니다. 여러 브라우저와 API 클라이언트로 테스트하여 모든 것이 작동하는지 확인하세요. 그런 다음 암호화되지 않은 페이지에서 호출될 수 있는 나머지 암호화 API가 있는지 코드를 감사하고 수정하세요. ToolAcre 생성기는 HTTPS를 가정합니다. 당신이 그것을 사용하고 있다면 당신은 이미 그 길의 일부인 것입니다.