XSS: 브라우저가 데이터를 코드로 해석할 때

01개념과 구성 요소

• 성립 원리신뢰하지 않는 값이 HTML·자바스크립트의 실행 문맥으로 해석되어 페이지 권한으로 동작하는 문제다.
• 추적 대상입력이 들어오는 Source, 디코딩·정화 과정, DOM이나 코드 실행 Sink를 연결한다.
• 방어 구성텍스트 API·문맥별 출력 처리·HTML 정화·CSP는 서로 다른 경계를 보호한다.

02게시물 문자열이 브라우저 출력이 되는 순서

1. 값 획득서버나 브라우저가 요청·저장 게시물·URL·API 응답 등에서 값을 읽는다.
2. 출력 문맥 선택값을 HTML 텍스트·속성·URL·스크립트 중 어디에 넣는지 결정한다. 문맥에 따라 필요한 처리가 달라진다.
3. 안전한 자료 삽입단순 표시는 textContent로 넣고, 허용된 HTML이 필요하면 정화된 구조를 사용한다.
4. 브라우저 해석innerHTML 같은 HTML Sink는 문자열을 요소 구조로 파싱한다. 실행 가능 여부는 실제 태그·속성·문맥과 정책에 달려 있다.
5. 경로 검증응답 원문·최종 DOM·실행 위치를 비교한다. 저장형은 저장 뒤 다른 조회에서도 같은 경로가 이어지는지 확인한다.

03XSS는 브라우저가 데이터를 코드 문맥으로 해석하는 문제다

• 실행 위치XSS에서 주입된 코드가 실행되는 곳은 일반적으로 사용자의 브라우저다. 서버가 위험한 HTML을 만들어 보내거나 클라이언트 자바스크립트가 외부 값을 위험한 DOM 위치에 넣으면, 브라우저는 그 내용을 현재 페이지의 출처 권한으로 처리할 수 있다.
• 입력 출처입력창이 반드시 필요한 것은 아니며 URL·게시물·헤더·파일명·외부 API 결과·관리 로그 화면도 값의 출처가 된다.
• 파서 문맥핵심은 신뢰할 수 없는 값이 최종적으로 어떤 파서와 실행 문맥에 들어가는가다. HTTPS는 전송 중 바이트를 보호하지만 이미 페이지에 포함된 코드가 브라우저에서 수행되는 이 경계를 대신 검사하지 않는다.
• 클라이언트 비밀브라우저에서 실행되는 자바스크립트는 사용자에게 도착한 뒤 개발자 도구로 읽을 수 있으므로 서버용 비밀을 숨겨 두는 저장소가 될 수도 없다.

04Reflected·Stored·DOM-based의 서로 다른 경로

• 반사·저장Reflected XSS는 요청값이 즉시 응답 HTML 등에 반영되어 실행되는 형태다. Stored XSS는 값이 DB나 파일에 저장된 뒤 다른 사용자가 조회할 때 실행된다.
• DOM 분류 축DOM-based XSS는 브라우저 자바스크립트가 Source에서 값을 읽어 위험한 Sink로 전달하는 흐름에 초점을 둔다. 저장·반사 여부와 클라이언트 처리 경계는 분류 축이 달라 실제 사례에서 단순 배타적 세 상자로만 나뉘지 않을 수 있다.
• 조회 사용자저장형에서는 처음 입력한 사람과 나중에 위험한 페이지를 읽는 사람이 다를 수 있다. 또한 공개 게시판만이 아니라 운영자가 여는 로그·댓글 관리 화면도 실행 지점이 될 수 있다.
• 클라이언트 제한클라이언트 maxlength를 바꾸었더니 더 긴 값이 저장되었다는 관찰은 브라우저 제한과 서버 검증이 별개라는 사실을 보여 준다.

05Source와 Sink를 코드에서 찾기

• SourceSource에는 location.search, location.hash, document.referrer, window.name, localStorage, postMessage 데이터처럼 외부 영향을 받을 수 있는 값이 있다.
• SinkSink에는 innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, 문자열을 실행하는 일부 API 등이 있다. 동일한 이름의 값이라도 중간의 디코딩·결합·정화 과정을 따라가야 실제 실행 가능성을 판단할 수 있다.
• URL fragmentURL fragment는 일반적으로 HTTP 요청에 포함되지 않지만 브라우저의 location.hash로 읽을 수 있다. 그래서 서버 로그나 응답 원문에 시험 문자열이 없어도 DOM 경로에서 문제가 생길 수 있다.
• DOM 구조DOM은 외부 객체가 아니라 브라우저가 문서를 해석해 만든 구조이며 자바스크립트가 이 구조를 바꾸는 것이다.

06innerHTML과 textContent의 차이를 눈으로 읽기

• HTML과 텍스트아래 예제에서 같은 <b>학습 표식</b> 값을 innerHTML에 넣으면 HTML 요소로 해석되지만 textContent에 넣으면 꺾쇠를 포함한 텍스트로 표시된다. 이 차이를 이해한 뒤 실행 가능한 문맥을 분석해야 한다.
• Script 실행 조건innerHTML에 넣은 모든 script 태그가 모든 조건에서 즉시 실행된다고 단순화할 수는 없지만 외부 문자열을 HTML로 해석시키는 위험 경계라는 점은 남는다.
• 텍스트 삽입단순 표시 기능이면 문자열을 HTML로 만들 필요가 없다. 요소를 만들고 textContent로 값을 넣으면 데이터가 HTML 구문으로 바뀌는 단계를 제거할 수 있다.
• innerText 차이innerText도 텍스트 성격이지만 렌더링·CSS와의 관계가 달라 textContent와 완전히 같은 API는 아니다.

const value = "<b>학습 표식</b>";
preview.innerHTML = value;     // b 요소로 해석
safePreview.textContent = value; // 꺾쇠를 포함한 문자 그대로

const item = document.createElement("li");
item.textContent = userSuppliedLabel;
list.appendChild(item);

네트워크 요청이나 정보 유출 없이 HTML 파싱과 텍스트 삽입의 차이를 보여 주는 비교 코드다.

07무해한 표식으로 실행과 저장 시점을 분리하기

• 무해한 실행 표식격리된 학습 페이지에서 <script>alert("training-marker")</script> 같은 무해한 표식은 서버가 만든 응답이 스크립트 문맥으로 실행되는지 확인하는 데 쓰일 수 있다. 표식의 목적은 알림 한 번이 아니라 입력→저장 또는 반사→브라우저 실행의 경로를 확인하는 것이다.
• 관찰 목적실제 쿠키·문서 내용을 외부 수신점으로 보내지 않아도 이 원리를 설명할 수 있다.
• 반사·저장 비교반사형에서는 해당 요청의 응답에서 입력 위치와 주변 태그를 본다. 저장형에서는 새로고침과 다른 가상 사용자 세션에서 같은 내용이 다시 출력되는지 본다.
• DOM과 재디코딩DOM형에서는 응답 원문과 최종 DOM, 실행된 자바스크립트의 Source·Sink 위치를 비교한다. 서버에서 인코딩했던 값을 클라이언트가 다시 디코딩하여 innerHTML에 넣으면 안전성이 다시 깨질 수 있다.

<script>alert("training-marker")</script>

관찰할 연결:
입력값 → 응답의 삽입 위치 → 파싱된 DOM → 실행 시점
저장형이라면: DB 저장 → 다른 조회 요청 → 같은 위치의 출력

수업의 실행 확인 예를 무해한 고정 문자열로 제한했다. 실제 세션이나 외부 전송 코드는 없다.

08출력 인코딩은 문맥에 맞아야 한다

• 출력 문맥HTML 텍스트에 들어갈 값, 따옴표로 둘러싼 속성값, URL, 자바스크립트 문자열은 같은 파서 규칙을 쓰지 않는다. HTML 특수문자 처리만 적용한 값을 script 내부에 삽입하거나 URL 검증 없이 링크 주소에 쓰면 기대와 다른 해석이 생길 수 있다.
• 공통 치환의 한계모든 곳에 한 번의 문자열 치환을 적용하는 방식보다 위험한 문맥 자체를 줄이는 것이 중요하다.
• 자동 이스케이프템플릿 엔진의 자동 이스케이프도 어떤 출력 문맥을 보호하는지 범위가 있다. 개발자가 safe 처리나 raw HTML 기능으로 우회하면 기본 보호가 사라질 수 있다.
• 반복 변환인코딩한 값을 다시 인코딩해서 화면이 깨지는 문제와 디코딩을 반복해서 위험 구문이 살아나는 문제도 있으므로 데이터가 어느 형식으로 저장되고 어느 단계에서 변환되는지 명확해야 한다.

12HTML이 필요한 기능은 정화 규칙이 필요하다

• 허용 HTML서식 있는 게시물을 허용해야 한다면 모든 태그를 일반 텍스트로 바꾸는 것과 허용된 HTML을 정화하는 것은 다른 기능이다. 정화기는 허용할 요소·속성·URL 스킴 등을 구조적으로 해석하고 위험한 구성을 제거한다.
• 정화기의 역할정규식으로 script라는 단어 하나를 지우는 방식은 브라우저가 가진 다양한 파싱 문맥을 대체하지 못한다.
• 변환 후 안전성정화 뒤 문자열을 다시 결합하거나 다른 파서 문맥으로 이동하면 앞선 보장이 달라질 수 있다. 그래서 저장 시 검증뿐 아니라 최종 출력 경계의 처리 방식이 중요하다.
• 기존 저장 자료기존 저장 자료에 위험한 값이 남아 있다면 코드 수정 후에도 조회 경로가 이를 안전하게 처리해야 하며, 새 글 입력만 차단했다고 저장형 위험이 모두 사라진 것은 아니다.

13CSP와 쿠키 속성은 피해 경로를 제한한다

• CSPCSP는 브라우저가 어떤 스크립트와 자원을 실행·불러올 수 있는지 제한한다. nonce나 해시를 사용하는 스크립트 정책은 허용된 코드와 주입된 코드를 구분하는 데 쓰일 수 있다.
• 실제 차단 모드단, 보고 전용 정책과 실제 차단 정책은 결과가 다르며 CSP가 안전한 출력 처리를 대신하지 않는다. 허용된 외부 스크립트 자체가 변조되는 공급망 문제도 별도로 남는다.
• 쿠키 속성HttpOnly는 일반적인 자바스크립트 쿠키 읽기를 제한하지만 XSS 코드가 같은 출처에서 사용자의 권한으로 요청을 만드는 경로까지 없애지 않는다. Secure는 전송 조건을, SameSite는 교차 사이트 쿠키 전송을 다룬다.
• 다층 통제각 속성이 보호하는 지점이 달라 한 속성이 켜져 있다는 이유로 XSS가 성립하지 않는다고 판단하지 않는다.

14iframe 표시와 DOM 접근은 다른 정책이다

• 동일 출처 정책다른 출처 iframe이 화면에 보인다고 부모 페이지가 그 내부 DOM과 입력값을 자유롭게 읽는 것은 아니다. Same-Origin Policy는 스킴·호스트·포트로 구분한 출처 사이의 접근을 제한한다.
• Mixed ContentHTTPS 페이지에서 HTTP iframe을 불러오는 Mixed Content 문제는 전송 보안의 문제이며, 모두 HTTPS라고 DOM 접근 제한이 사라지는 것도 아니다.
• 프레임 포함 정책X-Frame-Options와 CSP frame-ancestors는 누가 내 페이지를 프레임으로 포함할 수 있는지 제한해 클릭재킹 방어와 연결된다. 반대로 frame-src는 내가 어떤 프레임을 불러올 수 있는지를 제어한다.
• Sandboxiframe sandbox는 내부 기능 권한을 제한한다. 세 기술의 방향을 구분해야 “iframe을 막는다”는 막연한 설명을 실제 응답 헤더와 연결할 수 있다.

15외부 자바스크립트와 SRI의 신뢰 경계

• 외부 스크립트 권한CDN에서 내려받은 자바스크립트는 다른 서버에서 왔더라도 페이지가 포함하여 실행하면 그 페이지의 권한 문맥에서 동작할 수 있다. HTTPS는 다운로드 중 변조를 막는 경로를 제공하지만 신뢰한 배포 서버나 라이브러리의 잘못된 변경까지 자동으로 판별하지 않는다.
• SRISRI는 개발자가 지정한 해시와 내려받은 자원의 바이트를 비교하는 방식이다.
• 통제 역할 분리해시가 고정되어 있으면 파일이 바뀌었을 때 실행되지 않을 수 있으므로 버전 관리와 배포 동작을 함께 이해해야 한다. CSP의 출처 제한, SRI의 내용 무결성, 애플리케이션의 출력 인코딩은 각기 다른 통제다.
• 네트워크 방화벽 한계네트워크 방화벽은 브라우저 DOM의 출력 문맥을 안전하게 만드는 기능을 대신하지 않는다.