이미 20년도 넘은 공격 기법...2007년부터 웹 환경의 가장 큰 위협
누군가 코드를 함부로 바꾸고 엉뚱한 데이터를 주입한다는 걸 알면 막울 수 있어
[보안뉴스 문가용 기자] 어딘들 안 그렇겠냐만, 사이버 보안 업계에서도 ‘새로운 것’에 대한 관심도가 지나치게 높은 편이다. 그래서 생전 처음 등장하는 제로데이 익스플로잇들은 쉽게 화제가 되고 관심이 세례처럼 쏟아진다. 반면 오래된 위협들에 대한 관심은 시들하다. 실제로 기업들에게 피해를 입히는 것 중 대다수가 이 낡고 오래된 문제들인데 말이다.
너무 흔해서 닳고 닳은 이름이 되어 버린 취약점 중 XSS라는 게 있다. 교차 사이트 스크립팅(Cross-site scripting)의 준말이다. XSS가 세상에 처음 알려진 건 2000년 1월 16일이었으니, 이미 청년의 나이와 맞먹는 시간이 지났다. 심지어 이미 2007년(미운 일곱 살?)에는 웹 기반 애플리케이션 계통에서 가장 흔히 나타나는 취약점으로 꼽히기도 했다. 그리고 그 악명은 아직까지 유지되고 있다. 도대체 이 XSS란 무엇일까?
간단히 설명하자면
브라우저를 열고 주소 창에 URL을 적어보자. 그리고 엔터를 누르면 브라우저가 그 URL에 맞는 요청을 서버로 전송한다. 서버는 그 요청을 받아 그에 맞는 데이터를 브라우저로 보내고, 브라우저는 그 데이터를 받아 화면에 띄운다. 이미 1990년대에 해커들은 이와 같은 과정에서 자바스크립트를 적절히 사용하면 웹사이트를 또 다른 웹사이트의 프레임 안에 띄울 수 있다는 것을 알게 됐다. 한 사이트 안에 다른 사이트를 로딩시키는 것으로, 프레임을 작게 만듦으로써 눈에 안 띄게 할 수도 있었다.
그 작은 프레임 안에 몰래 로딩된 사이트가 악성 기능을 가지고 있다면 어떻게 될까? 어떤 악성 기능이냐에 따라 다르겠지만 진짜처럼 보이는 양식을 띄워 사용자 정보, 비밀번호 등을 훔친다거나, 요즘 같으면 몰래 암호화폐를 채굴하는 등 온갖 공격을 할 수 있게 된다. 이렇게 두 개의 웹사이트와 자바스크립트를 활용하는 공격이기 때문에 ‘교차 사이트 스크립팅’이라는 이름이 붙었고, 지금까지도 유효한 공격 형태로 남아 있다.
시간을 앞으로 빨리 돌려 2020년. 1990년대의 웹사이트와 달리 현대의 웹사이트는 대단히 복잡한 구조를 가지고 있다. 따라서 웹 페이지나 웹 애플리케이션을 브라우저에 나타나게 하는 과정도 복잡해졌다. 브라우저의 요청을 받고, 그에 대한 데이터를 되돌려 보내는 서버가 처리해야 하고 검토해야 할 것이 많아졌다는 뜻이다. 그 모든 것들을 다 검사하고 확인할 수 있다면 좋지만 현실에서는 한두 개 정도 실수를 저지르거나 오류가 나기 쉽고, 공격자들 역시 이러한 복잡한 과정을 자신들의 목적에 맞게 악용하는 방법을 계속 개발하고 있다.
하나 더 알아야 할 용어, DOM
XSS에 대해 더 설명하기 전에 짚고 넘어가야 할 용어가 있다. 바로 DOM, 문서 객체 모델(Document Object Model)이다. 아주 간단히 말해, 사용자 브라우저 내에 구현되는 웹 애플리케이션이나 사이트 전체를 싸잡아서 부를 때 DOM이라고 한다. 이 안에 스크립트도 들어가고, 객체도 들어가고, 링크도 들어가고... 웹 페이지라는 걸 구성하는 모든 요소들이 DOM에 포함되어 있기 때문에 XSS를 다루는데 있어 중요한 개념이다.
XSS 공격에는 여러 가지 종류가 있다. 위에서 말한 개념을 바탕으로 분파된 형태들이 존재한다. 다만 어떤 유형이든 결국 공격자가 정상적인 웹사이트나 웹 애플리케이션의 코드에 변형을 가할 수 있어야 공격이 성립된다. 이 코드는 서버에 있을 수도 있고, 사용자의 컴퓨터에 있을 수도 있으며, 서버와 컴퓨터 사이에 한창 전송 중일 수도 있다. 이 중 하나만이라도 공격자가 임의로 바꿔 자바스크립트를 추가할 수 있어야 한다. 아래 유형별 설명을 통해 좀 더 설명을 보충하겠다.
1) 1번 유형 : 주로 ‘지속적 XSS(persistent XSS)’나 ‘저장된 XSS(stored XSS)’라고 불린다. 사용자가 서버에 데이터를 저장해놓고, 그 데이터를 거의 아무런 방해 없이 가져올 수 있는 환경에서 성립한다. 커뮤니티에 달린 댓글들을 볼 때와 같은 경우다. 댓글은 서버에 저장되는 데이터이고, 이걸 열람하는 사용자는 보통 인증 과정과 같은 절차 없이 내용을 볼 수 있다.
이 때 사용자가 서버로부터 오는 데이터를 전부 검사하지 않는 게 보통이다. 이 점을 이용해 공격자가 댓글란과 같은 필드에 코드를 주입함으로써 사용자 컴퓨터에서 그 코드를 실행시킬 수 있게 된다. 댓글을 봤을 뿐인 사용자는 이를 전혀 알아챌 수 없다. 이런 공격을 감행하려면 웹 페이지 소스코드를 공격자가 변경할 수 있어야 하고, 웹 서버에도 접근할 수 있어야 한다. 즉 서버에 대한 공격으로도 볼 수 있다.
2) 2번 유형 : ‘비지속적 XSS(non-persistent XSS)’ 혹은 ‘반사된 XSS(reflected XSS)’라고 불린다. 사용자가 입력한 값이 즉각 사용자에게 되돌아오는 과정에서 공격이 성립된다. 특히 되돌아오는 값을 확인하는 과정이 없고, 사용자 입력 값이 서버에 저장되지 않아야 한다. 이런 공격은 서버가 전혀 개입되지 않으며, 브라우저 층위에서 모든 것이 다 이뤄진다. 즉 클라이언트 단에서 모든 일이 벌어진다는 것이다.
1번은 서버를 공격하는 것이므로 사이트 이용자가 사이트의 콘텐츠를 확인하는 것만으로도 공격이 가능하지만, 2번은 사용자 단에서 공격이 이뤄져야 하므로 사용자가 악성 링크를 누르거나 악성 파일을 열어보도록 꾀어야 한다. 서로 상충하는 난이도가 있는 공격 유형이다.
3) 0번 유형 : 가장 마지막에 발견된 유형의 XSS로, ‘DOM 기반 XSS(DOM-based XSS)’라고 불린다. 2번 유형과 마찬가지로 브라우저 내에서만 모든 공격을 감행내는 게 가능하다. 2번 유형과 다른 점은 악성 스크립트를 삽입하는 게 아니라, 브라우저에 구현되는 DOM 환경을 바꿈으로서 웹 페이지의 원래 코드가 엉뚱하게 실행되도록 유도한다는 것이다.
마치 선물을 주고받는 상황에서 Thank you는 감사하다는 뜻이 되지만, 테니스장이라는 상황에서 심판이 말하는 Thank you는 조용히 해달라는 뜻이 되는 것과 같다. 따라서 피해자가 보기에는 웹 페이지에는 아무런 변화가 없는데, 페이지 내부에 삽입된 코드가 엉뚱한 결과를 내게 된다.
XSS 싫어요
실제 해킹 사건에서 공격자들은 이 세 가지 유형 중 한 가지를 택해서 공격하지 않는다. 막 섞어서 쓴다. 그래서 방어하는 입장에서는 더 골치가 아프다. 하지만 모든 XSS 공격을 관통하는 개념이 있으니, 앞서 말한 것처럼 ‘누군가 서버나 브라우저 단에서 코드를 허락 없이 변경하려고 한다’는 것이다. 이 점을 기억하면 각종 복잡한 공격도 어느 정도 방어할 수 있게 된다.
먼저 개발자나 보안 팀은 이러한 XSS 공격에 대하여 어떤 방어 태세를 취해야 할까? 가장 중요한 건 그 누구도 함부로 기존의 코드에 다른 내용이나 데이터를 삽입하지 못하도록 하는 것이다. 이런 변경이 필요할 땐 공식 절차를 밟아서 해야만 한다. 생각보다 간단하다고? 현장에서는 생각보다 지키기 까다로운 일이라고 한다.
데이터의 무분별한 삽입을 막기 위해 가장 기본적으로 해야 할 일은 스크립트 세션을 시작하게 하는 ‘이니시에이터’를 막는 것이다. ‘자, 여기서부터 스크립트가 시작됩니다’라는 의미를 가진 문자들을 지정할 때 아스키(ASCII) 문자들을 사용하는 건 위험할 수 있다. 다음으로는 모든 매개변수들과 스크립트 호출 코드가 따옴표 안에 들어가도록 해야 한다. 따옴표 없이 각종 변수를 대입할 수 있게 되면 누군가 반드시 XSS를 시도한다.
하지만 가장 중요한 건 웹사이트의 코드를 주기적으로 검사하는 것이다. 정상일 때의 상태를 잘 인지하고, 비정상적인 부분을 주기적 모니터링을 통해 재빨리 파악하는 게 중요하다. 코드의 버전 관리가 그래서 중요하고, 이것이 몸에 배면 든든한 보험이 된다. 사실 이 습관이 잘 안 들었기 때문에 XSS가 여전히 유효한 위협인 것이 사실이지만, 웹 개발자들만의 잘못이라고 말하기 힘들다. 늘 출시일을 앞당겨야 하는 분위기에서 누구나 기본을 간과하거나 잊을 수 있기 때문이다. 누구보다 더 빨리 해야만 하는 문화가 디지털 경제에 존재하는 한, XSS 취약점은 항상 우리 곁에 있을 예정이다.
[문가용 기자(globoan@boannews.com)]
누군가 코드를 함부로 바꾸고 엉뚱한 데이터를 주입한다는 걸 알면 막울 수 있어
[보안뉴스 문가용 기자] 어딘들 안 그렇겠냐만, 사이버 보안 업계에서도 ‘새로운 것’에 대한 관심도가 지나치게 높은 편이다. 그래서 생전 처음 등장하는 제로데이 익스플로잇들은 쉽게 화제가 되고 관심이 세례처럼 쏟아진다. 반면 오래된 위협들에 대한 관심은 시들하다. 실제로 기업들에게 피해를 입히는 것 중 대다수가 이 낡고 오래된 문제들인데 말이다.
[이미지 = utoimage]
너무 흔해서 닳고 닳은 이름이 되어 버린 취약점 중 XSS라는 게 있다. 교차 사이트 스크립팅(Cross-site scripting)의 준말이다. XSS가 세상에 처음 알려진 건 2000년 1월 16일이었으니, 이미 청년의 나이와 맞먹는 시간이 지났다. 심지어 이미 2007년(미운 일곱 살?)에는 웹 기반 애플리케이션 계통에서 가장 흔히 나타나는 취약점으로 꼽히기도 했다. 그리고 그 악명은 아직까지 유지되고 있다. 도대체 이 XSS란 무엇일까?
간단히 설명하자면
브라우저를 열고 주소 창에 URL을 적어보자. 그리고 엔터를 누르면 브라우저가 그 URL에 맞는 요청을 서버로 전송한다. 서버는 그 요청을 받아 그에 맞는 데이터를 브라우저로 보내고, 브라우저는 그 데이터를 받아 화면에 띄운다. 이미 1990년대에 해커들은 이와 같은 과정에서 자바스크립트를 적절히 사용하면 웹사이트를 또 다른 웹사이트의 프레임 안에 띄울 수 있다는 것을 알게 됐다. 한 사이트 안에 다른 사이트를 로딩시키는 것으로, 프레임을 작게 만듦으로써 눈에 안 띄게 할 수도 있었다.
그 작은 프레임 안에 몰래 로딩된 사이트가 악성 기능을 가지고 있다면 어떻게 될까? 어떤 악성 기능이냐에 따라 다르겠지만 진짜처럼 보이는 양식을 띄워 사용자 정보, 비밀번호 등을 훔친다거나, 요즘 같으면 몰래 암호화폐를 채굴하는 등 온갖 공격을 할 수 있게 된다. 이렇게 두 개의 웹사이트와 자바스크립트를 활용하는 공격이기 때문에 ‘교차 사이트 스크립팅’이라는 이름이 붙었고, 지금까지도 유효한 공격 형태로 남아 있다.
시간을 앞으로 빨리 돌려 2020년. 1990년대의 웹사이트와 달리 현대의 웹사이트는 대단히 복잡한 구조를 가지고 있다. 따라서 웹 페이지나 웹 애플리케이션을 브라우저에 나타나게 하는 과정도 복잡해졌다. 브라우저의 요청을 받고, 그에 대한 데이터를 되돌려 보내는 서버가 처리해야 하고 검토해야 할 것이 많아졌다는 뜻이다. 그 모든 것들을 다 검사하고 확인할 수 있다면 좋지만 현실에서는 한두 개 정도 실수를 저지르거나 오류가 나기 쉽고, 공격자들 역시 이러한 복잡한 과정을 자신들의 목적에 맞게 악용하는 방법을 계속 개발하고 있다.
하나 더 알아야 할 용어, DOM
XSS에 대해 더 설명하기 전에 짚고 넘어가야 할 용어가 있다. 바로 DOM, 문서 객체 모델(Document Object Model)이다. 아주 간단히 말해, 사용자 브라우저 내에 구현되는 웹 애플리케이션이나 사이트 전체를 싸잡아서 부를 때 DOM이라고 한다. 이 안에 스크립트도 들어가고, 객체도 들어가고, 링크도 들어가고... 웹 페이지라는 걸 구성하는 모든 요소들이 DOM에 포함되어 있기 때문에 XSS를 다루는데 있어 중요한 개념이다.
XSS 공격에는 여러 가지 종류가 있다. 위에서 말한 개념을 바탕으로 분파된 형태들이 존재한다. 다만 어떤 유형이든 결국 공격자가 정상적인 웹사이트나 웹 애플리케이션의 코드에 변형을 가할 수 있어야 공격이 성립된다. 이 코드는 서버에 있을 수도 있고, 사용자의 컴퓨터에 있을 수도 있으며, 서버와 컴퓨터 사이에 한창 전송 중일 수도 있다. 이 중 하나만이라도 공격자가 임의로 바꿔 자바스크립트를 추가할 수 있어야 한다. 아래 유형별 설명을 통해 좀 더 설명을 보충하겠다.
1) 1번 유형 : 주로 ‘지속적 XSS(persistent XSS)’나 ‘저장된 XSS(stored XSS)’라고 불린다. 사용자가 서버에 데이터를 저장해놓고, 그 데이터를 거의 아무런 방해 없이 가져올 수 있는 환경에서 성립한다. 커뮤니티에 달린 댓글들을 볼 때와 같은 경우다. 댓글은 서버에 저장되는 데이터이고, 이걸 열람하는 사용자는 보통 인증 과정과 같은 절차 없이 내용을 볼 수 있다.
이 때 사용자가 서버로부터 오는 데이터를 전부 검사하지 않는 게 보통이다. 이 점을 이용해 공격자가 댓글란과 같은 필드에 코드를 주입함으로써 사용자 컴퓨터에서 그 코드를 실행시킬 수 있게 된다. 댓글을 봤을 뿐인 사용자는 이를 전혀 알아챌 수 없다. 이런 공격을 감행하려면 웹 페이지 소스코드를 공격자가 변경할 수 있어야 하고, 웹 서버에도 접근할 수 있어야 한다. 즉 서버에 대한 공격으로도 볼 수 있다.
2) 2번 유형 : ‘비지속적 XSS(non-persistent XSS)’ 혹은 ‘반사된 XSS(reflected XSS)’라고 불린다. 사용자가 입력한 값이 즉각 사용자에게 되돌아오는 과정에서 공격이 성립된다. 특히 되돌아오는 값을 확인하는 과정이 없고, 사용자 입력 값이 서버에 저장되지 않아야 한다. 이런 공격은 서버가 전혀 개입되지 않으며, 브라우저 층위에서 모든 것이 다 이뤄진다. 즉 클라이언트 단에서 모든 일이 벌어진다는 것이다.
1번은 서버를 공격하는 것이므로 사이트 이용자가 사이트의 콘텐츠를 확인하는 것만으로도 공격이 가능하지만, 2번은 사용자 단에서 공격이 이뤄져야 하므로 사용자가 악성 링크를 누르거나 악성 파일을 열어보도록 꾀어야 한다. 서로 상충하는 난이도가 있는 공격 유형이다.
3) 0번 유형 : 가장 마지막에 발견된 유형의 XSS로, ‘DOM 기반 XSS(DOM-based XSS)’라고 불린다. 2번 유형과 마찬가지로 브라우저 내에서만 모든 공격을 감행내는 게 가능하다. 2번 유형과 다른 점은 악성 스크립트를 삽입하는 게 아니라, 브라우저에 구현되는 DOM 환경을 바꿈으로서 웹 페이지의 원래 코드가 엉뚱하게 실행되도록 유도한다는 것이다.
마치 선물을 주고받는 상황에서 Thank you는 감사하다는 뜻이 되지만, 테니스장이라는 상황에서 심판이 말하는 Thank you는 조용히 해달라는 뜻이 되는 것과 같다. 따라서 피해자가 보기에는 웹 페이지에는 아무런 변화가 없는데, 페이지 내부에 삽입된 코드가 엉뚱한 결과를 내게 된다.
XSS 싫어요
실제 해킹 사건에서 공격자들은 이 세 가지 유형 중 한 가지를 택해서 공격하지 않는다. 막 섞어서 쓴다. 그래서 방어하는 입장에서는 더 골치가 아프다. 하지만 모든 XSS 공격을 관통하는 개념이 있으니, 앞서 말한 것처럼 ‘누군가 서버나 브라우저 단에서 코드를 허락 없이 변경하려고 한다’는 것이다. 이 점을 기억하면 각종 복잡한 공격도 어느 정도 방어할 수 있게 된다.
먼저 개발자나 보안 팀은 이러한 XSS 공격에 대하여 어떤 방어 태세를 취해야 할까? 가장 중요한 건 그 누구도 함부로 기존의 코드에 다른 내용이나 데이터를 삽입하지 못하도록 하는 것이다. 이런 변경이 필요할 땐 공식 절차를 밟아서 해야만 한다. 생각보다 간단하다고? 현장에서는 생각보다 지키기 까다로운 일이라고 한다.
데이터의 무분별한 삽입을 막기 위해 가장 기본적으로 해야 할 일은 스크립트 세션을 시작하게 하는 ‘이니시에이터’를 막는 것이다. ‘자, 여기서부터 스크립트가 시작됩니다’라는 의미를 가진 문자들을 지정할 때 아스키(ASCII) 문자들을 사용하는 건 위험할 수 있다. 다음으로는 모든 매개변수들과 스크립트 호출 코드가 따옴표 안에 들어가도록 해야 한다. 따옴표 없이 각종 변수를 대입할 수 있게 되면 누군가 반드시 XSS를 시도한다.
하지만 가장 중요한 건 웹사이트의 코드를 주기적으로 검사하는 것이다. 정상일 때의 상태를 잘 인지하고, 비정상적인 부분을 주기적 모니터링을 통해 재빨리 파악하는 게 중요하다. 코드의 버전 관리가 그래서 중요하고, 이것이 몸에 배면 든든한 보험이 된다. 사실 이 습관이 잘 안 들었기 때문에 XSS가 여전히 유효한 위협인 것이 사실이지만, 웹 개발자들만의 잘못이라고 말하기 힘들다. 늘 출시일을 앞당겨야 하는 분위기에서 누구나 기본을 간과하거나 잊을 수 있기 때문이다. 누구보다 더 빨리 해야만 하는 문화가 디지털 경제에 존재하는 한, XSS 취약점은 항상 우리 곁에 있을 예정이다.
[문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-05] 
