인터넷 뱅킹과 SSL… 변명은 이제 그만…

얼마 전 Viz란 닉네임을 사용하시는 분이 OpenWeb의 ‘Frame: 웹페이지 주소 감추기‘란 글에 현 체제(ActiveX체제)가 갖는 장점에 대한 코멘트를 남기셨습니다. 대략 그 내용은 다음과 같은데요.

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

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

ps3. SSL이 요구하는 연산비용은 만만한게 아닙니다.

사실 SSL의 부하가 큰 것은 사실이나 ActiveX를 사용하건 https를 사용하건 암호화를 해야한다면 똑같은 부하가 걸릴 수 밖에 없습니다. 이에 대한 내용을 코멘트로 달았고, 아래와 같은 답변을 들을 수 있었습니다.

플러그인 기반 페이지 암호화를 사용하면 페이지 중 특정 영역만 암호화가 가능합니다. 같은 html 문서 안에서도 일부분은 암호화 해서 전송하고 나머지는 평문으로 보낼 수 있습니다.

반면 SSL을 사용할 경우 html 문서나 이미지 등 http request/response 단위로 암호화가 되어야 할 뿐만 아니라 한 페이지를 이루는 모든 요소(html 문서, 이미지 등 임베딩 된 요소 등)가 SSL를 통해 암호화 되지 않으면 대부분의 브라우저에서 경고를 표시하게 됩니다. (디폴트 설정에서 크롬에서는 자물쇠 아이콘이 느낌표로 변하는 정도로 처리하지만 다른 메이저 브라우져에서는 경고 팝업이 뜹니다)

현실적으로 이용자들에게 http와 https가 혼합되어 있다는 경고 문구를 보여줄 생각이 아니라면 이미지, 플래시 등을 포함한 페이지 전체를 SSL로 암호화 해야 하는데, 이건 민감한 부분(계좌 번호, 잔액, 주민번호 등등)만 암호화 하는 플러그인 기반에 비해서 확실히 많은 부하를 주게 됩니다.

뭐 듣고 보니 그럴 수도 있겠다는 생각이 들기는 합니다. 하지만 페이게이트 사의 결제 모듈과 관련된 작업을 하면서 보니 대안이 없는게 아니었습니다.

페이게이트 사의 결제 모듈은 PGIOForm이란 이름을 가지는 form과 javascript만으로 모든 결제가 이루어집니다. 처음에는 AJAX를 사용하는 걸꺼라 생각했지만 AJAX는 Cross site 간의 통신이 불가능하기 때문에 AJAX만으로는 이런 식으로 구현할 수가 없을 것 같았습니다. 그렇다면 어떤 방법을 사용했는지가 궁금해져서 직접 소스를 분석해보았습니다.

위 코드가 바로 cross site로 값을 넘겨주고 또 값을 넘겨받기 위한 코드인데요. 보면 동적으로 script 태그를 만들어서 스크립트를 삽입하는 것을 통해 타 사이트로 값을 전달하고 있습니다. 그리고 받아온 스크립트의 내용을 참고하게 되면 타 사이트로부터 값을 넘겨받을 수도 있죠. 이 기법을 ‘JSONP‘ 라고 한다고 하네요.

구지 민감한 데이타들에 대해서만 암호화를 하고 싶다면 JSONP를 활용하면 된다는 거죠. ActiveX를 사용하게 될 경우 암호화된 데이터를 받아서 javascript를 통해 복호화한 뒤 javascript를 이용하여 보여주게 됩니다. 어짜피 javascript를 이용해야 한다면 ActiveX를 사용하나 JSONP를 사용하나 구현의 복잡한 정도는 거기서 거기일 거라 생각되네요.

별로 중요하지 않은 이미지/플래쉬 등은 http를 통해 전송되고, 민감한 데이타들은 JSONP를 통해 https 프로토콜로 전해진다. 아주 간단하죠. Viz님이 말씀하신 ActiveX로 구현을 했을 때의 장점을 모두 가지고 있으면서 보안 프로그램의 라이센스까지 필요없어지겠습니다.

참고로 JSONP를 사용하게 되면 값을 GET 방식으로 보낸다고는 하지만 https의 인증서 교환은 URI를 요청하기 전에 이미 이루어지게 되므로 누가 중간에 패킷을 가로챈다고 하더라도 어떤 URI를 요청했는지는 알 수 있는 방법이 없습니다.

Published by

2 thoughts on “인터넷 뱅킹과 SSL… 변명은 이제 그만…”

  1. 흥미로운 내용이네요.

    제가 javascript쪽은 전문이 아니라 잘은 모르겠지만 cross-site request 문제를 피하는 방법 중 하나인듯 하군요.

    그래도 좀 납득이 안되는 것은 SSL 요청 자체야 암호화 되겠지만 SSL 요청에 필요한 정보는 어차피 평문으로 가니까… JSONP 자체가 아니라 JSONP를 포함하는 html 문서가 중간에 노출되면 문제가 생길 수 밖에 없지 않는지요?
    http 하고 https 하고 쿠키가 공유되는 것도 아니고 어차피 https로 보낼 url + query string 값이 원래 http 문서에 딱 박혀 있는데 그거 가로채서 서버에 보내면 민감한 정보를 다 볼 수 있겠지요.

    뭐 서버단에서 IP 보고 같은 IP 에서 오면 허락하고 아니면 말고.. 할 수 도 있겠지만 이건 또 타임아웃은 어찌 할 것이냐.. 등등의 문제가 있을듯.

    위의 결제 모듈을 보면 저 방법으로 민감한 결제 정보는 “보내는 것”은 가능할 지 몰라도 “얻어오는 것”은 불가능할 듯 하네요.

    아무튼 보안 관련해서 새로운 걸 알게 되는 기회가 되었습니다. 감사드려요.

    뭐 제 생각에는 플래시 플레이어의 allowdomain/allowsecuredomain 처럼 xsr 예외를 명시하는 방법이 있는게 이쪽 이슈의 해결 방법이라고 생각하는데, 브라우져는 플래시처럼 한 회사가 독점하는게 아니니까 쉽게 되진 않겠군요. -_-

    1. SSL 요청에 필요한 정보는 평문으로 가지 않습니다. HTTPS에서 uri나 hostname 등은 SSL handshaking이 모두 끝난 후에 보내지거든요. 그런 이유로 https virtual hosting에는 애로사항이 많죠. 호스트 이름 별로 다른 인증서를 사용하고 싶어도 핸드쉐이킹이 모두 끝난 이후에 hostname이 전해지다보니… -_-a

      그리고 호스트네임이 같을 경우 http와 https의 쿠키는 공유됩니다.

      세션 쿠키만 공유되도 필요한 정보를 요청하는데 아무 문제가 없습니다. URL을 알아봐야 제대로된 세션 정보 없이는 필요한 정보를 얻을 수 없을테니까요.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">