CDN을 통해 전달 된 JavaScript 파일이 변경되지 않도록하려면 어떻게해야합니까?


88

일부 JavaScript 파일이 CDN에서 호스팅되는 시나리오를 작업 중입니다. 이 파일이 사용자 측에서 다운로드 될 때 파일이 변조되지 않았고 실제로 지정된 CDN에서 오는지 확인할 수 있도록 몇 가지 메커니즘을 갖고 싶습니다.

SSL을 사용하면 작업이 매우 쉽다는 것을 알고 있지만 여전히 SSL이없는 HTTP에서도 올바른 파일이 제공되는지 확인하고 싶습니다.

내가 검색 할 수있는 한, 플랫폼간에 지원되는 JavaScript 파일에 대한 디지털 서명과 같은 기존 메커니즘이 없습니다. 아마도 필요하지 않습니까?

JavaScript 파일의 작성자를 확인하기 위해 브라우저에 내장 된 방법이 있습니까? 이 작업을 안전하게 수행 할 수있는 방법이 있습니까?


13
이 질문이 흥미 롭다고 생각하지만 주제에서 벗어난 것은 아닙니까?
evolutionxbox

20
http에 파일을 제공하는 이유는 무엇입니까?
njzk2

12
"하지만 왜 그런 메커니즘이없는 걸까요?" 정말 어렵 기 때문 입니다. 데이터가 서버를 떠나면 건배입니다. HTTPS는 도움이되지만 일반 HTTP 연결 인 경우 유효성 검사가 실패 (또는 통과) 될 수 있습니다. MITM 공격은 브라우저가 기대치를 파악하기 전에 예상되는 서명 및 / 또는 제공되는 서명을 수정할 수 있습니다. 따라서 사용자가 페이로드를 받으면 완전히 안전한 것으로 간주됩니다. 반드시 그런 것은 아닙니다.
VLAZ

4
"하지만 왜 그런 메커니즘이없는 걸까요?" HTTPS에는 이미 저렴하고 효과적이며 광범위하게 적용 가능한 솔루션이 있기 때문입니다.
Kevin Krumwiede

9
이것은 실제로 안전한 방법으로 파일을 제공하는 것에 관한 것이기 때문에 아마도 ServerFault 또는 Security에있을 것입니다. 그리고 프로그래밍과의 모든 관계는 해당 파일이 소스 코드를 나타내는 경우에만 접할뿐입니다.
underscore_d

답변:


140

사실 이와 같은 기능은 현재 Subresource Integrity 라는 이름 으로 초안을 작성 하고 있습니다. 태그 integrity속성을 살펴보십시오 <script>. 아직 전체적으로 완전히 채택되지는 않았지만 이 목적을 달성합니다.

integrity

사용자 에이전트가 가져온 리소스가 예기치 않은 조작없이 전달되었는지 확인하는 데 사용할 수있는 인라인 메타 데이터를 포함합니다. 하위 리소스 무결성을 참조하십시오.

출처

SRI (Subresource Integrity)는 브라우저가 가져온 파일 (예 : CDN에서)이 예기치 않은 조작없이 전달되는지 확인할 수있는 보안 기능입니다. 가져온 파일이 일치해야하는 암호화 해시를 제공하는 방식으로 작동합니다.

출처


예:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

그러나 일반 HTTP를 통해 리소스를 전송하는 경우 Man in the Middle 공격 으로부터 보호되지 않습니다 . 이 경우 해시 코드가 공격자에 의해 스푸핑되어 조작 된 스크립트 파일에 대한 방어가 무용지물이 될 수 있습니다.

따라서 위에서 설명한 보안 조치 외에 일반 HTTP 대신 항상 보안 HTTPS 연결을 사용해야합니다.


9
OP가 HTML과 자산 파일을 HTTP로 보낼 계획이라고 가정하면 무결성 검사가 쉽게 스푸핑 될 수 있다는 점을 언급 할 가치가 있다고 생각합니다. 사이트가 HTTPS이고 HTTP를 통해 자산을 제공하려는 경우 대부분의 브라우저는 이것을 좋아하지 않고 HTTP 자산을 조용히 무시합니다.
MonkeyZeus

3
@MonkeyZeus 이것은 MITM 공격의 경우 또는 우리 자신의 서버가 손상된 경우에만 해당됩니다. 맞습니까? 내 이해는이 질문은 손상된 CDN을 방어하는 방법을 명시 적으로 묻는 것입니다.
Timo

10
@TimoSta 정확히! 대신 이러한 검사없이, 당신은에서 스크립트를 포함하는 경우, 예를 들어 https://code.jquery.com/, 타협 다음 사람이 code.jquery.com여부에 관계없이의 사이트를 XSS 수 code.jquery.com를 통해 액세스 HTTPS되고있다. 이러한 검사를 통해 공격자는 스크립트가로드되는 것을 막을 수 있으며 악의적 인 스크립트로 대체 할 수 없습니다.
Ajedi32

1
@MonkeyZeus 내 답변에 귀하의 우려 사항을 설명하는 메모를 추가했습니다. 문구에 동의하십니까?
Timo

1
@TimoSta 아주 좋아, 나는 그것을 좋아한다! BTW, 나는 내 첫 코멘트 :-) 게시하기도 전에 일을했다
MonkeyZeus

36

하위 리소스 무결성 검사를 찾고 있습니다.

예를 들어 다음은 jQuery CDN 스 니펫입니다.

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>

2
공격자가 다운로드하는 스크립트를 수정하는 동시에 무결성 필드를 수정할 수 있기 때문에 전혀 쓸모가 없습니다.
궤도의 가벼운 경주

15
@LightnessRacesinOrbit : HTTPS를 통해 액세스되는 자체 도메인을 제어하지만 code.jquery.com. 이렇게하면 code.jquery.com.
SilverlightFox

2
@SilverlightFox : 좋아요, MITM 공격에 대해 완전히 쓸모가 없습니다 *
궤도의 Lightness Races

@LightnessRacesinOrbit 예. 여전히 매우 유용하고이 공격을 막았을 것입니다. 예 : bleepingcomputer.com/news/security/…
Adrian Mouat

6

고지 사항 : 항상 그렇듯이 https를 사용할 때만 이러한 메커니즘을 사용하는 것으로 간주해야합니다. http를 사용하는 MitM을 통해 쉽게 비활성화 할 수 있기 때문입니다.

위 답변의 메커니즘 외에도 상위 페이지 에서 콘텐츠 보안 정책 http 응답 헤더를 사용할 수도 있습니다 .

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

콘텐츠 보안 정책 : script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

여기서 주목할 몇 가지 사항이 있습니다. sha *-접두사는 해시를 생성하는 데 사용되는 알고리즘을 지정합니다. 위의 예에서는 sha256-이 사용됩니다. CSP는 sha384- 및 sha512-도 지원합니다. 해시를 생성 할 때 태그를 포함하지 마십시오. 또한 선행 또는 후행 공백을 포함하여 대문자와 공백이 중요합니다.

Chrome 40 이상을 사용하면 DevTools를 연 다음 페이지를 다시로드 할 수 있습니다. 콘솔 탭에는 각 인라인 스크립트에 대한 올바른 sha256 해시가있는 오류 메시지가 포함됩니다.

이 메커니즘은 꽤 오랫동안 사용되어 왔으므로 브라우저 지원이 꽤 좋을 가능성이 높으므로 확인하십시오.

또한 이전의 비 호환 브라우저가 안전하지 않은지 확인하려면 정책에서 허용하지 않는 동기 리디렉션 스크립트를 페이지 상단에 포함 할 수 있습니다.


꽤 오랫동안 사용되어 왔지만 브라우저 지원은 그리 좋지 않습니다. caniuse.com/subresource-integrity
Sp0T

@ Sp0t-하위 리소스 무결성 (링크의 내용)은 다른 답변의 메커니즘입니다. 내 대답은 더 나은 지원이 컨텐츠 보안 정책에 관한 것입니다
파비오 Beltramini

3

이런 종류의 서명이 할 수있는 것과 할 수없는 것에 대한 중요한 점이 있습니다. 그것은 수있는 사람이 코드를 수정하는 가상의 공격으로부터 사용자를 보호합니다. 그것은 할 수없는 코드가 실행되는 코드입니다 귀하의 사이트를 확신합니다. 즉, 클라이언트로부터 귀하의 사이트로 들어오는 것을 여전히 신뢰할 수 없습니다.


2

공격자 모델이 공격자가 CDN에서 전달되는 JavaScript 파일을 수정할 수 있도록 허용하는 경우 공격자 모델은 확인 시도를 제거하기 위해 전달되는 참조 소스를 수정하여 소스 주소를 다른 것으로 변경하도록 허용합니다. CDN 및 / 또는 JavaScript에 대한 참조를 완전히 제거합니다.

그리고 애플리케이션이 사용자의 리졸버가 HTTP 요청 (또는 검증 된 신뢰 체인이없는 기타 메커니즘)을 통해 CDN에 올바르게 해결되는지 여부를 판별하는 방법에 대한 웜 캔을 열지 마십시오.

/ etc / hosts :

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...

2
첫 번째 문장은 분명히 사실이 아닙니다. 참조 페이지가 HTTPS를 통해로드되고 JavaScript 파일이 HTTP-not-S를 통해로드되면 어떻게됩니까?
user253751

또는 CDN 자체가 손상되었지만 자체 서버가 아닌 경우 어떻게해야합니까?
Ajedi32

@immibis : 나는 OP가 그러한 시나리오를 제안 할만큼 비합리적이지 않다고 가정하기로 결정했습니다.
Eric Towers

1
@immibis 브라우저가 일반적으로 HTTPS 페이지가 HTTP를 통해 JS를로드하는 것을 허용하지 않는 이유가 아닌가요?
Barmar

1
@immibis 나는 브라우저가 그것을 허용하지 않기 때문에 불가능한 상황을 개선한다고 말하고있었습니다.
Barmar

1

Subresource Integrity로이를 보장 할 수 있습니다. 많은 공개 CDN은 CDN 웹 사이트에서 제공되는 포함 가능한 코드에 SRI 해시를 포함합니다. 예를 들어 PageCDN에서 jQuery CDN 페이지 의 jquery 파일을 클릭 하면 다음과 같이 URL을 복사하거나 SRI 해시가 포함 된 스크립트 태그를 사용할 수있는 옵션이 제공됩니다.

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

페이지로드시 브라우저는이 리소스에 대한 요청을 발행하고 요청 완료시 수신 된 파일의 해시를 스크립트 태그의 무결성 값으로 지정된 해시와 일치시킵니다. 두 해시가 일치하지 않으면 브라우저는 jquery 파일을 버립니다.

현재이 기능은 전 세계 브라우저의 91 %에서 지원됩니다. caniuse 에 대한 자세한 내용 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.