[Spring Security] 웹 보안 공격 #1: CSRF공격과 XSS 공격 + 대응 전략

🌿Spring

[Spring Security] 웹 보안 공격 #1: CSRF공격과 XSS 공격 + 대응 전략

소영 🍀 2025. 5. 23. 16:42

웹 애플리케이션에서 발생할 수 있는 4가지 주요 보안 공격

: CSRF 공격, XSS 공격, 세션 고정 공격, JWT 탈취 공격에 대해 알아보고,

이를 방어할 수 있는 Spring Security 또는 일반적인 대응 전략을 살펴보고자 합니다.

글이 길어져서 두 편에 나누어 씁니다.

📌 CSRF 공격

CSRF는 Cross-Stie Request Forgery의 줄임말로 "사이트 간 요청 위조"를 의미합니다.

인터넷 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정한 웹 사이트에 요청하도록 만드는 공격입니다.

CSRF 공격이 성공하려면 3가지 조건을 만족해야 합니다.

사용자는 서버에 로그인되어 있는 상태여야 합니다.
해커(공격자)가 사용자의 세션 정보를 쿠키에서 읽을 수 있어야 합니다.
해커(공격자) 는 서버에 요청을 보내는 방법(API, 필요한 매개변수 )을 미리 알고 있어야 합니다.

시나리오를 볼까요? 다음과 같은 상황이 전제되어 있다고 합시다.

피해자는 은행 사이트(bank.com)에 로그인한 상태입니다.
은행 사용자는 POST /transfer 요청으로 서버에 송금을 요청할 수 있습니다.
해커는 이것을 알고 피해자 계정에서 자신의 계좌로 돈을 빼내고자 합니다.

🥊 해커는 다음 방법으로 공격할 수 있습니다.

<html>
  <body onload="document.forms[0].submit()">
    <form action="https://bank.com/transfer" method="POST">
      <input type="hidden" name="toAccount" value="hacker-account" />
      <input type="hidden" name="amount" value="1000000" />
    </form>
  </body>
</html>

해커는 자신의 블로그나 악성 사이트에 위와 같은 코드를 숨겨 둡니다.
해커는 이 사이트를 피해자에게 이메일이나 광고 등을 통해 전달하고, 피해자가 사이트에 방문하게 만듭니다.
피해자가 bank.com에 이미 로그인 되어 있던 상태에서 해커 사이트에 접속하면 위 폼이 자동으로 제출되며 bank.com으로 요청이 갑니다.
bank.com으로 해커의 계좌(hacker-account)로 1000000원 송금하라는 POST /transfer 요청이 전송됩니다. 이때 피해자의 세션 쿠키가 자동으로 포함됩니다.
- 왜 세션 쿠키가 자동으로 포함될까요? HTTP 쿠키는 특정 도메인에 대해 저장되고,
  브라우저는 사용자가 해당 도메인으로 요청을 보낼 때 쿠키의 출처와 상관 없이 그 도메인에 설정된 쿠키를 자동으로 첨부하기 때문입니다.
- bank.com에서 로그인해서 쿠키를 가지고 있고, bank.com으로 송금 요청을 보내게 되니 브라우저는 이전에 bank.com에서 받은 쿠키를 함께 보냅니다.
bank.com 서버는 요청에 로그인한 사용자의 세션 쿠키가 담겨있으니 적합한 요청이라 판단하고, 송금을 처리합니다.

💉대응 전략

✅ CSRF 토큰 사용

Spring에서는 Spring Security에서 CSRF 보호 설정을 하여 이 공격을 방어할 수 있습니다.

이 설정은 사용자 세션에 임의의 값, CSRF 토큰을 저장하여 모든 요청마다 해당 값을 포함하여 전송되도록 합니다.

서버에서 요청을 받을 때마다 세션에 저장된 값과 비교하여 올바른 요청인지 검증합니다.

Spring Security의 CSRF 보호 흐름

사용자로부터 첫 요청이 들어올 때 CsrfFilter가 동작
랜덤한 값의 CsrfToken을 생성하여 세션에 저장
사용자에게 CsrfToken을 보냄. 아래 두 값이 전송됨
- ${_csrf.token} → HTML 폼으로 hidden 필드로 포함
- javascript를 통해 X-CSRF-TOKEN 헤더로 설정
이후 사용자가 POST, PUT, DELETE 요청을 보내면 CsrfFilter가 토큰을 세션에 저장된 값과 확인
- GET 등의 다른 메서드는 안전한 메서드로 간주하여 검증 제외
불일치 시 403 Forbidden 응답

✅ Referer Check(리퍼러 체크)

Referer는 HTTP 요청 헤더 중 하나입니다. 사용잦가 어떤 사이트에서 이 요청을 보냈는지 나타냅니다.

예를 들어 사용자가 해커의 공격 사이트인 attack.com에서 은행 사이트인 bank.com으로 요청을 보냈다면

요청은 다음과 같이 갈 수 있습니다.

POST /transfer 
Host: http://bank.com
Referer: http://attack.com

서버에서는 Rererer 헤더를 확인한 후 호스트와 도메인이 일치하지 않으면

다른 사이트에서 온 요청이므로 거부합니다.

이 방법만으로 많은 CSRF 공격을 방어할 수 있다고 합니다.

📌 XSS 공격

XSS는 Cross-Site Scripting으로

관리자가 아닌, 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격입니다.

공격 방법에 따라 3가지로 구분됩니다.

🥊 Reflected XSS (반사형 크로스사이트스크립트)

사용자의 요청이 서버에서 데이터베이스에 따로 저장되지 않고, 응답 HTML에 그대로 반영되는 경우가 있습니다.

이때 사용자의 요청에 악성 스크립트가 포함되어 있었다면, 사용자가 준 값이 그대로 웹페이지에 "반사"되어

브라우저에서 악성 스크립트로 실행이 됩니다.

<script> (악성 스크립트 내용) </script>

🥊 Stored XSS (저장형 크로스사이트스크립트)

웹 서버에 악성 스크립트를 저장하는 공격 방법입니다.

해커가 악성 스크립트가 포함된 게시글을 작성하여 게시판 등 일반 사용자가 접근할 수 있는 페이지에 업로드합니다.

악성 스크립트가 DB에 저장되는거죠.

이후 다른 사용자가 해당 게시글을 요청하면 서버에 저장된 악성 스크립트가 사용자 측에서 동작하게 됩니다.

즉, 해커가 한 번만 삽입해도, 그 데이터가 노출될 때마다 피해자가 생기는 지속적인 위험 요소입니다.

🥊 DOM Based XSS (DOM 기반 크로스사이트스크립트)

악성 스크립트가 서버와 상호작용 없이 브라우저 자체에서 실행되는 취약점으로,

페이지에 포함되어 있는 브라우저 악성 코드가 DOM 환경에서 실행됩니다.

DOM(Document Object Model, 문서 객체 모델): 브라우저가 웹 페이지를 렌더링 하는데 사용하는 모델로 HTML 및 XML 문서에 접근하기 위한 인터페이스

서버를 거치지 않기 때문에 백엔드에서 해결할 수 있는 유형은 아닙니다.

💉대응 전략

✅ 입력값 필터링과 출력 시 이스케이프 처리

사용자 입력 중 <script>, onload= 와 같이 스크립트를 실행하려는 키워드가 있는 경우

이런 위험한 문자열은 차단하거나 필터링합니다.

또한 사용자 입력을 HTML, Javascript 등에 출력할 때 안전한 문자로 변환해야 합니다.

<!-- 위험 -->
<div>${userInput}</div>

<!-- 안전 (Thymeleaf, JSP 등은 자동 이스케이프 지원) -->
<div th:text="${userInput}"></div>

✅ Content Security Policy (CSP)

CSP는 브라우저 단에서 스크립트 실행을 제한하는 보안 정책입니다.

"이 페이지에는 이 리소스들만 허용한다"를 지시하는 것입니다.

Spring Security에서 아래와 같이 CSP를 설정할 수 있습니다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .headers(headers -> headers
            .contentSecurityPolicy(csp -> csp
                .policyDirectives("default-src 'self'; script-src 'self'")
            )
        );
    return http.build();
}

이러면 Spring Security는 응답 헤더에 아래처럼 추가합니다.

Content-Security-Policy: default-src 'self'; script-src 'self'

default-src 'self': 기본적으로 내 도메인(self)의 리소스만 허용
script-src 'self': 스크립트는 오직 내 서버(self)에서 제공되는 것만 실행 가능
- 외부 Javascript 파일이나 HTML내 <script> 태그가 인라인으로 있어도 실행되지 않습니다.
- 악성 스크립트 실행을 막기 위해 중요한 설정입니다.

self 외에도 다양한 옵션이 있습니다.

nonce-{랜덤값}: 특정 nonce 값을 가진 인라인 스크립트만 허용
sha256-{해시값}: 특정 해시와 일치하는 인라인 스크립트만 허용