Frame: 웹페이지 주소 감추기

2009.03.01 글쓴이 youknowit

1990년대 중반에 등장한 프레임 셋(frameset) 기술은 하나의 웹페이지에 여러개의 프레임 창(frame)을 배치하고, 각 프레임 창들이 독립적으로 기능할 수 있도록 하는데 사용된다.

웹페이지를 구성하는 내용 중, 흔히 메뉴 항목은 페이지 왼쪽이나, 윗 부분에 고정되어 있고, 페이지에 담긴 주된 내용은 변하더라도 메뉴 항목은 변하지 않는 경우가 많으므로, 메뉴를 하나의 프레임으로, 주된 내용을 다른 하나의 프레임으로 지정하곤 했다. 그러면 이용자가 그 웹사이트의 여러 하위 페이지를 둘러보는(navigate) 경우, 메뉴 프레임은 매번 새로 내려받을 필요 없이 언제나 고정되어 있고, 주된 내용을 담은 프레임만이 내려받아져서 화면에 표시되게 된다.

인터넷 전송 속도가 느렸던 시절에 페이지 내용 전부를 매번 새로 내려받아 화면에 나타나게 하는 것이 부담스러웠던 탓도 있고, 웹페이지 소스를 동적으로 편성하는(dynamically generated websites; 웹페이지 화면이 현란하게 움직인다는 뜻이 아니라, 웹페이지 소스가 그때 그때 즉시로 구성된다는 뜻) 다양한 기술(php, jsp, asp 등)이 없었을 때, 메뉴를 표시하는 소스 부분을 매 페이지 마다 반복해서 적어넣을 필요가 없도록 해주었기 때문에 한때 유행했던 기술이다.

그러나 프레임 기술이 가지는 가장 심각한 문제는 웹페이지 주소가 웹페이지의 내용과 일치하지 않는다는 점이다. 주된 내용을 담고 있는 프레임이 아무리 변해도, 그 프레임을 담고 있는 ‘페이지 자체’는 변하지 않는 것으로 웹브라우저가 인식하므로 주소창에 나타나는 주소는 단 하나로 고정되어 나타난다.

‘국가정보원 IT보안인증 사무국’ 웹사이트를 예로 들어 보자. 홈페이지 주소는 http://www.kecs.go.kr/ 이다. 시작 페이지는 다음과 같이 생겼다. 웹브라우저 주소창에 나타나는 주소를 유심히 보기 바란다.

kecs-home

페이지 왼쪽에 있는 메뉴에서, 보안적합성 검증 제도에 관한 페이지 중 하나를 클릭하여 방문하면, 다음과 같다:

kecs-rules

페이지 내용은 완전히 다르지만, 주소창에 나타나는 주소는 언제나 http://www.kecs.go.kr/ 로 고정되어 있다.

보안적합성 검증 제도의 근거 규정을 다른 사람에게 알려주려는 이용자는 어떻게 이 페이지를 특정할 것인가? 상대방에게 전화를 걸어 http://www.kecs.go.kr/ 를 방문하라고 말한 다음, 그 페이지 왼쪽에서 “보안적합성 검증” 링크를 클릭하라고 말하고, 그 하위에 있는 “관계 규정” 링크를 클릭하면 그 내용을 볼 수 있다고 일일이 말로 설명하라는 것인가? 관계 규정 페이지를 자신의 웹페이지에 ‘링크’하거나, 이메일로 상대방에게 알려주려는 경우에는 어떻게 하라는 말인가?

인터넷의 근본 전제를 이루는 기능은 정보가 “링크”되어 신속히 전파될 수 있다는 것이다. 웹페이지 소스를 흔히 HTML 페이지라고 하는데, 그 말은 Hyper Text Markup Language 라는 뜻이다. ‘Hyper Text’의 의미가 바로 ‘링크’가 가능한 텍스트라는 의미이다. 페이지가 담고 있는 내용을 웹주소로 특정할 수 있기 때문에 그 주소(url)를 사용하여 링크를 걸면 이용자가 그 정보를 당장 찾아 갈 수 있다는 것이 인터넷의 본질적 기능이다. URL 이라는 말도, ‘Uniform Resource Locator’라는 뜻이다. 요컨대, 웹 주소는 해당정보가 어디에 있는지를 정확하게 특정(locate)할 수 있는 기능을 수행하는 것이다.

프레임을 사용하면 이 모든 것이 불가능 해진다. 바로 이 이유 때문에 프레임 기술은 이제 전세계적으로 배척되는 기술로 전락하였다. 물론, php, jsp, asp 등의 기술이 등장하였고, 인터넷 전송 속도가 획기적으로 빨라졌으므로 더 이상 프레임을 사용할 아무런 ‘실익’이 없어졌기 때문이기도 하다.

그러나 우리 공공기관 웹사이트들 중, 특히 ‘정보 보안’과 관련된 웹사이트들은 더욱 ‘괴상한’ 이유와 방법으로 프레임 기술을 사용한다. ‘국가정보원 IT보안인증 사무국’ 홈페이지의 소스를 보면, 다음과 같다.

kecs-source

frameset 이라는 태그 안을 보면, 두개의 frame이 들어 있는 것을 알 수 있는데, 그 중 하나는 완전히 텅 빈(blank) 페이지이고, 다른 하나는 jsp 기술을 사용하여 ‘동적으로 생성되는’ 주된 페이지이다. 페이지 중의 일부(고정된 메뉴)를 하나의 프레임으로 사용하고, 나머지 부분(주된 내용)을 다른 하나의 프레임으로 사용하는 것이 아니라, 페이지의 모든 내용은 동적으로 생성되는 main.jsp 페이지(http://www.kecs.go.kr/main.jsp)에 다 담겨있고, 다른 프레임은 공백인 것이다. 공인인증 제도의 기술적 측면을 총괄한다는 한국정보보호진흥원의 홈페이지(http://www.kisa.or.kr)도 같은 수법을 쓰고 있다.

이렇게 해 두면 그 웹사이트의 어떤 하위 페이지를 이용자가 방문하더라도 주소창의 주소는 절대로 바뀌지 않으므로, 대부분의 이용자는 링크를 걸 수 없도록 되어 버린다. 링크를 못 걸게 하는 것이 ‘보안’에 도움이 되고 ‘정보보호’에 도움이 되는가? 알리고 싶지 않은 페이지라면 애초에 왜 웹사이트에 게시하는지 묻지 않을 수 없다.

‘국가정보원 IT보안인증 사무국’ 홈페이지는 더욱 ‘괴상한’ 짓도 하고 있다. 마우스 오른쪽 버튼이 작동되지 않도록 해 두었다. 마우스 오른쪽 버튼을 누르면 해당 페이지를 저장하거나, 즐겨찾기로 등록하거나, 페이지 소스를 보거나, 그 페이지 링크(url 주소)를 다른 사람에게 이메일로 간편하게 보낼 수 있는 기능 등이 있는데, 이 모든 기능을 사용하지 못하도록 해 둔 것이다. IT 보안인증 사무국의 실제 홈페이지인 main.jsp 의 소스를 보면, 다음과 같은 태그가 포함되어 있다. 소스는 여기.

kecs-mouse

아마도 페이지 소스를 못보게 하는 것도 ‘보안’에 도움이 된다고 생각하고 있는 듯 하다. 그야말로 컴퓨터의 ‘컴’ 자도 모르는 한심한 초보 수준의 발상이 아닐 수 없다. 여기 참조. 웹페이지가 이용자의 화면에 나타나려면, 페이지 소스가 이용자의 컴퓨터에 내려받아 저장될 수 밖에 없다. 그렇지 않고서는 웹페이지를 화면에 나타나게 할 방법이 없다. 컴맹 수준의 이용자는 자기 컴퓨터에 저장된 웹페이지 소스가 어디 있는지를 찾지 못하겠지만, 이런 수준의 이용자가 소스를 들여다 본들 무슨 해악을 끼칠 것인가? 원래부터 html 이 되었건, jsp 가 되었건, 웹페이지 소스는 (서버측 스크립트와는 달리) 당연히 공개되고(공개하지 않을 방법도 없다), 공개된다고 해서 컴퓨터 전문가가 웹서버에 무슨 공격을 가할 수도 없는 것이다(물론 그 소스가 형편 없는 저질 기술로 만든 것이라는 점을 지적하고, 비판할 수는 있겠지만).

프레임을 사용하여 웹페이지 주소를 감추려는 시도는 부끄러운 수준의 컴퓨터 지식을 가진 자만이 해낼 수 있는 괴상한 망상에 불과하다. ‘국가정보원 IT보안인증 사무국’ 의 모든 페이지들의 정확한 웹주소는 홈페이지 주소인 http://www.kecs.go.kr 대신, 그 소스에 적혀 있는 프레임 주소(http://www.kecs.go.kr/main.jsp)를 방문하여 그 웹사이트의 내용을 둘러보기 시작하면 웹브라우저 주소창에 모두 나타나게 되어 있다. 위에 언급한 ‘보안적합성 검증 제도 근거 규정’ 웹페이지의 주소는 http://www.kecs.go.kr/security/relation.jsp 이다.

마우스 오른쪽 버튼을 못쓰게 하면 소스가 보호될 것이라거나, 프레임을 사용하면 주소를 감추고 이용자들이 링크를 걸지 못하게 할 수 있을 거라는(그리고, 링크를 못걸게 하고 즐겨찾기로 등록하지 못하게 하는 것이 ‘보안’에 도움이 될거라는) 수준의 발상을 가지신 분들이 대한민국 ‘국가정보원 IT보안인증 사무국’을 좌지우지하고 있다는 사실은 참으로 안타까운 우리 나라 IT 보안의 현주소이다.

3 Pingbacks/Trackbacks

  • http://chatii.tistory.com chatii

    row=”0%,*”
    아직도 이런 식의 디자인이 있다니, 제가 다 부끄럽네요.

  • viz

    위에서 언급한 웹사이트가 프레임을 사용하는 것은 ActiveX 방식의 페이지 암호화를 사용하기 때문입니다.
    페이지 암호화를 하려면 서버와 브라우저가 어떤 상태(대칭키 등)를 공유해야 하는데 브라우저 쪽에서는 이 상태가 ActiveX의 메모리 상에서 유지됩니다. 그런데 페이지 마다 ActiveX를 로드하면(object 태그를 이용) 메모리가 초기화 되니 상태를 유지할 수 가 없습니다.
    그래서 프레임을 나누고 보이지 않는 감춰진 프레임에서 ActiveX를 로드하고 해당 웹사이트를 떠날때까지 유지하는 것이 현재 모든 정부기관 및 금융기관 웹사이트에서 사용하는 방식입니다.
    그래서 바로가기도 지정할 수 없고 ‘뒤로’ 버튼도 정상적으로 동작하지 않습니다.
    기술적으로 매우 부끄러운 구현이긴 한데, 현 ActiveX 체제 아래선 대안이 없는게 사실입니다. -_-

  • http://alankang.tistory.com alankang

    viz님. 대안이 없다는 말은 적절치 않습니다. 이 글에서 지적하고 있는 현재의 방식은 웹사이트 보안에 아무런 기여를 하지 못하기 때문에, “대안”이라는 것이 애초에 필요가 없습니다. 그냥 현재 방식을 없애면 되는 것입니다.

  • http://openweb.or.kr youknowit

    viz/ ‘보안접속’은 G마켓, 옥션, 인터파크, 디엔숍, 11번가 가 모두 채택 하였듯이 https로 하면 됩니다. “대안이 없다”는 것은 좀 이해하기 어렵군요.

    ‘전자서명’까지 필요하다면, 조금 이야기는 달라지겠지만, 전자서명이 필요 없는 페이지라면 ‘대안이 없는 것’이 아니라, 이미 여러 웹사이트가 실제로 채택, 운영하고 있습니다.

    아무 근거도 없는 “국정원-SEED” 레파토리는 이제 웃음거리일 뿐입니다.

  • http://openweb.or.kr youknowit

    그리고, ‘전자서명’을 위해서는 서버와 클라이언트가 대칭키를 공유할 필요가 없습니다.

    대칭키를 공유해야 하는 이유는 메시지를 SEED 대칭알고리즘으로 암호화/복호화하는 방법으로 ‘보안접속’을 구현하기 때문입니다(클리어 채널로 암호화된 메시지를 주고받는 방법).

    진작에 ‘전자서명’과 ‘보안접속’을 분리해서 구현했더라면 viz님께서 말씀하신 “매우 부끄러운 구현”을 하지 않아도 됐었겠지요.

    컴포넌트를 잘게 나누어, 각 컴포넌트 별로 설계, 개발하는 것은 유닉스, 리눅스 환경에서는 개발의 당연한 출발점이며, SOA에서도 기본 전제입니다. 그래서, 이것저것 혼자서 다하는 “짱뽕 플러그인”은 기술적으로 잘 납득이 가지 않으며, 후진 기술이라고 비난 받는 것 같습니다.

  • T. K.

    정말이지 이래서 끊임없이 공부가 필요한 모양입니다.

  • 우분투

    마우스 오른쪽 버튼을 누를 수 있다면 링크를 걸어줄 수 있으니 상관없지 않나요?

  • viz

    alankang, youknowit / ‘대안이 없다’ 는 서술 앞에 분명히 ‘현 ActiveX 체제 하에서는’ 이라는 한정하는 어구를 붙였습니다만…
    교수님이 제시하는대로 페이지 암호화를 SSL로 대치하고 공인인증만 플러그인을 쓰도록 하면 해결될 수 있는 문제이고 저도 그렇게 변화가 되길 바라고 있습니다. 위와 같은 웹사이트를 만들고 관리하는 실무자로서 북마크나 뒤로가기 버튼이 안되는 것은 정말 ‘부끄러운 일’ 이니까요.

    ps. 최근 몇몇 글에서 조금은 전문적인 시각에서 현 체제에도 장점이 전혀 없는 것은 아니다.. 라고 주장했더니 부끄러움을 호소하는 글도 심히 반박당하는군요 -_-

    ps2. 금융권 쪽에서 SSL을 통해 암호화 하는 방향으로 변화하기 위해서는 일단 SSL가속기를 사야하는 추가적인 부담 and/or 화려한 홈페이지를 전반적으로 수수하게 변경해야 하는 문제가 있습니다. 쇼핑몰의 경우 전체 사이트에서 ‘로그인’과 ‘결제정보 입력’ 등의 아주 일부분만 보안연결이 필요한 반면 금융권 사이트의 경우 거의 모든 부분이 보안연결이 필요합니다.

    ps3. SSL이 요구하는 연산비용은 만만한게 아닙니다. 우리 모두가 사랑하는 구글의 서비스만 하더라도 아주 최근까지는 (고의적으로) https으로 자동 redirection 해주지 않았습니다. 거의 모든 구글 서비스가 https를 지원하는데도 자동으로 https로 넘어가게 하지않고 처음부터 https로 들어온 경우에만 https로 사용할 수 있었죠.
    최근에 미국 어디 사막에 초대형 데이터 센터를 완공했다는 소식을 들은 후에야 gmail 부터 https redirection을 지원하기 시작하긴 했지만… 아무튼 실무적으로 SSL 부담이 됩니다.

  • http://openweb.or.kr youknowit

    저는 ‘현장’에 계시는, 그리고 정확한 기술 지식을 가지고 계시는 viz 님같은 분이 논의에 참여하시는 것을 진심으로 고맙게 생각하고 있습니다.

    누구를 면박주고, 논쟁에서 ‘이기고, 지고’하는 것은 오픈웹의 목표가 아닙니다.

    지난 10여년간 계속된 안타까운 사태로 ‘속골병’이 든 우리 환경을 최대한 신속히 개선해서, 선진적이고 국제 수준의 기술을 구비한 분들이 제대로 대접받는 개발 환경, 창의적 솔루션이 활발히 나올 수 있는 환경으로 만들기 위해서 모두가 노력하는 장소로 유지되었으면 하는 것이 제 바램입니다.

    플래시와 그림 파일로 구성한 페이지가 ‘화려하다’는 것도, 잘못된 전제이며, CSS기술을 제대로 구사하는 고급 기술자들의 입지를 계속 억압, 위축 시키는 구태의연한 발상이어서 안타깝게 생각하는 것입니다.

    그리고, 현재의 디자인 스타일이 심미적으로 어필한다는 선입견은, 기술적으로 훨씬 효율적이고 안전하며, 쉽게 확장 가능하며, 유연한 대안(ssl)의 도입을 가로막는, 기술을 모르는 경영진(비전문가)의 한심한 선입견이어서 저는 참 아쉽게 느끼고 있습니다.

  • gomibak

    viz님과 같은 전문적인 기술을 가진 분의 코멘트는 중요하다고 생각합니다. 다만, 서로의 전제가 다른 것을 가지고 비판할 수는 없겠지요. 서로 객관적인 기술적 부분에 대한 의견 개진은 충분히 귀담아 들을 필요가 있겠지요. 중요한 것은, 익숙하고 길들여진 것이 아니라, 오픈웹을 향해 갈 수 있는 기술 개발에 촛점을 맞추어야 하겠지요.

  • http://b.mytears.org/ 정태영

    viz// SSL이 요구하는 비용이 적지 않는 것은 사실이나 이 비용의 대부분은 암호화/복호화 부분에서 차지하는 것임을 생각하면, 플러그인 기반의 현 체제에서도 동일한 비용을 지불하고 있을 것입니다. 방식의 차이일 뿐 두 방식 모두 암호화 채널을 생성하고 있고, 암호화된 텍스트를 주고 받고 있으니까요.

    얼핏 읽으면 마치 SSL은 엄청난 연산이 요구되고 현재 사용되고 있는 방식들은 별다른 연산이 요구되지 않는 것처럼 느낄 수 있겠습니다.

    그리고 SSL을 사용하던 플러그인을 사용하던 외부 출력은 html 일텐데, 플러그인을 사용하지 않는다고 화려한 디자인에서 수수한 디자인으로 바뀌어야 한다는 것은 쉽게 동의할 수가 없네요.

    오히려 플러그인을 이용하여 html 을 뿌려주도록 복잡한 코드를 작성하는 것이 아니라 일반 plain html을 뿌려줄 때와 별다른 작업을 해줄 필요없이 그저 프로토콜만 https로 지정하면 되므로 구현에 있어 훨씬 간단해질 것 같은데 말이죠.

  • viz

    정태영/ 플러그인 기반 페이지 암호화를 사용하면 페이지 중 특정 영역만 암호화가 가능합니다. 같은 html 문서 안에서도 일부분은 암호화 해서 전송하고 나머지는 평문으로 보낼 수 있습니다.
    반면 SSL을 사용할 경우 html 문서나 이미지 등 http request/response 단위로 암호화가 되어야 할 뿐만 아니라 한 페이지를 이루는 모든 요소(html 문서, 이미지 등 임베딩 된 요소 등)가 SSL를 통해 암호화 되지 않으면 대부분의 브라우저에서 경고를 표시하게 됩니다. (디폴트 설정에서 크롬에서는 자물쇠 아이콘이 느낌표로 변하는 정도로 처리하지만 다른 메이저 브라우져에서는 경고 팝업이 뜹니다)
    현실적으로 이용자들에게 http와 https가 혼합되어 있다는 경고 문구를 보여줄 생각이 아니라면 이미지, 플래시 등을 포함한 페이지 전체를 SSL로 암호화 해야 하는데, 이건 민감한 부분(계좌 번호, 잔액, 주민번호 등등)만 암호화 하는 플러그인 기반에 비해서 확실히 많은 부하를 주게 됩니다.

  • Pingback: Blog of Hyeonseok

  • Pingback: Blog of Hyeonseok

  • 빛알

    작년에 이름만 대면 아는 이른바 한국 유수의 ‘보안 업체’ 관계자와 얘기를 나눈 적이 있습니다. 적어도 세션 암호화는 SSL로 해야 하지 않겠느냐고 했더니, 은행측이 SSL/TLS은 무겁게 여긴다고 하더군요. 무겁다?

    국민은행, 신한은행, 우리은행보다 훨씬 작은 미국 동네 은행도 다 SSL/TLS를 씁니다. 그런데, 왜 한국의 은행들은 못 쓰지요? 아, 규모가 훨씬 크니까 방문자 수도 훨씬 많다고요? 그만큼 네트웍/전산 관련 자원도 그만큼 큰 것 아닌가요?

    SSL/TLS를 쓰면 계산량/전송량이 현재 은행의 전산/네트웍의 용량을 넘어서거나 그 정도는 아니라도 여유 용량을 거의 제로로 만들 정도로 큰 것인지 실증적인 실험을 어느 누가 해 보았는지 궁금합니다. 추가 부하가 생기지 않는다는 얘기가 아니라, 과연 감당 못 할 비용이 드는지, 사용자가 불평할 정도 응답 속도를 느리게 하는지 등에 대해 ‘측정’을 해 보았느냐는 말입니다. (세션 키 교환을 위한 비대칭 암호 계산을 SSL/TLS 가속기에 맡겨서 세션당 한번 하고 나면, 실제 데이터 교환은 대칭 암호/복호법으로 합니다. 그게 과연 얼마나 부하를 증가시키는지 ‘측정’을 못 하면, 추산이라도 해 보아야 하지 않을까요?)

    미국 은행들에 비해 디자인이 화려해서 전송량이 많다고요? 정말 그런가요? 한국 쇼핑몰과 아마존을 비교하면 확실히 한국 쇼핑몰이 화려합니다. 그런데, 제가 지금까지 써 본 미국 은행 웹 사이트 (대여섯 곳 됩니다)와 한국 은행 웹 사이트 (두어 곳)을 비교하면 전송량이 그렇게 차이가 날 것 같지 않습니다.

    은행 웹 사이트에서 교환하는 정보가 별 것 있습니까? 한국 은행들이 뭐 정신이 나가지 않은 이상 계좌 조회하는데 그걸 모두 그림 파일로 바꿔서 전송하는 것도 아니고요. 오히려, 미국 은행들은 대부분 명세서를 PDF로 볼 수 있는 기능을 제공하니까 (우편으로 매월 명세서를 받는 대신), 오히려 전송량이 많을 수도 있을 것 같군요 (물론, 그 pdf 파일의 크기라야 얼마 되지 않지만요).

    네트웍 모니터링 도구로 한국의 은행과 미국의 은행에 접속해서 비슷한 일 – 이번 달 계좌 거래 명세 확인-을 하고 난 후, 전송량이 얼마나 되는지 한번 비교해 볼까요?

    참, 지금은 고쳤는지 모르지만, 몇 년 전까지만 해도 아무개 은행은 계좌 및 거래 명세를 평문으로 보내고 있더군요. 이미 viz님이 쓰신 대로, 웹 사이트 개발자가 “깜박”해서 그랬나 봅니다. 할 말이 없습니다.

  • Pingback: 인터넷 뱅킹과 SSL… 변명은 이제 그만… | 내 맘대로 보는 세상

  • http://b.mytears.org/ 정태영

    Viz// 위에서 얘기하셨던 내용들에 대한 포스트를 하나 작성했습니다. 위 트랙백을 한 번 읽어봐주셨음 좋겠네요. :)

  • http://b.mytears.org/ 정태영

    Viz// 윗 글에 달아주신 코멘트에 대한 답변을 추가로 기재했습니다. 간단히 얘기드리자면 https와 http의 쿠키는 공유되며 https에서의 hostname, uri 등은 ssl handshake 이후에 전송되기 때문에 중간에서 가로챈다고 하더라도 어떤 요청을 했는지를 알 수 있는 방법이 없습니다.