ความปลอดภัย Bug Bounty

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

ความมุ่งมั่นของเรา

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

  • เรามุ่งมั่นที่จะตอบรับทุกรายงานภายใน 48 ชั่วโมงและจะอัปเดตคุณตลอดกระบวนการแก้ไข

  • ขึ้นอยู่กับความรุนแรงและผลกระทบของการค้นพบของคุณ คุณอาจมีสิทธิ์ได้รับเครื่องหมายโปรไฟล์เอกสิทธิ์และเดือนฟรีของการสมัครสมาชิก PLUS ของเรา

เครื่องหมายนักวิจัย

นักวิจัยที่มีส่วนร่วมอย่างมีความหมายต่อความปลอดภัยของ Snipp สามารถได้รับเครื่องหมายโปรไฟล์ที่แสดงต่อสาธารณะในบัญชีของพวกเขา

นักล่าบั๊ก

มอบให้สำหรับรายงานช่องโหว่ที่ถูกต้องครั้งแรกของคุณ ยกย่องนักวิจัยที่ช่วยทำให้ Snipp ปลอดภัยยิ่งขึ้น

นักล่าบั๊กระดับสูง

มอบให้หลังจากรายงานที่ยอดเยี่ยม 3-5 ครั้ง หรือการค้นพบที่สำคัญร้ายแรงเพียงครั้งเดียว สงวนไว้สำหรับนักวิจัยที่กระตือรือร้นซึ่งค้นพบปัญหาที่มีผลกระทบมากที่สุด

แนวทาง

  • การทดสอบทั้งหมดต้องทำกับบัญชีของคุณเอง ห้ามโต้ตอบหรือส่งผลกระทบต่อข้อมูลหรือบัญชีของผู้ใช้คนอื่น

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

  • หลีกเลี่ยงกิจกรรมใดๆ ที่อาจทำให้บริการของเราเสื่อมลงหรือทำให้ความสมบูรณ์ของข้อมูลเสียหาย รวมถึง brute forcing, DoS, การสแปม และการโจมตีแบบ timing

  • ห้ามใช้เครื่องมือสแกนอัตโนมัติ การทดสอบทั้งหมดควรทำด้วยมือ

  • เราอาจยกเว้นช่องโหว่บางประเภทออกจากขอบเขตชั่วคราวขณะที่เรากำลังจัดการภายใน การเปลี่ยนแปลงใดๆ จะถูกสะท้อนในหน้านี้

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

วิธีที่เราจัดการกับรายงาน

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

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

หากมีหลายคนรายงานปัญหาเดียวกัน เราจะประเมินการส่งโดยพิจารณาจาก:

  • ความชัดเจนของคำอธิบายทางเทคนิค

  • รายงานสื่อสารผลกระทบในโลกแห่งความจริงได้ดีเพียงใด

  • การประทับเวลาของการส่ง

รายงานต้องแสดงให้เห็นถึงผลกระทบที่เกิดขึ้นจริง คะแนน CVSS เพียงอย่างเดียวโดยไม่มีหลักฐานเชิงพิสูจน์ (proof of concept) ที่ใช้งานได้จริงซึ่งแสดงว่าผู้โจมตีได้อะไรจริง ๆ จะถือเป็นเพียงข้อมูลประกอบและไม่มีสิทธิ์ได้รับรางวัล

เราซาบซึ้งใจกับนักวิจัยทุกคนที่สละเวลาช่วยให้ Snipp ปลอดภัยขึ้น

เปิดเผยต่อสาธารณะโดยการออกแบบ

ข้อมูลบางอย่างเปิดเผยต่อสาธารณะโดยเจตนา ข้อมูลที่ปรากฏอยู่แล้วบนหน้าสาธารณะไม่ถือเป็นความลับ และการอ่านข้อมูลดังกล่าวไม่ว่าจะผ่านเว็บไซต์ ผ่านปลายทาง API หรือขณะออกจากระบบ ก็ไม่ถือเป็นช่องโหว่ ก่อนรายงานการเปิดเผยข้อมูล โปรดตรวจสอบว่าข้อมูลเดียวกันนั้นแสดงต่อสาธารณะอยู่แล้วหรือไม่ รายการต่อไปนี้เปิดเผยต่อสาธารณะโดยการออกแบบ:

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

  • ตราโปรไฟล์และสถานะที่อยู่เบื้องหลัง รวมถึงทีมงาน พาร์ทเนอร์ นักล่าบั๊ก นักแปล ยืนยันแล้ว และผู้สนับสนุน รายการเหล่านี้แสดงต่อสาธารณะในรูปแบบของตรา

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

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

สิ่งที่ไม่อยู่ในขอบเขต

ก่อนส่ง คิดให้รอบคอบว่าปัญหามีสถานการณ์การโจมตีที่สมจริงและมีผลกระทบด้านความปลอดภัยที่มีความหมายหรือไม่ ต่อไปนี้มักจะถูกแยกออก:

  • การเปิดเผยข้อมูลที่เปิดเผยต่อสาธารณะโดยการออกแบบอยู่แล้ว (ดูส่วนด้านบน) รวมถึงฟิลด์โปรไฟล์ ตรา ข้อมูลเมตาของโพสต์ และแฟล็กที่อิงกับผู้ชม

  • รายงานที่อ้างอิงจากการตรวจสอบความถูกต้องฝั่งไคลเอนต์เพียงอย่างเดียว การตรวจสอบด้านความปลอดภัยถูกบังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ดังนั้นการขาดการตรวจสอบฝั่งไคลเอนต์จึงไม่ถือเป็นช่องโหว่เมื่อเซิร์ฟเวอร์ปฏิเสธอินพุตเดียวกัน

  • การจัดการประเภทไฟล์ MIME หรือนามสกุลไฟล์ในการอัปโหลด ไฟล์ที่อัปโหลดจะถูกตรวจสอบจากเนื้อหาจริงที่ฝั่งเซิร์ฟเวอร์ และประเภทที่จัดเก็บจะไม่เคยนำมาจากไคลเอนต์

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

  • ระเบียน DNS ที่ล้าสมัยหรือเป็นข้อมูลเก่าซึ่งไม่ได้ชี้ไปยังโครงสร้างพื้นฐานที่ใช้งานอยู่อีกต่อไป

  • เฮดเดอร์ด้านความปลอดภัยที่ขาดหายไปหรือกำหนดค่าผิดพลาด เช่น CSP, HSTS หรือ X-Frame-Options โดยไม่มีการแสดงการใช้ประโยชน์ที่ใช้งานได้จริง

  • ข้อความแสดงข้อผิดพลาดที่ละเอียดเกินไป สแต็กเทรซ หรือการเปิดเผยเวอร์ชันซอฟต์แวร์ โดยไม่มีการแสดงการใช้ประโยชน์ที่ใช้งานได้จริง

  • การแจกแจงทรัพยากรที่ถูกต้องด้วยตัวระบุ หรือการตอบกลับ 4xx และ 5xx ต่อตัวระบุที่ไม่ถูกต้อง การส่งคืนสถานะไม่พบสำหรับคำขอที่ไม่ถูกต้องเป็นพฤติกรรมที่คาดหวังไว้

  • การระบุบัญชี

  • การโจมตีที่ต้องใช้ MITM หรือการเข้าถึงอุปกรณ์ของผู้ใช้ทางกายภาพ

  • Clickjacking

  • การปลอมแปลงเนื้อหาและการแทรกข้อความ

  • ช่องโหว่ CSRF

  • บันทึก SPF, DKIM และ DMARC ของอีเมล

  • การไม่มี HttpOnly/Secure cookie flags

  • ส่วนหัว CORS แบบเปิด

  • การจำกัดอัตรา

  • รายงานจากสแกนเนอร์และเครื่องมืออัตโนมัติ

  • การใช้ประโยชน์ตนเอง (เช่น การใช้โทเค็นซ้ำและการสคริปต์คอนโซล)

  • การโจมตีแบบ social engineering หรือ phishing ที่กำหนดเป้าหมายผู้ใช้หรือพนักงาน

หมายเหตุเพิ่มเติม

บริการของบุคคลที่สาม

บริการภายนอก พันธมิตร และการรวมระบบอยู่นอกขอบเขตของโปรแกรมนี้ เฉพาะช่องโหว่ในคุณสมบัติและ API ที่ Snipp เป็นเจ้าของเท่านั้นที่ผ่านเกณฑ์ รายงานต้องแสดงผลกระทบด้านความปลอดภัยที่ชัดเจนต่อ Snipp เอง

การโจรกรรม Credential และ Token

สถานการณ์ใดๆ ที่ผู้โจมตีอาจได้รับ API keys, session tokens หรือ credentials ของผู้ใช้คนอื่นโดยไม่อาศัย social engineering ถือว่าอยู่ในขอบเขต

การล่มของเว็บไซต์

การล่มของเว็บไซต์ที่ทำซ้ำได้ ซึ่งเกิดจาก input ที่สร้างขึ้นหรือการโต้ตอบของผู้ใช้ปกติ ถือว่าอยู่ในขอบเขต โดยที่ไม่ขึ้นอยู่กับการใช้ทรัพยากรจนหมด สแปม หรือเทคนิค denial-of-service อื่นๆ

Race Conditions

รายงานที่ขึ้นอยู่กับการใช้ประโยชน์ race condition ต้องการหลักฐานเพิ่มเติมเพื่อให้ได้รับการยอมรับ กรุณาใส่อย่างน้อยหนึ่งอย่างต่อไปนี้:

  • สคริปต์ที่ทำซ้ำได้ (Python หรือ JavaScript เป็นที่ต้องการ แต่ภาษาอื่นๆ ก็ใช้ได้)

  • การเขียนอธิบายอย่างละเอียดครอบคลุม HTTP methods, endpoints และการเรียงลำดับคำขอที่แน่นอนที่จำเป็นในการกระตุ้นเงื่อนไข

การรวมสคริปต์ทำให้เราตรวจสอบปัญหาได้ง่ายขึ้นมากและเร่งกระบวนการตรวจสอบ

พบบางอย่างหรือไม่?

ส่งอีเมลถึงเราพร้อมคำอธิบายปัญหาที่ชัดเจน ขั้นตอนการทำซ้ำ และหลักฐานสนับสนุนใดๆ เราจะติดต่อกลับให้เร็วที่สุดเท่าที่จะทำได้

บทความเพิ่มเติม