주말 출근해서 다시 DB를 살펴 봤다.
아니~ 이 녀석들이~!
뚫었다. 인증 시도 건수가 예전만큼 많아 진 것은 아니지만 분명 Bot이 돌면서 인증 시도를 계속 하고 있었다. DB 기록 봐서는 인증 건당 재 시도하는데 수분이 소요 되는 것으로 보였다.
터미널 접속해 로그를 확인해 봤다. 인증 시도와 Captcha 정보를 얻어 오는 것 까지는 정상적인 루틴을 보여 준다. 그 다음 Captcha의 내용 분석 하는데 시간이 걸리는 것 같다. 일치 여부 체크 하는 로그를 보면 얼토 당토 않은 값을 전달하는 시도가 많이 보인다. 아마도 그림 문자 해석기를 이용해 이 값을 뚫어 버리는 짓을 하는 것 같았다. 구글링 해 보니 음성 출력 소스를 클라우드로 넘겨 보안 문자를 뚫는 기술도 있다고 하는데 현 서버의 로그에선 음성 요청 하는 로그는 보이지 않아 이 방법은 아닌 것으로 판단 됐다.
그렇다면 이 Captcha의 난이도를 높이는 방법이 가장 빠르게 할 수 있는 방안이라 생각했다. 우선 배경이 WHITE Flat 이였는데 디자인 팀에 요청해 알록달록 이쁜 것으로 요청 했다. 글자 폰트 및 컬러도 몇 가지 더 추가 했다.
그리고 한 화면에서 Captcha 새로 생성하는 것과 문자 검증하는 횟수도 3회로 제한 했다. 이 정도면 3회 이상 시도할 경우 다시 창을 닫고 시도해야 하는 번거로움이 생길 것이다.
허나 이것만으로는 좀 불안 했다. 더 나은 방법은 없을까?
일반적인 사용자라면 정보를 입력 할 때 Input Layer에선 포커싱 이벤트와 Key 관련 이벤트가 발생 될 것이라 판단하고 그 값이 Bot일 경우 다른 형태로 존재 할 것이라 생각했다. 그래서 각 개인정보 입력 Input의 이벤트 함수에 발생되는 이벤트 시간 값을 마킹 하고 그 값들을 인증 요청 시 함께 전달 하는 것으로 방향을 잡았다.
Front 와 Back단에서 각 작업을 하고 개발 서버에서 테스트 진행했다.
“모두들 한번씩 인증 시도 해줘~”
다닥. 다닥. 키보드와 마우스의 소리가 귀엽게 났다. 로그에선 일정 시간 차가 적절하게 올라 왔다.
“자 이번엔 더 빠르게~ 최대한 빨리 인증 시도 해줘. 빠르게 하는거 실패 하면 창 닫고 다시 시도해 줘~ 자~ 고고고”
파파파파파팍팍팍팍. 키보드와 마우스의 부숴지는 소리가 요란스럽게 났다. 로그를 보니 아까 패턴과는 조금 더 시간차가 줄어든 값이 올라 왔다. 실제 사용자의 경우 더 빠른 사람들도 있을 테니 테스트에서 얻은 값 보다 0.5~1S 정도 더 줄여 Bot 여부 검증을 통과 하도록 작업을 했다. 이보다 더 빠르면 인간이 아닌 것이다.
만일 Bot일 경우 새로 추가된 사용 패턴에 대응 못했을 수도 있어서 새로 추가된 변수는 필수가 아닌 것으로 처리 했다. 만일 이 변수가 빈 값으로 전달 될 경우 100% Bot이라 확신 할 수 있는 근거가 되기 때문이다. 이 IP도 수집 할 수 있도록 DB 작업도 추가 됐다.
만일 저 Bot 여부를 통과 하지 못할 경우 고객 센터로 문의 달라는 에러 메시지도 추가 했다. 실제 사용자들한텐 어떤 결과가 나올 지 몰라서… ㅎㄷㄷ. 서비스 올리기 전 CS팀장을 찾아갔다.
“팀장님~ 저 이번에 새로 올릴 껀데 에러 메시지에 고객센터 문의 하라는 글이 추가 될 꺼에요. 혹시라도 인증 관련 CS 접수 되면 저한테 바로 콜 해 주세요~”
“네. 꼭 연락 드릴께요.”
CS팀장이나 나나 굳은 결의에 찬 표정을 지었다. 이번엔 잘 되리라! 믿으며.
서비스 막상 올리니까 겁나 빠른 사용자들이 나왔다. 헐… 이 시간에 어떻게 입력 하지? Bot의 시간보단 느린 값이라 분명 사람이 입력한 값이긴 했지만 너무 빠른 값이 였다. 뭔가 다른 버그가 있나?
퍼블리셔와 얘기 해 보고 다양하게 테스트를 진행 해 봤다. 입력 안하고 재빨리 Input란을 터치 터치 하며 옮기면 그 주기가 엄청 짧아 Bot으로 인식 할 수 있는 버그가 재현됐다. 퍼블리셔는 난감해 하고~ 나도 헐~ 당황해 했다. 게다가 FireFox의 경우 이벤트 처리가 달라 Script 함수 작업도 추가 됐다.
다시 서비스 반영 후 로그와 DB는 꽤나 안정화 된 수치를 보여 줬다. 물론 Bot이 계속 시도를 하는 것으로 보였다. 하지만 통과 비율은 현저히 줄어 들었다. 게다가 결정적으로 새로 추가된 변수에 대한 값이 없는 상태로 인증 시도 로그가 올라 오고 있었다. 바로 이것들, 확실한 Bot이다. 이 나쁜 요청 값을 가진 IP들은 차곡 차곡 DB에 쌓이고 있었다. 그리고 그들의 결과에는 거짓 값을 리턴해 줘 마치 정상인양 리턴을 주고 있었다. 디테일 하게 딜레이도 3~5초 정도 줬다.
DB는 완전 실 사용자 데이터로 채워 졌다. 아주 만족스럽도다.
정상이다.
잘 끝났군. 퇴근하자.
(하지만 어떻게 완전히 못 오게 막지?)
