[웹 보안] CSRF, CORS, XSS, CSP

CSRF

Cross-Site Request Forgery : 사이트 간 요청 위조

---

CSRF 는 공격자가 사용자가 현재 로그인된 사이트에 대해 강제로 작업을 실행하게하는 공격 입니다.

 

// 공격 시나리오

1. 'example.com'을 방문합니다.

2. 'example.com'에는 페이지 로드시 'bank.com/송금'에 제출하는 숨겨진 양식이 있습니다.

3. 'bank.com'에 로그인 되었다면 bank.com 쿠키를 사용하여 자동으로 송금을 시작합니다.

4. 'example.com'과 'bank.com'은 출처가 다르기 떄문에 브라우저는 'example.com'에 응답 
    제공을 거부(CORS 때문에)하지만 공격자는 신경쓰지 않고 돈이 이미 이체되었습니다.

// 방어 시나리오

1. 'bank.com'이 사용자에게 양식을 제공 할 때마다 CSRF 토큰을 생성하여 양식의 숨겨진 필드에 삽입합니다.

2. POST 요청이 수식되면 데이터베이스에 대해 CSRF 토큰을 확인합니다.

3. 이 토큰이 유효하면 요청은 진행되지만 CSRF 토큰이 없거나 올바르지 않으면 거부됩니다.

 

CSRF 공격은 공격자에 의해 위조된 요청으로 공격이 진행되므로 실제 서버에서 발행한 View 페이지가 맞는지 CSRF 토큰으로 확인하여 공격을 방지합니다.

 

인증 -> View전달(CSRF 토큰) -> 요청 (CSRF 토큰) -> CSRF 토큰 확인 -> 거부 or 확인 -> 토큰 삭제

 

---

CORS

Cross-Origin Request Sharing : 교차 출처 요청 공유

---

CORS 는 브라우저 환경에서만 적용되며 한 출처가 다른 출처에 요청을 할 수 있도록 하는 보안 메커니즘입니다.

모든 브라우저는 단일 출처 정책(Single Origin Policy)을 따릅니다. 즉, 기본적으로 다른 출처에 요청할 수 없지만

서버가 적절하게 구성된 CORS 헤더를 제공하는 경우 선택적으로 교차 출처 정책을 사용할 수 있습니다.

 

※ 현대의 웹 서비스는 분산된 여러 서비스들이 상호작용하여 이루어진 구조를 가지기 때문에 CORS 정책을 따르는 경우가 많기 때문에 CORS를 알아두면 도움이 많이 됩니다.

 

기본적으로 다른 출처(origin)에 Ajax 요청을 하면 브라우저는 먼저 pre-flight options 요청을 보냅니다.

원래 요청은 서버가 허용된 출처(origin) 목록에 요청하는 출처가 포함된 경우에만 이루어집니다.

하지만 기본 헤더가 있는 GET HEAD POST 요청에서는 pre-flight 요청을 보내지 않습니다. 이것을 단순 요청이라고 합니다.

 

Cross-origin 요청에는 두가지 요청 방식이 있는데 단순 요청(simple request) 과 비 단순 요청 혹은 예비 요청(pre-flight) 가 있습니다.

예비 요청(pre-flight) 를 하는 목적은 유저 데이터에 영향을 줄 수 있기 때문에 미리 실제 요청을 전송하기에 안전한지 확인 합니다. 하지만 서비스에 따라 방화벽에서 options 이 차단되어 예비요청을 못하는 경우도 있습니다.

 

단순요청과 예비요청에 대한 자세한 사항은 MDN 문서를 확인하세요.

 

CORS - 응답 헤더

• access-control-allow-credentials : 설정된 경우 브라우저에서 쿠키를 보냅니다.
• access-control-allow-origin : 요청이 허용 된 출처 목록 또는 누구나 요청을 허용하는 '*'. 
  access-control-allow-credentials가 설정된 경우 '*'로 설정할 수 없거나 브라우저가 요청을 거부합니다.
• access-control-allow-methods : 통신이 허용 된 HTTP 메소드 목록-POST, PUT 등

서비스 API가 서비스 내부에서만 사용한다면 API 게이트웨이를 사용하면 CORS를 완전히 피할 수 있습니다.

반면, 제 3자에게 API를 제공하는 경우 CORS 사용은 불가피합니다.

---

XSS

Cross-Site Scripting  : 교차 사이트 스크립팅

---

XSS 는 공격자가 클라이언트 측 스크립트를 웹 페이지에 삽입하는 공격입니다.

XSS 를 사용하여 동일 출처 정책 및 CSRF 보호를 모두 우회 할 수 있습니다.

XSS 는 사용자가 웹 사이트를 방문 할 때마다 트리거되고 이는 서버를 손상시킬 수 있습니다.

XSS 는 가장 일반적으로 악용되는 취약점입니다.

 

XSS 는 출력부분에서 가장 잘 처리할 수 있습니다.

[ 입력 -> 데이터베이스 -> 출력(이스케이프 처리) ]

 

OWASP에는 XSS 삭제 우회 에 대한 포괄적인 섹션이 있습니다.

XSS 방지에 대한 OWASP 치트 시트는 XSS에 대한 애플리케이션 보안을 위한 좋은 시작점입니다.

---

CSP

Content Security Policy  : 콘텐츠 보안 정책

---

CSP 는 XSS 공격을 감지하고 완화하기위한 추가 보안 계층입니다.

스크립트를 실행 가능한 화이트리스트를 만들어 화이트리스트 도메인에서 로드된 스크립트만 실행합니다.

CSP는 스크립트, 스타일 시트, 이미지, 글꼴, 개체, 미디어 (오디오, 비디오), 프레임 및 양식 작업을 포함한 모든 동적 원본에 대해 허용된 원본을 지정할 수 있습니다.

 

CSP 는 Content-Security-Policy HTTP 헤더를 통해 설정됩니다.

 

CORS 와의 차이점은 CORS는 제 3자가 서버에 액세스하는 것을 방지하는 반면 CSP는 XSS에 대한 방어로 웹 사이트 자체가 제3자로부터 콘텐츠를 로드하지 못하도록 차단한다는 것입니다.

 

CSP 는 XSS를 무조건 막는건 아니지만 도움이 됩니다. 궁극적으로 XSS는 프론트 엔드와 백엔드 모두에서 신중한 설계와 이스케이핑을 통해 방지되어야합니다. 하지만 설계 난이도가 복잡하고 구현하기가 가장 어려울 수 있습니다. 그리고 충분한 테스트가 없다면 배포후 중단 될 수 있습니다. 

---

참고.

blog.vnaik.com/posts/web-attacks.html

CSRF, CORS, and HTTP Security headers Demystified

ko.wikipedia.org/wiki/%EA%B5%90%EC%B0%A8_%EC%B6%9C%EC%B2%98_%EB%A6%AC%EC%86%8C%EC%8A%A4_%EA%B3%B5%EC%9C%A0

교차 출처 리소스 공유 - 위키백과, 우리 모두의 백과사전

nhj12311.tistory.com/69

CORS 처리 시 options는 왜 부르는거지?(Simple, Pre-flight)