CRIZIN+

좀 극단적인 생각이지만 웹사이트를 오픈할때마다 사전에 어떤 기관으로부터 검사를 받고 허가받은 사이트만 운영할 수 있도록 하면 좋겠다는 생각을 했었다. 건물을 지을때 그 곳을 이용하는 사람들의 안전을 위해 안전점검을 받는 것 처럼 웹사이트를 이용하는 사람들을 위해 이 사이트가 최소한의 안전장치를 갖추고 있는지 미리 점검을 하는 것이다.

구글에서 뻘짓을 하다보면 한심한 광경을 많이 보게 되는데, 대표적인 사례가 회원 정보 조회 같은 관리자 페이지를 누구나 볼 수 있게 오픈해 놓은 사이트들이다. 개개의 페이지들에 인증을 요구하는 코드가 들어있지 않은 경우도 있고 단순히 '로그인 하세요' 라고 경고창만 띄우고 이전 페이지로 돌려보내는데 브라우저에서 자바스크립트만 꺼두면 관리자페이지를 볼 수 있는 경우도 있다. 우연찮게 눈에 띄는 것도 심심치 않으니 작정하고 찾으면 꽤 많을 거라고 생각한다.

위의 얘기는 그야말로 기초적인 내용이고 실력이 모자란 소규모 에이전시의 난립으로 보안에 취약한 웹사이트들이 양산되는게 문제다. 자기네들 데이터 깨지는거야 내가 상관할바 아니지만 나의 정보를 다루고 있으면서 그에 걸맞는 보호를 해주지 못하니 계정이 하나씩 늘때마다 점점 녹아가는 늦겨울 살얼음판을 걷는 기분이랄까.. 특히 네이버에 수십만원짜리 광고 올려놓고 몇달 운영하다 문닫는 성인사이트 같은 경우는 하나에서 열까지 구멍이 숭숭 뚫린데가 태반이라 웬만하면 개인정보를 남기지 않는 편이 좋다. 그냥 프루나에서 다운받아 즐기는게 여러모로 좋..

그리고 가장 열받는건 비밀번호를 암호화 하지 않고 저장하는 경우인데 이런애들은 잡아다 벌좀 줬으면 좋겠다. 사이트 관리자도 인간인데 내가 뭘 믿고 그 사람에게 비밀번호를 맡기겠나.. 안쓰면 그만이라지만 메이저 사이트라는 싸이월드 조차도 이따위로 개인정보를 관리하고 있는 마당에 마음에 안든다고 안쓰고 살기란 불가능 한 것 같다. 그렇다고 사이트마다 비밀번호를 따로 관리하는건 나에겐 능력밖의 일이다 -_-

어제 뉴스에서 하루종일 도용당한 개인정보로 리니지에 가입당한 사람이 많다는 얘기가 나오길래 죄없이 이미지 무지하게 깎이겠구나 생각했는데 아니나 다를까 리니지가 독박쓰는 분위기라 안타깝다. (제일 나쁜놈은 개인정보 관리 못한, 혹은 빼돌린 ㅅㅂㄹㅁ이거늘..)

이쯤에서 구글에서 주민번호 검색한번 해주고 '한 검색업체의 검색사이트에서 개인의 신상정보가 무더기로 검색되고있어 논란이 되고있습니다' 하고 뉴스를 때려줄법한데 몇번 재탕해먹은 소재라 식상하고.. '내가 이걸 몇번이나 보도했는데 아직도 검색사이트에 개인정보가 노출될 정도로 개념없는 사이트가 졸라게 많답니다' 정도의 기사 한번 때려주면 좋겠다.

관련글 : [보안]웹 어플리케이션 해킹 (Web Application Hacking)에 대비한 프로그램 코딩법

이 주제에대해 겉핥기 식으로나마 한번쯤 적어보고 싶었는데 마침 좋은 게시물을 발견해서 날림 포스팅 해본다. 초보에서 프로에 이르기까지 이런쪽에 신경쓰지 않는 사람이 의외로 많다. 개인적으로는 시청에 공익근무요원으로 일하면서 본 담당 개발업체의 막무가내식 보안개념이나 인터넷의 많은 결제 대행 서비스들 중 몇몇 서비스에 허점에 꽤 충격이었다고나 할까. 위의 글에 관련해서 시시콜콜한 얘기 몇자 적어보려고 한다. 본의아니게 안산시청 개발업체 까는 얘기가 많이 포함됐는데.. 미안하다, 내가 니들한테 좀 맺힌게 많다;;

예측 불가능한 파라미터

특히나 웹 어플리케이션에서 정해진 파라미터만 입력받기를 기대하는건 사람을 100% 믿는 것만큼이나 어리석다. 게시판 따위에서 페이지 변수에 이상한 값을 넘겨준다고 해봤자 고작 warning 메세지 출력되고 사이트가 이상한 모습을 보여주는 정도겠지만 로그인 처리같은 중요한 부분에서는 최소한 이게 로그인에 필요한 문자로 이루어진 문자와 유효한 길이인지 등등 로그인 처리 이전에 입력값에 대한 유효성 검사를 해줄 필요가 있다.

대표적으로 로그인 파라미터에 SQL 쿼리를 삽입해서 로그인 되는걸로 위장하는 수법을 들 수 있는데 이미 한물 간데다 유치하기까지 한 기술이지만 아직도 먹히는 곳이 꽤 된다. 간단히 설명하면 비밀번호 넣는 곳에 a' OR 1=1 OR 'a 따위의 문자열을 집어넣어 SELECT ... FROM ... WHERE pass='$password' 문장이 패스워드와 상관없이 무조건 참이되게 하는건데 입력받는 값에 유효하지 않은 문자 체크를 생략하거나 쿼리문을 멍청하게 짜면 저런 트릭에도 쉽게 무너지게 된다. 실제로 안산시청 민원게시판의 비밀번호 시스템은 아직도 이런게 통한다. 더 문제가 되는건 그냥 대충 때워막기에 급급하다는건데, 새 홈페이지 런칭 직후에 메인 로그인창에 작은따옴표가 입력돼 SQL 오류를 내고 죽어버리는 문제를 지적하자 로그인창에 자바스크립트로(-_-) 작은따옴표 입력을 막아놓은 뒤 작업 끝이라고 유지보수비만 받아갔던 적이 있다. 나머지 수많은 입력 폼들은 차마 체크할 엄두가 나지 않았었나보다.

어려울수록 고급기술?

역시 안산시청 민원실을 예로들면 불과 얼마전까지는 게시물 본문을 뿌려주는 모듈에서 비밀번호 체크하는 부분이 아예 없었다. 게시물 목록 -> 비밀번호 확인 -> 게시물 조회 이런 스텝이라 바로 게시물 번호를 넣어 게시물 조회 프로그램에 접근하면 그냥 조회가 가능했다. 이 문제를 지적하면서 게시물 조회 모듈 안에 비밀번호 확인 단계를 넣을꺼라 예상했지만 웅진 씽크빅만 풀면서 자랐는지 아주 그냥 창의력 대장이다. 이들의 해결책은 비밀번호 확인 스텝에서 비밀번호가 맞으면 세션에 비밀번호를 집어넣은 후 게시물 조회 프로그램에서 세션에 들어있는 비밀번호와 실제 비밀번호를 다시한번 비교해서 게시물을 보여준다. 한번으로 될걸 두번으로 나눈건 기존의 UI를 유지하기 위함이라고 추측되지만 이렇게 꼬인 방법은 어딘가에 허점이 있기 마련이다. 이 비밀번호 확인 단계에도 1번 항목에서 언급했던 부적절한 입력값 트릭이 먹히는데 여기서 세션에 특정한 값을 심어놨을 경우 마찬가지로 조회 프로그램의 비밀번호 확인 루틴이 무용지물이 될 수도 있다. 관련글에도 있는 말이지만 가장 간단한 보안이 가장 효과적일 수도 있다.

사용자는 착하지 않아요

언젠가 한번은 시청 보안 감사때 게시판에 스크립트 삽입이 가능하다는 점이 지적되자 개발자를 불러 게시판에 태그 입력이 불가능 하도록 htmlspecialchars 처리를 부탁했는데 이 양반이 한 짓이라는게 게시판 글쓰기 화면에서 HTML 태그 사용 체크박스 부분을 주석으로 묶어놓은 것 뿐이다. 과연 이걸로 된 것인가? 또 다른 예로, 얼마 전까지의 민원게시판의 실명인증 시스템은 팝업창에서 실명인증 절차를 거치면 글쓰기 페이지의 hidden value에 인증이 완료됐다는 값이 세팅되고 폼 내용을 전송할때 자바스크립트로 확인하는 것 뿐이었다. 정말 이걸로 된 것인가?

사용자를 신뢰할 수 있는 소규모의 인트라넷 같은데라면 이해가 될법 하지만 public한 사이트에서 저런식의 땜질은 곤란하다. HTML 본문을 조작해서 태그를 포함해 글을 쓰고 스크립트 한줄로 실명인증이 완료됐다고 위장하는건 기술적으로 그리 어려운 일이 아니다. 사이트를 운영하다보면 비정상적인 개발자가 예측하지 못한 방법으로 어플리케이션에 접근하는 사람이 최소한 한명쯤은 있을테고 그 한명은 반드시 전문가다. 유효성 검사를 자바스크립트에 맡긴다는건 사용자의 양심에 맡긴다는 얘기와 같다. 외국 사이트들의 가입폼들을 보면 대개 SUMIT 버튼을 누른 후에 서버에서 유효성 검사를 한 뒤에 틀린 부분에 표시를 해서 다시 입력받게 하는 방법을 많이 쓰는 것 같다. 우리나라는 SUBMIT 버튼 누르기 이전에 자바스크립트로 유효성 검사를 하고 DB에 정보를 넣는 과정에서 한번 더 검사를 하게되는데 이 한번 더를 생략하는 경우가 의외로 많다. 다시한번 강조 하지만 스크립트는 사용자가 얼마든지 뜯어고칠 수 있다.

형편없는 결제대행 서비스들

이 얘기는 언젠가 자료를 정리해 한번 포스팅할 예정이었는데 간단히 훑어만 보자면, 흔히 쇼핑몰등 에서 많이 이용하는 PG업체들 중 상당수가 사용자의 부적절한 접근에 무방비로 노출돼 있는 상태다. 정말 규모가 꽤 된다 싶은 업체도 포함돼있는데 몇년씩이나 이런식으로 방치해두고 있다는게 신기할 따름이다.

인터넷상의 결제라는건 대개 이런식으로 흐른다.

1. 사용자가 결제 금액등의 정보를 입력하고 결제버튼을 누른다
2. PG사의 결제페이지가 팝업으로 뜬다
3. 카드번호, 계좌번호 등을 입력하고 결제가 성공한다
4. 팝업창에서 부모창으로 결제가 성공됐다는 값을 전송한다
5. 부모창에선 이 값을 판단해서 결제 과정을 완료한다

일단 가장 위험한건 5번 과정이다. 결국 결제 성공 메세지라는건 사용자의 컴퓨터에서 쇼핑몰로 전송하는건데 이걸 꼭 결제 프로그램을 통해서 전송하라는 법은 없다. 사용자가 HTML로 대충 폼 만들고 그 안에 필요한 값들을 세팅해서 전송해주면 결제 완료 페이지에서는 이를 결제 성공으로 받아들인다. 이 결제 성공값의 전송을 사용자->쇼핑몰이 아닌 사용자->PG사->쇼핑몰 전송으로 바꾸면 해결이 가능한 문제지만 무슨 이유인지 다들 그렇게 하지 않는다. 좀 신경썼다 하는 업체도 고작 체크섬을 같이 전송해 확인 하도록 하는건데 어차피 해쉬될 값들이 다 예측 가능한 관계로 소용없는 짓이다. 이 값들은 PG사에서 제공하는 매뉴얼에 상세하게 적혀있어서 사용자가 결제 완료 코드를 작성하는건 매우 쉽다. 개발자에게만 제공돼야할 매뉴얼이 버젓이 홈페이지에 공개돼있는 것도 좀 문제다.

1번에서 2번 과정으로 넘어가는 부분도 치명적이다. 그렇지 않은 곳도 있지만 대부분은 이 페이지에서 최종 결제처리 페이지를 파라미터로 넘겨주게 된다. 말하자면 크래커가 공격해야 할 페이지를 친절하게 안내해주는 셈이다. 이제 이 페이지에 결제 성공 메세지가 뜰때까지 이값 저값을 넣어보기만 하면 된다. 물론 어떤 값을 넣어야 하는지에 대한 매뉴얼은 PG사에서 제공해준다.

이런상황에서 2, 3번 과정에 키보드 보안, 암호화, 방화벽 따위를 ActiveX로 쳐바르고 보안 우수기업이라니 웃긴 노릇이다. 충분히 막을 수 있는걸 왜 안막는건지 도무지 모르겠다. PG사에서 기본으로 제공하는 결제연동 예제는 비정상적인 접근 등을 차단하는 루틴이 거의 없다시피한데 쇼핑몰 개발자들은 그걸 그대로 가져다 쓰는 경우가 많다.

예전에 쇼핑몰 개발할때 T모 업체와 계약을 맺고 예제코드를 돌려보면서 정말 의아하게 생각했던게 사용자의 비정상적인 접근에 대비한 코드가 한줄도 들어있지 않다는 거였다. 경험이 없을때라 다른데는 이런걸 어떻게 막는가 궁금해서 찾아보니 쇼핑몰이 입주해있던 호스팅 업체가 마침 같은 T사의 PG 서비스를 쓰고 있었다. 여긴 어떻게 해놨을까 기대하면서 조작된 값을 넘겨봤더니 '결제가 성공했습니다' 란다(-_-). PG사에게 이런 문제가 있는데 해결방법이 없느냐고 물어봤더니 팝업방식이 아닌 소켓 통신을 할 수 있는 모듈을 보내줬다. 이렇게 하면 결제 완료 페이지 주소가 노출될 염려도 없고 전송되는 값이 사용자의 컴퓨터에서 전송되는게 아니라 PG사에서 소켓으로 직접 쏴주는거니 발신지를 확인할 수 있다. 프로그래밍이 다소 부담스럽지만 취약점의 상당부분이 개선되는 방법인데 그나마 이렇게 직접 물어보지 않으면 있는줄도 모르는 상황이다. 지금은 몇몇 PG사에서 이런 소켓 통신을 이용한 방법을 같이 제공하고 있으니 그나마 다행이지만 아직도 많은 개발자들이 약간의 귀찮음으로 팝업방식을 선호하고 있는 것 같아 안타깝다.

횡설수설해서 끝맺기가 좀 힘들게 됐는데..;; 아무튼 중요한건 프로그램이 처할 수 있는 모든 환경을 고려해야 한다는 점이다. 이상한 파라미터가 들어오거나 프로그램 실행이 중단되거나 파일 오픈이 실패하는 등의 일은 반드시 발생한다. 에러가 나도 상관없는 부분이라고 무신경하게 작성하면 어떤식으로 역이용 당할지 모르는 일이다. 모두들 조심!