15강 / 20강

XSS — 남의 브라우저에서 내 코드를 돌린다

저장된 스크립트가 다른 손님을 노린다

14강의 인젝션이 서버의 DB를 노렸다면, XSS(Cross-Site Scripting)는 다른 손님의 브라우저를 노립니다. 후기·댓글·닉네임처럼 남에게 보이는 곳에 공격자가 스크립트를 심어 두면, 그 페이지를 여는 다른 손님의 브라우저에서 그 코드가 실행돼요.

뿌리는 같습니다(13강) — 손님이 넣은 데이터가 코드로 해석된 것.

고등학생남의 브라우저에서 내 코드를 돌린다

14강이 서버의 DB 를 노렸다면 XSS 는 다릅니다.

피해자는 다른 이용자다 — 서버가 아니다

어떻게 일어나나

단계	—
1	공격자가 스크립트를 입력한다
2	서버가 그대로 저장·출력한다 ⚠
3	다른 이용자가 그 페이지를 연다
4	그 사람의 브라우저에서 실행된다

서버는 전달자일 뿐이다 — 피해는 이용자에게

세 가지 유형

유형	—	위험
저장형	DB 에 남아 모두에게	가장 크다 ⚠
반사형	링크를 클릭하게 유도	중간
DOM 기반	브라우저 안에서만	서버 로그에 안 남는다 ⚠

저장형이 가장 무섭다 — 가만있어도 퍼진다

비유 — 공용 게시판에 붙인 쪽지

—	—
누가 이상한 지시를 써 붙였다	—
읽는 사람마다	그대로 따른다 ⚠

게시판(서버)은 멀쩡한데 읽는 사람이 당한다

고등학생왜 브라우저가 실행하나

브라우저가 속는 이유를 봅시다.

브라우저는 같은 출처에서 온 스크립트를 신뢰한다

동일 출처 정책

—	—
a.com 의 스크립트는	a.com 의 자료에 접근 ✔
b.com 의 스크립트는	a.com 에 접근 못 한다 ✔

이 격리가 웹 보안의 기둥이다

XSS 가 무너뜨리는 것

—	—
공격자 코드가 a.com 페이지 안에 있다	—
브라우저가 보기에	a.com 의 코드다 ⚠

격리를 우회한 게 아니라 — 안쪽에 들어간 것이다

그래서 할 수 있는 일

—	—
쿠키 읽기	세션 탈취 ⭐
화면 조작	가짜 로그인 폼
대신 요청	비밀번호 변경 등 ⚠
키 입력 기록	—

그 사이트에서 사용자가 할 수 있는 모든 것을 할 수 있다

비유 — 신분증을 가진 사람

—	—
담을 넘은 게 아니라	정문으로 들어왔다
안에서는	구별이 안 된다 ⚠

후기에 태그를 심어 봅시다

상품 후기창에 <b>강조</b> 를 써 봅니다. 앱이 이걸 그대로 페이지에 넣으면, 브라우저는 이게 후기인지 개발자 코드인지 구분하지 못하고 글자를 굵게 만들어요. 태그가 먹혔다면, <script> 도 먹힌다는 뜻입니다.

실습실에서 이스케이프를 끈 상태로 시도해 보세요.

글자가 굵어짐 → 태그가 먹힘

코드가 실행됨

세션 탈취 😱

고등학생왜 쿠키 탈취가 무서운가

note 의 이 경고를 17강과 이어 봅시다.

세션 쿠키는 비밀번호와 같다 — 그것만 있으면 로그인된다

왜 그런가

—	—
로그인하면 서버가 쿠키를 준다	—
이후 요청마다	그 쿠키로 "나야" 를 증명 ⭐

쿠키를 가진 사람이 곧 그 사용자다

그래서 대책 — HttpOnly

플래그	효과
HttpOnly	자바스크립트가 못 읽는다 ✔ ⭐
Secure	HTTPS 로만 전송 (8강)
SameSite	CSRF 방어 (17강)

HttpOnly 하나로 쿠키 탈취는 막힌다 — 반드시 켠다

⚠ 그래도 XSS 는 위험합니다

쿠키를 못 훔쳐도	—
대신 요청을 보낼 수 있다	쿠키는 자동으로 붙는다 ⚠
화면을 바꿔 속인다	—

HttpOnly 는 피해를 줄일 뿐 — XSS 자체를 막아야 한다

근본 대책

조치	—
출력 이스케이프	13강 · `/db` 15강 ⭐
CSP	어느 스크립트를 실행할지 제한 ⭐
템플릿 자동 이스케이프	기본으로 켜 둔다

CSP 는 강력하다 — 인라인 스크립트를 아예 금지할 수 있다

근본 방어 — 출력할 때 이스케이프

핵심은 들어올 때가 아니라 나갈 때(화면에 그릴 때) 막는 것입니다. 같은 데이터도 HTML·JS·URL 중 어디에 놓이느냐에 따라 위험한 글자가 다르거든요.

출력 이스케이프는 < 를 < 로 바꿉니다. 그러면 브라우저는 그걸 '꺾쇠라는 글자'로 그릴 뿐, 태그로 읽지 않아요. 요즘 템플릿 엔진(우리 사이트의 Jinja 포함)은 기본으로 이스케이프합니다 — 개발자가 일부러 끄지만 않으면 됩니다.

이스케이프가 무엇을 하는지 눈으로 봅니다.

Python 브라우저 안에서 실행 (계산용)

import html
dangerous = "<script>steal(document.cookie)</script>"
print("이스케이프 전:", dangerous)
print("이스케이프 후:", html.escape(dangerous))
print()
print("브라우저는 '이스케이프 후' 를 글자로만 그립니다 — 코드로 실행하지 않아요.")

고등학생이스케이프에서 자주 하는 실수

15강을 마치며 실무 함정을 봅시다.

맥락이 다르면 이스케이프 방법도 다르다 — 13강

실수 ① 속성 안에서

<div title="{{ 값 }}">

—	—
값에 따옴표가 있으면	속성을 탈출한다 ⚠

속성값은 반드시 따옴표로 감싸고 따옴표도 이스케이프한다

실수 ② 자바스크립트 안에서

<script>var x = "{{ 값 }}";</script>

—	—
HTML 이스케이프로는	부족하다 ⚠
대신	JSON 직렬화로 넣는다 ✔

스크립트 안에 사용자 값을 직접 쓰지 않는 것이 최선이다

실수 ③ |safe 남용

—	—
화면이 깨져 보여서	`\|safe` 를 붙인다 ⚠
그 순간	보호가 사라진다

|safe 는 내가 만든 HTML 에만 — 사용자 입력엔 절대

실수 ④ URL 맥락

<a href="{{ 링크 }}">

—	—
`javascript:` 로 시작하면	실행된다 ⚠

URL 은 스킴을 화이트리스트로 검사한다 — http · https 만

사용자 HTML 을 허용해야 한다면

—	—
직접 필터링	하지 않는다 ⚠
검증된 새니타이저	DOMPurify 등 ✔

4강·5강과 같은 조언 — 직접 만들지 않는다

🤔 확인 문제

XSS 공격이 주로 노리는 것은?

🤔 확인 문제

XSS 를 막는 근본 방어는?

해설 핵심은 출력 이스케이프입니다. 화면에 그릴 때 < 를 글자로 바꾸면 브라우저가 코드로 실행하지 않아요. 입력 필터링은 우회가 많아 근본책이 못 됩니다.