크로스사이트 스크립팅(XSS)

왜 배우는가: XSS는 웹 애플리케이션 취약점 중 가장 빈번하게 보고되는 유형이며, 사용자 세션 탈취와 페이지 변조로 이어져 실무 보안 점검의 기본 항목이다. 기술사 시험에서는 정의, 유형 구분, 시큐어 코딩 대응을 묻는 문제로 반복 출제된다. 이 절은 개념의 정의와 배경을 먼저 정리해 이후 유형과 대응 설명의 기초가 되도록 한다.

출제 이력: 제111회 1교시 10번, 제99회 2교시 6번

1. 한 줄 정의와 핵심 키워드

크로스사이트 스크립팅(XSS)은 공격자가 웹 페이지에 악성 스크립트를 삽입하여 다른 사용자의 브라우저에서 실행시키는 클라이언트 측 코드 삽입 공격이다.

핵심 키워드

• 크로스사이트 스크립팅(XSS): 악성 클라이언트 스크립트를 타 사용자 브라우저에서 실행시키는 공격
• 입력값 검증: 사용자 입력이 허용된 형식과 길이를 따르는지 확인하는 절차
• 출력 인코딩: 특수문자를 HTML 엔터티로 변환해 스크립트로 해석되지 않게 하는 처리
• 반사형 XSS: 요청 값이 응답 페이지에 즉시 되돌아와 실행되는 유형
• 저장형 XSS: 악성 스크립트가 서버 저장소에 남아 다수 사용자에게 실행되는 유형
• DOM 기반 XSS: 서버 응답이 아닌 클라이언트 DOM 조작으로 실행되는 유형
• 콘텐츠 보안 정책(CSP): 허용된 스크립트 출처만 실행하도록 브라우저에 지시하는 정책

2. 개념 풀이

XSS는 웹 사이트 자체가 아니라 그 사이트를 이용하는 사용자를 공격하는 방식이다. 쉽게 말해 게시판이나 검색창에 넣은 코드가 다른 사람의 화면에서 실행되는 것이다.

정식 정의는 다음과 같다. 신뢰할 수 없는 사용자 데이터가 적절한 검증이나 인코딩 없이 웹 페이지에 포함되면, 공격자의 스크립트가 피해자 브라우저에서 실행되어 세션 탈취, 웹 페이지 변조, 악성 사이트로의 리다이렉션 등을 수행하는 취약점이다. OWASP는 이 용어가 원래 사이트 간 데이터 탈취를 뜻했으나 이후 여러 형태의 데이터 주입 공격을 포함하게 되어 이름이 적절치 않다고 본다.

핵심 용어는 다음과 같다. 동일 출처 정책(Same-Origin Policy)은 서로 다른 출처의 스크립트가 서로의 자원에 접근하지 못하게 하는 브라우저 규칙이며, XSS는 이 정책을 우회하는 수단으로 쓰인다. 세션 쿠키는 로그인 상태를 나타내는 값으로, 탈취되면 공격자가 사용자로 가장할 수 있다.

XSS의 본질은 신뢰할 수 없는 입력이 HTML·스크립트 문맥으로 해석되는 것이다. 따라서 대응은 입력 단계의 검증과 출력 단계의 인코딩을 함께 적용하는 것이다.

3. 등장 배경과 필요성

웹 애플리케이션이 사용자 입력을 화면에 다시 보여 주는 기능(검색 결과, 댓글, 게시글)을 가지면서 XSS가 생겼다. 브라우저는 서버가 보낸 문자열을 신뢰하고 실행하므로, 서버가 입력을 구분하지 못하면 공격 코드가 그대로 실행된다.

2000년대 중반부터 OWASP Top Ten에 XSS가 상위 항목으로 올랐다. 2004년판에서는 A4, 2007년판에서는 A1, 2010년판에서는 A2로 계속 높은 순위를 차지했다. 이는 XSS가 오랫동안 가장 흔한 웹 취약점 중 하나였음을 보여 준다.

국내에서는 행정안전부가 시큐어 코딩 기준을 제시했다. 「행정기관 및 공공기관 정보시스템 구축·운영 지침」(행정안전부고시 제2021-3호, 2021.1.19.)에 따라 소프트웨어 보안 약점 항목이 정리되어 있다. 이 기준은 개발 단계에서 입력 데이터 검증 및 표현 항목으로 XSS 대응을 요구한다.

XSS가 중요한 이유는 피해가 이용자에게 직접 돌아가기 때문이다. 공격자는 서버를 침투하지 않아도 피해자의 권한으로 행위를 수행할 수 있다. 따라서 개발자가 코드 단계에서 차단하는 것이 가장 효과적이다.

4. 구성요소·원리·절차

XSS 공격은 공격 페이로드, 취약 지점, 전달 경로, 피해자 브라우저의 네 요소로 이루어진다. 원리는 신뢰할 수 없는 입력이 검증과 출력 인코딩 없이 HTML 응답에 들어가고, 브라우저가 그 데이터를 코드로 해석하는 데 있다. XSS의 근본 원인은 입력 데이터가 출력 문맥에서 코드로 해석되는 것이다. 브라우저는 같은 출처(origin)에서 온 스크립트를 신뢰하므로, 공격 스크립트는 동일 출처 정책을 우회해 쿠키와 세션 정보에 접근할 수 있다.

위 표에서 취약 지점과 전달 경로가 XSS 유형을 가른다. 반사형은 요청에 실린 입력이 응답에 되돌아와 즉시 실행된다. 저장형은 입력이 서버에 저장되어 그 페이지를 여는 모든 사용자에게 전달된다. DOM 기반은 서버 응답을 거치지 않고, 클라이언트 스크립트가 URL 같은 값을 DOM에 넣는 과정에서 실행된다. 따라서 서버 측 필터만으로는 DOM 기반 XSS를 막기 어렵다.

공격 절차는 다음 순서로 진행된다.

• 공격자가 악성 입력, 즉 페이로드를 준비한다.
• 입력이 URL, 폼, 저장소를 거쳐 서버에 들어간다.
• 서버가 검증 없이 입력을 응답 HTML에 포함한다.
• 브라우저가 응답을 해석하면서 스크립트를 실행한다.
• 스크립트가 쿠키를 외부로 보내거나 페이지를 변조한다.

방어의 핵심은 출력 시점에 특수문자를 HTML 엔터티로 바꾸는 출력 인코딩이다. 예를 들어 < 를 &lt; 로 바꾸면 브라우저는 태그가 아닌 문자로 표시한다. 입력 검증은 허용 문자와 최대 길이를 정하는 보조 수단이며, 출력 인코딩을 대신하지 못한다. 이 구분은 답안에서 자주 틀리는 부분이다.

추가 방어는 CSP(Content Security Policy) 헤더와 HttpOnly 쿠키 속성이다. CSP는 스크립트를 실행할 수 있는 출처를 제한해 인라인 스크립트의 실행을 막는다. HttpOnly 속성은 자바스크립트에서 쿠키에 접근하지 못하게 하여 쿠키 탈취 피해를 줄인다. 두 장치는 인코딩을 대체하지 않고 피해 범위를 줄이는 다층 방어 수단이다.

5. 관련 법령·기준·표준

국내 공공 분야의 시큐어 코딩은 행정안전부 고시로 관리된다.

위 표의 첫 두 행은 법적 의무를 정하는 기준이다. 공공 정보시스템을 개발하는 기업은 이 가이드의 보안 약점 항목을 개발 단계의 점검표로 쓴다. 입력데이터 검증 및 표현 분류는 XSS뿐 아니라 인젝션 계열 약점도 함께 다루므로, 답안에서는 출력 인코딩과 입력 검증을 이 분류 아래에 묶어 설명하면 된다.

시큐어 코딩 기준은 2012년 12월부터 시행되었고, 현재 확인되는 고시 표기는 제2021-3호(2021년 1월 19일)다. OWASP 순위는 2004년 A4, 2007년 A1, 2010년 A2로 나타난다.

국제 기준으로는 CSP가 W3C 표준이며, 약점 분류 체계인 CWE에서 XSS는 CWE-79로 등록되어 있다. 답안에서는 기준 이름과 역할만 쓰고, 국내 고시와 수치를 섞어 쓰지 않는다.

6. 유형과 비교

XSS는 악성 스크립트가 들어가는 경로와 실행 위치에 따라 저장형(Stored XSS), 반사형(Reflected XSS), DOM 기반 XSS(DOM-based XSS)로 나뉜다. 세 유형은 스크립트가 머무는 곳이 서버 저장소인지, 요청·응답인지, 브라우저 내 DOM인지로 구분된다. 답안에서는 먼저 유형 분류를 제시하고, 이어서 각 유형의 특징을 비교표로 정리하는 순서가 명확하다.

표에서 보듯 저장형은 한 번 심어지면 방문자 모두에게 실행된다. 반사형은 피해자가 악성 링크를 클릭해야 성립한다. DOM 기반 XSS는 서버 응답이 정상이어도 클라이언트 코드가 입력을 위험하게 쓰는 경우 발생한다.