....

브라우져에서 오는 파라매터를 너무 믿지좀 맙시다... 본문

JAVA

브라우져에서 오는 파라매터를 너무 믿지좀 맙시다...

idkook 2009. 5. 27. 12:22

이전부터도 물론 중요한 사항이였지만...
이번에 IE8에서 개발자툴을 기본으로 지원하면서 특히 파라매터 위조와 관련해서 더욱 문제가 공론화 되가고 있는것 같다.

실제로 클라이언트에서 전송되어온 값을 그대로 믿고 받아들이는건 말도 안되는거지만...
의외로 그렇게 구성된 사이트가 정말 많다는데 적잖히 놀라고 있기도 하다...

대표적인 예를 들어서 회원가입...

보통 실명인증엔진을 탑재한 페이지의 경우... 실명인증으로 우선 이름과 주민번호(혹은 대체수단)을 받는다.
이 경우 실명인증에서 제공하는 Javascript암호화를 이용해서 이름과 주민번호를 다른 Form에 암호화해서 넣어서 서버로 발송한다.

그런데... 열심히 암호화해서 발송하면서.. 이름과 주민번호를 또 평문으로 같이 발송하는 사이트가 있다..

더욱 미치는건... 그걸 그다음 상세회원정보 입력화면의 form에 hidden으로 다시 재발송하는거다..
hidden으로 하면 안보인다고 생각하는건가....

그리고 다시 또 평문으로 서버에 전송한다..... 뭐하러 암호화 한거냐.... 세션은 뒀다 국 끓여 먹을라고 하는거냐....

코드를 뜯어보면.. Struts의 Form에 매핑을 걸기 위해서나 혹은 프레임워크의 Form매핑 기반에 맞추기 위해서 어거지로 브라우져와 중요한 정보를 주거니 받거니 하는 흐름을 만든게 뻔히 보인다....

여기서 한술 더 떠서....  회원상세정보에 hidden으로 보낸 주민번호를... 다시 서버에서 받아들일때 아무런 검사도 하지 않는다...
진짜 hidden의 value는 바꿀 수 없다고 생각하는건가... readonly속성은 바꿀 수 없다고 생각하는건가...
(설마 진짜로 바꿀 수 없다고 생각 하는 사람은 IE8에서는 당장 F12키를.. Firefox에서는 firebug를 한번 실행해보면 안다...)

더 미치고 팔짝 뛰는 사이트도 봤다... SQL Injection을 차단하겠다고 Javascript의 정규식으로 특수 문자를 제거하고 조치를 완료했다고 한다..... Javascript가 도대체 어디에서 실행되는거라고 생각하는건지...

나도 실력이 뛰어나진 않지만... 저런 사이트는 진짜 1분만에 뚫어버리거나 장난질하기 딱 좋은 사이트다...

개발자가 기본적으로 알아야 할 서버-클라이언트 구조조차 이해하지 못하고 페이지만 푹푹 찍어대는 현실의 폐해라고 해야 할까...

물론 Javascript를 이용해서 입력값을 제한하는(주민번호에 한글, 영문같은 잡다리 기호가 못들어오게 하는등..)게 않좋다는게 아니다..
이런 부분은 서버와의 통신횟수를 줄여주면서 사용자가 빠르게 정규화된 입력을 할 수 있도록 유도해주는 역활을 한다.
하지만... Javascript는 거들뿐... 을 명심하자..

위와 같이 실명인증 후에 다시 상세정보에 중요한 정보를 hidden으로 재전송하는 사이트는..
이 시점에서 파라매터를 휘딱 바꿔서 인증받은 다음의 중요정보를 마음대로 지지고 볶아 먹을 수 있다는 사실...
(실제로 내 주민번호 까기 싫어서 몇몇 사이트는 그렇게 가입되어 있기도 하다..)

Javascript로 정규화 하고 또 서버에서 Validator를 만드는게 일 두번 하는거라고 생각하고 하기 싫다면... 차라리 Javascript를 포기하고 서버에서 Validator를 돌려야 한다는걸 좀 제발 알았음 싶다..

(그건 그렇고 지금 뜯어고치고 있는 사이트.. 만든 개발자 누군지 진짜 궁금하다...)
Comments