Daily Dev Q&A: XSS와 CSRF

Topic (오늘의 주제)

XSS(Cross-Site Scripting)와 CSRF(Cross-Site Request Forgery)의 차이 및 방어 메커니즘

웹 서비스에서 사용자의 권한과 데이터를 탈취하는 가장 대표적인 두 공격의 원리를 이해하고, 클라이언트와 서버 양측에서 이를 원천 차단하는 방법을 학습합니다.

---

Why (왜 사용하는가? 왜 중요한가?)

• 실무: 이 방어 로직이 뚫리면 관리자 계정이 해킹되어 사이트 전체에 악성 스크립트가 유포되거나(XSS), 사용자가 인지하지 못한 채 비밀번호가 변경되고 무단 결제가 발생하는(CSRF) 치명적인 보안 사고와 서비스 장애로 이어집니다.
• 구조적 의미: 프론트엔드와 백엔드 간의 신뢰 경계를 명확히 하고, 입력값 검증(Sanitization)과 안전한 인증 헤더/쿠키 관리를 통해 시스템의 견고성(Robustness)을 높입니다.
• 면접 의도: 지원자가 웹 보안의 기본 동작 원리를 아는지, 단순히 보안 프레임워크에 의존하는 것을 넘어 각 계층에서 어떤 책임을 져야 하는지(예: 쿠키의 HttpOnly 속성, XSS 필터링)를 정확히 이해하고 있는지 확인하려 합니다.

---

Core Concept (핵심 개념 정리)

요소	XSS (크로스 사이트 스크립팅)	CSRF (사이트 간 요청 위조)
개념 정의	공격자가 웹 사이트에 악성 스크립트를 삽입하여, 다른 사용자의 브라우저에서 실행되게 만드는 공격입니다.	사용자가 자신의 의지와 무관하게, 공격자가 의도한 행위(수정/삭제/결제 등)를 서버에 요청하게 만드는 공격입니다.
동작 방식	게시판 등에 <script> 태그 삽입 ➔ 다른 사용자가 게시물 열람 ➔ 브라우저에서 스크립트 자동 실행 ➔ 쿠키/세션 탈취	로그인된 사용자에게 악성 링크 클릭 유도 ➔ 브라우저가 사용자 인증 쿠키를 포함해 변조된 요청 자동 전송 ➔ 서버는 정상 요청으로 오인하여 처리
핵심 목적	사용자의 정보(세션, 토큰 등) 탈취	인증된 사용자의 권한 도용
방어 조건 (해결책)	1. 입력/출력값 치환: HTML Entity 인코딩 (< 를 &lt; 로 치환) 2. HttpOnly 쿠키: 자바스크립트에서 document.cookie로 접근할 수 없도록 차단	1. CSRF Token: 상태를 변경하는 요청 시 서버가 발급한 임의의 난수 토큰 검증 2. SameSite 쿠키: 타 도메인에서 쿠키가 전송되는 것을 제한
예시/비교	스크립트를 통해 탈취한 인증 정보로 공격자가 직접 행동함.	공격자는 인증 정보 자체는 모르지만, 브라우저의 특성을 이용해 요청만 위조함.

 

---

Interview Answer Version (면접 답변식 요약)

"XSS는 악성 스크립트를 주입해 브라우저에서 실행되게 하여 사용자의 정보를 탈취하는 공격이고, CSRF는 인증된 사용자의 브라우저가 가진 권한을 도용해 위조된 요청을 보내는 공격입니다.

XSS를 방어하기 위해서는 서버와 클라이언트 양측에서 입력값을 필터링 및 이스케이프 처리해야 하며, 쿠키에 HttpOnly 옵션을 적용해 스크립트 접근을 막아야 합니다.

CSRF를 방어하기 위해서는 POST, PUT, DELETE 같은 상태 변경 요청에 대해 CSRF 토큰을 발급하여 검증하거나 쿠키의 SameSite 속성을 활용합니다. 최근 REST API 서버에서는 브라우저가 자동으로 첨부하는 쿠키 대신, Authorization 헤더에 JWT를 담아 보내는 방식을 사용하여 CSRF 위협을 근본적으로 줄이고 있습니다."

---

Practical Tip (사용시 주의할 점 or 활용 예)

• 실무 활용 예 (프레임워크 적용):
  • React (XSS 방어): 기본적으로 JSX는 렌더링 시 데이터 바인딩 과정에서 문자열을 이스케이프 처리하여 XSS를 막아줍니다. 하지만 에디터 기능 등을 위해 dangerouslySetInnerHTML 속성을 사용할 때는 이스케이프가 무력화되므로, 반드시 DOMPurify 같은 라이브러리로 코드를 정제(Sanitize)한 후 렌더링해야 합니다.
  • Spring Boot (CSRF 방어): Spring Security를 적용하면 기본적으로 CSRF 방어가 켜져 있어 토큰이 없는 POST 요청은 403 에러가 납니다. 하지만 세션(Session) 인증이 아닌, RESTful 기반의 JWT 토큰 인증을 구현할 때는 브라우저의 쿠키 자동 전송 메커니즘을 타지 않으므로 http.csrf(AbstractHttpConfigurer::disable) 설정을 통해 무력화하는 것이 일반적입니다.
• 설정 시 반드시 고려해야 할 보안 속성:
  • 인증과 관련된 쿠키(Session ID, Refresh Token 등)를 구울 때는 HttpOnly=true(XSS 방어), Secure=true(HTTPS 통신만 허용), SameSite=Lax 또는 Strict(CSRF 방어) 파라미터를 반드시 함께 설정해야 합니다.
• "이걸 모르고 사용하면 생기는 문제" (CORS와 CSRF의 혼동):
  • 종종 CORS(교차 출처 리소스 공유) 설정을 빡빡하게 하면 CSRF도 막아줄 것이라고 오해하는 경우가 많습니다. CORS는 '응답(Response)'을 브라우저가 읽지 못하게 막는 정책일 뿐, CSRF처럼 브라우저가 서버로 '요청(Request)'을 보내고 서버가 이를 실행해 버리는 것 자체를 막아주지는 못합니다. 별도의 CSRF 대책이 반드시 필요합니다.

---

예상 꼬리질문 정리

1. React에서는 기본적으로 XSS를 어떻게 방어하나요? 프론트엔드 개발자로서 예외적으로 취약해지는 상황(예: 게시판 에디터)에서 어떻게 대응하시겠습니까?
   • (의도: JSX의 이스케이프 특징과 DOMPurify 등을 활용한 실무적인 방어 경험 확인)
2. Spring Security에서 JWT를 사용할 때 CSRF 설정을 disable 하는 이유는 무엇인가요? JWT 자체는 탈취 위험이 없나요?
   • (의도: 세션 인증과 토큰 인증 구조의 차이를 알고, Authorization 헤더의 동작 방식을 이해하는지 확인)
3. CORS(Cross-Origin Resource Sharing) 에러가 무엇인지 설명해 주시고, 이것이 방금 말씀하신 CSRF 공격을 막아줄 수 있는지 설명해 주세요.
   • (의도: 동일 출처 정책(SOP)과 CORS의 목적을 이해하고, 보안 취약점 대책과 혼동하지 않는지 확인)