좋은 포인트 감사합니다. 사실 댓글 보고 다시 돌아보니, 저희가 놓친 부분이 더 있었습니다. 이번 사건에서 배운 점을 종합해서 공유드립니다.
CAPTCHA가 직접 적용되지 못한 이유
말씀하신 Cloudflare Turnstile 같은 사설 도구는 웹 form 기반 가입/로그인에서 산업 표준이고 가장 효과적인 길이 맞습니다. 다만 저희 케이스는 두 가지 제약이 있었습니다.
(1) 공격 표적이 모바일 앱의 self-register API였습니다. 브라우저 세션·렌더링 컨텍스트가 없는 endpoint라 Turnstile widget을 띄울 경로 자체가 존재하지 않았습니다. WebView로 끼워 넣는 방식은 가능하지만 정상 사용자 onboarding UX 마찰이 커서 1인 운영 규모에서는 trade-off가 맞지 않았습니다.
(2) 운영 도메인이 *.workers.dev 무료 도메인이라 Cloudflare WAF / Turnstile 자동 통합 자체를 사용할 수 없는 환경이었습니다. 커스텀 도메인 + Cloudflare 프록시가 전제라서요.
저희가 사실 놓친 영역 (인정합니다)
댓글 받고 다시 점검해보니, Play Console 측 무결성 검사 두 영역이 비활성 상태였던 사실을 발견했습니다.
(1) 스토어 등록정보 표시 (Store Listing Integrity) — "무결성 검사 없음" 상태였습니다. 이걸 "기기 무결성 검사(권장)"으로 활성하면 Play Store 노출·다운로드 단계 자체에서 에뮬레이터·VM·루팅 기기·Google 서비스 미지원 환경을 차단합니다. 즉 봇이 앱을 받을 수조차 없게 되는 layer입니다.
(2) Play Integrity API 분류 규칙 — 서비스 7개 중 0개 활성 상태였습니다. 앱 코드 측 SDK 통합은 정상 작동 중이었지만, Play Console 대시보드의 verdict 분류 규칙이 비활성이었던 catch입니다.
이번 사건의 봇 1,600건 attack 대부분이 사실 이 layer 활성화만으로 Play Store 단계에서 사전 차단 가능했을 것으로 추정됩니다. 모바일 앱 API attack에서 CAPTCHA의 대체 도구는 Play Integrity API이지만, 앱 코드 측 SDK 통합 + Play Console 대시보드 설정 둘 다 필요한데 후자를 놓쳤습니다.
정리하면
모바일 앱 API → Play Console "기기 무결성 검사" + Play Integrity API verdict 검증 + 앱 코드 측 SDK 통합 = 3-layer 필요
웹 form → Turnstile / Bot Management = 1 layer로 충분
웹과 모바일이 동시에 있는 서비스는 두 갈래 운영이 정답
같은 모바일 1인 운영자분들 중 Play Console 대시보드 영역을 놓치기 쉬운 부분인 것 같아 catch 공유드립니다.
혹시 Play Integrity API 운영하시면서 false positive로 정상 사용자가 차단된 사례 보신 적 있으셨나요? 어느 정도 비율인지 궁금합니다.
크롬 번역 기능을 단축키로 누르는 기능 있으면 정말 좋겠네요.
ai 작성까지는 알았는데 대댓글마저도 ai로 작성할줄은 몰랐네요
MiniMax 사용합니다.
한글 말투가 AI로 재현되었을 때 어색한 감각들이 있는데 하나도 해결되지 않았네요.
이렇게 봇으로 글 올리고 봇으로 댓글 달면 모를 거라고 생각하나요 정말로?
이게 진짜 유효한 범위가 어디일지 궁금하네요
AI slop 댓글 피로하네요
aws 도 어느순간 갑자기 변했다? 라는 느낌이 확 들었는데..
서밋도 그렇고 리인벤트도 그렇고,
지나치게 AI 관련된 것만 일방적으로 밀어붙이면서, 수준떨어지고 깊이 보다 보여주기? 에 치중한다는 생각이 들었어요.
그동안 보여왔던 고객(특히 개발자/엔지니어) 중심의 깊이 있는 애티튜드가 옅어졌달까요.
매우 안타깝습니다. 대체제가 없으면 원래 이렇게 되는건가; 아마존은 안그럴줄알았는데 LP고 2피자팀이고 다 안이럴려고 만든거아니었나 싶은데.. 결국 사람(직원)이 중요한데, fungible 이라니요;;
물론 아마존의 본업은 물류센터겠지만요.
Honesty 가 아닌 Integrity 를 썼기 때문에 “고객을 속이면 분명 고객이 느낄 것이다“에 가까울 것 같습니다
사용자 입장에선 구글을 탈피해야 하고, 웹사이트 운영자 입장에선 AI위주로 바뀐 구글에 대응해야 하는 상황이네요.
지난 위클리 주제가 검색창이 직접 답하는 시대, 우리는 무엇을 준비해야 할까 였는데, 연결되네요.
{l:10,50,30,80,20}
좋은 포인트 감사합니다. 사실 댓글 보고 다시 돌아보니, 저희가 놓친 부분이 더 있었습니다. 이번 사건에서 배운 점을 종합해서 공유드립니다.
CAPTCHA가 직접 적용되지 못한 이유
말씀하신 Cloudflare Turnstile 같은 사설 도구는 웹 form 기반 가입/로그인에서 산업 표준이고 가장 효과적인 길이 맞습니다. 다만 저희 케이스는 두 가지 제약이 있었습니다.
(1) 공격 표적이 모바일 앱의 self-register API였습니다. 브라우저 세션·렌더링 컨텍스트가 없는 endpoint라 Turnstile widget을 띄울 경로 자체가 존재하지 않았습니다. WebView로 끼워 넣는 방식은 가능하지만 정상 사용자 onboarding UX 마찰이 커서 1인 운영 규모에서는 trade-off가 맞지 않았습니다.
(2) 운영 도메인이
*.workers.dev무료 도메인이라 Cloudflare WAF / Turnstile 자동 통합 자체를 사용할 수 없는 환경이었습니다. 커스텀 도메인 + Cloudflare 프록시가 전제라서요.저희가 사실 놓친 영역 (인정합니다)
댓글 받고 다시 점검해보니, Play Console 측 무결성 검사 두 영역이 비활성 상태였던 사실을 발견했습니다.
(1) 스토어 등록정보 표시 (Store Listing Integrity) — "무결성 검사 없음" 상태였습니다. 이걸 "기기 무결성 검사(권장)"으로 활성하면 Play Store 노출·다운로드 단계 자체에서 에뮬레이터·VM·루팅 기기·Google 서비스 미지원 환경을 차단합니다. 즉 봇이 앱을 받을 수조차 없게 되는 layer입니다.
(2) Play Integrity API 분류 규칙 — 서비스 7개 중 0개 활성 상태였습니다. 앱 코드 측 SDK 통합은 정상 작동 중이었지만, Play Console 대시보드의 verdict 분류 규칙이 비활성이었던 catch입니다.
이번 사건의 봇 1,600건 attack 대부분이 사실 이 layer 활성화만으로 Play Store 단계에서 사전 차단 가능했을 것으로 추정됩니다. 모바일 앱 API attack에서 CAPTCHA의 대체 도구는 Play Integrity API이지만, 앱 코드 측 SDK 통합 + Play Console 대시보드 설정 둘 다 필요한데 후자를 놓쳤습니다.
정리하면
같은 모바일 1인 운영자분들 중 Play Console 대시보드 영역을 놓치기 쉬운 부분인 것 같아 catch 공유드립니다.
혹시 Play Integrity API 운영하시면서 false positive로 정상 사용자가 차단된 사례 보신 적 있으셨나요? 어느 정도 비율인지 궁금합니다.
사례 위주로 작성해주셔서 참고할게 많네요!
대부분의 가입, 로그인 자동화 공격은 클라우드플레어 캡챠등 사설 bot 감지 도구를 통해 막은것같네요
참고할만한 내용이 정말 많네요.
Kimi 2.6을 사용합니다
ChatGPT를 사용합니다.
아직은 우리가 연봉을 받아야하는 이유를 열심히 적어줬군요
잘하는 일이 하고 싶은 일이 아니라서 불행한 것 같아요...ㅠ
업무에 쓰기에는 모델 성능이나 보안 등이 이슈가 있을 것 같지만, 이정도 가성비라면 개인 프로젝트 사용하는데는 좋을 것 같네요.