해킹 기법 시리즈 두 번째 주제: XSS(크로스사이트 스크립팅)
지난 편에서 다룬 SQL 인젝션이 서버 쪽 데이터베이스를 노리는 공격이었다면, 오늘 다룰 XSS(Cross-Site Scripting, 크로스사이트 스크립팅)는 방향이 정반대입니다. 서버가 아니라 그 화면을 보는 ‘다른 사람의 브라우저’를 노립니다. 심지어 링크를 클릭하지 않아도, 이메일 하나를 열어보는 것만으로 뚫리는 경우까지 있습니다. 실제로 지난 7월 22일부터 러시아 계열 해커 조직이 이 방식으로 미국·유럽 정부기관을 공격했습니다. 도대체 어떤 구조이길래 이런 일이 가능한 걸까요.
XSS란, 비유로 이해하기
XSS는 ‘남이 쓴 메모를 그대로 소리 내 읽어주는 방송 시스템’에 비유할 수 있습니다. 게시판 댓글이나 방명록처럼 누구나 글을 남길 수 있는 공간에서, 그 글이 다른 방문자 화면에 그대로 표시되는 구조를 떠올려보세요. 원래는 텍스트만 안전하게 표시돼야 하는데, 시스템이 그 안에 섞인 코드까지 구분하지 못하고 ‘실행해도 되는 명령’으로 착각해버리면 문제가 생깁니다.
공격자가 댓글이나 이메일, 프로필 소개란처럼 사용자 콘텐츠가 들어가는 자리에 스크립트 코드를 몰래 끼워 넣으면, 이 페이지를 열어본 다른 사람의 브라우저에서 그 코드가 그대로 실행됩니다. 서버가 털리는 게 아니라, 그 페이지를 보는 ‘피해자의 브라우저’가 공격 무대가 되는 셈입니다. 그 결과 로그인 세션이 탈취되거나, 화면이 조작되거나, 심지어 이메일 미리보기 화면 안에서 추가 악성 동작이 실행되는 일까지 벌어질 수 있습니다.
XSS는 왜 구조적으로 막기 어려운가
원리를 알면 단순해 보이는데, 왜 여전히 문제가 될까요. 첫째, 사용자 콘텐츠를 받는 지점 자체가 너무 많습니다. 댓글, 리뷰, 프로필, 검색어, 심지어 이메일 본문까지—사람이 뭔가 입력하고 그게 다른 사람에게 보이는 모든 곳이 잠재적 취약 지점입니다. 그중 한 곳만 이스케이프 처리(코드가 아니라 순수 텍스트로만 표시되게 변환하는 작업)를 빠뜨려도 뚫립니다.
둘째, XSS는 ‘검증하지 않은 사용자’뿐 아니라 ‘어느 정도 권한을 가진 사용자’에게서도 나옵니다. 뒤에서 볼 워드프레스 플러그인 사례처럼, 일반 방문자가 아니라 콘텐츠 등록 권한을 가진 계정이 악용되면 방어선이 한 겹 더 뚫립니다. 셋째, 방어 기술 자체도 계속 진화해야 합니다. 콘텐츠 보안 정책(CSP) 같은 브라우저 차원의 방어 장치가 나온 지 오래됐지만, 오래된 시스템이나 서드파티 코드가 이를 제대로 적용하지 않은 채로 남아 있는 경우가 여전히 많습니다.
넷째, 탐지가 유독 까다롭다는 점도 한몫합니다. SQL 인젝션은 서버 로그나 데이터베이스 접근 기록을 보면 이상 징후가 비교적 뚜렷하게 남지만, XSS는 피해가 ‘다른 사람의 브라우저’라는 눈에 잘 안 보이는 곳에서 조용히 일어납니다. 운영자 입장에서는 사용자가 직접 신고하기 전까지 문제를 인지하기 어려운 경우가 많고, 그만큼 발견까지 걸리는 시간도 길어지는 편입니다.
2026년 XSS 실제 사례 3가지
성격이 전혀 다른 세 가지 사례가 올해 XSS의 위험성을 보여줬습니다.
가장 파장이 컸던 건 마이크로소프트 아웃룩 웹 액세스(OWA)의 CVE-2026-42897입니다. 러시아 계열로 알려진 위협 그룹이 지난 7월 22일부터 이 취약점을 악용한 캠페인을 벌였는데, 방식이 특이했습니다. 피해자가 링크를 클릭하거나 첨부파일을 열 필요 없이, 특수하게 조작된 메일을 웹메일 화면에서 열어보는 것만으로 스크립트가 실행됐습니다. 연구자들은 이를 ‘반쪽짜리 클릭 공격’이라고 부릅니다. 이 캠페인은 미국·유럽 정부기관과 통신·금융·항공 분야까지 노렸습니다.
3월에는 전 세계 1,000만 개 이상 사이트에 설치된 워드프레스 SEO 플러그인 요스트 SEO(Yoast SEO)에서 CVE-2026-3427이 발견됐습니다. ‘기여자(Contributor)’ 권한만 있으면—즉 관리자가 아니어도—특정 입력란을 통해 스크립트를 저장해둘 수 있는 구조였습니다. 이렇게 저장된 코드는 그 페이지를 열람하는 모든 방문자의 브라우저에서 실행됩니다.
같은 해 상반기에는 팔로알토네트웍스 방화벽 관리 화면(PAN-OS)에서도 CVE-2026-0256이 확인됐습니다. 인증된 관리자 계정이 악용되면 관리 화면에 스크립트를 저장해둘 수 있는 구조로, 다행히 실제 악용 사례는 아직 확인되지 않았지만 기업 핵심 인프라의 관리자 화면조차 예외가 아니라는 걸 보여줬습니다.
XSS 방어 체크리스트
일반 사용자라면 이렇게 할 수 있습니다.
– 출처가 불분명한 메일은 미리보기·열람도 주의한다
– 웹메일과 브라우저는 항상 최신 버전으로 유지한다
– 평소와 다른 로그인·활동 알림이 오면 즉시 비밀번호를 바꾼다
– 회사 메일이라면 보안팀 공지를 주기적으로 확인한다
운영자·개발자라면 이 원칙이 더 중요합니다.
– 사용자 입력값은 저장할 때가 아니라 화면에 출력하는 시점에 반드시 이스케이프 처리한다
– 사용 중인 플러그인·라이브러리는 최신 버전으로 자주 업데이트한다
– 콘텐츠 보안 정책(CSP)으로 페이지 안에서 실행 가능한 스크립트 범위를 제한한다
– 기여자·에디터 같은 낮은 권한 계정도 입력 가능한 범위를 정기적으로 점검한다
FAQ
XSS와 지난 편에서 다룬 SQL 인젝션은 뭐가 다른가요?
SQL 인젝션은 서버 쪽 데이터베이스를 겨냥하고, XSS는 그 페이지를 보는 다른 사용자의 브라우저를 겨냥합니다. 둘 다 ‘검증되지 않은 입력값’에서 시작한다는 점은 같지만, 공격이 실행되는 장소가 다릅니다.
메일을 열어보기만 해도 정말 뚫릴 수 있나요?
이번 OWA 사례처럼 웹메일 화면 자체에 취약점이 있으면 가능합니다. 다만 이는 서비스 쪽 결함이 patch되지 않았을 때의 이야기이고, 패치가 적용된 이후에는 같은 방식으로는 뚫리지 않습니다.
워드프레스를 쓰는데 나도 위험한가요?
설치한 플러그인이 최신 버전인지가 핵심입니다. 특히 여러 사람이 글을 쓰는 사이트라면 기여자 이상 권한을 가진 계정 관리도 함께 점검하는 게 좋습니다.
XSS 공격을 당하면 개인정보가 유출되나요?
꼭 그런 것은 아닙니다. 세션 쿠키가 탈취돼 로그인이 도용되는 경우도 있고, 화면이 눈속임용으로 조작돼 다른 사이트로 유도되는 경우도 있습니다. 결과는 사례마다 다르지만, 공통점은 피해자 본인의 브라우저 안에서 벌어진다는 점입니다.
마치며
XSS는 서버가 아니라 ‘화면을 보는 사람’을 노린다는 점에서 SQL 인젝션과는 또 다른 종류의 위협입니다. 방향은 다르지만 원인은 결국 똑같습니다. 검증되지 않은 입력값을 그대로 믿고 처리했다는 것. 다음 편에서는 계정 자체를 직접 노리는 크리덴셜 스터핑을 다뤄보겠습니다.
출처
국내 기업 금융 보안 조직 8년차. 취약점 진단과 보안 기획 업무를 하며, 업계 밖에서는 잘 안 보이는 보안 이야기를 정리하고 있습니다. 개인 자격으로 쓰며 소속 조직과 무관합니다.