[TECH-QA] CSRF(Cross-Site Request Forgery)와 XSSCross-Site Scripting

Posted 4 months Updated 4 months

By 베짱이가 되고싶은 개미。

CSRF 토큰 이란

CSRF 토큰은 크로스 사이트 요청 위조(Cross-Site Request Forgery, CSRF) 공격을 방어하기 위해 사용되는 고유한 랜덤 문자열입니다. 서버에서 생성되어 사용자 세션과 연결되며, 클라이언트가 서버에 요청(예: 폼 제출, AJAX 호출)을 보낼 때 이 토큰을 함께 전송하여 요청의 유효성을 검증합니다.

CSRF 토큰의 일반적인 흐름

📝 서버에서 CSRF 토큰 생성

사용자가 웹 애플리케이션에 접속하면, 서버는 해당 사용자 세션에 고유한 CSRF 토큰을 생성합니다.
이 토큰은 서버의 세션에 저장됩니다(예: 세션 ID와 연계된 서버 메모리, 데이터베이스, 또는 캐시).
서버 세션은 사용자마다 고유하며, 서버가 관리하는 상태 저장소입니다.

📝 클라이언트로 CSRF 토큰 전달

서버는 생성한 CSRF 토큰을 클라이언트(프론트엔드)로 전송합니다. 이는 보통 다음과 같은 방식으로 이루어집니다:

HTML 폼의 숨겨진 필드()로 포함.
AJAX 요청을 위해 HTTP 헤더(예: X-CSRF-Token)로 전달.
쿠키로 전송(단, 쿠키 자체는 CSRF 방지에 직접 사용되지 않음).

클라이언트는 이 토큰을 받아서 저장합니다. 이 저장은 주로 프론트엔드의 메모리(예: JavaScript 변수)나 HTML 폼에 일시적으로 유지되며, 프론트엔드의 세션 스토리지나 로컬 스토리지에 저장하는 경우는 드뭅니다(보안상 권장되지 않음).

📝 클라이언트가 요청 전송

사용자가 폼을 제출하거나 AJAX 요청을 보낼 때, 클라이언트는 CSRF 토큰을 요청에 포함시킵니다.
예: POST 요청의 바디에 _csrf 필드로 포함되거나, 헤더에 X-CSRF-Token으로 추가됨.

📝 서버에서 CSRF 토큰 검증

서버는 클라이언트로부터 받은 CSRF 토큰을 서버 세션에 저장된 토큰과 비교합니다.
토큰이 일치하면 요청이 유효한 것으로 간주하고 처리합니다.
토큰이 일치하지 않거나 없으면 요청을 거부(예: 403 Forbidden 응답).

📝 세션 유지 및 토큰 갱신

요청이 성공적으로 처리된 후, 서버는 필요에 따라 새로운 CSRF 토큰을 생성하여 세션에 저장하고 클라이언트에 전달합니다. 이는 보안을 강화하기 위해 토큰을 일회성 또는 주기적으로 갱신하는 방식입니다.

📝 예시

<form method="POST" action="/update-profile">
  <span class="point"><input type="hidden" name="_csrf" value="abc123xyz789"></span>
  <input type="text" name="username">
  <button type="submit">저장</button>
</form>

📝 예제: JavaScript (Fetch API)

<!DOCTYPE html>
<html>
<head>
    <title>CSRF AJAX Example</title>
    <!-- CSRF 토큰을 메타 태그로 포함 -->
    <meta name="csrf-token" content="3f9a8b2c-7e5d-4a1b-9c0f-1234567890ab">
</head>
<body>
    <button onclick="submitData()">Submit via AJAX</button>

    <script>
        function submitData() {
            // 메타 태그에서 CSRF 토큰 가져오기
            const csrfToken = document.querySelector('meta[name="csrf-token"]').getAttribute('content');

            fetch('/submit', {
                method: 'POST',
                headers: {
                    'Content-Type': 'application/json',
                    'X-CSRF-Token': csrfToken // CSRF 토큰을 헤더에 추가
                },
                body: JSON.stringify({ username: 'john' })
            })
            .then(response => response.text())
            .then(data => console.log(data))
            .catch(error => console.error('Error:', error));
        }
    </script>
</body>
</html>

는 서버에서 생성한 CSRF 토큰을 프론트엔드에 전달하는 일반적인 방법입니다. JavaScript에서 fetch를 사용하여 POST 요청을 보낼 때, X-CSRF-Token 헤더에 토큰을 추가합니다.

POST /submit HTTP/1.1
Host: example.com
Content-Type: application/json
X-CSRF-Token: 3f9a8b2c-7e5d-4a1b-9c0f-1234567890ab

📝 HTTP 요청 헤더

POST /submit HTTP/1.1
Host: example.com
Content-Type: application/json
X-CSRF-Token: 3f9a8b2c-7e5d-4a1b-9c0f-1234567890ab

📝 요청 바디

{"username":"john"}

서버는 _csrf 값이 세션의 토큰과 일치하는지 확인 후 요청을 처리합니다.

CSRF 토큰의 중요성

공격 방어: 공격자가 사용자의 인증 쿠키를 악용해 위조 요청을 보내더라도, CSRF 토큰이 없으면 서버가 요청을 거부합니다.
간단한 구현: 대부분의 웹 프레임워크(예: Spring, Django, Laravel)는 CSRF 토큰 생성 및 검증 기능을 기본 제공합니다.

📝 추가 고려사항

보안: 토큰이 노출되지 않도록 HTTPS를 사용하고, GET 요청에 포함시키지 않습니다.
사용성: AJAX 요청에서는 헤더로 토큰을 전송하는 방식이 일반적입니다.
SameSite 쿠키와 조합: CSRF 토큰 외에 SameSite 속성을 쿠키에 설정하면 추가적인 보호를 제공합니다.

쿠키 속성 설정(SameSite)

쿠키에 SameSite 속성을 설정하여 동일 출처(Same-Origin) 또는 제한된 조건에서만 쿠키가 전송되도록 합니다.

Strict: 동일 도메인에서만 쿠키 전송 가능.
Lax: 동일 도메인 외의 GET 요청(예: 링크 이동)에서만 쿠키 전송 가능.
None: 모든 요청에서 쿠키 전송(단, HTTPS와 Secure 속성 필수)

SameSite=Lax 는 대부분의 CSRF 방어에 적합하며, 사용자 경험을 해치지 않으면서 보안을 강화합니다. SameSite=Strict는 더 강력하지만, 외부 링크를 통한 접근 시 쿠키가 전송되지 않아 기능적 제약이 있을 수 있습니다.

HTTP 메서드 제한: 상태 변경 요청(예: 돈 이체, 계정 수정)은 POST, PUT, DELETE와 같은 메서드만 허용하고, GET 요청은 상태 변경을 유발하지 않도록 설계합니다.
Referer/Origin 헤더 검증: 요청의 출처를 확인하여 신뢰할 수 있는 도메인에서만 요청을 허용합니다. 단, Referer 헤더는 브라우저 설정에 따라 누락될 수 있으므로 보조적 수단으로 사용합니다.

XSS 공격 이란

XSS 공격은 악성 스크립트를 웹 페이지에 삽입하여 사용자의 브라우저에서 실행되도록 만드는 공격입니다. 이를 방어하기 위한 방법은 다음과 같습니다.

📝 입력 값 유효성 검증 및 특수문자 이스케이프

사용자로부터 입력받은 데이터(예: 텍스트, URL, JSON 등)의 유효성을 검증하고, HTML, JavaScript, SQL 등에서 실행 가능한 특수문자( <, >, ", ', & 등)를 이스케이프 처리합니다.

사용자가 입력한 데이터(예: 텍스트 필드, 쿼리 파라미터)를 서버 또는 클라이언트에서 받으면 입력 데이터에 포함된 특수 문자를 안전한 문자(예: <)로 변환하여 변환된 데이터를 HTML, JavaScript 등의 문맥에서 출력하여 브라우저가 이를 코드가 아닌 텍스트로 처리하도록 함.

<!-- 입력: <script>alert('XSS')</script> --> 
<!-- 이스케이프 처리 후 출력 -->
&lt;script&gt;alert(&#39;XSS&#39;)&lt;script&gt;

브라우저는 위를 로 표시하며, 실행하지 않음.

클라이언트와 서버 모두에서 입력 검증을 수행해야 하며 서버에서는 데이터베이스 저장 전, 클라이언트에서는 사용자 경험을 위해 검증합니다. 예를 들어,

📝 CSP(Content Security Policy) 설정

서버에서 HTTP 응답 헤더에 CSP를 설정하여 허용된 스크립트, 스타일, 이미지 등의 출처를 제한합니다.

Content-Security-Policy: script-src 'self' https://trusted.cdn.com;

CSP는 인라인 스크립트()나 외부 출처의 악성 스크립트 실행을 차단합니다. 'strict-dynamic', 'nonce', 'hash'와 같은 옵션을 사용하면 더 세밀한 제어가 가능합니다. 그러나 CSP 설정은 신중히 설계해야 하며, 기존 코드와의 호환성 문제를 테스트해야 합니다.

출력 이스케이프: 데이터를 렌더링할 때 문맥(HTML, 속성, JavaScript, CSS, URL 등)에 맞게 이스케이프 처리합니다. 예: HTML 속성에는 더블쿼테이션(")를 "로 변환.
안전한 API 사용: innerHTML 대신 textContent나 setAttribute를 사용해 스크립트 실행을 방지합니다.
쿠키 보호: HttpOnly 속성을 쿠키에 설정하여 JavaScript에서 쿠키에 접근하지 못하도록 제한합니다.
프레임워크 보안: React, Angular 등 현대 프레임워크는 기본적으로 XSS 방어를 제공하지만, dangerouslySetInnerHTML 같은 기능을 사용할 때는 주의가 필요합니다.

📝 HTTPS를 통한 통신 보안

HTTP는 데이터가 평문으로 전송되어 도청 및 조작에 취약합니다. HTTPS는 SSL/TLS를 통해 통신을 암호화하여 보안을 강화합니다.

📝 HTTPS 적용

HSTS는 웹 브라우저에게 해당 사이트는 항상 HTTPS로만 접속해야 한다고 지시하는 보안 기능입니다. 한 번 브라우저가 이 헤더를 받으면, 이후엔 자동으로 HTTP 요청을 HTTPS로 업그레이드합니다.

📝 HSTS 헤더 예시

서버에서 다음과 같은 헤더를 응답에 추가합니다.

Strict-Transport-Security: max-age=31536000; includeSubDomains

HTTPS는 데이터 무결성과 기밀성을 보장하며, CSRF와 XSS 공격에서 쿠키나 토큰이 탈취되는 것을 방지합니다. HSTS는 중간자 공격(MITM)을 줄이는 데 효과적입니다. 또한, 최신 TLS 버전(예: TLS 1.3)과 강력한 암호화 알고리즘을 사용하는 것이 중요합니다.

📝 추가 보안 고려사항

인증서 관리: 신뢰할 수 있는 인증 기관(CA)에서 발급받은 SSL/TLS 인증서를 사용하고, 만료 전에 갱신합니다.
혼합 콘텐츠 방지: HTTPS 페이지에서 HTTP 리소스(이미지, 스크립트 등)를 로드하지 않도록 주의합니다. 브라우저는 혼합 콘텐츠를 차단하거나 경고를 표시할 수 있습니다.

종합적인 보안 전략

CSRF와 XSS 방어는 단일 기법에 의존하지 않고, 여러 방어 계층을 조합하여 적용하는 심층 방어(Defense-in-Depth) 전략이 필요합니다.

개발 단계: 코드 리뷰, 보안 라이브러리 사용, OWASP 가이드라인 준수.
배포 단계: 보안 헤더 설정(CSP, HSTS, X-Frame-Options 등), 취약점 스캔.
운영 단계: 로그 모니터링, WAF(Web Application Firewall) 도입, 정기적인 보안 패치.