애플리케이션의 인증 메커니즘과 상호작용하여 유효한 사용자 이름 목록을 수집할 수 있습니다. 이 테스트는 유효한 사용자 이름이 주어졌을 때 해당 비밀번호를 찾을 수 있는지 확인하는 브루트 포스 테스트에 유용합니다.
웹 애플리케이션은 잘못된 구성이나 설계 결정의 결과로 시스템에 특정 사용자 이름이 존재하는지를 노출하는 경우가 많습니다. 예를 들어, 잘못된 자격 증명을 제출하면 사용자 이름이 시스템에 존재하는지 또는 제공된 비밀번호가 잘못된지를 나타내는 메시지를 받는 경우가 있습니다. 이렇게 얻은 정보는 공격자가 시스템의 사용자 목록을 확보하는 데 사용될 수 있습니다. 이 정보는 웹 애플리케이션에 대한 공격, 예를 들어 브루트 포스 공격이나 기본 사용자 이름 및 비밀번호 공격에 사용될 수 있습니다.
두 분 모두 감사합니다. 저는 meta.discourse.org에서 이 버그를 우연히 발견했고, 해당 설정에 대해 알지 못했지만, 수정 코드가 이미 작성되어 있고 패치가 매우 간단할 것이라는 점은 다행입니다. OWASP 모범 사례를 준수하려면 이 설정은 항상 활성화되어야 합니다. 이를 비활성화하려는 관리자가 왜 있겠는지 이해할 수 없으며, 그렇게 하면 업계 모범 사례 기준을 명시적으로 위반하는 완전히 불필요한 보안 및 개인정보 보호 취약점이 발생하기 때문입니다. 제가 이해할 수 없는 이유로 레거시 설치 환경에서 이 옵션을 유지해야 한다면, 현재 구성이 업계 표준 모범 사례를 위반하고 있음을 나타내는 경고 메시지를 추가하고, 대신 준수하는 구성을 권장해야 합니다.
이 스레드를 공유해 주셔서 감사합니다. @awesomerobot 님은 자신의 의견을 가질 권리가 있지만, 업계 표준 모범 사례를 대담하게 무시하고 있으며, 잘 알려져 있고 자주 보고되며 명시적으로 문서화된 버그가 어떻게 "버그가 아니다"라고 주장하고 있습니다. 공개된 업계 표준 모범 사례와 비교할 때, 저는 그 의견이 매우 설득력이 없다고 생각합니다.
최소한 기본값은 더 안전한 구성을 반영해야 하며, 이 옵션을 비활성화하면 포럼에 의도적이고 불필요한 보안 및 개인정보 보호 취약점이 발생한다는 점을 초보 관리자에게 알려줄 수 있는 어떤 표시가 있어야 합니다. OWASP 항목에 대한 링크나 같은 것 말이죠.
누군가 이 옵션을 비활성화하는 것이 더 바람직한 시나리오가 무엇인지 알려줄 수 있을까요? 이 문제가 왜 논쟁의 대상인지 진심으로 알지 못하며, 이 설정으로 구현된 옵트인(opt-in) 보안 모델을 무효화하는 사용 사례를 제가 놓치고 있는지 알고 싶습니다. 만약 그러한 시나리오를 제시할 수 없다면, 이 설정은 항상 활성화되어 있어야 하므로 아예 설정 항목이 아니어야 합니다.
단순히… 사람들은 계정을 만들 때 어떤 이메일 주소를 사용했는지 기억하는 데 서투르기 때문에 문제를 해결하려고 관리자에게 연락하는 경우가 많습니다.
이것은 2단계 인증 강제나 최소 비밀번호 길이와 유사합니다. 일반적인 권장 사항으로는 항상 2단계 인증을 요구하는 것이 있으며, 현재 일반 사용자를 위한 기본값보다 최소 비밀번호 길이 권장 사항이 더 높아진 것으로 보입니다… 하지만 보안 권장 사항과 평균적인 컴퓨터 사용 능력 사이에는 간극이 존재합니다.
기본값 변경에 대해 강하게 반대하지는 않지만, 이것이 사용성(useability)에 영향을 미칠 수 있다는 점을 주목할 가치가 있습니다.
이 버그에 대해 소중한 의견과 관점을 나눠 주셔서 감사합니다. 제게 있어서는 이는 매우 명확하고 복잡하지 않습니다. 저와 같은 관리자 및 보안 전문가들이 반복적으로 지적해 온, Discourse에 존재하는 잘 알려진 버그가 보안 취약점이 아니라 기능으로 취급되고 있기 때문입니다: NIST: CWE-200: 권한 없는 행위자에게 민감한 정보 노출.
산업 표준 모범 사례를 위반하는 이러한 위험한 기본 구성을 정당화하기 위해, 포럼 관리자가 가입에 사용된 이메일이 무엇인지 묻는 사용자 문의로 압도당하는 가상의 상황을 언급하는 것은 논리적이지 않습니다. 이 설정의 구성과 관계없이 ‘비밀번호 찾기’ 페이지를 사용하면 이러한 관리자 상호작용이 필요하지 않기 때문입니다. 더 안전하고 표준에 부합하는 설정이 활성화되면, 사용자는 ‘이메일 찾기’ 대화 상자에서 자신의 이메일을 확인하여 해당 주소가 비밀번호 재설정 이메일을 받았는지 확인하면 됩니다. 이는 대화 상자에 설명된 대로, 그리고 모든 현대적이고 프라이버시를 존중하며 표준에 부합하는 웹 애플리케이션에서 흔히 볼 수 있는 방식입니다. 또한, 이 위반을 다른 사이트들이 최선책을 위반하고 있을 수도 있다는 전제에 기반하여 정당화하는 것은 보안 및 데이터 보호 관점에서 논리적이거나 설득력 있는 주장이 아닙니다. 명확한 이득 없이 관리자에게 Discourse 설치를 약간 덜 안전하고 표준에 덜 부합하게 만드는 '기능’을 제공하는 이유가 무엇인지 이해하기 어렵습니다.
그럼에도 불구하고, @sam님이 지시하신 작업을 수행했습니다:
Google: 사용자 열거(user enumeration)를 허용하지 않습니다.
YouTube: 사용자 열거를 허용하지 않습니다 (Google 로그인을 사용하며, Google은 사용자 열거를 허용하지 않기 때문).
Baidu: 이메일 찾기 페이지에서 사용자 열거를 허용하며, 캡차(그리고 아마도 레이트 리미팅? 제 중국어 실력이 부족합니다)를 구현합니다. 흥미롭게도, 복구 과정은 간단한 복구 이메일이 아니라 관리팀에 이의를 제기하는 것을 요구합니다. CCP의 중앙 통제 방식에 매우 전형적인 모습입니다.
Wikipedia: 사용자 열거를 허용하지 않습니다.
Yahoo: 비밀번호 찾기 페이지를 통해 사용자 열거를 허용하지만, 레이트 리미팅과 캡차를 구현합니다. Yahoo가 이 버그를 악용하는 해커들에게 지급하거나 논란에 휩싸인 사례를 찾지는 못했지만, 명백한 이유로 인해 어떤 검색 엔진에서든 Yahoo를 검색하는 것은 매우 어렵습니다.
Yandex: 로그인 페이지에서 사용자 열거를 허용하며, 이메일 찾기 페이지에서 캡차와 질문(챌린지)을 구현합니다.
Whatsapp: 사용자 열거를 허용하지 않습니다. PC 로그인은 모바일 자격 증명을 통해 이루어집니다. 모바일 자격 증명은 휴대폰 번호에 바인딩됩니다. 로그아웃 버튼도, 로그인 페이지/이메일 찾기 페이지도 없습니다.
Xnxx: 사용자 열거를 허용하지 않습니다. 메인 사이트에는 사실상 로그인 페이지가 없으며, ‘골드’ 사이트는 사용자 열거를 허용하지 않습니다. 일반 사이트의 모바일 버전에서 폐쇄된 로그인 페이지를 발견했는데, 여기에는 ‘이메일 찾기’ 기능이 전혀 없었습니다 (또한 ‘골드’ 웹사이트를 대체하기 위해 폐쇄된 것으로 보입니다).
Tik Tok: 사용자 열거를 허용하지 않습니다. 비밀번호 찾기 페이지에서 MFA(다중 인증)를 강제 적용합니다.
(21. Reddit: 사용자 열거를 허용하지 않습니다. 산업 표준 모범 사례를 준수하고 있습니다.)
해당 목록의 상위 15개 사이트 중 8/15는 사용자 열거를 허용하지 않습니다 (Reddit을 포함하면 9/16, 그리고 사용자가 의도적으로 공개 승인한 정보만 열거되므로 Facebook은 0.5를 더할 수 있습니다). 또한, 사용자 열거를 허용하는 해당 목록의 사이트 중 최소 3/7은 이러한 결정으로 인해 치명적인 보안 사건을 겪었습니다.
가입 페이지가 있는 모든 사이트에 해당되는 것 아닌가요? 이메일 서비스 제공업체에만 국한되는 것이 아닙니다. 가입 페이지가 유사한 프라이버시 및 데이터 취약성의 잠재적 벡터가 될 수 있으므로 보호해야 한다는 점은 이해합니다. 하지만 그것은 이 주제를 논의하면서 다루고 있는 사용자 인증 플로우의 다른 부분입니다. 이 주제에서는 구체적으로 “비밀번호를 잊으셨나요?” 대화 상자에서 발생하는 정보 유출을 다루고 있습니다. 오해하지 마세요: 둘 다 매우 중요하고, 신중한 주의를 기울여야 하며, 프라이버시 및 데이터 취약성을 방지하기 위해 완화 조치가 필요합니다. 일반적으로 가입 폼에는 캡차를 요구하며, ‘비밀번호를 잊으셨나요?’ 엔드포인트에서는 이메일이 유효한지 여부에 관계없이 동일한 응답을 반환하도록 구성해야 합니다. 많은 사이트가 ‘비밀번호를 잊으셨나요?’ 엔드포인트도 캡차로 보호합니다. 두 엔드포인트 모두 속도 제한(rate-limiting)을 적용해야 합니다.
저는 결코 기만적인 의도를 가진 것이 아닙니다. 다른 사이트도 비준수 상태이므로 비준수 상태가 괜찮다는 것은 논리적으로 타당한 결론이라고 생각하지 않습니다. 저는 단순히 Sam의 요청을 이행하고, 그가 제공한 링크를 사용하여 그가 원했던 '증거’를 제시함으로써 그가 가질 수 있는 우려를 완화하려는 것이었습니다.
저는 관리자 자유를 확실히 장려하며, 관리자나 사용자의 삶을 더 어렵게 만드는 것을 좋아하지 않습니다. 하지만 이 설정의 '장점’이 어떤 시나리오에서도 '단점’을 능가한다고 생각하지 않으며, 관리자가 실제로 이 '기능’을 원할 만한 경우도 없습니다. 우리가 관리자에게 최대 비밀번호 길이를 강제할 수 없듯이, ‘비밀번호를 잊으셨나요?’ 대화 상자에서 열거 취약성(enumeration vulnerability)을 허용하여 포럼의 보안을 불필요하게 소폭 저하시키는 것도 허용해서는 안 됩니다. 이 옵션을 완전히 제거하고 모든 사용자가 표준 준수 방식을 따르도록 강제하는 것이 좋다고 생각합니다. 솔직히 대부분의 관리자는 이를 알아차리거나 신경 쓰지 않을 것이라고 생각하지만, 이는 모든 Discourse 설치 환경에서 공개 인터넷에 노출된 엔드포인트를 다소 더 안전하게 만들 것입니다. 반드시 이 설정을 포함해야 한다면, 더 안전한 위치가 기본값이어야 하며, 덜 안전한 위치는 초보 관리자가 왜 권장되지 않는지 이해할 수 있도록 명확히 구분해야 합니다. 하지만 저는 이 설정을 단순히 리팩토링하여 없애는 것이 최선의 선택이라고 생각합니다. 이를 위한 PR을 제출하는 것은 기꺼이 하겠습니다.
나는 둘 중 어느 것도 고립된 상태로 볼 수 없다고 생각합니다. Discourse의 가입 과정에는 "이미 사용 중인 이메일입니다"라는 메시지가 있으며, 이를 다르게 처리하는 방법을 이해하기 어렵습니다. 이 메시지가 존재하는 한, "계좌를 찾았습니다"라는 특정 메시지에 큰 문제가 무엇인지 이해하기 어렵습니다.
포럼이 외부 인증만 허용하는 경우라면 상황이 달라질 수 있을 것입니다.
당신의 말투 때문에 단순히 반박하고 싶은 충동을 누른 후, 실질적인 내용에서 당신의 입장이 기본값은 더 안전한 옵션이어야 하며, 적어도 외부 인증이 사용될 때 그러하다는 점에서 당신이 옳다고 생각합니다. 여전히 더 안전한 옵션이 아무 곳에도 적합하지 않다는 데에는 동의하지 않습니다(제 포럼은 Discourse의 기본 가입 과정을 사용하므로 비밀번호 재설정 옵션을 변경할 계획이 없습니다).
그리고 참고로, 당신이 컨텍스트에서 추측하도록 남겨둔 XVideos와 Xnxx(하지만 X는 제외)가 포르노 사이트라는 사실에 웃었습니다. 그런데 아마존은 "전자상거래 사이트"라고 설명하는 데에는 공을 들였습니다.
Amazon.com과 AWS를 구별하기 위함이었습니다. 그리고 질문하신 내용에 대해 말씀드리자면: AWS는 사용자 열거(user enumeration)를 허용하지 않습니다.
사용자 인증 플로우의 모든 단계와 이들이 어떻게 상호작용하는지를 고려해야 한다는 점에 동의합니다. 이는 매우 중요하며, 가장 흔한 보안 취약점의 원인 중 하나입니다. 언급하신 가입 페이지의 유사한 이메일 열거 버그가 적절히 완화되지 않았다면, 이 주제의 결론과 관계없이 반드시 패치되어야 합니다. 이는 hide_email_address_taken 구현의 버그가 될 것입니다. 다만 해당 잠재적 버그/누락에 대한 논의는 다른 주제에서(아마도 bug 태그와 함께) 이루어지는 것이 적절할 것입니다.
hide_email_address_taken SiteSetting을 prevent_password_recovery_by_username으로 이름을 변경하고, 비준수하는 동작을 모든 사용자를 위해 앱에서 리팩토링해 제거하는 것을 제안합니다. 이렇게 하면 모든 설치 환경에서 비밀번호 재설정 기능이 변경 없이 유지되는 동시에 이메일 열거 취약점도 해결할 수 있습니다. 저는 숙련된 RoR + JavaScript 개발자로서 이 풀 리퀘스트를 구현하는 데 기꺼이 참여할 준비가 되어 있습니다. 코드베이스를 빠르게 살펴본 결과, 이 PR이 매우 방대하지는 않을 것으로 보입니다.
만약 이 '기능’을 리팩토링하여 완전히 제거하는 것이 실제로 불가능하다면, 여전히 이 두 가지 관련 개념을 별도의 SiteSetting 항목으로 분리하는 것이 합리적이라고 생각합니다.
