ฟีเจอร์บางส่วนของ Google OAuth ขัดข้อง

 (trufflesecurity.com)
1 คะแนน โดย GN⁺ 2023-12-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในบริการที่เชื่อถือ email claim ของ Google OAuth เพื่อตัดสินสิทธิ์การล็อกอิน พนักงานที่ลาออกแล้วอาจยังคงเข้าถึงแอปอย่าง Slack·Zoom ได้แม้ถูกลบออกจากองค์กร Google ของบริษัทแล้ว
  • สามารถสร้างบัญชี Google ด้วยอีเมลที่ไม่ใช่ Gmail ได้ และหากใช้อีเมลบริษัทที่เป็น alias หรือการส่งต่อที่อยู่แบบ plus address บัญชี Google ที่ไม่ได้อยู่ในองค์กรก็สามารถส่ง email claim ของอีเมลโดเมนบริษัทได้
  • บัญชีที่ไม่ใช่ Gmail นี้จะไม่ปรากฏในหน้าผู้ดูแลระบบหรือรายชื่อผู้ใช้ขององค์กร Google ของบริษัท แต่บริการจำนวนมากอนุญาตให้ล็อกอินโดยดูเพียง โดเมน ท้ายอีเมล
  • องค์กรสามารถลดความเสี่ยงได้โดยปิด Google login และบังคับใช้ SAML อย่างเข้มงวด แต่บริการบางรายการหรือแอปภายในอาจไม่มีตัวเลือกนี้หรือไม่รองรับ SAML
  • มีการรายงานต่อ Google เมื่อวันที่ 4 สิงหาคม และจ่ายรางวัล $1337 เมื่อวันที่ 5 ตุลาคม จากนั้นเปิดเผยต่อสาธารณะหลังผ่านไป 134 วันในวันที่ 16 ธันวาคม แต่จนถึงเวลาที่เปิดเผย Google ยังไม่ได้เผยแพร่การเปลี่ยนแปลงเพื่อลดความเสี่ยง

การเปิดเผยช่องโหว่และไทม์ไลน์

  • ช่องโหว่ใน Google OAuth อาจทำให้พนักงานที่ถูก offboarding ออกจากบริษัทและถูกลบออกจากองค์กร Google แล้วยังคงรักษาการเข้าถึงแอปพลิเคชันอย่าง Slack·Zoom ได้ไม่มีกำหนด
  • จนถึงเวลาที่เปิดเผย Google ยังไม่ได้เผยแพร่การเปลี่ยนแปลงเพื่อลดความเสี่ยงนี้
  • ไทม์ไลน์มีดังนี้
    • 4 สิงหาคม: รายงานต่อ Google และแจ้งว่าแอปพลิเคชันหลายร้อยรายการอาจได้รับผลกระทบ
    • 7 สิงหาคม: ประเด็นนี้ถูก triage
    • 5 ตุลาคม: Google จ่ายเงิน $1337 สำหรับประเด็นนี้
    • 25 พฤศจิกายน: รายงานแบบกลุ่มเป็นการส่วนตัวต่อแอปพลิเคชันที่ได้รับผลกระทบหลายสิบรายการ รวมถึง Zoom·Slack
    • 16 ธันวาคม: เปิดเผยต่อสาธารณะหลังแจ้ง Google ไปแล้ว 134 วัน

ความเสี่ยงของการใช้ email claim เป็นตัวระบุ

  • การล็อกอิน Forager ของ Truffle Security เคยได้รับผลกระทบจาก ช่องโหว่ Microsoft OAuth ของ Descope มาก่อน
  • ตอนนั้นพบว่าสามารถส่ง Email claim ที่ Microsoft ไม่ได้สร้างหรือยืนยันโดยตรงได้ และโดยทั่วไป email claim ไม่ใช่ตัวระบุที่เชื่อถือได้
  • เอกสาร OIDC ของ Google ก็เตือนว่าไม่ควรใช้ Email เป็นตัวระบุหลัก
  • email_verified claim ก็ถูกมองว่าเป็นจุดที่ผิดปกติ แต่ยังไม่พบวิธีสร้าง email claim จากอีเมลที่ไม่ได้รับการยืนยัน
  • อย่างไรก็ตาม มีการยืนยันกรณีการใช้ email claim ในทางที่ผิดได้เพียงพอแล้ว

บัญชี Google ที่ไม่ใช่ Gmail และ email claim ซ้ำกัน

  • บัญชี Google สามารถสร้างด้วยที่อยู่อีเมลเดิมได้ แม้ไม่ใช่ที่อยู่ Gmail
    • ตัวอย่างเช่น สามารถสร้างบัญชี Google ด้วยที่อยู่อีเมล Yahoo ได้
    • บัญชีนี้สามารถส่ง email claim ของอีเมลดังกล่าวได้ในขณะที่ตั้งค่าเป็นอีเมลที่ไม่ใช่ Gmail
  • เหตุผลหนึ่งที่เอกสาร Google ระบุว่าไม่ควรใช้อีเมลเป็นตัวระบุหลัก คือบัญชี Google สองบัญชีที่ต่างกันสามารถส่ง email claim เดียวกันได้
    • หลังแก้ไขอีเมลที่ไม่ใช่ Gmail ในการตั้งค่า
    • หากสร้างบัญชีใหม่ด้วยอีเมลก่อนแก้ไข ก็สามารถมี email claim เดียวกันได้

บัญชีที่เหลืออยู่นอกองค์กร Google ของบริษัท

  • ช่องโหว่สำคัญคือสามารถใช้ email alias และ การส่งต่อ plus address กับอีเมลขององค์กร Google ของบริษัทเพื่อสร้างบัญชี Google ที่อยู่นอกองค์กรได้
  • plus address ของอีเมลบริษัทสามารถถูกส่งต่อไปยังกล่องจดหมายของผู้ใช้เดิมได้
  • ด้วยขั้นตอนนี้ สามารถสร้างบัญชี Google แบบไม่ใช่ Gmail ที่อิง plus address โดยใช้อีเมลขององค์กร Google ของบริษัทได้ และบัญชีนี้ไม่สามารถถูกลบหรือ offboarding โดยองค์กรได้
  • บริการจำนวนมาก parse อีเมลนี้แล้วตัดสินว่าอนุญาตให้ล็อกอินหรือไม่โดยอิงโดเมนท้ายอีเมล
    • สามารถสมัคร Zoom ด้วยบัญชีนี้ได้
    • สามารถสมัคร Slack ด้วยบัญชีนี้ได้
  • บัญชี Google ที่ไม่ใช่ Gmail แบบนี้ไม่ใช่สมาชิกจริงขององค์กร Google จึงไม่แสดงในค่าผู้ดูแลระบบหรือรายชื่อผู้ใช้ Google

แนวทางลดความเสี่ยงขององค์กร ผู้ให้บริการ และ Google

  • องค์กรสามารถลดความเสี่ยงได้โดยปิด Google login และบังคับใช้ SAML อย่างเข้มงวด
    • วิธีนี้ใช้ได้กับผู้ให้บริการส่วนใหญ่
    • บางบริการไม่มีตัวเลือกดังกล่าว
    • แอปพลิเคชันที่พัฒนาภายในอาจได้รับผลกระทบแต่ไม่รองรับ SAML
  • ผู้ให้บริการสามารถใช้ HD claim ของ Google OAuth ได้
    • HD claim ส่งโดเมนขององค์กร Google ที่บัญชีเชื่อมโยงอยู่
    • บัญชีที่ไม่ใช่สมาชิกขององค์กร Google จะไม่มี HD claim รวมอยู่
    • ผู้ให้บริการส่วนใหญ่ที่ทดสอบใช้ email claim แทน HD
  • HD claim ยังมีข้อจำกัดสำคัญอยู่
    • HD ไม่ใช่ตัวระบุเฉพาะ แต่เป็นเพียงโดเมน
    • หากองค์กร Google ถูกลบและโดเมนถูกปล่อยทิ้งไว้ บุคคลอื่นอาจได้โดเมนนั้นมาและสร้างองค์กร Google ใหม่ได้
    • ตัวอย่างเช่น บริษัท A ถูกบริษัท B ซื้อกิจการ แล้ว B ยุติบริการของ A และไม่ต่ออายุโดเมนเดิม
    • หากใครสักคนบนอินเทอร์เน็ตซื้อโดเมนของบริษัท A ได้ ก็สามารถล็อกอินเข้าสู่บัญชีบริการเดิมของบริษัท A ได้
  • ผู้ให้บริการสามารถไม่อนุญาตให้ การสร้างบัญชีแบบ JIT เป็นฟีเจอร์ทั่วไป และเปลี่ยนไปใช้การสร้างบัญชีแบบเชิญเท่านั้นหรือการ provisioning บัญชีตามกลุ่ม LDAP
  • Google สามารถลดความเสี่ยงในวงกว้างได้ด้วยการห้ามสร้างบัญชี Google ด้วยโดเมนขององค์กร Google ที่มีอยู่แล้ว
    • Google ห้ามบัญชี google.com ด้วยตัวเองอยู่แล้ว
    • สามารถขยายการป้องกันแบบเดียวกันไปยังองค์กรอื่นได้
  • แนวทางลดความเสี่ยงอื่นจากฝั่ง Google ได้แก่ ห้ามสมัครบัญชี Google ด้วย plus address, ห้ามสมัครด้วย email alias ของ Google และจัดเตรียมการตั้งค่าผู้ดูแลระบบที่ดีขึ้นเพื่อให้องค์กรกำหนดค่าที่เกี่ยวข้องได้

ผลกระทบเพิ่มเติม: อีเมลสนับสนุนและขั้นตอน magic link

  • แม้ไม่มีสิทธิ์เข้าถึงตั้งต้น ก็อาจเป็นไปได้ในเชิงเทคนิคที่จะเข้าถึง Zoom·Slack ขององค์กร
  • ขั้นตอนนี้ใช้ประโยชน์จากงานวิจัยช่องโหว่ที่นักวิจัยรายอื่นพบใน magic link sign-in flows
  • ระบบสนับสนุนและ ticket บางระบบ เช่น Zendesk สามารถสร้าง ticket สนับสนุนผ่านอีเมลได้
    • สามารถสร้างบัญชี Google ด้วยที่อยู่อีเมลของ ticket สนับสนุนได้
    • อาจตรวจสอบเนื้อหา ticket เพื่อทำการสร้างบัญชีให้เสร็จสมบูรณ์ได้
    • จากนั้นสามารถลองล็อกอินผ่าน OAuth ด้วยที่อยู่อีเมลสนับสนุนนั้นได้
  • การคงฟีเจอร์ email to support ไว้บนโดเมนหลักนั้นไม่ปลอดภัย และมีแนวทางให้ตั้งค่าอีเมลสนับสนุน Zendesk เป็นที่อยู่อีเมลทางเลือก

วัตถุประสงค์ของการเปิดเผยและปัญหาที่ยังคงอยู่

  • ปัญหาที่อดีตพนักงานยังคงเข้าถึงแพลตฟอร์มอย่าง Slack·Zoom ได้ มีต้นตอมาจากช่องโหว่ในระบบ Google OAuth
  • Google มีความสามารถในการแก้ไขในวงกว้างเพื่อลดความเสี่ยงของปัญหานี้
  • วัตถุประสงค์ของการเปิดเผยคือเพื่อผลักดันให้เกิดการเปลี่ยนแปลงจริง ไม่ใช่แค่การแก้เอกสารเล็กน้อย
  • Google triage ประเด็นนี้อย่างรวดเร็ว แต่ปัญหาถูกเปิดเผยในวันที่ 134 ซึ่งต่างจากแนวปฏิบัติการปรับปรุงภายใน 90 วันของตนเอง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-22
ความคิดเห็นจาก Hacker News

  • ผมทำงานอยู่ในด้านนี้ และในช่วง 3–4 ปีที่ผ่านมาเคยจัดการกับรูปแบบย่อยของช่องโหว่นี้มากกว่า 20 ครั้งในผู้ให้บริการล็อกอินและบริษัท SaaS หลายแห่ง บทความบล็อกนั้นถูกต้อง แต่ผมคิดว่าปัญหาหลักมาไกลเกินกว่าจะแก้ได้แล้ว การยืนยันตัวตนแบบมอบอำนาจ ทั่วทั้งอินเทอร์เน็ตยุ่งเหยิงไปหมด และผมก็เคยคุยกับวิศวกรของ Google และ Microsoft มามาก จึงมั่นใจว่าพวกเขารู้จักกลุ่มปัญหานี้อยู่แล้ว เพียงแต่ถ้าเปลี่ยนพฤติกรรมตอนนี้ จะทำให้บริการเดิมและการติดตั้งระบบล็อกอินขององค์กรที่มีอายุหลายสิบปีพังจำนวนมาก
    “การแก้” ณ ตอนนี้ทำได้ง่าย ๆ ถ้าไซต์ใช้ “Sign in with XYZ” ก็ไม่ควรเชื่อถือที่อยู่อีเมลที่ผู้ให้บริการส่งมาให้ อย่าให้สิทธิ์พิเศษเพียงเพราะดูจากโดเมนอีเมล และควรส่ง อีเมลยืนยันของตัวเอง เสมอก่อนจะทำเครื่องหมายว่าได้รับการยืนยันแล้วในฐานข้อมูล ผู้ให้บริการ OAuth รายใหญ่ก็อัปเดตเอกสารให้ระบุเรื่องนี้ไว้แล้ว และตัวบทความเองก็ชี้ประเด็นนั้น ดังนั้นการที่มีเงินรางวัลออกมาจึงน่าประหลาดใจเสียด้วยซ้ำ

    • รู้สึกเหมือนเป็นผลจากการที่องค์กรต่าง ๆ ไม่เข้าใจจริง ๆ ว่าพื้นที่นี้ซับซ้อนแค่ไหน จากที่เห็นหลายบริษัทนำ OAuth2 + OIDC มาใช้ มันมักถูกขายเป็น ฟีเจอร์ อย่าง “ล็อกอินด้วย x” ไม่ใช่จากมุมมองที่ให้ความสำคัญกับความปลอดภัยก่อน แม้จะพยายามทำให้ flow ปลอดภัยขึ้นด้วยสิ่งอย่าง PKCE ก็กลายเป็นเกมตีตัวตุ่น เพราะแต่ละแพลตฟอร์มจัดการเรื่องการแชร์คุกกี้หรือการ redirect กันอย่างเละเทะ พื้นฐานของ 3-legged OAuth2 นั้นแข็งแรง และก็มีตัวอย่างก่อนหน้าอย่าง CAS อยู่มาก แต่ OpenID Foundation ควรถูกวิจารณ์อย่างหนักจากวิธีที่ทำการตลาดและขาย OIDC
    • วิธีที่ว่า “อย่าให้สิทธิ์พิเศษเพียงเพราะดูจากโดเมนอีเมล และควรส่งอีเมลยืนยันของตัวเองเสมอก่อนจะทำเครื่องหมายว่าได้รับการยืนยันแล้วในฐานข้อมูล” จะล้มเหลวไม่ใช่หรือ ถ้าผู้ใช้ลงทะเบียนบัญชีกับ Google ด้วยที่อยู่แบบ plus addressing แล้วล็อกอินเข้าใช้บริการด้วยบัญชี Google นั้นก่อนจะถูกไล่ออก? เว้นแต่จะส่งอีเมลยืนยันทุกครั้งที่ล็อกอิน
    • ในกรณีเฉพาะนี้ ผู้โจมตีสามารถรับอีเมลยืนยันได้จริง ดังนั้นผมไม่เข้าใจว่าขั้นตอนยืนยันนั้นมีความหมายอะไร
    • “ควรส่งอีเมลยืนยันของตัวเองเสมอก่อนจะทำเครื่องหมายว่าได้รับการยืนยันแล้วในฐานข้อมูล” ทำให้ฟีเจอร์ ล็อกอินด้วย x ไร้ประโยชน์จากมุมมองผู้ใช้ไปเลย
    • Google ป้องกันไม่ให้สมัครโดยใช้โดเมนของลูกค้า Google Apps ไม่ได้หรือ? อันนั้นดูไม่น่าจะทำให้อะไรพังเป็นพิเศษ

  • ที่เกี่ยวข้องคือ ผู้ให้บริการจำนวนมากขึ้นควรเลิกใช้ อีเมลเป็นตัวระบุหลัก ตามที่เอกสารของ Google แนะนำ ผมเสียเวลาไปมากกับการจัดการปัญหาใน Slack, Datadog, GoLinks ฯลฯ เมื่อต้องเปลี่ยนชื่อผู้ใช้ใน Google Apps

    • แล้วผู้ให้บริการควรใช้อะไร? ผมเคยคิดเสมอว่าอีเมลเป็นตัวระบุสากลที่เสถียรที่สุดของผู้ใช้ แต่ดูเหมือนสมมติฐานนั้นจะผิด
    • เห็นด้วยยาก แนวทางแบบนี้แค่ผลักความรับผิดชอบไปให้นักพัฒนาแอปพลิเคชัน และส่วนใหญ่ก็คงไม่ทำอะไรเลยหรือไม่ก็ใช้งานกันคนละแบบ
      ทิศทางที่ถูกต้องตรงนี้คือการให้ API ที่เหมาะกับความต้องการของแอปพลิเคชันที่จะใช้งาน และลดความรับผิดชอบเพิ่มเติมให้น้อยที่สุด ในกรณีนี้ ผมคิดว่า Google ควรตั้ง email_verified เป็น false เพื่อให้แอปพลิเคชันหรือ IdP ระดับล่างรู้ว่าจำเป็นต้องมีการตรวจสอบเพิ่มเติม

  • ถ้า user@domain ถูกจัดการโดยเมลเซิร์ฟเวอร์ของ Google อยู่แล้ว และกฎ plus routing จึงมีผล ผมไม่เข้าใจว่าทำไมถึงสร้างบัญชี Google ใหม่ด้วยอีเมลอย่าง user+suffix@domain ได้ ต่อให้ไม่ใช่การนำไปใช้ในทางที่ผิด ก็ดูเหมือนเหมาะมากที่จะสร้างการตั้งค่าอีเมลที่ชวนสับสน

    • โดเมนสามารถย้ายเมลเซิร์ฟเวอร์ได้อย่างอิสระ Google จัดการ a+b@domain.com ในแบบหนึ่ง แต่เซิร์ฟเวอร์อื่นอาจไม่เป็นแบบนั้น สุดท้ายแล้วทั้งสองเป็น ที่อยู่อีเมลที่ไม่ซ้ำกัน คนละอัน และทั่วทั้งอินเทอร์เน็ตก็ควรปฏิบัติต่อมันเช่นนั้น
    • ฟีเจอร์ alias นี้ดูซับซ้อนเกินตัวไปแล้ว โดยเฉพาะในระดับขนาดของ Google
    • แย่กว่า user+suffix@domain อีก อย่างน้อย +XYZ ก็ระบุไว้ใน RFC ของอีเมล Google ยังไปไกลกว่านั้นด้วยการตัดสินว่าจุดในชื่อก็ถือเป็นอีเมลปกติแบบเดียวกันด้วย เช่น hi.my.name@google.com เท่ากับ himyname@google.com และเมลทั้งหมดจะถูก route ไปยังอันหลัง
    • เพราะระบบยืนยันตัวตนของ Google เป็น legacy ที่เก่าแก่มาก “บัญชี Google” ก็เป็นแค่ สตริง เท่านั้น

  • สำหรับประเด็นที่ว่า “น่าตกใจที่ Microsoft ส่งเคลมอีเมลที่ Microsoft ไม่ได้สร้างหรือยืนยันเอง และโดยทั่วไปเคลมอีเมลก็ไม่ถือว่าน่าเชื่อถือ” แม้เดิมทีเจตนาอาจเป็นแบบนั้น แต่ผมมองว่าการที่ OIDC ยืดหยุ่นได้มากกว่านั้นมีประโยชน์มาก เช่น ผมให้บริการผู้ให้บริการล็อกอินฟรี[0] ซึ่งยืนยันตัวตนผ่าน OIDC ต้นทางหรืออีเมลโดยตรงกับผู้ให้บริการตัวตน (IdP) ซึ่งเป็นบุคคลที่ 4 และสร้าง กำแพงกั้นความเป็นส่วนตัว ระหว่างแอปกับ IdP นั้น กล่าวคือ ทำให้ Google ติดตามไม่ได้ว่าผู้ใช้ล็อกอินเข้าแอปใดบ้าง
    การที่สามารถนำอีเมลของตัวเองมาใช้กับ Google ได้ หมายความว่าคุณจะได้ทั้งความปลอดภัยและประสบการณ์ผู้ใช้ของ Google OIDC พร้อมกับความเป็นส่วนตัวแบบอีเมล+รหัสผ่าน แต่มีข้อแม้สำคัญคือตอนนี้ต้องเชื่อใจ LastLogin แทน Google อยู่ และกำลังทำโปรโตคอลเพื่อลดการพึ่งพานั้นอยู่ ส่วนที่ว่า “เอกสารของ Google เตือนจริง ๆ ว่าอย่าใช้อีเมลเป็นตัวระบุ” ผมคัดค้านอย่างสิ้นเชิง อีเมลคือ federated identity ที่แท้จริงเพียงอย่างเดียวที่ผู้คนใช้จริง จนกว่าจะมีทางเลือกที่ดีกว่าและถูกใช้งานอย่างแพร่หลาย ผมเชื่อว่าเราควรปฏิบัติต่อที่อยู่อีเมลในฐานะตัวตน
    [0]: https://lastlogin.io

    • ผมไม่เห็นด้วยกับคำว่า “ควรปฏิบัติต่อที่อยู่อีเมลในฐานะตัวตน” มีเหตุผลสองข้อ
      นอกโลกตะวันตก โทรศัพท์มือถือพบได้บ่อยกว่าคอมพิวเตอร์ และ UI ก็มักใช้ง่ายกว่า ดังนั้น หมายเลขโทรศัพท์ จึงมีแนวโน้มจะเป็นตัวตนมากกว่า นอกจากนี้ การทำเช่นนั้นเท่ากับยกตัวตนให้ผู้ให้บริการอีเมลไปทั้งหมด องค์กรไร้หน้าอย่าง Google สามารถและก็ทำจริง ๆ ในการบล็อกการเข้าถึงโดยไม่มีการเตือนหรือกระบวนการอุทธรณ์ ทำให้คุณสูญเสียทุกอย่างได้ ขอเล่าภูมิหลัง: ผมเปิดตัวผลิตภัณฑ์ OAuth และ OIDC ของ Okta สร้างคอร์สที่เกี่ยวข้องของ LinkedIn และตอนนี้กำลังทำเรื่องนี้อีกครั้งที่ Pangea Cyber
    • “ควรปฏิบัติต่อที่อยู่อีเมลในฐานะตัวตน” นี่ตั้งอยู่บนสมมติฐานว่าไม่มีใครแชร์ที่อยู่อีเมลกัน และอีเมลปลอดภัยมากอย่างนั้นหรือ
      จะรอไปตลอดก็ได้ หรือไม่ก็เริ่มสร้างวิธีแก้ปัญหาได้แล้ว
    • มีความแตกต่างสำคัญระหว่างตัวระบุอีเมลภายในระบบของคุณเอง กับอีเมลในฐานะตัวระบุของบัญชี Google ที่เชื่อมต่ออยู่ ผมเห็นด้วยว่าอีเมลพอใช้เป็นตัวตนภายในระบบที่คุณควบคุมได้ แต่เมื่อเชื่อมต่อกับระบบภายนอก มันเป็นวิธีที่แย่ตามที่ Google ว่าไว้ มันเป็นสิ่งชั่วคราว อาจผูกกับหลายบัญชีได้ และในเมื่อมี ID จริงที่ใช้ได้อยู่แล้ว ก็ไม่มีเหตุผลต้องใช้อีเมล
    • ถ้าช่วยเปรียบเทียบ LastLogin กับ Dex ได้จะดีมาก ทั้งคู่เขียนด้วย Go เลยยิ่งน่าสนใจ อยากรู้ด้วยว่าเคยประเมิน Dex ไหม
      ผมเคยลอง Portier กับ Mozilla Persona สมัยก่อนมาบ้าง แต่สุดท้ายปัญหาเรื่องการ normalize อีเมลก็ดูเหมือนเป็นศึกที่แพ้แน่ หรือยากเกินไป ผมแทบยอมรับแล้วว่าคงตายก่อนจะมีทางแก้ที่ดีบุกเบิกออกมา และหันความสนใจไปเรื่องอื่น

  • นี่เป็นปัญหา Google OAuth จริง ๆ หรือเป็นความล้มเหลวของผู้ให้บริการจำนวนมากที่ตรวจสอบ claims ของ OAuth token ไม่ถูกต้องก่อนอนุญาตให้เข้าถึงกันแน่? ดูเหมือนอย่างหลังมากกว่า

    • ฟังดูเหมือนปัญหาคือผู้ให้บริการเหล่านี้ยอมทำตามกฎ alias ของ Google แต่กลับมองข้ามข้อเท็จจริงที่ว่าไม่ควรใช้อีเมลเป็นตัวระบุหลัก [1] ที่น่าสนใจคือ ถ้าพวกเขาทำตามสเปกให้ดีกว่านี้ก็คงไม่เป็นไร และในทางกลับกัน ถ้าทำตามสเปกน้อยกว่านี้โดยถือว่า alias เป็นอีเมลคนละอัน อย่างน้อยก็จะปลอดภัยกว่านี้
      [1] https://developers.google.com/identity/openid-connect/openid...
    • ผมมองว่า OAuth ทำงานตามที่คาดไว้แล้ว user@domain กับ user+wildcard@domain ยังคงได้รับการยืนยันว่าเป็นที่อยู่อีเมลที่ผู้ใช้ “เป็นเจ้าของ” ดังนั้นจึงให้การยืนยันตัวตนและตัวตนที่ถูกต้องสำหรับที่อยู่อีเมลนั้น
      ปัญหาอยู่ที่ฝั่งเว็บไซต์องค์กรของ Google ผู้ดูแลระบบไม่สามารถเพิกถอน credentials ของบัญชีหรืออีเมลที่มองไม่เห็นได้ ประเด็นสำคัญคือส่วนที่ว่า “บัญชี Google ที่ไม่ใช่ Gmail เหล่านี้ไม่ได้เป็นสมาชิกขององค์กร Google จริง ๆ จึงไม่ปรากฏในการตั้งค่าผู้ดูแลระบบหรือรายชื่อผู้ใช้ Google”

  • ถ้าตามโฟลว์นี้ ก็สามารถสร้างบัญชี Google ด้วยที่อยู่อีเมลของ support ticket อาจตรวจดูเนื้อหาใน ticket เพื่อสร้างบัญชีให้เสร็จ แล้วใช้ที่อยู่อีเมล support นั้นล็อกอินผ่าน OAuth เข้าบริการต่าง ๆ ได้ เรื่องนี้อาจกระทบ บริษัทขนาดเล็ก จำนวนมาก

  • ข้อสรุปใหญ่ที่สุดที่ได้จากตรงนี้คือ การยืนยันตัวตนบนเว็บยังคงเป็นความยุ่งเหยิงอันเลวร้าย

    • เพราะผู้คนไม่อ่านเอกสาร และเดาเอาเองว่ามันทำงานตามแบบที่ตัวเองคิด
    • ถ้าถามว่าทำไมคนที่มีสติและลงมือทำจริงยังใช้และเรียกร้อง การยืนยันตัวตนด้วยรหัสผ่าน แบบเรียบง่ายอยู่ ก็เพราะรหัสผ่านทำงานได้ถูกต้อง

  • สเปก OIDC บอกว่าไม่ควรใช้อีเมลเป็นตัวระบุที่ไม่ซ้ำกัน ควรใช้ฟิลด์ iss และ sub เป็นชื่อผู้ใช้ของแอปพลิเคชัน
    เหตุผลข้อแรกชัดเจนคือที่อยู่อีเมลของผู้ใช้อาจถูกนำกลับมาใช้ใหม่ได้ หากคอนแทรกเตอร์คนหนึ่งทำงานให้ทั้ง Business A และ Business B และทั้งคู่สร้างบัญชีผู้ใช้ของคนคนนั้นในบริการยืนยันตัวตน สำหรับแพลตฟอร์ม SaaS แล้วจะไม่สามารถแมปที่อยู่อีเมลเดียวเข้ากับลูกค้า B2B รายเดียวได้ ข้อสองคือที่อยู่อีเมลเปลี่ยนได้ บริษัทถูกซื้อกิจการ เปลี่ยนชื่อ ควบรวม และชื่อคนก็เปลี่ยนได้จากการแต่งงาน การหย่า หรือการเลือกส่วนตัว การทำ SSO ในสตาร์ทอัพช่วงแรกยากมากจริง ๆ ทำให้ถูกต้องได้ยาก และก่อนใช้งานต้องเข้าใจแนวคิดทั่วไป รวมถึง OIDC และ OAuth2 ให้ดี Auth0 มีหนังสือดี ๆ อยู่ ถ้าไม่เข้าใจเรื่องนี้ ก็มีแนวโน้มจะไปทำการยืนยันตัวตนแบบ password grant กระจัดกระจายไปทั่ว และทำให้แอปพลิเคชันไม่ปลอดภัย

    • บางครั้งการอ่านบทความแบบนี้ช่วยลดภาวะ impostor syndrome ที่สะสมอยู่ได้บ้าง ทำให้คิดว่า “ถ้าจะเชื่อมต่อกับระบบของบุคคลที่สามเพื่อแทน actor เชิงนามธรรมบางอย่าง ก็ควรมีตัวระบุที่เชื่อถือได้ เสถียร และไม่ใช่แค่สตริงธรรมดา” จริง ๆ แล้วสเปกก็ชัดเจนมากในส่วนนี้ และมันเป็นระดับที่เกินกว่าข้อพิจารณาพื้นฐานเมื่อสร้างระบบที่แข็งแรงแม้เพียงเล็กน้อยด้วยซ้ำ

  • เหมือนภาพย่อขนาดเล็ก ๆ สิ่งที่เรียกว่า OAuth2 จริง ๆ แล้วไม่มีอยู่จริง OAuth2 เป็นเพียงวิธีให้บริษัทยักษ์ใหญ่ใช้ทำระบบยืนยันตัวตนแบบตามใจและเป็นกรรมสิทธิ์ของตัวเองเท่านั้น ไม่ใช่ระบบยืนยันตัวตน แต่เป็นกล่องเครื่องมือสำหรับสร้างระบบยืนยันตัวตน ดังนั้น OAuth2 ตั้งใจจะเป็นมาตรฐาน แต่ในความเป็นจริงกลับกลายเป็นโลกที่แต่ละบริษัทยักษ์ใหญ่มี implementation ที่เข้ากันไม่ได้ แน่นอนว่าผู้คนก็จะพัฒนาให้เข้ากับ use case ของบริษัทยักษ์ใหญ่ และเมื่อเป็นแบบนั้น “มาตรฐาน” สุดท้ายก็กลายเป็นอะไรทำนองวิธีที่ Google ทำ
    และแต่ละเจ้าก็มีบั๊กเล็ก ๆ แบบนี้ของตัวเอง ควรกลับไปใช้ OAuth1 นั่นเป็นมาตรฐานจริง ๆ ไม่ใช่กล่องเครื่องมือสำหรับสร้างมาตรฐาน

    • เรื่องนี้ไม่น่าจะเป็นบั๊กเท่าไร แต่น่าจะเป็นผลข้างเคียงที่โชคร้ายจากการที่องค์ประกอบบางอย่างมารวมกันมากกว่า เช่น ชื่อโดเมนที่เปลี่ยนเจ้าของได้, การนำอีเมลของตัวเองมาใช้, อีเมลสำรองกับแหล่งที่มาของอีเมล, การอนุญาต plus alias อย่างผ่อนปรน และผู้ implement บริการที่ไม่อ่านเอกสาร ผลคือผู้ implement คงคัดลอกวิธีแก้มาจากวิดีโอหรือจากตัวอย่างที่ตัดทอนเพื่อความกระชับ
      ถ้าจะออกแบบวงจรด้วยชิ้นส่วน PCB ไม่กี่ชิ้น และต้องใส่ตัวต้านทานกับทรานซิสเตอร์ให้ตรงกับข้อกำหนดแรงดันและกระแส เราก็ควรคาดหวังให้เขาอ่าน datasheet ไม่ใช่หรือ? ถ้าเดาแบบคร่าว ๆ จากตัวอย่างง่าย ๆ แล้วดันทุรังไป วงจรหลายกรณีก็อาจทำงานได้ และถ้าทำ bench test กับ probe บ้างก็อาจพอใช้งานได้ แต่ก็อาจมีประสิทธิภาพต่ำ หรือชิ้นส่วนลัดวงจรจนค่าเวลาเฉลี่ยก่อนเสียหายลดลงและทำให้ลูกค้าไม่พอใจ กรณีเลวร้ายที่สุด แบตเตอรี่อาจลุกไหม้จนเกิดความเสียหายจริง ๆ ได้ แล้วการที่อุปกรณ์เสียก่อนเวลาเป็นความผิดของผู้ผลิตโมดูล PCB หรือเป็นความรับผิดชอบของผู้ผลิตอุปกรณ์ที่ควรอ่าน datasheet กันแน่? ผมไม่ได้คาดหวังความเข้มงวดแบบนั้นกับซอฟต์แวร์ทั้งหมด แต่ถ้าดูแลเรื่อง authentication และ authorization เจ้าของบริการควรทำอย่างละเอียดรอบคอบ ต้นฉบับเองก็บอกว่าถ้าทำตามเอกสาร ปัญหานี้จะไม่เกิดขึ้น Alphabet จ่าย bug bounty จึงถือว่ายอมรับว่ามีจุดอ่อน ดังนั้นอาจให้ control แก่ผู้ดูแลบริษัทเพื่อจัดการ allow/deny list สำหรับ plus alias หรือ role ที่ไม่มีอยู่จริง หรือจำกัดไม่ให้ email ที่เกี่ยวข้องกับ Apps ถูกโอนไปเป็น claim นอกองค์กรได้ ตอนนี้คงกำลังวัดผลกระทบหรือจัดลำดับความสำคัญในการวัดอยู่ แต่เพราะนี่เป็นปัญหาฝั่ง client ที่สมมติว่า email claim มีอำนาจและถาวรมากกว่าความเป็นจริง ลำดับความสำคัญน่าจะต่ำ นิยามของ “บั๊ก” ขึ้นอยู่มากกับว่าเรานิยาม “พฤติกรรมที่คาดไว้” อย่างไรและใครเป็นคนคาดหวัง แต่ผมมองว่าอย่างน้อยมันก็ไม่ได้เบี่ยงเบนจากพฤติกรรมที่ตั้งใจไว้ และสำหรับคนที่เข้าใจเอกสารอย่างถูกต้องก็ไม่ใช่เรื่องเหนือความคาดหมาย
    • อืม... สมมติว่าเป็นอย่างนั้นก็ได้ แล้วความเข้ากันได้ระหว่าง provider เกี่ยวข้องอะไรกับบทความนี้ที่ว่าด้วยความปลอดภัยของ Google OAuth2?

  • ผมพลาดอะไรไปหรือเปล่า? นอกจากระบบซัพพอร์ต/Zendesk ที่บทความกล่าวถึงกับวิธีใช้โดเมนเก่าที่ถูกปล่อยทิ้งไว้ ตอนสร้างบัญชี Google ใหม่ด้วย whatever@mydomain.com ก็จะถูกขอให้ยืนยันอยู่แล้ว ถ้าอย่างนั้นความเป็นไปได้ในการนำไปโจมตีจริงมีแค่ไหน?

    • ประเด็นหลักคือทำไว้ล่วงหน้าตอนที่ยังมีสิทธิ์เข้าถึงอย่างถูกต้อง แล้วภายหลังเสียสิทธิ์นั้นไป
      เช่น สมมติว่ามีบัญชี Google egamirorrim@mydomain.com อย่างถูกต้องตามสิทธิ์ คุณสามารถสร้างบัญชี Google ใหม่ที่มีที่อยู่อีเมลที่ผ่านการยืนยันเป็น alias เช่น egamirorrim+woopsie@mydomain.com ได้ แล้วเมื่อใช้ “Sign in with Google” Google จะส่ง email claim เป็น egamirorrim+woopsie@mydomain.com ต่อมาหากถูกไล่ออกจาก mydomain.com บัญชีที่ผูกกับ egamirorrim@mydomain.com จริง ๆ จะล็อกอินไม่ได้อีก เพราะผู้ดูแลปิดใช้งานไปแล้ว แต่บัญชี Google ใหม่ egamirorrim+woopsie@mydomain.com ไม่ได้เชื่อมกับองค์กร จึงยังล็อกอินได้ต่อ อย่างไรก็ตาม ในมุมผม สิ่งนี้จะเป็นปัญหาก็ต่อเมื่อ provider ทำ authorization จาก email claim เพียงอย่างเดียว เท่านั้น ผมเคยใช้ OIDC มาก่อน และไม่ควร parse ข้อความของ email address claim เพื่อให้สิทธิ์เข้าถึง resource ผมเข้าใจว่าทำไมผู้เขียนถึงรู้สึกว่ามันขัดกับสัญชาตญาณ แต่ในบทความก็เขียนว่าเอกสารเตือนไว้ว่าอย่าทำแบบนี้ ต้นฉบับบอกว่า “ผู้ให้บริการส่วนใหญ่ที่ผมทดสอบไม่ได้ใช้ HD แต่ใช้ email claim” ก็โอเค แล้ว “ใช้” มันเพื่ออะไร? เทคนิคนี้ใช้ได้จริงกับบริการในโลกจริงหรือไม่? ถ้าใช่ก็ควรเปิดชื่อออกมาให้ถูกวิจารณ์ ถึงแม้จะสมมติผิด ๆ ว่าค่านี้ unique และ immutable แต่แค่นั้นก็ไม่ได้แปลว่าจะได้สิทธิ์เข้าถึงอะไรเสมอไป