Hacker News 의견
  • "계정 기반 웹 앱에서 '이메일 주소와 계정 연결' 기능의 위험성에 대해 말하고 싶다. 이 기능은 펜테스터들이 즉시 조작하려고 하는 것 중 하나이며, 초기 2000년대부터 취약점이 발견되었다. GitLab에서도 이런 문제가 재현되었다. GitLab은 훌륭한 보안 팀을 갖고 있지만, 이러한 버그를 피하기 어려운 것으로 보인다. 이 이야기에 관심이 있는 일반 해커뉴스 독자라면, 자신의 비밀번호 재설정 기능, 특히 이메일 연결 로직을 확인해보길 바란다."

  • "Rails 코드베이스에서 이 취약점을 발견한 커밋 링크를 공유한다: GitLab 커밋 링크"

  • "이 버그로 인해 피해를 입었다. 사용자의 이메일을 알아야 공격이 가능하지만, GitLab 사용자 ID(1부터 증가하는 숫자)에 연결된 숨겨진 이메일 주소가 있다. ID 1이나 2는 관리자일 가능성이 높으므로 좋은 목표가 된다. 이메일 형식은 '1-user@mail.noreply.<gitlabhost>'와 같다. 자동화된 공격처럼 보였으며, 2FA가 우리를 구했다."

  • "이메일을 통한 비밀번호 재설정은 올바르게 구현되었을 때조차 보안 악몽이다. 대부분의 서비스에서는 이 기능을 비활성화할 수 없으며, 대안은 종종 엔터프라이즈 SSO뿐이다. 일부 서비스에서는 SMS 토큰을 위한 전화번호를 설정할 수 있지만, 이메일과 SMS 토큰을 모두 요구하는 옵션은 본 적이 없다."

  • "로그인 폼에 비밀번호 배열을 입력하여 계정을 무차별 대입 공격할 수 있는 버그를 발견한 적이 있다. 스팸 어플라이언스에 대한 조악한 웹 인터페이스였으며, 의도된 것인지, PHP 초보자가 코드를 작성한 것인지 확실하지 않다. 당시 특수 문자가 들어간 비밀번호를 사용하던 사용자가 이를 발견했다."

  • "GitLab과 같은 내부 서비스는 신뢰할 수 있는 사용자만 접근할 수 있는 VPN 뒤에서 운영하는 것이 좋다는 점을 상기시킨다."

  • "GitLab 업데이트 자동화는 매우 쉽다. Docker+Compose에서 GitLab을 사용하고 Watchtower 등을 통해 매일 업데이트하면 된다. 7년 이상 이 방법으로 GitLab 서버를 운영하고 있으며 문제가 없었다. 주변을 둘러보면 많은 GitLab이 구버전인데, 관리자들은 무엇을 하고 있는가?"

  • "어떤 종류의 내부 서버든 공개 인터넷에 노출시키지 않겠다는 원칙을 갖고 있다. VPN을 통해서만 접근 가능하게 하여 두 번째 방어선을 구축한다."

  • "항상 SSO를 사용하고 2FA를 사용하는 것을 잊지 말아야 한다는 또 다른 상기."

  • "Ruby/Rails가 안전해야 하는 소프트웨어에 적합한 선택이라는 생각을 그만두자. GitLab이 이를 다루어야 하는 상황을 이해하지만, 앞으로는 지능적이고 숨겨진 제어 흐름을 우선시하는 언어와 프레임워크보다 더 단순한 것이 낫다는 것을 인정해야 한다. 나는 생산 Ruby 코드베이스에서 일하고 있으며, 여러 층의 추상화가 코드를 매우 확장 가능하게 만들었다고 생각하는 누군가로 인해 비슷한 문제가 발생할 가능성이 분명히 보인다."