이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
XSS는 사용자가 넣은 입력이 화면에서 글자가 아니라 코드로 실행되는 것으로 이해합니다. 핵심은 데이터로 와야 할 게 코드 자리에 끼는 것입니다. 예를 들어 댓글에 넣은 글이 그대로 화면에 박히면, 그 안의 스크립트가 다른 사람 브라우저에서 실행됩니다. 왜 위험하냐면, 그 스크립트가 그 사용자 권한으로 동작해, 로그인 정보를 빼돌리거나 그 사람인 척 행동할 수 있기 때문입니다. 단순 화면 깨짐과 차원이 다릅니다. 막는 원리도 거기서 나옵니다.
입력을 화면에 넣을 때 코드로 안 읽히게 글자로 처리(이스케이프)하는 게 핵심입니다. 데이터를 데이터 자리에만 두는 것입니다. 학부 프로젝트에서 입력을 그대로 출력했다가, 스크립트 한 줄이 실행되는 걸 직접 확인하고 막은 경험이 있습니다. 다만 한 가지 처리로 다 막힌다고 보진 않습니다.
입력이 들어가는 자리마다 맥락이 달라, 자리에 맞게 막아야 한다고 봅니다.
저는 XSS를 작은 사고를 겪고 제대로 이해했습니다. 학부 프로젝트에서 사용자 이름을 화면에 그대로 보여 줬는데, 한 사람이 이름 자리에 스크립트를 넣자 그게 다른 사람 화면에서 실행됐습니다. 그때 알았습니다. XSS의 본질은 입력을 믿고 코드 자리에 그대로 둔 것이라는 걸요. 위험한 이유는, 실행된 스크립트가 그 페이지의 권한을 그대로 써, 그 사람 세션을 훔치거나 대신 요청을 보낼 수 있기 때문입니다. 그래서 막는 핵심은 입력을 출력할 때 코드가 아니라 글자로만 보이게 처리하는 것입니다. 저는 그 사고 뒤 모든 사용자 입력을 출력 직전에 글자로 변환하게 바꿨습니다. 다만 그것만으로 끝이 아니라는 것도 압니다.
주소나 스크립트 안에 들어가는 입력은 또 다른 처리가 필요해서, 자리마다 막는 법이 다르다는 걸 같이 배웠습니다.
XSS는 한 가지로 다 막힌다는 오해부터 걷어내고 설명하는 게 분명합니다. 본질은 단순합니다. 사용자 입력이 화면에서 코드로 실행되는 것이고, 위험한 건 그 코드가 피해자 권한으로 세션 탈취나 대리 행동을 하기 때문입니다. 가장 기본 방어는 입력을 출력할 때 글자로만 보이게 변환하는 것입니다. 다만 그것만으로 끝이 아닙니다. 입력이 주소 자리에 들어가거나, 스크립트 문맥 안에 들어가면 변환 방식이 달라야 하고, 화면을 동적으로 만드는 코드에서 또 새는 자리가 생깁니다. 그래서 저는 XSS 방어를 한 함수가 아니라, 입력이 들어가는 자리마다 그 맥락에 맞게 막고, 그 위에 정책으로 한 겹 더 두는 것으로 봅니다. 학부 때 출력 변환만 해 두고 안심했다가, 주소 자리로 다른 입력이 새던 걸 발견한 경험이 이 시각의 근거입니다. 핵심은 한 방어가 아니라 자리별로 막는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 KT 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.