참고로 @codinghorror 크롬 팀은 여전히 아무 조치도 취하지 않았습니다.
크롬에서의 문제는 여전히 해결되지 않았으며, 스팸 방지용 허니팟을 일종의 작업 증명(Proof of Work) 방식으로 교체하면 간단히 해결할 수 있습니다.
2개월 더 닫아두겠습니다.
Chrome 팀은 이 문제를 수정하는 데 관심이 많은 것 같지만, 여기에 로그가 필요합니다:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
내일 모을 수 있는지 확인해 보겠습니다. 제가 먼저 하기 전에 누군가 해 주신다면 정말 감사하겠습니다. 이 게시물을 표시해 주세요.
수정 … 로그를 보냈습니다.
@codinghorror 이 문제는 구글에서 계속 반복되고 있습니다. 그들은 이 동작이 의도된 것이며, textarea가 보이는지 여부를 정확히 감지할 수 있는 방법이 없다고 합니다.
여기서 흔히 듣는 반응은 "봇이 이걸 우회하는 건 너무 쉬우니, 그러면 뭐가 중요하다는 건지"라는 것입니다. 솔직히 저도 딱히 반박할 말이 없습니다. 사실 그들도 동의하는 것 같고, 허니팟은 좀 어리석은 방법이라고 생각합니다. 대신 사용자가 계정을 등록할 때 최소한 JavaScript를 실행하고 있는지 확인하기 위해 다른 방식으로 쉽게 대체할 수 있습니다.
이 문제로 이미 너무 많은 시간을 낭비했고, 바람개비와 싸우는 기분이 듭니다. 그냥 수정 사항을 적용하고 넘어가고 싶습니다.
알겠습니다. 하지만 꽤 복잡한 작업증명(Proof of Work)을 원합니다. 가져다 쓸 수 있는 기존 코드가 있을까요?
네, 뭔가 만들어 볼 수 있을 것 같아요. 현재 시스템보다는 확실히 나을 거예요. 지금 우리가 쓰는 ‘작업 증명’ 시스템은 '문자열 뒤집기’거든요.
이 문제에 대해 너무 많은 시간을 보냈기 때문에 이제 마무리를 짓기로 결정했습니다:
해당 커밋에 따라 여기의 OP(원래 게시물)는 "수정"되었습니다.
수정 내용은 다소 복잡하며, 두 부분으로 구성되어 있습니다. 다행히 이 두 부분을 모두 완료했습니다.
-
honeypot(허니팟)과 challenge(챌린지) 로직을 대폭 강화했습니다.
-
Chrome의 자동완성 버그를 위한 클라이언트 사이드 전용 우회 처리를 추가했습니다. 이는 서버 사이드 프로토콜을 변경하지 않으므로 이 방식에 문제가 없다고 생각합니다.
이전에는 사이트 전체의 모든 계정 등록에 동일한 honeypot과 challenge 랜덤 문자열을 재사용했습니다. 이는 계정 생성 스크립팅을 매우 쉽게 만들었으며, 값을 한 번만 하드코딩하면 되기 때문입니다.
새로운 구현 방식은 모든 사용자에게 고유한 문자열을 부여하여 검증하도록 합니다. 이 문자열은 쿠키 저장소(우리의 보안 세션 저장소)에 바인딩되며, 1시간 후 만료됩니다.
즉, 스크립팅을 통해 이 작업을 수행하려면 요청 사이에 새로운 challenge와 honeypot을 가져오기 위해 정기적으로 호출을 해야 하며, 단순히 계정을 일괄 생성하는 방식은 불가능해집니다.
2번의 우회 처리는 Chrome이 혼란을 겪는 INPUT 요소를 찾아내어, Chrome이 혼란을 겪지 않는 text 타입의 INPUT으로 대체하는 것입니다.
전체적으로 볼 때, (2)번 조치가 알려지지 않은 사이트에서 계정을 등록하는 "범용"으로 코딩된 봇에게 더 유리하다고 느끼지 않습니다. 우선 봇은 Chrome 웹 드라이버를 사용해야 하고, 우리의 모든 Ember를 파싱한 후 매우 구체적인 흐름을 따라야 합니다. 이 특정 장벽은 매우 낮으며, 새로운 사용자별 로테이팅 challenge에 비하면 아무것도 아닙니다.
Proof of work(작업 증명) 추가에 대해서는 조금 더 기다리고 싶습니다. 특별히 구현하기 어렵기 때문이 아니라, 가장 빠른 sha1 알고리즘을 찾아서 클라이언트에 온디맨드로 전송하는 일을 하고 싶지 않기 때문입니다.
사람들이 제 수정 사항이 문제를 해결했는지 확인할 수 있도록 잠시 열어두겠습니다. 일주일 후 이 이슈를 닫을 예정입니다.