파서 차이를 이용한 SAML SSO 인증 우회 기술

Hacker News 의견

• GitHub의 SAML 구현이 쓸모없음

  • 사용자가 자신의 계정을 기업에 가져올 수 있는 아이디어는 사이트 자체에서는 어느 정도 작동하지만, 앱에서 GitHub로 로그인할 때 조직 멤버십을 읽는 것을 막지 못함
  • SAML 세션은 사용자가 얻은 토큰을 통해 데이터를 가져오는 경우에만 필요함
  • SAST 도구는 거의 항상 앱 인스턴스 토큰을 사용하며, GitHub 계정이 있는 누구에게나 코드를 보여줌
  • Tailscale은 이 문제를 해결했으나, Sonarcloud는 비밀로 해달라고 요청했고, GitHub는 몇 주 후에 이 행동이 예상된 것이라고 답변함
  • 보안 버그를 보고하는 것은 감사받지 못하는 일임

• 최근 SAML을 구현해야 했으며, 이 헤드라인이 전혀 놀랍지 않음

  • SAML 사양 자체는 합리적이지만, XML 서명과 XML 정규화에 기반을 두고 있어 매우 복잡함
  • 위원회만이 이러한 모순된 아이디어를 결합할 수 있음

• SAML (더 넓게는 XML-DSIG)은 일반적으로 사용되는 최악의 보안 프로토콜임

  • OAuth로 전환하기 위해 필요한 모든 조치를 취해야 함
  • 새로운 제품을 시장에 출시할 때 이를 의존하지 않을 것임
  • 실질적인 형식 검증의 돌파구가 없다면, DSIG 취약점이 마지막이거나 최악이 아닐 것임

• REXML을 사용해서는 안 됨

  • 잘못된 XML을 기꺼이 구문 분석하여 무한한 문제를 일으킴
  • 정규 표현식을 사용하여 XML을 구문 분석하는 것은 잘못된 사례임
  • 프로젝트들은 성능 때문에 Nokogiri를 사용한 것이 아님, 정확성 때문임

• 훌륭한 글임

  • ahacker1의 SAML 구현 보안 작업에 감사함
  • WorkOS가 ahacker1과의 협업에 대한 글을 작성함

• GitLab에서 취약점이 발견되었고, 보안 팀에 알림

  • GitLab은 이를 수정했음

• Latacora의 2019년 기사, JSON 객체 서명 방법 관련

  • 트리를 중첩하고 서명하는 것은 어려움
  • 메시지를 원시 문자열로 보관하고 서명하는 것이 더 쉬움

• 서명이 있어야 할 위치를 찾는 것이 더 간단한 결론임

  • 예상치 못한 위치의 서명을 찾는 일반적인 XPath를 사용하지 말아야 함

• 블로그 게시물에서 취약점을 설명하고 관련된 파서 차이를 생략하는 것은 짜증남

  • 이야기의 도입부를 쓰고 절정을 생략하는 것과 같음

• XML 서명의 기술적 세부 사항을 처음 읽었으며, 머리가 어지러움

  • SAML 대신 libsodium의 공개 키 인증 암호화(crypto_box)를 사용할 비유산 이유가 있는지 궁금함
  • libsodium의 crypto_box와 Golang의 x/crypto/nacl/box를 사용할 때 파서 차이의 비이론적 위험이 있는지 궁금함