1. 쇼핑몰에서 웹클라이언트에게 가격 정보(A)를 넘겨 줌.2. 웹클라이언트(고객컴퓨터)는 구매를 클릭할 경우 1번에서 받은 가격 정보를 PG사에 넘겨 줌(B).
쇼핑몰을 해킹해서 가격을 마음대로 조작한 겁니다.
경찰은 16개월간 2억 7000만 원을 챙긴 이씨를 사기 혐의로 구속하고, 웹페이지에서 공개되는 결제소스에 대한 보안을 강화할 것을 관련 업계에 통보했습니다.
http://news.kbs.co.kr/society/2012/04/19/2464858.html
경찰은 인터넷 쇼핑몰 결제시스템이 암호화돼 있지 않아 해킹될 우려가 높다면서 근본적인 보안 대책을 세워야 한다고 지적했습니다.
기사들을 보고 있노라니, 암호화해야 한다고 나오는데, 암호화는 근본적인 해결 방안이 아닌 것 같습니다. 이번 사건은 Application Layer에서의 문제이지 Network Layer에서는 문제가 아니기 때문입니다.
이왕이면 다홍치마라고 암호화를 도입해야 하는 것도 당연한 얘기이지만, 원래 암호화라는 것은 나와 상대방과의 통신을 제 3자에게 노출되지 않도록 하는 것이 주 목적인데, 이번 해킹에서는 자신에게 수신되는 내용을 자기 자신 스스로가 바꿔 버리려고 하기 때문이죠. 네트워크 단에서 암호화를 잘 했다 하더라도 최종적으로 자신에게 수신되는 HTML or Java Scipt 컨텐츠를 해커가 의도적으로 바꾸려고 하는 행위는 암호화를 잘 했다 하더라도 무용지물이라는 것.
쉽게 말해서 암호화가 아무리 잘 되어 있다 하더라도(편지 내용을 봉투로 싸서 다른 사람에게 보이지 않게 하더라도) 최종적으로 자신에게 편지가 도달했을 때에는 봉투는 뜯어 지게 되어 있고, 그 평문은 드러날 수 밖에 없는 셈. 나에게 수신된 내용을 내가 보겠다는데 누가 딴지를 갈 수가 있을까요? ^^
C : 클라이언트(고객 or 해커)
S : 쇼핑몰
P : PG사
1. S는 C에게 제품 및 가결 정보를 알려 준다.
2. C는 구매을 원할 경우 P에서 결제를 한다.
3. C가 P에서 결제를 했다고 S에게 알려 준다.
4. S는 C가 결제했다는 정보를 P에게 물어 보고 가격 조작이 있었는지를 검증한다.
4번 과정을 거치면 되겠군요. PG사는 이러한 Interface를 쇼핑몰에게 제공해야 하고, 쇼핑몰은 그 Interface를 이용하면 되겠네요.
결국 쇼핑몰에서 자신들이 가지고 있는 가격과 실제 PG사에 결제된 가격을 비교를 하여 그 값이 다르다면 결제를 취소시키면 되니까요.