CORS (Cross-Origin Resource Sharing)
다른 도메인에서 호스팅되는 리소스에 대한 접근을 제어할 수 있는 메커니즘 제공
브라우저가 A사이트에서 B사이트로 API 요청이 가능하도록 하는 정책
웹 애플리케이션은 다른 출처의 리소스를 자유롭게 로드할 수 있어야 하지만, 보안상의 이유로 브라우저는 기본적으로 같은 출처 정책(Same-Origin Policy)을 적용한다.
CORS는 이 정책을 유연하게 해주어, 특정 조건 하에서의 교차 출처 접근을 허용한다.
작동 방식
사전 요청 (Preflight Request): 브라우저는 본 요청을 보내기 전에, OPTIONS 메소드를 이용한 사전 요청을 서버에 보낸다. 이를 통해 서버는 요청을 받아들일 수 있는지 확인한다.
헤더 설정: 서버는 Access-Control-Allow-Origin과 같은 CORS 헤더를 설정하여, 어떤 출처, 메소드, 헤더가 허용되는지 브라우저에 알린다.
예시
http://example.com의 스크립트가 http://api.example.com에서 데이터를 요청하고자 할 때, CORS 정책에 따라 api.example.com 서버는 적절한 Access-Control-Allow-Origin 헤더를 포함한 응답을 보내야 한다. 헤더가 없다면 브라우저는 요청을 거부한다.
CSRF (Cross-Site Request Forgery)
사용자가 자신의 의지와는 무관하게, 이미 인증된 세션을 이용하여 악의적인 변경을 요청하도록 만드는 공격
"one-click attack" 또는 "session riding"이라고도 한다.
주로 사용자가 로그인한 상태에서 안전하지 않은 링크를 클릭할 때 발생하며, 의도치 않은 명령이 실행된다.
예시
사용자가 온라인 뱅킹 서비스에 로그인해 있는 상태에서 악의적인 링크를 클릭하게 되면 이 링크는 사용자의 은행 계좌에서 돈을 이체하라는 요청을 은행 웹사이트로 보낼 수 있다. 사용자는 이를 인지하지 못한 채 자신의 인증 정보를 이용한 요청을 보낸다.
방어 방법
CSRF 토큰: 서버는 폼을 제출할 때마다 유니크한 토큰을 생성하고, 클라이언트는 폼 데이터와 함께 이 토큰을 제출해야 한다. 서버는 토큰을 검증하여 요청의 유효성을 확인한다.
SameSite 쿠키 속성: 이 속성을 사용하면 쿠키가 같은 사이트의 요청에서만 전송된다. 즉, 다른 사이트에서의 요청에는 쿠키가 포함되지 않아 CSRF 공격을 방지할 수 있다.
XSS(Cross-Site Scripting)
공격자가 사용자 측 스크립트를 웹 페이지에 삽입하여 다른 사용자의 브라우저에 실행되게 하는 공격
사용자의 세션 쿠키를 탈취하거나, 악성 스크립트를 실행하여 사용자 정보를 빼내거나, 피해 사용자를 가장할 수 있다.
공격 유형
Stored XSS
악성 스크립트가 웹 서버에 저장되는 형태
사용자가 해당 스크립트가 저장된 페이지를 방문할 때 마다 스크립트가 실행
Reflected XSS
사용자가 제공한 데이터를 웹 페이지가 즉시 에코하는 경우 발생
사용자가 특정 링크를 클릭하면 그 링크에 포함된 스크립트가 사용자의 브라우저에서 실행
DOM-Based XSS
웹 페이지의 DOM 환경에서 발생, 클라이언트 측 스크립트가 DOM을 변경하여 악성 스크립트를 실행
서버와의 왕복 없이 클라이언트 측에서 발생하므로 감지하기 어려움
XSS 방어 기법
입력 데이터 검증: 사용자로부터 입력받은 모든 데이터는 실행 가능한 스크립트 요소를 포함하지 않도록 필터링, 새니타이즈한다.
출력 인코딩: 데이터를 HTML, JavaScript 등에서 안전한 형태로 인코딩하여 출력한다.
콘텐츠 보안 정책(CSP): 웹 페이지에서 스크립트를 실행할 수 있는 출처를 제한하는 CSP를 설정하여 추가적인 보호층을 제공한다.
