CSA STAR Level 1

Odoo ได้เข้าร่วมในโปรแกรม CSA Security Trust Assurance and Risk (STAR)
ดูคำตอบสำหรับแบบสอบถาม CAIQv3.1 ของเรา

— Odoo Cloud (แพลตฟอร์ม) —

การสำรองข้อมูล / กู้คืนระบบ

  • เราเก็บข้อมูลสำรองทั้งหมด 14 รายการสำหรับแต่ละฐานข้อมูลบน Odoo นานสูงสุด 3 เดือน: 1 ครั้งต่อวันเป็นเวลา 7 วัน 1 ครั้งต่อสัปดาห์เป็นเวลา 4 สัปดาห์ 1 ครั้งต่อเดือนเป็นเวลา 3 เดือน
  • การสำรองข้อมูลจะถูกทำซ้ำในศูนย์ข้อมูลที่แตกต่างกันอย่างน้อย 3 แห่ง ในทวีปต่างๆ อย่างน้อย 2 แห่ง
  • สถานที่จริงของศูนย์ข้อมูลของเราระบุไว้ใน นโยบายความเป็นส่วนตัว.
  • คุณสามารถดาวน์โหลดข้อมูลสำรองด้วยตนเองได้ตลอดเวลาโดยใช้แผงควบคุม
  • คุณสามารถติดต่อฝ่าย Helpdesk ของเราเพื่อกู้คืนข้อมูลสำรองบนฐานข้อมูลที่ใช้งานจริงของคุณ (หรือแบบจำลอง)
  • ฮาร์ดแวร์ เฟลโอเวอร์: สำหรับบริการที่โฮสต์บน Bare Metal ซึ่งมีความเป็นไปได้ที่ฮาร์ดแวร์จะล้มเหลว เราจะทำการ Hot Standby ภายในเครื่อง พร้อมการตรวจสอบและขั้นตอนการเฟลโอเวอร์แบบแมนนวลที่ใช้เวลาน้อยกว่า 5 นาที
  • การกู้คืนข้อมูลเมื่อเกิดภัยพิบัติ:ในกรณีที่เกิดภัยพิบัติแบบเลวร้ายที่สุด โดยที่ศูนย์ข้อมูลทั้งหมดหยุดทำงานเป็นเวลานาน และกันการเฟลโอเวอร์ไปยังพื้นที่ Hot standby (ซึ่งยังไม่เคยเกิดขึ้นมาก่อน แต่นี่เป็นแผนกรณีที่เลวร้ายที่สุด) เรามีวัตถุประสงค์ดังต่อไปนี้:
    • RPO (Recovery Point Objective) = 24 ชั่วโมง ซึ่งหมายความว่าคุณอาจสูญเสียงานสูงสุด 24 ชั่วโมงหากไม่สามารถกู้คืนข้อมูลได้ และเราจำเป็นต้องกู้คืนข้อมูลสำรองรายวันล่าสุดของคุณ
    • RTO (Recovery Time Objective) = 24 ชั่วโมงสำหรับการสมัครสมาชิกแบบชำระเงิน และ 48 ชั่วโมงสำหรับการทดลองใช้ฟรี ข้อเสนอการศึกษา ผู้ใช้แบบฟรีเมียม และอื่นๆ นี่คือเวลาที่จะคืนค่าบริการในศูนย์ข้อมูลอื่นหากเกิดภัยพิบัติและศูนย์ข้อมูลหยุดทำงานโดยสิ้นเชิง
    • สิ่งนี้จะสำเร็จได้อย่างไร: เราเฝ้าติดตามข้อมูลสำรองรายวันของเราอย่างแข็งขัน และได้สำรองข้อมูลเหล่านี้ไว้ในหลายตำแหน่งในทวีปต่างๆ เราได้เตรียมการโดยอัตโนมัติเพื่อปรับใช้บริการของเราในสถานที่โฮสต์ใหม่ การกู้คืนข้อมูลตามข้อมูลสำรองของเราเมื่อวันก่อนสามารถทำได้ภายในไม่กี่ชั่วโมง (สำหรับคลัสเตอร์ที่ใหญ่ที่สุด) โดยให้ความสำคัญกับการสมัครสมาชิกแบบชำระเงินก่อน
      เราใช้ทั้งการสำรองข้อมูลรายวันและสคริปต์การจัดเตรียมเป็นประจำสำหรับการดำเนินการรายวัน ดังนั้นทั้งสองส่วนของขั้นตอนการกู้คืนระบบจึงได้รับการทดสอบตลอดเวลา

ความปลอดภัยของฐานข้อมูล

  • ข้อมูลลูกค้าจะถูกจัดเก็บไว้ในฐานข้อมูลเฉพาะ - จะไม่มีการแชร์ข้อมูลระหว่างลูกค้า
  • กฎการควบคุมการเข้าถึงข้อมูลจะใช้การแยกอย่างสมบูรณ์ระหว่างฐานข้อมูลของลูกค้าที่ทำงานบนคลัสเตอร์เดียวกัน การเข้าถึงจากฐานข้อมูลหนึ่งไปยังอีกฐานข้อมูลหนึ่งจะไม่สามารถทำได้

การรักษาความปลอดภัยด้วยรหัสผ่าน

  • รหัสผ่านของลูกค้าได้มีการปกป้องด้วยการเข้ารหัสมาตรฐานอุตสาหกรรม PBKDF2+SHA512 (salted + stretched เป็นพันรอบ)
  • เจ้าหน้าที่ Odoo ไม่สามารถเข้าถึงรหัสผ่านของคุณ และไม่สามารถกู้คืนรหัสผ่านให้คุณได้ แต่ถ้าหากคุณลืมรหัสผ่าน ทางเลือกเดียวคือการรีเซ็ตรหัสผ่านของคุณ
  • ข้อมูลรับรองการเข้าสู่ระบบจะถูกส่งผ่าน HTTPS ที่ปลอดภัยเสมอ
  • ผู้ดูแลระบบฐานข้อมูลลูกค้ายังมีทางเลือกในการ กำหนดค่าการจำกัดอัตรา และระยะเวลาคูลดาวน์สำหรับการพยายามเข้าสู่ระบบซ้ำ
  • นโยบายรหัสผ่าน: ผู้ดูแลระบบฐานข้อมูลมีการตั้งค่าในตัวเพื่อบังคับใช้ความยาวรหัสผ่านผู้ใช้ขั้นต่ำ นโยบายรหัสผ่านอื่นๆ เช่น คลาสของตัวอักษรที่จำเป็น ไม่ได้รับการสนับสนุนโดยค่าเริ่มต้น เนื่องจากได้รับการพิสูจน์แล้ว ว่าไม่มีประสิทธิภาพ ดูตัวอย่าง [Shay et al. 2016]), เช่นเดียวกับ NIST SP 800-63b.

การเข้าถึงของพนักงาน

  • เจ้าหน้าที่ฝ่าย Helpdesk ของ Odoo อาจลงชื่อเข้าใช้บัญชีของคุณเพื่อเข้าถึงการตั้งค่าที่เกี่ยวข้องกับปัญหาที่คุณได้พบ สำหรับเรื่องนี้ พวกเขาจะใช้ข้อมูลประจำตัวพนักงานพิเศษของพวกเขาเข้าระบบเอง และจะไม่ใช้รหัสผ่านของคุณ (ซึ่งพวกเขาจะไม่มีทางรู้ถึงรหัสผ่านของคุณได้)
  • การเข้าถึงพนักงานแบบพิเศษนี้จะช่วยพัฒนาประสิทธิภาพและความปลอดภัย: พวกเขาสามารถจำลองปัญหาที่คุณพบได้ทันที คุณไม่จำเป็นต้องเปิดเผยรหัสผ่านของคุณ และเราสามารถตรวจสอบ และควบคุมการดำเนินการของพนักงานแยกกันได้!
  • เจ้าหน้าที่ Helpdesk ของเรามุ่งมั่นที่จะเคารพความเป็นส่วนตัวของคุณให้มากที่สุด การเข้าถึงไฟล์เฉพาะและการตั้งค่าที่จำเป็นในการประเมินและแก้ไขปัญหาของคุณ

ความปลอดภัยของระบบ

  • เซิร์ฟเวอร์ Odoo Cloud ทั้งหมดกำลังเรียกใช้การกระจาย Linux ที่เสริมประสิทธิภาพด้วยแพตช์ที่อัปเดตล่าสุดและมีความปลอดภัย
  • การติดตั้งเป็นแบบเฉพาะกิจและจำกัดจำนวนการบริการที่อาจมีช่องโหว่ (ไม่มี PHP/MySQL stack เป็นต้น)
  • จะมีวิศวกรของ Odoo ที่เชื่อถือได้เพียงไม่กี่คนเท่านั้นที่ได้รับอนุญาตให้จัดการเซิร์ฟเวอร์จากระยะไกล และการเข้าถึงสามารถทำได้โดยใช้คู่กุญแจ SSH ส่วนบุคคลที่เข้ารหัสเท่านั้น และดำเนินการจากคอมพิวเตอร์ที่มีการเข้ารหัสทั้งดิสก์

ความปลอดภัยเชิงกายภาพ

เซิร์ฟเวอร์ Odoo Cloud โฮสต์อยู่ในศูนย์ข้อมูลที่เชื่อถือได้ในภูมิภาคต่างๆของโลก (เช่น OVH, Google Cloud) และเซิร์ฟเวอร์ทั้งหมดต้องเกินเกณฑ์ความปลอดภัยโดยธรรมชาติของเรา:

  • ขอบเขตที่ถูกจำกัด สามารถเข้าถึงได้โดยพนักงานศูนย์ข้อมูลที่ได้รับอนุญาตเท่านั้น
  • ควบคุมการเข้าถึงเชิงกายภาพ ด้วยป้ายความปลอดภัยหรือการรักษาความปลอดภัยแบบไบโอเมตริกซ์
  • กล้องรักษาความปลอดภัยตรวจสอบตำแหน่งของศูนย์ข้อมูลตลอด 24 ชั่วโมงทุกวัน
  • เจ้าหน้าที่รักษาความปลอดภัยอยู่บนเว็บไซต์ตลอด 24 ชั่วโมงทุกวัน

ความปลอดภัยของบัตรเครดิต

การเข้ารหัสข้อมูล

ข้อมูลลูกค้าจะถูกถ่ายโอนและจัดเก็บในรูปแบบการเข้ารหัสเสมอ (การเข้ารหัสระหว่างการส่งและทั้งหมดที่เหลือ)
  • การสื่อสารข้อมูลทั้งหมดไปยังอินสแตนซ์ของลูกค้าได้รับการปกป้องด้วยการเข้ารหัส SSL (HTTPS) 256 บิตที่ล้ำสมัย
  • การสื่อสารข้อมูลภายในทั้งหมดระหว่างเซิร์ฟเวอร์ของเรายังได้รับการปกป้องด้วยการเข้ารหัสที่ล้ำสมัย (SSH)
  • เซิร์ฟเวอร์ของเราอยู่ภายใต้การเฝ้าระวังความปลอดภัยที่เข้มงวด และได้รับการปรับปรุงแก้ไขช่องโหว่ SSL อยู่เสมอ เกรด A การจัดอันดับ SSL ตลอดเวลา
  • ใบรับรอง SSL ทั้งหมดของเราใช้โมดูลัส 2048 บิตที่มีประสิทธิภาพ พร้อมเชนใบรับรอง SHA-2 อย่างเต็มรูปแบบ
  • ข้อมูลของลูกค้าทั้งหมด (เนื้อหาฐานข้อมูลและไฟล์ที่เก็บไว้) ได้รับการเข้ารหัสเมื่อไม่มีการใช้งาน ทั้งในการผลิตและในการสำรองข้อมูล (AES-128 หรือ AES-256)

เครือข่าย  การป้องกัน

  • ผู้ให้บริการศูนย์ข้อมูลทั้งหมดที่ใช้โดย Odoo Cloud มีความจุของเครือข่ายขนาดใหญ่ และได้ออกแบบโครงสร้างพื้นฐานมาให้ทนทานต่อการถูกโจมตีแบบ Distributed Denial of Service (DDoS) ที่ใหญ่ที่สุด ระบบลดผลกระทบแบบอัตโนมัติและแบบแมนนวลสามารถตรวจจับและเบี่ยงเบนทราฟฟิกการโจมตีของเครือข่ายหลายทวีป ก่อนที่ระบบจะขัดขวางความพร้อมใช้งานของบริการ
  • ไฟร์วอลล์และระบบป้องกันการบุกรุกบนเซิร์ฟเวอร์ Odoo Cloud ช่วยตรวจจับและบล็อกภัยคุกคามต่างๆ เช่น การโจมตีด้วยรหัสผ่านแบบบังคับที่มีจุดประสงค์ร้าย
  • ผู้ดูแลระบบฐานข้อมูลลูกค้ายังมีทางเลือกในการ กำหนดค่าการจำกัดอัตรา และระยะเวลาคูลดาวน์สำหรับการพยายามเข้าสู่ระบบซ้ำๆ

— Odoo (ซอฟแวร์) —

ความปลอดภัยของซอฟต์แวร์

Odoo เป็นโอเพนซอร์ส ดังนั้น codebase ทั้งหมดจึงอยู่ภายใต้การตรวจสอบอย่างต่อเนื่องจากผู้ใช้ Odoo และผู้ร่วมให้ข้อมูลทั่วโลก การรายงานจุดบกพร่องของ Community จึงเป็นแหล่งความคิดเห็นที่สำคัญแหล่งหนึ่งเกี่ยวกับความปลอดภัย เราสนับสนุนให้นักพัฒนาตรวจสอบรหัสและรายงานปัญหาด้านความปลอดภัยอยู่ตลอดเวลา

กระบวนการ R&D ของ Odoo มีขั้นตอนการตรวจสอบโค้ดที่รวมถึงแง่มุมด้านความปลอดภัย สำหรับโค้ดใหม่และโค้ดร่วม

ออกแบบมาเพื่อความปลอดภัย

Odoo ได้รับการออกแบบในลักษณะที่ป้องกันไม่ให้เกิดช่องโหว่ด้านความปลอดภัยทั่วไป:

  • การแทรก SQL จะถูกป้องกันโดยการใช้ API ระดับสูงกว่า ซึ่งไม่ต้องการการสืบค้น SQL ด้วยตนเอง
  • การโจมตี XSS สามารถป้องกันได้โดยการใช้ระบบเทมเพลตระดับสูงที่ทำการหลบหลีกข้อมูลที่ถูกแทรกโดยอัตโนมัติ
  • เฟรมเวิร์กป้องกันการเข้าถึง RPC ด้วยวิธีแบบส่วนตัว ทำให้ยากต่อการแนะนำช่องโหว่ที่เจาะจงได้

ดูเพิ่มเติมที่ ช่องโหว่อันดับต้นๆ ของ OWASP เพื่อดูว่า Odoo ได้รับการออกแบบตั้งแต่เริ่มต้นอย่างไรเพื่อป้องกันช่องโหว่ดังกล่าวไม่ให้ปรากฎขึ้นมา

การตรวจสอบความปลอดภัยแบบอิสระ

Odoo ได้รับการตรวจสอบอย่างสม่ำเสมอโดยบริษัทอิสระที่ได้รับการว่าจ้างจากลูกค้าและผู้ที่มีแนวโน้มจะเป็นลูกค้าของเรา ให้ทำการตรวจสอบและทดสอบการเจาะระบบ ทีมรักษาความปลอดภัยของ Odoo ได้รับผลลัพธ์และใช้มาตรการแก้ไขที่เหมาะสมตามความจำเป็น

อย่างไรก็ตาม เราไม่สามารถเปิดเผยผลลัพธ์ได้ เนื่องจากผลลัพธ์เหล่านี้เป็นความลับและเป็นของกรรมาธิการ โปรดอย่าถาม ;-)

นอกจากนี้ Odoo ยังมีชุมชนนักวิจัยด้านความปลอดภัยอิสระที่กระตือรือร้น ซึ่งคอยตรวจสอบซอร์สโค้ดอย่างต่อเนื่องและทำงานร่วมกับเราเพื่อปรับปรุงและเพิ่มความปลอดภัยให้กับ Odoo ในส่วนของโปรแกรมความปลอดภัยของเรามีอธิบายไว้ใน การเปิดเผยข้อมูลอย่างมีความรับผิดชอบ หน้า

ช่องโหว่อันดับต้นๆ ของ OWASP

นี่คือสาเหตุที่ Odoo สามารถอยู่เหนือปัญหาของความปลอดภัยได้เป็นอันดับต้นๆ สำหรับเว็บแอปพลิเคชัน ตามที่ระบุไว้โดย Open Web Application Security Project (OWASP):

  • Injection Flaws:โดยเฉพาะอย่างยิ่งการแทรก SQL นั้นมีอยู่ทั่วไปในเว็บแอปพลิเคชัน การแทรกจะเกิดขึ้นเมื่อข้อมูลที่ผู้ใช้ระบุถูกส่งไปแปลงเป็นส่วนหนึ่งของคำสั่งหรือแบบสอบถาม ข้อมูลที่ประสงค์ร้ายของผู้โจมตีจะหลอกผู้แปลงให้ดำเนินการคำสั่งที่ไม่ได้ตั้งใจหรือให้เปลี่ยนแปลงข้อมูล

    Odoo อาศัยเฟรมเวิร์ก Object-Relational-Mapping (ORM) เพื่อสรุปการสร้างแบบสอบถามและป้องกันการแทรก SQL ตามค่าเริ่มต้น โดยปกติแล้วนักพัฒนาซอฟต์แวร์จะไม่สร้างการสืบค้น SQL ด้วยตนเอง แต่มันจะถูกสร้างขึ้นโดย ORM และพารามิเตอร์จะถูก Escape อย่างถูกต้องเสมอ

  • Cross Site Scripting (XSS): ข้อบกพร่อง XSS เกิดขึ้นเมื่อแอปพลิเคชันนำข้อมูลที่ผู้ใช้ให้มาและส่งไปยังเว็บเบราว์เซอร์โดยไม่ได้ตรวจสอบความถูกต้องหรือเข้ารหัสเนื้อหานั้นก่อน XSS ช่วยให้ผู้โจมตีเรียกใช้สคริปต์ในเบราว์เซอร์ของเหยื่อ ซึ่งสามารถจี้เซสชันของผู้ใช้ ทำให้เว็บไซต์เสียหาย และอาจทำให้หนอนคอมพิวเตอร์หรือมัลแวร์เข้ามาได้ เป็นต้น

    เฟรมเวิร์ก Odoo หลีกเลี่ยงตัวสั่งงานทั้งหมดที่แสดงผลในมุมมองและเพจตามค่าเริ่มต้น ป้องกัน XSS นักพัฒนาต้องทำเครื่องหมายตัวสั่งงานว่า "ปลอดภัย" เป็นพิเศษสำหรับการรวมข้อมูลดิบในหน้าที่แสดงผล

  • Cross Site Request Forgery (CSRF): การโจมตี CSRF บังคับให้เบราว์เซอร์ของเหยื่อที่เข้าสู่ระบบส่งคำขอ HTTP ปลอม รวมถึงคุกกี้เซสชันของเหยื่อและข้อมูลการตรวจสอบอื่นๆ ที่รวมโดยอัตโนมัติไปยังเว็บแอปพลิเคชันที่มีช่องโหว่ ซึ่งช่วยให้ผู้โจมตีสามารถบังคับให้เบราว์เซอร์ของเหยื่อสร้างคำขอที่แอปพลิเคชันที่มีช่องโหว่คิดว่าเป็นคำขอที่ถูกต้องจากเหยื่อ

    เครื่องมือเว็บไซต์ Odoo มีกลไกการปกป้อง CSRF ในตัว ป้องกันไม่ให้คอนโทรลเลอร์ HTTP ใด รับคำขอ POST โดยไม่มีโทเค็นความปลอดภัยที่เกี่ยวข้อง นี่เป็นเทคนิคที่ถูกแนะนำสำหรับการป้องกัน CSRF โทเค็นการรักษาความปลอดภัยนี้จะเป็นที่รู้จักและมีอยู่ก็ต่อเมื่อผู้ใช้เข้าถึงแบบฟอร์มเว็บไซต์ที่เกี่ยวข้องอย่างแท้จริง และผู้โจมตีจะไม่สามารถปลอมแปลงคำขอได้หากไม่มีโทเค็นดังกล่าว

  • การดำเนินการไฟล์ที่มีการประสงค์ร้าย: รหัสที่เสี่ยงต่อการรวมไฟล์ระยะไกล (RFI) ทำให้ผู้โจมตีสามารถรวมรหัสและข้อมูลที่ประสงค์ร้าย ส่งผลให้เกิดการโจมตีที่รุนแรง เช่น การบุกรุกเซิร์ฟเวอร์ทั้งหมด

    Odoo ไม่เปิดเผยฟังก์ชันเพื่อทำการรวมไฟล์ระยะไกล อย่างไรก็ตาม อนุญาตให้ผู้ใช้ที่มีสิทธิ์ปรับแต่งฟีเจอร์โดยเพิ่มตัวสั่งงานแบบกำหนดเองซึ่งระบบจะประเมิน ตัวสั่งงานเหล่านี้ได้รับการประเมินเสมอโดยสภาพแวดล้อมแบบแซนด์บ็อกซ์และสะอาด ซึ่งอนุญาตให้เข้าถึงได้เฉพาะฟังก์ชันที่ได้รับอนุญาตเท่านั้น

  • Insecure Direct Object Reference (IDOR): ช่องโหว่การอ้างอิงวัตถุโดยตรง จะเกิดขึ้นเมื่อนักพัฒนาเปิดเผยการอ้างอิงไปยังวัตถุการใช้งานภายใน เช่น ไฟล์ ไดเร็กทอรี บันทึกฐานข้อมูล หรือคีย์ เป็น URL หรือแบบฟอร์มพารามิเตอร์ ผู้โจมตีสามารถปรับเปลี่ยนการอ้างอิงเหล่านั้นเพื่อเข้าถึงวัตถุอื่นๆ โดยไม่ได้รับอนุญาต

    การเข้าถึง Odoo ไม่ได้ใช้งานที่ระดับอินเทอร์เฟซผู้ใช้ ดังนั้นจึงไม่มีความเสี่ยงในการเปิดเผยการอ้างอิงไปยังวัตถุภายในของ URL ผู้โจมตีไม่สามารถหลีกเลี่ยงชั้นการควบคุมการเข้าถึงโดยจัดการการอ้างอิงเหล่านั้น เนื่องจากทุกคำขอยังคงต้องผ่านชั้นการตรวจสอบความถูกต้องของการเข้าถึงข้อมูล

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

    Odoo ใช้การแฮชที่ปลอดภัยตามมาตรฐานอุตสาหกรรมสำหรับรหัสผ่านของผู้ใช้ (โดยค่าเริ่มต้น PKFDB2 + SHA-512 พร้อมการยืดคีย์) เพื่อปกป้องรหัสผ่านที่เก็บไว้ นอกจากนี้ยังเป็นไปได้ที่จะใช้ระบบตรวจสอบความถูกต้องจากภายนอก เช่น OAuth 2.0 หรือ LDAP เพื่อหลีกเลี่ยงการจัดเก็บรหัสผ่านของผู้ใช้ไว้ในเครื่อง

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

    Odoo Cloud ทำงานบน HTTPS ตามค่าเริ่มต้น สำหรับการติดตั้งภายในองค์กร ขอแนะนำให้เรียกใช้ Odoo หลังเว็บเซิร์ฟเวอร์ที่ใช้คำขอเข้ารหัสและพร็อกซีไปยัง Odoo เช่น Apache, Lighttpd หรือ nginx คู่มือการปรับใช้ Odoo ประกอบด้วย รายการตรวจสอบความปลอดภัย เพื่อการใช้งานสาธารณะที่ปลอดภัยยิ่งขึ้น

  • ไม่สามารถจำกัดการเข้าถึง URL ได้: บ่อยครั้งที่แอปพลิเคชันปกป้องเฉพาะฟังก์ชันการทำงานที่ละเอียดอ่อนโดยป้องกันการแสดงลิงก์หรือ URL ต่อผู้ใช้ที่ไม่ได้รับอนุญาต เพราะว่าผู้โจมตีสามารถใช้จุดอ่อนนี้เพื่อรับการเข้าถึงและดำเนินการโดยไม่ได้รับอนุญาตด้วยการเข้าถึง URL เหล่านั้นโดยตรง

    การเข้าถึง Odoo ไม่ได้ใช้งานที่ระดับอินเทอร์เฟซผู้ใช้ และการรักษาความปลอดภัยไม่ได้ขึ้นอยู่กับการซ่อน URL พิเศษ ผู้โจมตีไม่สามารถหลีกเลี่ยงเลเยอร์ควบคุมการเข้าถึงได้ด้วยการใช้ซ้ำหรือปรับเปลี่ยน URL ใดๆ เนื่องจากทุกคำขอยังคงต้องผ่านเลเยอร์การตรวจสอบการเข้าถึงข้อมูล ในบางกรณีซึ่งเกิดขึ้นไม่บ่อยนักที่ URL ให้การเข้าถึงข้อมูลที่ละเอียดอ่อนโดยไม่ผ่านการพิสูจน์ตัวตน เช่น URL พิเศษที่ลูกค้าใช้ในการยืนยันคำสั่งซื้อ URL เหล่านี้จะเซ็นชื่อแบบดิจิทัลด้วยโทเค็นเฉพาะ และส่งทางอีเมลไปยังผู้รับที่ต้องการเท่านั้น

รายงานความเสี่ยงด้านความปลอดภัย

หากคุณต้องการรายงานช่องโหว่เรื่องความปลอดภัย โปรดติดต่อไปที่ หน้าการเปิดเผยข้อมูลอย่างรับผิดชอบ. การรายงานเหล่านี้ได้รับการปฏิบัติด้วยลำดับความสำคัญสูง ทีมรักษาความปลอดภัยของ Odoo และความร่วมมือจากผู้สื่อข่าว จะประเมินและแก้ไขทันที เปิดเผยอย่างมีความรับผิดชอบต่อลูกค้าและผู้ใช้ Odoo