개발자 도구 · SHA 해시 계산기
하위 리소스 무결성: 브라우저가 SHA-384을 사용하여 스크립트를 확인하는 방법
· 배경
샤-256 베이스64 브라우저 API 보안
무결성 속성을 사용하면 브라우저는 바이트가 변경된 CDN 스크립트를 거부할 수 있습니다. 이 게시물에서는 속성의 형식, base64의 SHA-384이 일반적인 선택인 이유, SRI가 보호할 수 없는 사항에 대해 설명합니다.
무엇이든 제공할 수 있는 CDN — 공급망 위험 SRI는 다음을 위해 설계되었습니다.
웹페이지의 스크립트 태그는 무결성 속성 `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`을(를) 전달할 수 있습니다. 무결성 값은 스크립트 바이트의 암호화 다이제스트입니다. 브라우저는 스크립트를 다운로드할 때 수신된 바이트의 다이제스트를 계산하고 무결성 속성과 비교합니다. 일치하면 스크립트가 로드됩니다. 일치하지 않으면 브라우저는 로드를 거부하고 콘솔에 실패를 보고합니다. 이는 수정된 코드를 제공하는 손상된 CDN이나 응답을 가로채서 변경하는 네트워크 공격자로부터 보호합니다.
SRI(하위 리소스 무결성)는 스크립트 및 스타일시트에 적용되는 W3C 사양입니다. 이는 교차 출처 리소스의 콘텐츠에 대해 브라우저가 수행할 수 있는 유일한 암호화 보장입니다. 즉, 바이트가 다이제스트와 일치해야 하며 그렇지 않으면 리소스가 거부됩니다. 이는 리소스를 만든 사람이 누구인지 증명하는 것이 아니라 다이제스트가 계산된 이후 변경되지 않았다는 사실만 증명합니다. 평판이 좋은 CDN에서 HTTPS를 통해 제공되는 리소스의 경우 다이제스트는 CDN이 손상되거나 오래되고 캐시된 콘텐츠를 제공하는 것에 대한 보호 장치를 제공합니다.
무결성 속성 — 알고리즘 접두사, 하이픈, base64 다이제스트 및 여러 해시 지원
무결성 속성은 base64의 알고리즘 이름, 하이픈, 다이제스트와 같은 특정 형식을 갖습니다. 예: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. 알고리즘 이름은 SHA-256, SHA-384 또는 SHA-512일 수 있습니다. Base64는 16진수가 아닌 인코딩입니다. 이는 SRI 사양에 따른 의도적인 선택입니다. Base64는 16진수보다 더 컴팩트하며(동일한 다이제스트에 대해 약 33% 더 짧음) 이는 HTML 속성에 포함될 때 중요합니다. 하이픈은 알고리즘 이름을 다이제스트와 구분합니다. 여러 무결성 값을 공백으로 구분하여 나열할 수 있습니다. 둘 중 하나라도 일치하면 리소스가 허용됩니다.
왜 SHA-384인가요? SRI 사양에서는 SHA-256, SHA-384 및 SHA-512을 허용합니다. SHA-384는 /security 크기의 잔액을 제공하기 때문에 커뮤니티 기본값이 되었습니다. SHA-256은 더 작지만(base64에서는 32바이트, 44자) SHA-384는 더 넓으며(base64에서는 48바이트, 64자) SHA-256에 비해 속성 크기를 의미 있게 늘리지 않았습니다. SHA-512을 사용할 수 있지만 이 사용 사례에는 더 큰 다이제스트가 필요하지 않아 거의 사용되지 않습니다. SHA-384의 선택은 우수한 보안 속성을 반영하는 것이 아니라 역사적이고 실용적입니다(세 가지 모두 이 목적을 위해 암호화가 강력합니다).
SHA-384이(가) 제공되고 필요한 base64 자료를 생성합니다. 커뮤니티 선호도는 도구에서 추론되지 않습니다.
SRI의 Base64 인코딩은 base64url이 아닌 표준 base64입니다. 표준 base64는 + 및 / 문자를 사용합니다. 이는 백분율 인코딩 없이 HTML 속성에서 유효하지만 URL 및 양식 데이터에서는 특별한 의미를 갖습니다. SRI 형식은 URL이 아닌 HTML 속성용으로 설계되었으므로 표준 base64가 적합합니다. 무결성 값을 직접 작성하는 경우 SHA-384 다이제스트(바이트 시퀀스)를 계산한 다음 해당 바이트를 표준 base64로 인코딩한 다음 앞에 `sha384-`을 추가하고 무결성 속성에 붙여넣습니다.
브라우저는 동일한 단계를 역순으로 수행합니다. 즉, 무결성 속성에서 base64를 추출하고, 바이트로 디코딩하여 다이제스트를 복구하고, 다운로드한 스크립트 바이트의 SHA-384을 계산하고 두 다이제스트 값을 비교합니다. 정확히 일치해야 합니다. 다이제스트의 단일 비트 차이로 인해 거부가 발생합니다. 퍼지 매칭이나 부분 점수가 없습니다. 무결성은 이분법입니다.
교차 출처 SRI 동작에는 이 해시 계산기 이상의 브라우저 문서가 필요합니다.
SRI에는 교차 출처 응답에 대한 CORS가 필요합니다. 다른 원본에서 스크립트를 로드하는 경우 서버는 `Access-Control-Allow-Origin: *` 또는 해당 원본을 포함하는 특정 원본 헤더로 응답해야 합니다. CORS 헤더가 없으면 브라우저는 SRI를 확인할 수 없습니다. 왜냐하면 CORS가 없으면 응답 본문이 서버가 보내려는 내용과 일치하는지 확인할 수 없기 때문입니다. CORS 헤더는 이 응답이 확인하기에 안전하다는 서버의 설명입니다. SRI는 바이트가 올바른지 확인하는 것입니다. 이들은 함께 공급망 약속을 형성합니다. 즉, 서버를 통해 콘텐츠를 확인할 수 있고 실제로 그렇게 됩니다.
교차 원본 스크립트에 CORS 헤더가 없고 무결성 속성이 있는 경우 브라우저는 이를 다운로드하지만(해당 원본의 스크립트가 사이트 CSP에서 허용되는 경우) 무결성을 확인하지는 않습니다. 무결성 속성이 없는 것처럼 스크립트가 로드됩니다. 이것은 SRI의 실패가 아닙니다. 이는 보안 경계이므로 읽을 수 없는 응답을 확인할 수 없습니다.
불일치 시 발생하는 상황 - 브라우저가 리소스를 차단하고 콘솔에 보고합니다.
브라우저가 무결성 불일치를 감지하면 스크립트 실행을 거부하고 브라우저 콘솔에 메시지를 기록합니다. 메시지에는 일반적으로 URL, 예상 해시 및 계산된 해시의 이름이 지정됩니다. 실패는 원자적입니다. 리소스가 있는 그대로 로드되거나 완전히 거부됩니다. 부분 로딩이나 폴백은 없습니다. 웹사이트가 해당 스크립트에 의존하고 거부되면 사이트가 중단될 수 있습니다. 이는 의도적인 것입니다. 잘못된 코드를 전달하는 것은 코드를 전달하지 않는 것보다 더 나쁘며, 자동 실패로 인해 공격이 무기한 지속될 수 있습니다.
SRI 설정 테스트는 간단합니다. 브라우저 콘솔을 열고 페이지를 로드한 다음 무결성 불일치에 대한 메시지를 찾으세요. 불일치가 발견되면 콘솔에 표시된 계산된 해시를 무결성 속성의 해시와 비교하세요. 일치하지 않으면 다시 계산하십시오. 스크립트가 업데이트되었을 수 있으며 새 다이제스트가 필요합니다.
작업 예 — 스크립트에 대한 다이제스트를 계산하고 이를 base64 단계를 포함하여 무결성 값으로 형식화합니다.
SRI 다이제스트를 수동으로 계산하려면 스크립트 바이트와 해시 도구만 필요합니다. 스크립트를 다운로드하여 ToolAcre SHA 해시 계산기에 붙여넣고 SHA-384을 선택한 다음 base64 출력(16진수 아님)을 복사하고 앞에 `sha384-`을 추가한 후 무결성 속성에 붙여넣습니다. 스크립트가 큰 경우 컬이나 wget을 사용하여 파일에 저장한 다음 파일을 읽는 것이 붙여넣는 것보다 빠릅니다. 인라인 스크립트(URL이 아닌 HTML의 `<script>` 태그)의 경우 SRI가 적용되지 않습니다. 인라인 스크립트는 정의에 따라 항상 신뢰됩니다. SRI는 외부 리소스를 위한 것입니다.
실제 예: SRI를 사용하여 CDN에서 jQuery를 로드한다고 가정합니다. 스크립트 URL을 찾아서 다운로드하고(또는 컬을 사용하여 가져오고) 바이트를 계산기에 붙여넣거나 명령줄에서 `sha384sum`을 사용하고 SHA-384 다이제스트를 base64로 가져오고 `sha384-[base64-digest]`로 형식을 지정합니다. 스크립트 태그의 무결성 속성에 붙여넣습니다. 페이지를 로드하고 콘솔 오류가 나타나지 않는지 확인하십시오.
여기서 다루지 않는 내용 — 의도적으로 변경되는 스크립트 및 외부 스크립트를 전혀 로드하지 않아 고정할 것이 없는 ToolAcre와 같은 사이트
SRI는 모든 공급망 공격으로부터 보호하지 않습니다. 다이제스트가 계산된 후 바이트 변경으로부터 보호하지만 처음부터 손상된 코드에서 계산되는 다이제스트로부터는 보호하지 않습니다. 다이제스트를 계산하기 전에 CDN이 손상되면 SRI가 도움을 줄 수 없습니다. 다이제스트는 계산한 소스만큼만 신뢰할 수 있습니다. 최대한의 보증을 위해 원본 소스(예: 라이브러리의 GitHub 릴리스)에서 다이제스트를 계산하고 CDN에서 로드할 때 해당 다이제스트를 사용하세요. 다이제스트는 릴리스 프로세스를 통해 관리자의 약속이 됩니다.
SRI는 또한 다이제스트를 계산하는 순간 손상된 네트워크나 손상된 개발 시스템으로부터 보호하지 않습니다. 다이제스트가 생성된 시간과 브라우저가 스크립트를 로드하는 시간 사이에 스크립트가 변경되는 경우에만 보호합니다. 지속적인 보증을 위해 일부 배포에서는 SRI 외에 릴리스 서명을 사용합니다. 릴리스는 관리자의 키로 서명되며 서명을 확인하고 확인된 바이트에서 다이제스트를 계산하여 SRI에서 사용합니다.
이 기사는 해시 소스에서 ToolAcre의 사이트 전체 외부 스크립트 인벤토리를 주장하지 않습니다.
ToolAcre SHA 해시 계산기는 표준 base64에서 다이제스트를 직접 내보냅니다(`toBase64()` 함수의 `base64` 출력으로). SRI 형식으로 변환하려면 알고리즘 이름 앞에 하이픈(`sha256-`, `sha384-` 또는 `sha512-`)을 추가합니다. 해시는 알고리즘 이름이 분리되거나 다르게 인코딩되는 많은 컨텍스트(git, Docker, npm, URL)에 나타나기 때문에 계산기는 해당 접두사를 자동으로 적용하지 않습니다. 경계는 명확합니다. 계산기는 파일이나 바이너리 키가 아닌 사용자가 붙여넣은 UTF-8 텍스트를 해시합니다. 16진수와 base64를 모두 출력합니다. 상황에 따라 사용할 항목을 선택합니다. SRI의 경우 사양에 따라 base64가 필요합니다. git 및 기타 도구의 경우 hex가 일반적입니다. npm 및 Go의 경우 base64가 사용됩니다. 인코딩 선택은 귀하의 몫입니다. 다이제스트 바이트는 동일합니다.
SRI는 브라우저가 중앙 권한 없이 클라이언트 측에서 수행할 수 있는 몇 안 되는 암호화 검사 중 하나입니다. 컴퓨팅은 ToolAcre의 SHA 계산기와 같은 신뢰할 수 있는 도구를 사용하여 스스로를 소화하고 로드된 리소스에 대해 이를 확인하는 것은 특정 공급망 공격으로부터 웹 사이트를 강화하는 접근 가능한 방법입니다. 보호는 다이제스트만큼 좋습니다. 외부 리소스를 업데이트할 때마다 다시 계산하고 브라우저가 스크립트를 거부하지 않고 로드하는지 테스트합니다.