CS Repo/네트워크 - Top-down Approach + @

쿠키, XSS, CSRF, SOP, CORS

조금씩 차근차근 2024. 9. 27. 23:09

쿠키 개념

  • Name (이름): 쿠키의 고유 식별자입니다.
  • Value (값): 쿠키에 저장되는 실제 데이터입니다.
  • Expires/Max-Age: 쿠키의 유효 기간을 설정합니다.
    • Expires: 정확한 만료 날짜와 시간
    • Max-Age: 쿠키가 유효한 초 단위 시간
  • Domain: 쿠키가 전송될 수 있는 도메인을 지정합니다.
    • set-Cookie 시 앱웹 서버가 직접 지정하여
    • 우리 사이트 전용 쿠키라는 것을 지정해둔다.
  • Path: 쿠키가 유효한 서버의 경로를 지정합니다.
  • Secure: HTTPS 연결에서만 쿠키를 전송하도록 합니다.
  • HttpOnly: JavaScript를 통한 쿠키 접근을 방지합니다.
  • SameSite: 크로스 사이트 요청에 대한 쿠키 전송 제어:
    • Strict
    • Lax
    • None

XSS

  • 사용자 브라우저에 스크립트를 실행시켜 정보를 탈취하거나 조작
  • 사용자 브라우저의 자바스크립트 레벨에 직접 접근하여 HTTP 요청을 실행한다.

HTTP Only

  • 자바스크립트를 통한 쿠키에 접근을 제한한다
  • 그럼 공격자가
    • 사용자의 정보를 가지고
    • 자신의 서버에 HTTP요청을 보내고,
    • 거기서 쿠키에 접근을 수행하면?

SameSite

  • CSRF(XSRF) 공격을 방어하기 위한 헤더 레벨어서 설정 가능한 보안 설정
  • 다른 사이트에 대해선 쿠키를 포함시키지 않도록 설정 가능
    • 공격자 웹 사이트는 앱 웹 사이트와 다른 도메인을 가진다
    • 공격자 웹 사이트에서 사용자 쿠키를 가지고 앱 웹 사이트의 정보를 호출하려고 하지만
    • SameSite 헤더로 인해, 앱 웹서버의 쿠키는 포함되지 않았다.
    • 따라서 공격자 웹 서버에서 앱 웹 서버로 HTTP요청을 보내도, 사용자 인증 정보가 없어 값 변경이 불가능하게 된다.

CSRF

  • 인증된 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹 사이트에 요청하게 하는 공격
  1. 사용자가 로그인된 상태
  2. 특정 URL 클릭
    1. 로그인된 앱 웹사이트와는 다른 사이트 → 그 사이트 도메인이 없음
    2. 로그인된 앱 웹사이트에 데이터를 CRUD 하는 HTTP 포함
  3. 해당 HTTP 요청 호출
  4. 앱 웹서버는 인증된 사용자 정보로 인해 구분하지 못하고 해당 요청 처리

SOP

  • Same-Origin Policy
  • XSS 공격을 막기 위해, 브라우저 단에서 수행하는 보안 로직
  • 특정 사이트에서 호출하는 HTTP 요청은 모두 같은 출처의 요청을 보내야 한다

출처: Spring Security in Action

CORS 의 정확한 정의

  • Cross-Origin Resource Sharing (교차 출처 리소스 공유)
  • example.com 에서 api.example.com 에 접근하고 싶다면,
  • 앱 웹서버에서 이정도는 허용하게 할 수 있도록 브라우저에게 알리는 것.
  • @CrossOrigin 어노테이션 혹은 CorsConfigurationSource 빈으로 설정

JWT 의 저장 방법 (JWT 가 XSS공격에 취약한 이유)

  • 일반 헤더 (Authorization 헤더):
    • 가장 흔한 방법
    • 주로 "Bearer" 스키마와 함께 사용
    • 예: Authorization: Bearer <token>
    • XSS 공격을 방어할 수단이 없음
    • 주로 앱에서 사용되고, 앱은 자바스크립트로 접근이 불가능하고 패키징되어있으므로 안전함.
  • 쿠키:
    • 쿠키에 JWT를 저장할 수도 있음
    • 이 방법은 XSS 공격에 더 취약할 수 있지만, HttpOnly 플래그를 사용하여 보안을 강화할 수 있음
    • 따라서 XSS공격에 비교적 더 안전