결제 시스템의 이야기

이게 과연 Programming 분류에 들어가야 하나 싶지만. 아무튼.

웹은 그 태생의 한계 때문에 여러 시스템을 구현할때 다양한 편법이 이용되어진다. 처음에는 편법이었지만 시간이 지나갈수록 당연시 되어지고 그 헛점 조차 그 편리함에 덮혀지는 뭐 그런..

방금전에 뉴스 사이트를 보다가 이러한 기사를 보았다.

http://news.naver.com/news/read.php?mode=LSS2D&office_id=032&article_id=0000203799&section_id=102&section_id2=249&menu_id=102

대략 요약하자면 인터넷 쇼핑몰에서 별도의 결제 사이트를 연동하여 결제할때 주고 받는 통신을 위조해서 적은 금액으로 물건을 구매 하는 행위에 대한 이야기다.

이거를 처음 발견했던건 3년쯤 전이었다.

보통 대형 쇼핑몰이 아닌 일반 쇼핑몰들의 결제 시스템은 결제 대행 서비스를 이용한다. 또한 결제 대행 서비스 업체들은 자체 보안 때문에 쇼핑몰 서버에 별도의 모듈을 제공하는게 아닌 본인들이 제공하는 특정 페이지를 연결해서 관련 정보를 받아서 처리하고 해당 결과를 쇼핑몰 호스트로 다시 넘겨주는 작동 방식을 가진다.

이 문제는 결국 쇼핑몰의 결제 시스템은 결제 여부를 대행 업체의 결제 시스템에 의존하게 된다는거다. 두 호스트는 물리적으로 연결 되어 있지만 단일 랜 선이 아닌 인터넷을 넘나드는 공개된 패킷에 의해서 주고 받게 된다.

이는 쇼핑몰 솔루션의 호환성과도 직접적 관계가 있기 때문에 일반적으로 (지금은 어떨지 모르겠지만) GET, POST 와 같은 단순 전송 방식을 사용한다. 차라리 서비스나 데몬이 돌면서 TCP/IP 를 통한 직접 통신이면 나을지도.

아무튼, 그러한 통신은 결국 한번이라도 그러한 시스템을 구축해보거나 시스템 구조를 아는 사람에게는 허약하지 그지없다.

대표적이로 두가지 취약점이 여기서 들어난다.

1. 쇼핑몰에서 대행 업체로 보내는 결제 조건 정보. 즉, 금액과 결제 방식 등의 정보의 공개 문제
2. 대행 업체에서 결제 완료후에 쇼핑몰로 결과를 전송할떄의 문제

이 두가지 문제는 모두 사용자(클라이언트. 여기서는 브라우저)를 거친다는것에 있다.

이중에 제일 쉽게 접근이 가능한 첫번째 문제는 매번 우리가 결제할때 쇼핑몰에서 결제 정보를 브라우져에 특정 URL에 특정 파라미터(위의 결제 정보)를 가지고 열도록 명령하고 그 정보는 사용자 브라우저에 그대로 남은 상태로 해당 페이지로 가게 되는거다.

즉, 해당 페이지를 열때 넘어오는 파라미터를 변경하면 결국 그 파라미터대로 페이지가 열리게되고 이는 위의 기사에서 나온 것 처럼 금액의 변경으로 쉽게 이어진다. 결국 대행 업체의 솔루션은 받은 금액 그대로 (변경 여부는 알 수 없으므로) 결제를 하게 되고 그 결과를 쇼핑 솔루션에 통보 하게 되는거다.

여기서 결국 쇼핑몰 솔루션을 개발한 사람의 완벽성에 영향을 받게 되는데 어지간한 대행 업체는 결과를 보낼때 대략 요청한 결제 번호 (주문 인덱스 넘버와 같은 인덱스 넘버), 금액, 결제 정보 등을 넘겨준다.

결국 이곳에서 결제 번호(인덱스)만으로 결제 여부를 처리 해버리면 백만원짜리를 만원을 결제 했든, 십만원을 결제 했든 해당 주문번호의 결제 여부는 처리가 되어 버리고 완료 처리가 되어 버릴것이다.

이것 저것 크로스 체크를 하는 개발자라면 돌아온 결제 정보의 금액까지 확인 해서 크로스 해야 할 것이고 2번의 문제 역시 막기 위해서 해당 정보를 전송한 호스트의 주소 역시 크로스 체크 해야 한다. 물론 이것도 작정을 하고 스누핑 한다면 대책이 없겠지만 -_-

어쨌든 가급적 결제 시스템과 같은 예민한 시스템은 클라이언트에서는 입력만 받고 모든 전송 및 처리는 호스트에서 처리 하는게 제일 안정적이다.

쩝.

저 기사를 보니까 그때 내가 테스트 했던 10곳의 쇼핑몰중에 저 방법이 통하지 않았던 곳은 단 두곳밖에 없었다는 기억이 다시 새록 떠 오른다.

난 차마 지르지는 못했는데 ...