어제 KT의 고객 정보 유출 사고의 내용을 보면, 웹 개발 시 서버 유효성 확인이 얼마나 중요한가를 다시 한번 깨닫게 합니다. 예전에 제가 블로그에서도 한번 지적한 바 있는데, 프론트엔드 개발
방식이 확대됨에 따라 상대적으로 서버 유효성 확인을 등한시 하는 개발자들이 늘어 나고 있습니다.
“웹 개발의 가장 중요한 불문율 중에 하나가 프론트 엔드, 즉 UI 영역에서 유효성 확인(Validation)을 믿지 말라는 것이다. 사용자 데이터 유효성 확인은 꼭 백엔드 프로그램에서 이루어져야 한다. 이는 보안 취약성을 제거해 줄 뿐만 아니라 견고한 웹 프로그래밍의 기초가 되는 사실이다. ”
– 출처: http://blog.creation.net/359
KT 유출 사고 역시 서버 유효성 없이 고객 정보를 JSON으로 내려주고 그걸 모든 웹애플리케이션이 이용하다 벌어진 사고로 간단히 웹 브라우저 개발 도구만 사용할 줄 알아도 금방 취약성을 확인할 수 있는 것입니다.
1. 고객정보에 해당하는 9자리 코드에 대한 적합성 검증 절차 부재
– 사용자의 식별자에 해당하는 파라미터를 변조하였을때, 변조된 데이터에 대한 검증이 (서버단에서) 이루어지지 않음
– 예) http://my2.olleh.com/main.jsp?myollehUrlCd=xxxxxxxxx
위 파라미터만 랜덤하게 변경하여 무작위 대입을 한 후 서버에 요청
2. 사용자에게 제공하지 않는 정보까지 Ajax를 이용하여 전송한 후 일부 데이터만 화면에 뿌려짐
– KT의 경우 브라우저에 보여줄 필요가 없는 데이터까지 AJAX Data로 전송
– 주민등록번호, 카드사 정보, 카드 유효기간, 은행계좌정보, 이전 통신사 이력, 개통정보, 할부정보등 대부분의 고객 데이터 포함
사실 웹 개발자들의 업무의 70%는 새로운 로직을 개발하는게 아니라, 오류 처리/유효성 확인에 있다고 해도 과언이 아닐 정도로 중요한 일입니다.
조금만 파라미터를 바꾸거나 null 값을 넣어도 유효성 없이 처리하는 로직을 짜는 개발자는 정말 경멸할 정도… 특히나, Ajax를 기반한 데이터 API를 내려 줄 때는, 각 method와 parameter에 따라 적절한 동작을 해야 함에도 편의를 위해 고객 정보를 다 내리는 건 API 설계에 개념이 없는 것이죠.
구현에만 집중할 게 아니라 사용자(혹은 해커)의 모든 액션에 대한 경우에 대한 대비를 하는 사고 훈련을 게을리 하지 말아야 할 것입니다.
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)