간단하게 설명하기
방에서 장난감을 가지고 놀고 있는 아이를 상상해보자.
아이의 놀이방에 아기가 원하는 장난감이 모두 다 있을 수도 있지만, 대부분은 그렇지 않을 것이다.
만약 아이가 원하는 장난감이 옆집 친구에게 있다면, 아이는 친구 또는 친구 부모님께 혀락을 받고 장난감을 빌려와 가지고 놀 수 있을 것이다.
이처럼 웹사이트도 다른 웹사이트에서 정보나 사진을 얻어와야 하는 경우가 있다.
하지만 장난감을 빌려오기 위해 허락을 받는 것처럼 정보나 사진을 얻어올 때 허락을 받아야 한다.
CORS
CORS
교차 출처 자원 공유는 웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다.
CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의한다.
출처: 위키백과
CORS(Cross-Origin Resource Sharing)는 웹 페이지가 원래 페이지가 아닌 다른 도메인에 요청하는 것을 방지하기 위해 웹 브라우저에 구현된 보안 기능이다.
즉, 다른 웹 사이트에서 명시적으로 허용하지 않는 한 웹 페이지가 다른 웹 사이트의 리소스에 접근하지 못하도록 제한한다.
웹 사이트를 방문하면 웹 브라우저가 해당 웹 사이트를 호스팅하는 서버에 요청을 보내고 서버는 브라우저에 표시되는 웹 페이지로 응답한다.
때로는 웹 페이지가 원래 도메인이 아닌 다른 도메인(즉, 다른 웹 사이트)의 데이터나 리소스를 요청해야 한다.
예를 들어 웹 페이지는 다른 서버에서 호스팅되는 API에서 데이터를 가져오거나 다른 웹 사이트에서 호스팅되는 이미지를 표시하려고 할 수 있다.
CORS가 없으면 이것은 보안 문제가 된다.
악의적인 웹 사이트는 잠재적으로 다른 도메인에 요청을 만들어 사용자를 속여 중요한 정보를 보내거나 원치 않는 작업을 수행하도록 할 수 있다.
이를 방지하기 위해 웹 브라우저는 리소스를 호스팅하는 서버가 명시적으로 다른 도메인이 리소스에 접근할 수 있도록 허용해야 하는 CORS를 구현한다.
웹 페이지가 다른 도메인의 데이터 또는 리소스를 요청하면 리소스를 호스팅하는 서버는 웹 페이지가 리소스에 접근할 수 있는지 여부를 브라우저에 알려주는 HTTP 헤더로 응답할 수 있다.
CORS를 제어하는 HTTP 헤더를 "Access-Control-Allow-Origin" 헤더라고 한다.
서버가 특정 도메인의 웹 페이지가 리소스에 접근하도록 허용하려는 경우 해당 도메인을 헤더에 포함한다.
( 이미지 출처 : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS )
예를 들어 헤더는 다음과 같을 수 있다.
접근 제어 허용 원본: https://www.example.com
이는 https://www.example.com 에서 호스팅되는 웹 페이지가 리소스에 접근할 수 있음을 브라우저에 알린다.
요청하는 웹 페이지가 다른 도메인에 있는 경우 서버가 올바른 Access-Control-Allow-Origin 헤더를 포함하지 않는 한 브라우저는 요청을 허용하지 않는다.
경우에 따라 서버는 모든 도메인에서 액세스를 허용하려고 할 수 있다(예: 이미지 또는 비디오와 같은 공개 리소스의 경우).
이 경우 서버는 헤더에 "*" 와일드카드를 포함할 수 있다.
액세스 제어 허용 원본: *
이는 모든 도메인의 요청을 허용하도록 브라우저에 지시한다.
CORS는 악의적인 공격으로부터 사용자를 보호하는 데 도움이 되는 중요한 보안 기능이다.
신뢰할 수 있는 소스에서만 리소스에 접근할 수 있도록 하고 웹사이트에서 접근해서는 안 되는 데이터에 접근하지 못하도록 방지한다.
이는 신뢰할 수 있는 소스에서만 리소스에 접근하도록 하여 XSS(교차 사이트 스크립팅) 및 CSRF(교차 사이트 요청 위조)와 같은 악의적인 공격을 방지하는 데 도움이 되기 때문에 중요하다.
CORS의 사전 요청
CORS의 사전 요청은 웹 브라우저가 사용자 데이터 또는 기타 민감한 정보를 포함하는 "실제" 요청을 보내기 전에 서버에 "실행 전" 요청을 보낸다는 사실을 나타낸다.
실행 전 요청의 목적은 서버가 사용자가 현재 방문 중인 도메인의 요청을 허용하는지 여부를 확인하는 것입니다.
( 이미지 출처 : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS )
실행 전 요청은 몇 가지 추가 헤더를 포함하는 HTTP OPTIONS 요청이다.
이러한 헤더에는 다음이 포함된다.
Origin 사용자가 현재 방문하고 있는 도메인
Access-Control-Request-Method 실제 요청에 사용될 HTTP 방식(예: GET, POST)
Access-Control-Request-Headers 실제 요청에 포함될 커스텀 헤더
서버가 사전 요청을 받으면 리소스에 접근할 수 있는 도메인을 지정하는 몇 가지 추가 헤더와 함께 HTTP 200 OK 상태 코드로 응답해야 한다.
이러한 헤더에는 다음이 포함된다.
Access-Control-Allow-Origin 서버 리소스에 접근이 허용된 도메인
Access-Control-Allow-Methods 지정된 도메인에 허용되는 HTTP 메서드
Access-Control-Allow-Headers 지정된 도메인에 허용되는 사용자 정의 헤더
서버의 응답에 이러한 헤더가 포함되어 있고 요청된 도메인이 해당 리소스에 접근할 수 있도록 허용하는 경우 브라우저는 사용자 데이터 또는 기타 민감한 정보가 포함된 실제 요청을 진행한다.
서버의 응답에 필요한 헤더가 포함되어 있지 않거나 요청된 도메인이 해당 리소스에 접근하는 것을 허용하지 않는 경우 브라우저는 실제 요청이 전송되지 않도록 한다.
요약하면 CORS의 사전 요청은 웹 브라우저가 사용자 데이터 또는 기타 민감한 정보를 포함하는 실제 요청을 보내기 전에 서버에 보내는 실행 전 요청을 말한다.
사전 요청의 목적은 서버가 사용자가 현재 방문하고 있는 도메인의 요청을 허용하는지 확인하고 승인되지 않은 요청이 전송되는 것을 방지하는 것이다.
XSS
XSS(Cross-Site Scripting)는 공격자가 다른 사용자가 보는 웹 페이지에 악성 코드를 삽입할 수 있는 웹 애플리케이션 취약점 유형이다.
이는 로그인 자격 증명과 같은 민감한 정보를 도용하거나 사용자를 대신하여 무단 작업을 수행하는 데 사용될 수 있다.
XSS 공격은 일반적으로 종종 양식 필드 또는 URL 매개변수를 통해 웹 페이지에 악성 JavaScript 코드를 삽입하는 것과 관련 있다.
다른 사용자가 페이지를 보면 브라우저에서 악성 코드가 실행되어 공격자가 세션 쿠키에 접근하고 대신 작업을 수행할 수 있습니다.
XSS 공격에는 저장 XSS와 반영 XSS 두 가지 주요 유형이 있다.
저장(또는 영구) XSS
악성코드가 서버에 저장되어 해당 페이지를 보는 모든 사용자에게 노출되는 경우 발생한다.
예를 들어 공격자는 페이지를 보는 모든 사용자에게 표시되는 포럼 게시물이나 댓글에 악성 코드를 삽입할 수 있다.
반영(또는 비지속) XSS
URL 매개변수 또는 양식 필드에 악성코드가 포함되어 있을 때 발생하며, 서버 응답에서 사용자에게 다시 반영된다.
예를 들어 공격자는 클릭 시 사용자의 세션 쿠키를 포함하고 사용자 대신 무단 작업을 수행하는 악성 URL을 만들 수 있습니다.
XSS 공격을 방지하기 위해 웹 개발자는 입력 유효성 검사 및 출력 인코딩과 같은 다양한 기술을 사용하여 사용자 입력이 삭제되고 안전하게 렌더링되도록 할 수 있다.
웹 애플리케이션 방화벽을 사용하여 악의적인 요청을 탐지하고 차단할 수도 있다.
요약하면 XSS는 공격자가 다른 사용자가 보는 웹 페이지에 악성 코드를 주입할 수 있는 웹 애플리케이션 취약점의 한 유형이다.
민감한 정보를 도용하거나 승인되지 않은 행위를 수행하는 데 사용될 수 있으며 다양한 보안 기술을 통해 방지할 수 있다.
CSRF
CSRF(Cross-Site Request Forgery)는 공격자가 사용자가 알지 못하거나 동의 없이 웹 애플리케이션에서 의도치 않게 작업을 수행하도록 속일 수 있는 웹 애플리케이션 취약성 유형이다.
이 공격은 웹 애플리케이션이 사용자의 브라우저에서 갖는 신뢰를 악용하여 작동한다.
예를 들어 사용자가 취약한 웹 응용 프로그램에 로그인하고 악성 웹 사이트를 방문하는 경우 웹 사이트는 취약한 웹 응용 프로그램에서 사용자 대신 작업을 수행하는 숨겨진 양식을 제출할 수 있다.
사용자의 브라우저는 취약한 웹 애플리케이션에 속하는 모든 쿠키를 요청에 자동으로 포함하여 마치 사용자가 직접 작업을 시작한 것처럼 보이게 한다.
예를 들어 취약한 웹 응용 프로그램이 은행 웹 사이트인 경우 공격자는 사용자가 공격자의 웹 사이트를 방문할 때 사용자 계정에서 돈을 이체하는 숨겨진 양식을 만들 수 있다.
사용자는 이미 뱅킹 웹사이트에 로그인되어 있으므로 요청이 인증되고 사용자 모르게 또는 동의 없이 송금이 이루어진다.
CSRF 공격을 방지하기 위해 웹 개발자는 CSRF 토큰을 모든 양식 및 요청에 추가하거나 SameSite 쿠키를 사용하여 교차 사이트 요청에서 쿠키가 전송되지 않도록 하는 등의 다양한 기술을 사용할 수 있다.
CSRF 토큰은 서버에서 생성되고 양식 또는 요청에 포함된 임의의 값이다.
서버는 작업 수행을 허용하기 전에 토큰이 유효한지 확인하여 공격자가 승인되지 않은 요청을 제출하지 못하도록 한다.
요약하면 CSRF는 공격자가 사용자가 알지 못하거나 동의 없이 웹 애플리케이션에서 작업을 수행하도록 속일 수 있는 웹 애플리케이션 취약성 유형이다.
이 취약점은 CSRF 토큰 또는 SameSite 쿠키 사용과 같은 다양한 보안 기술을 통해 방지할 수 있다.
CSRF vs. XSS
CSRF와 XSS는 모두 웹 애플리케이션 취약점이지만 다음과 같은 몇 가지 중요한 차이점이 있다.
1. 공격 방법
CSRF 공격은 피해자가 자신도 모르는 사이에 취약한 웹사이트에 요청을 제출하도록 속이는 것이다.
반대로 XSS 공격은 다른 사용자가 보는 웹 페이지에 악성 코드를 주입하는 것과 관련이 있다.
2. 피해 유형
CSRF 공격은 사용자가 의도하지 않은 취약한 웹 사이트에서 무의식적으로 작업을 수행하도록 할 수 있다.
반대로 XSS 공격은 민감한 정보(예: 로그인 자격 증명 또는 신용 카드 번호)를 도용하거나 사용자를 대신하여 무단 작업(예: 스팸 이메일 전송 또는 세션 쿠키 도용)을 수행하는 데 사용될 수 있다.
3. 방지 기술
CSRF 토큰 또는 SameSite 쿠키와 같은 기술을 사용하여 CSRF 공격을 방지할 수 있다.
이러한 기술에는 승인된 사용자만 수행할 수 있도록 웹 양식 및 요청에 추가 보안 조치를 추가하는 것이 포함된다.
XSS 공격은 입력 유효성 검사 및 출력 인코딩과 같은 기술을 사용하여 방지할 수 있다.
이러한 기술에는 악성 코드가 포함되어 있지 않은지 확인하기 위해 사용자 입력을 주의 깊게 확인하고 삽입된 코드가 다른 사용자에 의해 실행되지 않도록 출력을 인코딩하는 작업이 포함된다.
그래서 CORS가 어떻게 방지하는데?
실제로 CORS는 CSRF 및 XSS 공격을 직접 방지하지 않는다.
대신 CORS는 이러한 유형의 공격으로 인한 위험을 완화하기 위해 웹 브라우저가 여러 도메인에 있는 웹 서버와 상호 작용하는 방식을 제어하도록 설계된 보안 메커니즘이다.
특히 CORS를 사용하면 웹 서버에서 HTTP 헤더를 사용하여 리소스(예: API, 쿠키 및 세션 데이터)에 접근할 수 있는 도메인을 지정할 수 있다.
기본적으로 웹 브라우저는 서로 다른 도메인 간에 만들 수 있는 요청 유형을 제한하는 "동일 출처 정책"을 적용한다.
그러나 웹 서버가 다른 도메인이 CORS 헤더를 사용하여 해당 리소스에 접근할 수 있도록 허용하도록 지정하는 경우 브라우저는 해당 요청이 진행되도록 허용한다.
그렇다면 이것이 CSRF 및 XSS 공격과 어떤 관련이 있을까?
이러한 유형의 공격은 모두 사용자가 현재 방문하고 있는 도메인이 아닌 다른 도메인에서 요청을 보내거나 악성 코드를 주입하는 기능에 의존한다.
CORS 헤더를 사용하여 중요한 리소스에 대한 액세스를 제한함으로써 웹 서버는 이러한 공격이 성공하지 못하도록 방지할 수 있다.
예를 들어 웹 서버는 CORS 헤더를 사용하여 API에 대한 액세스를 신뢰할 수 있는 소수의 도메인으로만 제한하여 악의적인 웹 사이트가 사용자를 대신하여 무단 요청을 하는 것을 방지할 수 있다.
마찬가지로 웹 서버는 쿠키 및 세션 데이터에 적절한 CORS 헤더를 설정하여 XSS 공격을 통해 주입된 악성 스크립트가 중요한 사용자 정보를 훔치는 것을 방지할 수 있다.
요약하면 CORS 자체가 CSRF 및 XSS 공격을 직접 방지하지는 않지만 이러한 유형의 공격으로 인한 위험을 완화하기 위한 심층 방어 전략의 일부로 사용할 수 있다.
민감한 리소스에 접근할 수 있는 도메인을 제어함으로써 웹 서버는 공격자가 웹 애플리케이션의 취약성을 악용하는 것을 방지할 수 있다.
