การสร้าง VDP

นโยบายโปรแกรมเป็นสิ่งสําคัญสําหรับ VDP และต้องมีการสร้างอย่างละเอียดรอบคอบ นโยบายโปรแกรมเป็นสิ่งแรกที่นักวิจัยด้านความปลอดภัยจะเห็นเมื่อเข้าร่วมใน VDP โดยจะกำหนดแนวทางสำหรับโปรแกรม กำหนดความคาดหวัง และกำหนดคำมั่นสัญญาที่มีต่อนักวิจัยที่เลือกเข้าร่วม

วิธีสร้างและโฮสต์นโยบายโปรแกรม

ใช้หลักเกณฑ์ด้านล่างเพื่อร่างนโยบายโปรแกรมสำหรับ VDP ของคุณ นโยบายโปรแกรมมักจะยาวเพียง 1-3 หน้า และมักจะมีหัวข้อต่อไปนี้ด้วย

  • นักวิจัยสัญญา
  • หลักเกณฑ์การตรวจหาเชื้อไวรัส
  • ขอบเขตของโปรแกรม

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

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

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

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

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

ผู้มีส่วนเกี่ยวข้องกับนโยบายโปรแกรม

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

ผู้มีส่วนเกี่ยวข้อง ข้อควรพิจารณา
กฎหมาย
  • ทำงานร่วมกับทีมกฎหมายเพื่อร่างนโยบายโปรแกรมและข้อกำหนดที่แฮ็กเกอร์จะเข้าร่วม
  • นักวิจัยไม่ได้รับค่าตอบแทนใดๆ จึงไม่มีเหตุผลอันดีที่จะต้องทำตามข้อกำหนดการเริ่มต้นใช้งานที่ครอบคลุมหรือเงื่อนไขต่างๆ ที่สร้างภาระได้
ไอที
  • ทำงานร่วมกับทีมไอทีเพื่อช่วยพัฒนาข้อกำหนดการทดสอบและกำหนดขอบเขต เช่น ไม่สร้างเงื่อนไขการปฏิเสธการให้บริการ
วิศวกรรมศาสตร์
  • ทีมวิศวกรอาจมีข้อมูลด้านข้อกำหนดและขอบเขตการทดสอบ รวมถึงประเภทของช่องโหว่ที่น่าสนใจมากที่สุดหรือน้อยที่สุด
PR
  • ทำงานร่วมกับทีมประชาสัมพันธ์ของคุณเพื่อตรวจสอบข้อความเกี่ยวกับนโยบายเกี่ยวกับการเปิดเผยข้อมูล
ความปลอดภัย
  • โดยปกติแล้วทีมรักษาความปลอดภัยจะเป็นหัวหน้าทีมจัดทำนโยบาย
  • ทีมรักษาความปลอดภัยมักจะได้รับความคิดเห็นจากแฮกเกอร์และทบทวนนโยบายกับผู้มีส่วนเกี่ยวข้องคนอื่นๆ เมื่อเวลาผ่านไป

คำมั่นสัญญาจากนักวิจัย

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

ตัวอย่าง

<ชื่อองค์กรของคุณ> มุ่งมั่นที่จะทำงานร่วมกับนักวิจัยด้านความปลอดภัยเพื่อช่วยระบุและแก้ไขช่องโหว่ในระบบและบริการ ตราบใดที่คุณกระทำการโดยมีเจตนาดีและปฏิบัติตามหลักเกณฑ์ที่ระบุไว้ในนโยบายนี้ เราจะพยายามอย่างเต็มที่ที่จะดำเนินการตาม สิ่งต่อไปนี้
  • ตอบกลับเบื้องต้นสำหรับรายงานช่องโหว่ภายใน 3 วันทำการ
  • ตัดสินใจว่าจะยอมรับ (ตั้งใจแก้ไข) หรือปฏิเสธ (ระบุว่ารายงานเป็นความเสี่ยงที่เป็นผลบวกลวงหรือความเสี่ยงที่ยอมรับได้) รายงานช่องโหว่ของคุณภายใน 10 วันทำการ
  • แจ้งให้คุณทราบเกี่ยวกับความคืบหน้าล่าสุดในการแก้ไขรายงานที่เรายอมรับจากคุณ

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

หลักเกณฑ์การตรวจหาเชื้อไวรัส

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

ตัวอย่าง:
เมื่อทำการทดสอบความปลอดภัย โปรดปฏิบัติตามหลักเกณฑ์ต่อไปนี้

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


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

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


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

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

ขอบเขต

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

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

ชิ้นงาน mail.example.com
คำอธิบาย โดเมนหลักสำหรับผู้ใช้ในการเข้าถึงอีเมล
ช่องโหว่และผลกระทบที่น่าสนใจ
  • ช่องโหว่ที่ส่งผลให้เกิดการเข้าถึงอีเมลของผู้ใช้รายอื่นโดยไม่ได้รับอนุญาต
  • ความสามารถในการลบอีเมลหรือทั้งบัญชีของผู้ใช้รายอื่นโดยไม่สามารถกู้คืนได้
ปัญหาที่มีแนวโน้มจะถูกปฏิเสธ
  • SPF
  • ฟิชชิงหรือปัญหาที่นำไปสู่ฟิชชิง
  • ความสามารถในการส่งไฟล์แนบที่อาจเป็นอันตราย
คำแนะนำในการทดสอบ ทดสอบกับบัญชีที่คุณเป็นเจ้าของหรือได้รับความยินยอมที่ชัดเจนให้ทดสอบเท่านั้น เมื่อสร้างบัญชีทดสอบ โปรดใส่ "vdptest" ไว้ที่ใดที่หนึ่งในชื่อผู้ใช้ คุณสามารถสร้างบัญชีทดสอบได้ที่ mail.example.com/new

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

ขอบเขต

  • mail.example.com
  • example.com

อยู่นอกขอบเขต

  • blog.example.com

การระบุแหล่งที่มา VDP

คุณจะต้องมีทรัพยากรบางอย่างให้พร้อมก่อนเปิดตัว VDP คุณจะต้องมีแหล่งข้อมูลสำหรับ

  • กำลังตรวจสอบรายงานช่องโหว่ขาเข้า
  • การสื่อสารกับแฮ็กเกอร์
  • การค้นหาเจ้าของเนื้อหาและการส่งข้อบกพร่อง
  • การแก้ไขข้อบกพร่อง
  • การจัดการช่องโหว่ / ติดตามผลการแก้ไข

กลับไปเยือนผู้มีส่วนเกี่ยวข้องคนสำคัญ

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

สร้างทีมของคุณ

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

สร้างกำหนดเวลาที่ทำงาน

เมื่อคุณมีทรัพยากรอยู่ในระบบและพร้อมช่วยเหลือเกี่ยวกับ VDP แล้ว ก็ให้กำหนดโครงสร้างการทำงานโดยการกำหนดตารางเวลาในหน้าที่ คุณสร้าง URL นี้ได้ตามต้องการ แต่การหมุนเวียนรายสัปดาห์เป็นเรื่องปกติ เมื่อคุณปฏิบัติหน้าที่ทั้งสัปดาห์ คุณมีหน้าที่ดำเนินการต่อไปนี้

  • Triage - ตรวจสอบรายงานช่องโหว่ที่เข้ามาใหม่
    • ตรวจสอบรายงานทางเทคนิค แล้วเลือก "ยอมรับ" หรือ "ปฏิเสธ"
    • แจ้งการตัดสินใจของคุณให้แฮ็กเกอร์ที่รายงานปัญหาทราบ
    • หากจำเป็น ให้ขอข้อมูลเพิ่มเติมจากแฮกเกอร์หากคุณไม่สามารถ ทำให้ปัญหาเกิดซ้ำได้
    • หากช่องโหว่นี้ถูกต้อง ให้ยื่นข้อบกพร่องที่มีการปรับแต่งกับเจ้าของที่ถูกต้อง
  • การจัดการช่องโหว่ - ส่งต่อช่องโหว่ที่มีอยู่
  • สื่อสาร - แจ้งข้อมูลอัปเดตเกี่ยวกับรายงานที่มีอยู่แก่นักวิจัยด้านความปลอดภัย
    • นักวิจัยอาจขอให้อัปเดตรายงานที่มีอยู่ ตรวจสอบเรื่องนี้และตอบกลับตามความจำเป็น
    • หากช่องโหว่ได้รับการแก้ไขแล้ว ให้แจ้งเรื่องนี้กลับไปให้นักวิจัยทราบว่าความพยายามอย่างหนักของพวกเขาทำให้เกิดการเปลี่ยนแปลงในทางที่ดีกับองค์กรของคุณ คุณยังสามารถใส่ภาษาเทมเพลตเพื่อขอให้ผู้วิจัยแจ้งให้ทราบว่าคุณพลาดการแก้ไขใดๆ ไปหรือไม่ หรือระบบอาจข้ามการแก้ไขของคุณไปในทางใดทางหนึ่ง

ขึ้นอยู่กับจำนวนรายงานที่คุณได้รับ ความซับซ้อนของรายงานเหล่านี้ รวมทั้งทักษะและความรู้ของบุคคลที่ปฏิบัติงาน การเข้าเวรอาจใช้เวลานานตั้งแต่ 2-3 ชั่วโมงไปจนถึงทั้งสัปดาห์ เคล็ดลับสำหรับการหมุนเวียนหน้าที่ ให้ประสบความสำเร็จมีดังนี้

  • ตรวจสอบว่าทีมของคุณพร้อมที่จะเข้ามาช่วยสนับสนุนงานในช่วงสัปดาห์ที่หนักๆ โดยเฉพาะ
  • เตรียมขั้นตอนการส่งมอบที่ดี หากมีปัญหาที่อาจต้องให้เจ้าหน้าที่รับหน้าที่ดูแลทราบทันที ให้เขียนบันทึกการโอนงานหรือสนทนาสดในช่วงปลายสัปดาห์
  • สร้างการกำหนดเวลาอัตโนมัติเพื่อให้ทุกคนรู้เวลาที่ต้องปฏิบัติหน้าที่ ซึ่งอาจเป็นการสร้างรายการปฏิทินที่เกิดซ้ำสำหรับแต่ละคน
  • โดยเฉพาะอย่างยิ่งในช่วงเริ่มต้น VDP ให้ตรวจสอบกับบุคคลที่ปฏิบัติหน้าที่ว่าจำได้ว่าเป็นสัปดาห์ของตน และดูว่าพวกเขา ต้องการความช่วยเหลือหรือไม่ หากคุณมีทรัพยากรระดับต้นในการหมุนเวียนมากกว่านี้ ให้เรียกใช้ทรัพยากรระดับอาวุโสเพื่อดูแลให้พนักงานรู้สึกสบายใจและถามคำถามได้เมื่อมีปริมาณมากขึ้น
  • มีกระบวนการที่ยืดหยุ่นสำหรับการสลับสัปดาห์ แน่นอนว่าอาจมีบางคนที่มีเหตุฉุกเฉินและจำเป็นต้องหยุดพักระหว่างสัปดาห์ หรือมีบางคนจะลาพักร้อน ฯลฯ ในกรณีนี้ โปรดกระตุ้นให้ทีมสลับสัปดาห์กันตามที่จำเป็นเพื่อจัดตารางเวลาของทุกคนให้พร้อม
  • สร้าง "ข้อมูลสรุป" เกี่ยวกับหน้าที่ซึ่งสรุปงานที่ต้องครอบคลุม รวมถึงเอกสารเกี่ยวกับวิธีทำงาน

ตัดสินใจเกี่ยวกับภายในองค์กรเทียบกับบุคคลที่สาม

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

การรับรายงาน

หากคุณเลือกใช้แพลตฟอร์มของบุคคลที่สาม แฮกเกอร์ควรมีช่องทางให้แฮ็กเกอร์ส่งรายงานถึงคุณโดยตรง หากคุณสร้างโปรแกรมภายในองค์กร คุณจะต้องสร้างโปรแกรมด้วยตนเอง ซึ่งอาจเป็นอีเมลที่สร้างคำขอแจ้งปัญหาหรือข้อบกพร่องโดยอัตโนมัติในตัวติดตามปัญหา (เช่น [email protected]) หรืออาจเป็นเว็บฟอร์มซึ่งมีช่องแบบฟอร์มที่จำเป็น ลิงก์จากหน้าเดียวกับนโยบายโปรแกรมก็ได้ ไม่ว่าจะเป็นรูปแบบใด นี่เป็นโอกาสที่ดีที่สุดในการ แจ้งให้แฮ็กเกอร์ทราบรูปแบบที่คุณต้องการรับรายงาน โปรดทราบว่าการขอให้แฮ็กเกอร์ส่งรายงานในรูปแบบใดรูปแบบหนึ่งไม่ได้รับประกันเสมอไปว่าจะทำได้จริง แต่ก็ไม่มีอะไรเสียหายที่จะถาม นี่คือตัวอย่างของสิ่งที่คุณอาจขอในแบบฟอร์มการส่งรายงาน

เรื่อง: [โปรดเพิ่มรายละเอียดเกี่ยวกับปัญหา 1 บรรทัด เช่น "XSS ใน mail.example.com
ทำให้เกิดการขโมยเซสชัน"]

บทสรุป: [โปรดเพิ่มรายละเอียดสั้นๆ เกี่ยวกับช่องโหว่และความสำคัญ เช่น เนื่องจากการหลบเลี่ยงไม่มีการหลบหนี คุณสามารถส่งอีเมลไปยังผู้ใช้รายอื่นที่มีเพย์โหลด XSS ที่อาจทำให้ผู้โจมตีขโมย คุกกี้ของผู้ใช้อีกรายหนึ่งที่มีข้อมูลเซสชันได้ ซึ่งจะทำให้ผู้บุกรุกเข้าสู่ระบบบัญชีของเหยื่อได้] ขั้นตอนการทำซ้ำ: [โปรดเพิ่มวิธีการแบบทีละขั้นตอนในการสร้างช่องโหว่อีกครั้ง]
1.
2.
3.

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