XSS·CSRF·파일 업로드·경로 조작 방어
XSS의 코드 실행과 CSRF의 인증정보 악용 요청을 구분한다. 문맥별 출력 처리·CSRF 토큰·파일 내용 및 저장 위치 검증·서버 파일 ID 매핑으로 각 약점의 원인과 방어를 이해한다.
핵심 요약
XSS는 비신뢰 데이터가 브라우저에서 코드로 실행되는 문제이고, CSRF는 사용자의 인증 상태를 이용해 의도하지 않은 요청을 수행하게 만드는 공격이다. 파일 업로드와 경로 조작에서는 파일의 내용·저장 위치·사용 권한을 함께 통제해야 한다.
1. XSS의 유형과 원인
| 유형 | 특징 | 예 |
|---|---|---|
| 저장형 XSS | 악성 내용이 저장되었다가 다른 사용자의 화면에 출력 | 게시글·댓글의 비신뢰 HTML |
| 반사형 XSS | 요청의 입력값이 즉시 응답에 포함되어 실행 | 검색어·오류 메시지의 무처리 출력 |
| DOM 기반 XSS | 클라이언트 코드가 비신뢰 값을 위험한 DOM 처리 지점에 전달 | URL 값을 읽어 원시 HTML로 삽입 |
저장형·반사형은 데이터의 전달 경로, DOM 기반은 클라이언트의 처리 위치를 강조한다. 실제 사례에서 이 분류가 겹칠 수 있다.
핵심은 입력에 특정 단어가 있는지가 아니라 브라우저가 데이터를 코드로 해석할 수 있는 위치에 전달했는가다. DB에 저장된 데이터도 최초 입력이 비신뢰라면 출력할 때 방어해야 한다.
2. XSS 방어
일반 텍스트는 안전한 템플릿 출력이나 textContent처럼 텍스트로 처리하는 기능을 사용한다. HTML 본문·속성·URL·스크립트 등 실제 출력 문맥에 맞춰 인코딩하고, 비신뢰 값을 실행 코드에 직접 끼워 넣지 않는다.
| 수단 | 역할 | 한계 |
|---|---|---|
| 문맥별 출력 인코딩 | 데이터를 제어 문법과 구별 | 다른 문맥에 같은 처리를 그대로 적용하면 안전하지 않을 수 있음 |
| 안전한 출력 API | 텍스트를 코드로 해석하지 않도록 처리 | 위험한 API에 다시 넘기면 보호가 사라질 수 있음 |
| HTML 정화 | 필요한 태그·속성만 남김 | 검증된 처리와 적절한 정책 필요 |
| CSP | 실행 가능한 콘텐츠 출처·방식을 제한하는 보조 통제 | 안전한 출력 처리의 대체재가 아님 |
| HttpOnly 쿠키 | 스크립트의 쿠키 직접 읽기 제한 | XSS의 실행 자체나 사용자 권한의 요청 전송까지 막지는 않음 |
사용자가 서식을 넣은 게시글을 작성해야 한다면 모든 HTML을 그대로 허용하는 대신 필요한 요소만 남기는 정화가 필요하다. 자동 이스케이프가 있는 템플릿에서도 이를 해제하거나 원시 HTML 삽입 기능을 사용하면 취약점이 다시 생길 수 있다.
3. CSRF의 성립 조건
CSRF(Cross-Site Request Forgery)는 브라우저가 쿠키 등의 인증정보를 자동으로 보내는 점을 이용한다. 사용자가 로그인한 상태에서 공격자가 유도한 요청이 서버로 전달되고, 서버가 사용자의 실제 의도를 확인하지 않으면 상태 변경이 일어날 수 있다.
공격자는 반드시 응답 내용을 읽어야 하는 것이 아니다. 예를 들어 비밀번호·배송지 변경 요청이 처리되면 응답을 읽지 못해도 피해가 발생할 수 있다.
| 비교 | XSS | CSRF |
|---|---|---|
| 악용하는 지점 | 브라우저의 코드 해석과 실행 | 서버가 브라우저의 인증된 요청을 신뢰하는 방식 |
| 핵심 결과 | 대상 사이트 문맥에서 의도하지 않은 코드 실행 | 사용자가 의도하지 않은 상태 변경 요청 처리 |
| 대표 방어 | 문맥별 인코딩·안전한 출력·HTML 정화 | CSRF 토큰·출처 확인·쿠키 정책 |
4. CSRF 방어
서버는 상태를 변경하는 요청에 예측하기 어려운 CSRF 토큰을 포함시키고 정당한 값인지 검증할 수 있다. 토큰이 있다는 이름만 중요한 것이 아니라 서버가 실제로 검사해야 한다.
SameSite 쿠키 속성은 사이트 간 요청에서 쿠키가 전송되는 조건을 제한한다. Origin·Referer 확인은 요청 출처를 검토하는 보조 방법이다. 민감한 작업에는 재인증이나 명시적 확인을 함께 적용할 수 있다.
상태 변경을 GET 요청에 두지 않는 것이 원칙이지만, POST로 바꾸는 것만으로 CSRF가 해결되지는 않는다. 공격자는 POST 요청도 유도할 수 있다.
동일 출처 정책과 CORS는 주로 브라우저에서 다른 출처의 응답을 읽는 권한 등에 관여하며 모든 상태 변경 요청의 전송을 막는 일반적인 CSRF 방어책은 아니다. 또한 XSS가 있으면 같은 사이트에서 토큰을 읽거나 요청을 수행할 수 있으므로 두 약점을 함께 방어해야 한다.
5. 파일 업로드의 위험
업로드는 서버가 외부 파일을 받아 보관·해석·제공하는 과정이다. 실행 가능한 스크립트, 악성코드, 비정상 파일 구조, 과도하게 큰 파일, 저장형 XSS, 기존 파일 덮어쓰기 등이 문제가 될 수 있다.
| 통제 대상 | 기본 방어 |
|---|---|
| 사용자와 행위 | 인증·업로드 권한 확인, 필요한 CSRF 방어 |
| 파일 형식 | 허용 확장자와 실제 내용·서명·파싱 결과 확인 |
| 크기·개수 | 파일 크기, 요청 개수, 압축 해제 후 자원 한도 제한 |
| 파일명 | 원본명을 저장 경로로 직접 사용하지 않고 서버가 저장 이름 부여 |
| 저장 위치 | 웹 루트 밖이나 별도 저장소에 보관하고 실행 권한 제한 |
| 악성 내용 | 필요에 따라 악성코드 검사·안전한 재처리 적용 |
| 다운로드 | 파일마다 접근권한 확인, 안전한 형식으로 제공 |
클라이언트가 보내는 Content-Type이나 확장자는 조작될 수 있다. 파일 앞부분의 서명만으로도 모든 위협을 검출할 수 있는 것은 아니다. 여러 검사를 결합해야 한다.
난수 이름으로 저장하면 충돌·경로 조작 위험을 줄일 수 있지만, 파일 주소를 알아낸 사용자가 접근할 권한이 있는지는 별도 확인해야 한다. 파일명 난수화는 인가의 대체재가 아니다.
압축 파일은 압축 상태의 크기뿐 아니라 해제 후 크기·파일 수를 고려한다. 내부 항목이 지정 폴더 밖으로 나가도록 되어 있으면 경로 조작 위험도 발생한다.
6. 경로 조작
경로 조작(Path Traversal)은 입력값으로 파일 경로를 조작하여 허용된 디렉터리 밖의 파일을 읽거나 수정·삭제하는 약점이다. 상위 디렉터리를 가리키는 ../, ..\ 외에도 절대 경로, 인코딩된 표현, 심볼릭 링크 등을 고려해야 한다.
가장 단순한 안전 설계는 외부에 실제 경로를 받지 않고 파일 ID → 서버의 고정 매핑 → 허용 저장소로 연결하는 것이다. 파일 ID를 받은 뒤에도 해당 사용자가 그 파일에 접근할 수 있는지 인가를 검사한다.
경로를 처리해야 한다면 실제 사용할 형태로 정규화하고, 허용 기준 디렉터리 안의 경로인지 확인한다. 단순 문자열 접두사 비교는 적절하지 않을 수 있다. /data/user-old는 문자열이 /data/user로 시작하지만 같은 디렉터리의 하위 경로가 아니다.
심볼릭 링크와 검사 후 사용 사이의 상태 변경도 고려해야 한다. 경로를 한 번 검사했다는 사실만으로 이후 실제 파일 열기까지 항상 안전한 것은 아니다. 파일 처리 프로세스의 권한도 필요한 범위로 제한한다.
7. 통합 판별 예
사용자가 업로드한 소개 파일을 서버의 실행 가능 폴더에 원본 이름으로 저장하고, 그 파일을 다른 사람에게 원시 HTML로 보여준다고 하자. 이는 파일 형식·저장 위치·실행 권한 문제와 XSS 문제가 함께 존재할 수 있다.
보관 위치를 분리해도 화면에서 내용을 위험하게 해석하면 XSS가 남는다. 출력만 인코딩해도 파일의 경로 조작이나 무단 다운로드는 남는다. 입력·저장·실행·출력·인가의 각 지점을 따로 통제해야 한다.
웹 요청·브라우저 문맥·업로드 경계
Origin 검증은 임의 문자열 포함 여부가 아니라 신뢰하는 스킴·호스트·포트 조건을 비교한다. 브라우저 요청의 모든 상황에 동일한 헤더가 있다는 가정은 피한다.
SameSite=Strict는 일반적인 교차 사이트 요청에서 쿠키 전송을 제한한다. 이를 서버의 모든 인가 검사를 생략할 근거로 사용하지 않는다. GET은 조회처럼 안전한 의미로 사용하고 자원 상태를 바꾸는 작업을 GET으로 설계하지 않는다. POST라는 이유만으로 CSRF가 자동 방지되는 것도 아니다.
링크의 href에 URL을 넣을 때 URL 구성요소 인코딩과 허용 스킴 검사를 구분한다. 문자열이 URL 형태라는 사실만으로 실행 가능한 위험한 스킴을 허용하면 안 된다. HTML 속성에 넣는 실제 문맥의 안전한 표현도 필요하다.
파일 업로드에서는 확장자, 실제 내용, 허용 형식, 저장 위치, 접근·실행 권한과 크기를 함께 검토한다. Content-Length와 같은 선언만 믿지 않고 실제 수신되는 바이트의 누적량을 제한한다. 임의의 큰 파일은 이름을 난수로 바꾸어도 자원을 고갈시킬 수 있다.
압축 파일은 바깥 파일 이름과 내부 항목의 경로가 다르다. 각 항목의 정규화된 최종 해제 경로가 허용 디렉터리를 벗어나지 않는지 확인한다. 심볼릭 링크와 재해석 등 파일시스템 조건도 고려한다. 압축 해제 후 용량·항목 수·시간 제한 역시 필요하다. 바깥 확장자 하나만 확인하는 것은 충분하지 않다.