dreamhack2-2

• 출처: dreamhack webhacking 2강 client-side basic https://dreamhack.io/lecture/courses/7

 

Client-side Basic

•  
• Cross Site Scripting (XSS)
  공격자의 입력값이 크로스 사이트의 자바스크립트 일부로 웹 브라우저에서 실행되는 취약점을 말합니다. 실행된 스크립트는 해당 사이트의 일부가 되어 SOP 제약 없이 사이트의 구조를 변경하거나 임의 HTTP 요청을 보낼 수 있습니다.
• Cross Site Request Forgery (CSRF)
• 비정상적으로 사용자의 의도와 무관하게 HTTP 요청을 보내는 것을 CSRF 공격이라 합니다. Simple Request나 HTML 엘리먼트라면 SOP의 제약을 받지 않는다는 점을 이용합니다.
• --Simple Request : 보통은 사용자에게 피해를 주지 않는 요청

• Open Redirect
• Redirect 기능을 악용해 피싱사이트로 접속을 유도하거나, 다른 취약점을 연계하여 사용자를 공격할 수 있습니다.
• Click Hijacking
• 공격자가 생성한 버튼, 이미지와 같은 엘리먼트를 정상적인 iframe 위에 겹쳐 올려 UI를 스푸핑해 사용자 의도와는 다른 작업을 수행하게 하는 취약점입니다

<Cross Site Scripting>

서버의 응답에 공격자가 삽입한 악성 스크립트가 포함되어 사용자의 웹 브라우저에서 해당 스크립트가 실행되는 취약점을 Cross Site Scripting (XSS) 이라고 합니다.

XSS은 임의의 악성 스크립트를 실행할 수 있으며 이를 통해 해당 웹 사이트의 사용자 쿠키 또는 세션을 탈취해 사용자의 권한을 얻거나, 사용자의 페이지를 변조하는 등의 공격을 수행할 수 있습니다.

 

XSS 공격을 성공적으로 수행하기 위해서--

1. 입력 데이터에 대한 충분한 검증 과정이 없어야 합니다.
   • 입력한 데이터가 충분한 검증 과정이 이루어지지 않아 악성 스크립트가 삽입될 수 있어야 합니다.
2. 서버의 응답 데이터가 웹 브라우저 내 페이지에 출력 시 충분한 검증 과정이 없어야 합니다.
   • 응답 데이터 출력 시 악성 스크립트가 웹 브라우저의 렌더링 과정에 성공적으로 포함되어야 합니다.

대표적인 예시로 게시판 서비스가 있습니다.

공격자의 악성 스크립트가 포함된 게시글이 검증이 이루어지지 않은 채 웹 서버에 업로드 되고 다른 사용자가 해당 게시글을 조회한다면 공격자의 악성 스크립트가 사용자의 웹 브라우저에서 실행됩니다.

 

XSS는 악성 스크립트가 전달되는 방식에 따라 Stored XSS, Reflected XSS 등으로 분류됩니다.>>뒤에

악성 스크립트의 전달 방식 차이가 있을 뿐 사용자의 웹 브라우저에서 악성 스크립트를 실행한다는 것은 동일합니다.

 

악성 스크립트는 브라우저가 실행할 수 있는 웹 리소스를 말하며, 대표적으로 HTML, JS 등이 있습니다.

 

---XSS 취약점에 대한 정보를 공유할 때 alert 또는 prompt와 같은 메시지 창을 실행하는 이유는 XSS 취약점이 발생하였다는 점을 시각적으로 표현이 가능하기 때문입니다.

주로 메시지 창에는 해당 페이지의 domain을 확인하기 위해 document.domain을 인자로 전달합니다.

ex) dreamhack.io

 

Javascript(자바스크립트)는 사용자의 웹 브라우저에서 화면을 동적으로 보여줄 수 있도록 자동으로 버튼을 누르거나 화면 구성을 바꾸는 등의 작업을 할 때 많이 사용됩니다. 이러한 UI적인 측면 외에도 사용자와의 상호작용 없이 사용자의 권한으로 정보를 조회하거나 변경하는 등의 요청을 주고 응답받는 것도 가능합니다. 이는 사용자의 권한을 가지고 있는 세션 쿠키는 사용자에게 저장되어있고 웹 브라우저는 해당 쿠키에 접근할 수 있기 때문입니다.

 

이외에도 웹 브라우저에서 출력되어지는 페이지의 내용을 조작하거나, 웹 브라우저의 위치를 공격자가 원하는 주소로 변경 가능합니다. 이처럼 사용자의 입장에서 발생하는 행위를 동작 시킬 수 있기 때문에 자바스크립트는 XSS 공격 시 많이 사용합니다.

 

자바스크립트를 실행하는 대표적인 방법은 script 태그를 이용하는 방식이 있으며 공격자가 입력 데이터로 script 태그를 전송 해 다른 사용자의 응답에 포함되면 공격자의 자바스크립트가 실행됩니다. script 태그 외에도 태그의 속성 중 특정 상황에서 발생하는 on*이벤트들을 사용하여 자바스크립트 실행이 가능합니다.

>>script 태그 보내서 다른 사용자에게 실행시키기

 

쿠키 및 세션

 

페이지 변조

위치 이동

 

Stored XSS

Stored XSS는 악성 스크립트가 서버 내에 존재하는 데이터베이스 또는 파일 등의 형태로 저장되어 있다가 사용자가 저장된 악성 스크립트를 조회하는 순간 발생하는 형태의 XSS 입니다. 대표적인 예시로 게시판 서비스에서 악성 스크립트가 포함된 게시물을 조회할 때 악성 스크립트가 실행되는 공격 방식이 있습니다.

 

게시판과 같이 서버 내에 저장되어 있는 형태에서는 불특정 다수에게 공격이 가능하다는 점에서 높은 파급력을 가질 수 있는 가능성도 존재하지만, 악성 스크립트가 실행되는 페이지가 사용자가 일반적으로 접근하기 어려운 서비스일 경우에는 파급력이 높지 않을 수 있습니다. 이와 같이 서비스의 형태와 접근성, 그리고 해당 서비스를 통해 얻을 수 있는 정보 또는 행위들에 따라 파급력은 달라질 수 있습니다.

 

아래 탭에서는 게시판에서 게시글을 작성하는 기능에서 사용자의 입력값에 대한 검증 과정의 부재로 인해 HTML을 그대로 출력 하게 됩니다. <script> 태그 등을 포함한 HTML 태그를 게시글에 삽입해보고 실제 응답 시 반환되는 HTML 코드를 통해 Stored XSS의 발생 형태를 확인해 볼 수 있습니다.

 

게시글 내용에 
ㅎ <script> location.href="https://www.naver.com" </script> 입력

악성 스크립트 injected 

다른 사용자가 이 게시물 클릭하면 네이버로 이동

 

Reflected XSS

Reflected XSS는 악성 스크립트가 사용자의 요청과 함께 전송되는 형태입니다. 사용자가 요청한 데이터가 서버의 응답에 포함되어 HTML 등의 악성 스크립트가 그대로 출력되어 발생하게 됩니다.

 

Reflected XSS는 Stored XSS와는 다르게 사용자의 요청 데이터에 의해 취약점이 발생하기 때문에, 변조된 데이터가 사용자의 요청으로 전송되는 형태를 유도해야 합니다. 가장 간단한 방법으로는 특정 링크를 유도하는 방식이 존재하며 Click Jacking, Open Redirect 등의 다른 취약점과 연계하여 발생시키는 방법도 존재합니다.

 

대표적인 예시로는 게시판 서비스에서 작성된 게시물을 조회하는 과정에서 조회하기 위해 입력한 데이터에 의해 발생하는 방식이 있습니다. 사용자가 게시물 조회를 요청 시 서버는 해당 요청에 대하여 조회한 결과를 응답에 출력하며, 편의성을 위해 사용자가 조회한 내용을 응답에 포함하기도 합니다. 이때 서버에서 악성 스크립트에 대한 검증을 올바르지 않을 경우 응답에 포함되며, 웹브라우저에서 페이지를 출력 시 해당 스크립트가 반영(Reflect)되어 Reflected XSS로 이어질 수 있습니다.

 

아래 탭에서는 게시판에서 게시글을 조회하는 기능에서 사용자의 입력 데이터 대한 검증 과정의 부재로 인해 HTML을 그대로 출력하게 됩니다. HTML 태그를 조회를 위한 데이터에 삽입해보고 실제 응답 시 반환되는 HTML 코드를 통해 Reflected XSS의 발생 형태를 확인해 볼 수 있습니다.

http://dreamhack.io/?search=35

변환시켜보기

 

<대처방안>

XSS는 웹 서비스상에서 빈번하게 일어나는 취약점 중 하나이며 오래전부터 발생했던 취약점이기 때문에 이를 방어하기 위해 많은 방안들이 생겨났습니다.

브라우저 단에서 방어하는 기술뿐만 아니라 서버 내부에 저장하는 시점 혹은 저장된 데이터를 출력하는 시점에 입력 값을 올바르게 검증하는 방식으로 XSS를 방어해야 합니다. 아래는 방어 기술의 종류입니다.

• Server-side Mitigations
• HTTPOnly 플래그 사용
• Content Security Policy 사용
• X-XSS-Protection

Server-side Mitigation(서버쪽 대처방법)

XSS를 유발할 수 있는 태그 삽입을 방지하기 위해 서버 단에서 검증하는 방법입니다.

사용자의 입력 값이 HTML 태그가 될 일이 없다면 꺽쇠 (<, >), 따옴표(", ')와 같은 특수 문자를 HTML Entity Encoding을 이용해 태그로 인식하지 않도록 수정(Escape) 할 수 있습니다.

만약 사용자 입력 값에 HTML 형태를 지원해야 한다면 화이트리스트 필터링을 해야합니다.

화이트리스트 필터링이란 허용해도 안전한 일부 태그, 속성을 제외한 모든 값을 필터링 하는 것을 의미합니다.

게시글을 운영하는데 있어서 img, video, a 태그만 필요하다면 해당되는 세 개의 태그를 제외한 모든 태그는 필터링하는 방식입니다.

--사용자의 입력 값을 필터링 할 때 유의할 점은 요청의 URI Query 값이나 POST Body 값만 필터링하는 것이 아니라 User-Agent, Referer와 같은 헤더도 모두 포함하여 사용자로부터 입력된 값에 모두 적용해야 합니다.

Mozilla 에서 제작한 Bleach (https://github.com/mozilla/bleach) 라는 HTML 필터링 라이브러리를 추천합니다.

mozilla/bleach

 

그 외에도..

사용자가 로그인할 때 세션에 로그인한 IP주소를 함께 저장하고, 사용자가 페이지를 접속할 때마다 현재 IP주소와 로그인 했던 IP주소의 동일 여부를 확인하는 방법이 있습니다. 해당 방법은 공격자가 세션 ID를 탈취해도 피해자와 IP주소가 달라 피해자의 세션을 사용하지 못하게 하는 장점이 있어 과거에 널리 쓰였습니다.

최근에는 Mobile 환경의 사용자가 점점 많아지면서 WiFi를 주로 이용합니다. 사용자가 이용하는 WiFi가 바뀔 때마다 사용자의 IP주소는 매번 바뀌기 때문에 접속한 IP가 아닌 접속한 국가가 변경된 경우를 탐지하는 형태로 변형되었습니다.

 

HTTPOnly Flag

Set-Cookie: session=sbdh1vjwvq; HttpOnly

HTTPOnly 플래그는 서버 측에서 응답 헤더에 Set-Cookie 헤더를 전송해 자바스크립트에서 해당 쿠키에 접근 하는 것을 금지합니다. 이는 쿠키를 생성할 때 옵션으로 설정 가능하며, XSS 취약점이 발생하더라도 공격자가 알아낼 수 없는 쿠키 값이기 때문에 세션쿠키를 설정할 땐 HTTPOnly 플래그를 적용하는 것을 권장합니다.

 

<Content Security Policy(CSP)>

CSP는 응답 헤더나 meta 태그를 통해 아래와 같이 선언해서 사용할 수 있으며, 각각의 지시어를 적용하여 사이트에서 로드하는 리소스들의 출처를 제한할 수 있습니다.

Content-Security-Policy: <지시어>; ...

예를 들어 default-src 'self' *.dreamhack.io   와 같이 설정된 CSP는

모든 리소스(이미지 파일, 스크립트 파일 등)의 출처가 현재 도메인이거나, *.dreamhack.io 도메인일 경우만 허용합니다.

 

또한 script-src를 선언해 자바스크립트 코드의 출처를 제한할 수 있으며, 공격자가 외부에 업로드된 자바스크립트 파일을 호출하거나 직접 자바스크립트 코드를 작성하는 등의 행위를 막을 수 있습니다.

 

그러나 신뢰할 출처를 선언하는 방식인만큼 신뢰하는 CDN 서버가 해킹당하면 무력화되는 단점이 존재합니다.

 

이 외에도 많은 리소스 형식 (이미지, 폰트, 오브젝트, ...) 의 출처를 제한할 수 있는 지시어들이 존재하며

script-src 'nonce-noncevalue13b739d8ea12' 와 같이 script-src를 이용해 nonce (랜덤) 값을 설정하고

HTML 태그를 이용해 자바스크립트를 실행할 때는 반드시 서버에서 생성된 nonce 값을 알아야만 실행될 수 있도록 할 수 있습니다.

즉, XSS 공격을 당하더라도 서버에서 매번 생성되는 nonce 값을 알 수 없다면 일반적인 방법으로 자바스크립트 실행이 불가능해집니다.

 

또한 script-src 'sha256-hashvalue_base64' 와 같은 형태로 자바스크립트나 스타일시트의 해시를 알아내 CSP를 적용하면 미리 알아낸 해시와 다를 경우 실행하지 않도록 할 수 있습니다.

작성한 CSP 지시어가 올바른지 확인하려면 http://csp-evaluator.withgoogle.com/에서 확인 가능합니다.

CSP Evaluator

 

 

<X-XSS-Protection Header>

X-XSS-Protection은 Response Header에 아래와 같이 선언해서 사용할 수 있습니다.

X-XSS-Protection: <값>

해당 정책은 웹 브라우저에 내장된 XSS Filter를 활성화할 것인지를 판단합니다.

XSS Filter는 웹 브라우저에서 전송된 Request 값이 XSS 공격 코드와 유사하고, Response에 해당 공격 코드가 포함되었을 경우에 XSS 공격이 수행되고 있음을 판단하여 XSS 공격 발생을 사용자에게 알리고 차단합니다.

Request 값과 Response를 비교해 판단하는 것으로 보아 Reflected XSS 공격을 막는 데에 적합한 방어 방법임을 알 수 있으며, 다른 유형의 XSS 공격을 방어할 수 없습니다.

 

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

X-XSS-Protection: 1; report=<reporting-uri>

위와 같이 네 가지의 사용법이 있으며 해당 Header를 선언하지 않았을 때의 브라우저의 기본 값은 1로, 기본으로 적용됩니다. 0일 경우 XSS Filter를 사용하지 않으며, 1일 경우 XSS 공격이 탐지되면 해당 부분만 제거한 뒤 페이지의 결과를 화면에 출력합니다.

mode=block일 경우 XSS 공격이 탐지되면 페이지 전체의 렌더링을 중단하며,

report를 선언할 경우에 XSS 공격이 탐지된 사실을 미리 설정한 주소에 신고하여 운영자가 대처하기 쉽도록합니다.

 

<Cross Site Request Forgery(CRSF)>

웹 브라우저는 기본적으로 Same-Origin-Policy에 위반되지 않은 모든 요청에 쿠키를 포함해 전송합니다.

비정상적으로 사용자의 의도와 무관하게(공격자가 사용자의 권한으로) 다른 사이트에 HTTP 요청을 보내는 것을 CSRF 공격이라 합니다.

--Same-Origin-Policy :다른 오리진의 리소스를 요청하거나 상호작용하는 것을 제한하는 웹 브라우저 보안정책

 

CSRF 공격을 통해 공격자가 취할 수 있는 이득은 해당 세션 쿠키를 가진 사람만 사용할 수 있는 기능을 요청할 수 있다는 것입니다.

기존 권한을 갖고 있는 사용자가 사용할 수 있는 정상적인 기능을 공격자가 사용자의 의도와 무관하게 요청을 보내 원하는 이득을 취할 수 있습니다.

예를 들어, 임의 금액을 송금하게 만들어 금전적인 이득을 얻거나, 사용자의 패스워드를 공격자가 임의로 설정한 값으로 변경해 계정을 탈취하거나, 관리자 권한을 가진 사용자를 공격해 공지사항 작성 등으로 혼란을 야기할 수 있습니다.

 

CSRF 공격을 성공적으로 수행하기 위해서는 아래의 두 가지 조건이 요구됩니다.

1. 해당 웹 사이트가 쿠키를 이용한 인증 방식을 사용해야 합니다.
   • 모든 HTTP 전송엔 쿠키가 함께 전송되기 때문에 쿠키에 저장된 세션 아이디도 전송됩니다.
2. 공격자가 사전에 알 수 없는 파라미터가 존재해서는 안됩니다.
   • 자동입력 방지 문자를 넣어야 하는 요청은 공격자가 미리 알 수 없습니다.
   • 패스워드 변경 기능에서 기존 패스워드를 입력 받는 다면 이 또한 공격자가 알 수 없습니다.

 

게시글에

<img src="/sendmoney?to=dreamhack&amount=1000000">

<img src=1 onerror="fetch('/sendmoney?to=dreamhack&amount=100000');">

<link rel="stylesheet" href="/sendmoney?to=dreamhack&amount=100000">

 

이 내용을 포함해서 게시글을 쓰면 조회한 사람이 dreamhack에게 입금하게 된다. 

 

CSRF 공격을 막기 위해서는 보통 두 가지 방법을 사용합니다.

1. 세션 쿠키 대신 커스텀 헤더를 사용하여 사용자 인증
   • 사용자 인증만을 위한 헤더를 추가합니다. (e.g. Authorization)
2. 공격자가 예측할 수 없는 파라미터 추가 및 검증
   • Same Origin에서만 접근 가능한 데이터를 삽입합니다.
     • CSRF Token
   • CAPTCHA
   • 정상적인 사용자만 알고있는 기존의 값을 검증합니다. (예: 현재 비밀번호)

SameSite Cookie

위 두가지 방법은 서버 사이드에서 추가적인 검증을 통해 CSRF를 방어하는 방법입니다. 서버 코드에 검증 로직이 추가되는 방식이라 어쩔 수 없는 오버헤드가 발생하게 됩니다.

 

CSRF 공격이 가능한 이유를 다시 한번 생각해보면 웹 브라우저가 크로스 사이트, 즉 다른 사이트로부터 온 요청에 쿠키를 함께 전송한다는 것입니다.

 

웹 브라우저는 다른 사이트로부터 온 요청에 쿠키를 삽입할지를 SameSite 쿠키 설정을 보고 판단합니다.

쿠키에는 key=value를 포함해 추가적인 설정 값도 함께 저장합니다. 기존에는 Domain, Expires, Path 등만 포함했지만 새롭게 SameSite 옵션이 추가되었습니다.

 

크로스 사이트에서 출발한 요청에 제한적으로 쿠키를 포함시키게 하는 옵션입니다. 총 세 가지(Strict, Lax, Normal) 값을 설정할 수 있습니다.

기본적으로 Strict는 모든 크로스 사이트에서 출발한 요청에 해당 쿠키를 삽입하지 않습니다.

Lax는 Link, Prerender, Form GET을 제외한 요청에는 쿠키를 삽입하지 않고

Normal 옵션은 기존과 동일하게 모든 요청에 쿠키를 삽입합니다.

해당 옵션을 설정하지 않을시 Normal과 동일한 권한을 가집니다.

--크롬 브라우저는 2020년부터 개발자가 강제로 SameSite=None; Secure; 을 넣지 않는 이상 웹 브라우저는 모든 쿠키에 SameSite=Lax를 강제로 적용하고 있습니다.

 

<Open Redirect>

Redirect(리다이렉트)는 사용자의 Location(위치)를 이동시키기 위해 사용하는 기능 중 하나입니다.

리다이렉트가 사용되는 코드는 아래와 같이 HTTP Response의 300번대 영역을 통해 이동하거나, 자바스크립트를 통해 이동하는 경우가 대부분이며 이때 이동하는 주소가 공격자에 의해 변조될 경우 Open Redirect(오픈 리다이렉트) 취약점이 발생하게 됩니다.

오픈 리다이렉트 취약점은 사용자가 접속한 도메인 사이트에 대한 신뢰를 무너뜨릴 수 있는 공격으로 오픈 리다이렉트 취약점을 통해 피싱사이트로 접속을 유도하거나, 다른 취약점을 연계하여 사용자를 공격할 수 있습니다.

 

오픈 리다이렉트의 공격 방법은 리다이렉트가 발생하는 경로에서 공격자의 입력 값에 의해 리다이렉트되는 주소가 변경 될 경우, 해당 경로와 공격자의 값이 함께 전달되도록 사용자를 유도하여 리다이렉트가 되도록 하는 방법이 있습니다.

 

아래 코드는 사용자가 입력하는 url 데이터를 location.href을 통해 이동하는 테스트 모듈과 코드다. 

https://example.com과 같이 다른 주소를 입력해 접속을 유도하거나, javascript:<JS Code>의 형태와 같이 자바스크립트 scheme을 통해 자바스크립트를 실행해 볼 수 있습니다.

<html>

<head>

<script>window.onload = function(){

let searchParams = new URLSearchParams(window.location.search);

location.href = searchParams.get('url');}

</script>

</head>

<body>

</body>

</html>

 

모르겠따

 

리다이렉트 기능은 서비스적인 측면에서 사용해야 하는 경우가 존재하며, 오픈 리다이렉트 취약점으로 발생할 수 있는 피해를 최소화 해야합니다.

최소화하는 방법 중 이동을 허용한 주소에 대해서만 이동하게끔 하는 방법이 있습니다.

 

사용자의 입력 값으로 리다이렉트 되는 기능을 사용해야 하는 경우 서버에서 해당 링크에 대한 검증을 거친 후 사용자에게 배포하거나, 외부 링크로 이동하는 것을 사용자가 알 수 있도록 하는 방법 등이 있습니다.

>>경고화면: 이 링크를 클릭할 시 모든 책임은 사용자에게~~~~

 

<Click Jacking>

Click Jacking(클릭 재킹)은 웹 브라우저 화면에 출력되는 내용에 HTML, CSS, JS 등과 같이 화면 출력에 영향을 미치는 요소들을 이용하여 사용자의 눈을 속여 사용자의 클릭을 유도;;하는 공격 방법입니다. 외부 페이지 리소스를 불러올 수 있는 태그 엘리먼트(<frame>, <iframe>, <object>, <embed>, <applet>)를 사용합니다.

 

사용자의 클릭을 유도하는 페이지를 구성한 후, 그 페이지 위에 iframe 등의 태그로 누르게 할 페이지를 로드합니다. 그리고 CSS opacity(요소의 투명도를 조정)와 같이 사용자의 눈에는 보이지 않도록 숨겨 놓는 방법 등을 이용하여 공격을 할 수 있습니다. 사용자가 보는 페이지와 실제로 누르는 곳에 차이가 있는 이유는 iframe 태그가 웹 브라우저 상에서는 더 앞에 위치해 있기 때문입니다.

myframe 주목

<!doctype html>

<html> <head> <meta charset='utf-8'> </head>

<body> <div id="wrapper"> <div id="my-div"> <button id='my-button'>광고 끄기</button> <img src="theori_tv.jpg" id='my-img'> </div>

//여기부분

<iframe src="https://bank.dreamhack.io/send_money_preview?to=hacker&amount=10000" id="my-frame"></iframe>

 

</div> <script> </script><style>button { width: 100px; height: 30px; }* { margin: 0; padding: 0; }#wrapper { position: absolute; top: calc(50% - 250px); left: calc(50% - 250px);}#my-div { position: absolute; z-index: -9; top: 118px; left: 10px;}#my-img { border: 1px solid blue; width: 600px; position: absolute; left: 0; z-index: -10;}#my-button { width: 100px; height: 100px;}

//투명하게

#my-frame { border: 1px solid red; width: 300px; height: 300px; opacity: 0.1;}

 

</style> </body></html>

 

클릭 재킹의 미티게이션은 X-Frame-Options와 frame-ancestors 두 가지가 있습니다.

 

X-Frame-Options

HTTP 응답 헤더를 통해 DENY와 SAMEORIGIN 두 개의 값으로 설정할 수 있습니다.

값                                     내용

DENY	부모 페이지 URL 상관없이 모두 차단.
SAMEORIGIN	부모 페이지 URL이 Same Origin이라면 허용.

X-Frame-Options: DENY

 

frame-ancestors 

Content Security Policy(CSP)의 frame-ancestors 지시어를 통해 값을 설정할 수 있습니다. frame-ancestors 지시어는 CSP를 HTTP 응답 헤더를 통해 설정해야 하며 <meta> 태그로는 설정할 수 없습니다.

값내용

'none'	X-Frame-Options DENY와 동일
'self'	X-Frame-Options SAMEORIGIN과 동일
http://, https://	scheme이 같으면 모두 허용
*.dreamhack.io, dreamhack.io, https://dreamhack.io	host나 scheme+host가 같으면 모두 허용, 와일드카드(*)를 사용할 수 있음.

 

Content-Security-Policy: frame-ancestors

http://dreamhack.io *.google.com https://

 

>>http://dreamhack.io와 google.com의 모든 서브도메인 그리고 https:// scheme을 모두 허용

 

X-Frame-Options vs CSP frame-ancestors

The World Wide Web Consortium(W3C)에서는 X-Frame-Options 은 최상위 parent의 URL을, frame-ancestors은 모든 parent의 URL들을 검사해야 한다고 명시했습니다.

대부분의 브라우저에서는 호환성과 보안 문제로 모든 parent URL들을 검사하지만 X-Frame-Options보다는 최신 기술인 CSP frame-ancestors를 사용하는 것을 권장합니다.

 

[frame-ancestors 지시어의 값은 'self'로 동일 오리진만 허용

- https://www.google.com으로 인해 실패]

[frame-ancestors 지시어의 값은 'self'로 동일 오리진만 허용 - 성공]

https://sandbox.dreamhack.io/test

 

참고: 도메인 vs 오리진

• 도메인(domain): naver.com
• 오리진(origin): https://www.naver.com/PORT

이와 같이 도메인과 오리진의 차이는 프로토콜과 포트번호의 포함 여부이다.

출처: https://velog.io/@josworks27/CORS-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90

CORS(Cross-origin Resource Sharing)의 기초 개념

퀴즈

ㅇ