การติดตามสแต็คควรอยู่ในข้อความแสดงข้อผิดพลาดที่ปรากฏแก่ผู้ใช้หรือไม่

ฉันมีข้อโต้แย้งเล็กน้อยในที่ทำงานของฉันและฉันพยายามคิดออกว่าใครถูกและสิ่งที่ถูกต้องคืออะไร

บริบท: เว็บแอปพลิเคชันอินทราเน็ตที่ลูกค้าของเราใช้สำหรับการบัญชีและสิ่ง ERP อื่น ๆ

ฉันเห็นว่าข้อความแสดงข้อผิดพลาดที่นำเสนอต่อผู้ใช้ (เมื่อเกิดข้อผิดพลาด) ควรมีข้อมูลให้มากที่สุดรวมถึงการติดตามสแต็ก แน่นอนว่าต้องเริ่มต้นด้วยดี "มีข้อผิดพลาดเกิดขึ้นโปรดส่งข้อมูลด้านล่างไปยังผู้พัฒนา" ด้วยตัวอักษรขนาดใหญ่ที่เป็นมิตร

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

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

น่าเสียดายที่มี "การตรวจสอบความปลอดภัย" บางประเภท (ไม่รู้เลยว่าพวกเขาทำอย่างไรโดยไม่มีแหล่งที่มา ... แต่ไม่ว่าอะไรก็ตาม) และพวกเขาก็บ่นเกี่ยวกับข้อความยกเว้นทั้งหมดที่อ้างว่าเป็นภัยคุกคามความปลอดภัย ตามปกติแล้วลูกค้า (อย่างน้อยหนึ่งคนที่ฉันรู้จัก) ได้ทำสิ่งนี้ตามมูลค่าที่กำหนดและตอนนี้ต้องการให้มีการล้างข้อความ

ฉันล้มเหลวในการดูว่าผู้โจมตีที่มีศักยภาพสามารถใช้กองติดตามเพื่อค้นหาสิ่งที่เขาไม่สามารถหามาก่อน มีตัวอย่างใดบ้างมีหลักฐานรับรองว่าใครเคยทำเช่นนั้นบ้าง? ฉันคิดว่าเราควรต่อสู้กับความคิดที่โง่เขลา แต่บางทีฉันอาจเป็นคนโง่ที่นี่ดังนั้น ...

ถูกต้องใคร

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

หากไซต์ของคุณติดตั้งในสภาพแวดล้อมของลูกค้าและคุณไม่สามารถเข้าถึงได้คุณสามารถรับแผนกไอทีในสถานที่เพื่อส่งสารสกัดบางส่วนตามข้อผิดพลาดที่ไม่มี

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

การมีระบบที่รั่วไหลโดยพื้นฐานเมื่อสิ่งที่ไม่ถูกต้องไม่ได้สร้างแรงบันดาลใจให้กับผู้ใช้ที่ไม่ใช่ด้านเทคนิค - มันมีแนวโน้มที่จะทำให้พวกเขาคิดว่ามีบางอย่างผิดปกติ (เช่นคุณเข้าใจ BSOD มากแค่ไหนและอย่างไร คุณรู้สึกอย่างไรเมื่อมีคนมา)

บน stacktrace:

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

ใช่มีมากมาย

การติดตามสแต็กสามารถเปิดเผยได้

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

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

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

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

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

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

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

คุณอาจพิจารณาไม่แสดงการติดตามสแต็กด้วยเหตุผลต่อไปนี้

ความปลอดภัย

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

ประสบการณ์ผู้ใช้

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

ชื่อเสียงของคุณ

เมื่อใดก็ตามที่มีการติดตามสแต็กปรากฏบนเว็บไซต์มันดูไม่ดี คนส่วนใหญ่ไม่รู้ว่ามันคืออะไรและทำให้พวกเขารู้สึกว่าเว็บไซต์ไม่เป็นมิตรกับพวกเขา สำหรับผู้ที่รู้ว่ามันคืออะไรมันอาจเป็นข้อบ่งชี้ว่าแอปพลิเคชันไม่ได้รับการพิจารณาอย่างดี แอปพลิเคชันที่เขียนไม่ดีจำนวนมากแสดงสแต็กร่องรอยบ่อยเกินไปเนื่องจากเป็นค่าเริ่มต้นในบางเฟรมเวิร์กเช่น ASP.Net

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

คำตอบยาว:

เหมือนกันเกิดขึ้นกับฉันในที่ทำงาน ฉันเคยคิดว่าหากแอปล้มเหลวก็ควรล้มเหลวอย่างเสียงดัง

แต่แล้วพวกเขาก็อธิบายให้ฉันฟังว่าแฮ็กเกอร์ที่มีศักยภาพสามารถแทรกซึมสิ่งต่างๆมากมายจากสแต็คเทรซ

ฉันคิดว่าไม่จำเป็นต้องพิสูจน์ เห็นได้ชัดว่ายิ่งแฮ็กเกอร์รู้เกี่ยวกับแพลตฟอร์มของคุณมากเท่าไหร่ก็ยิ่งดีสำหรับเขาและยิ่งแฮ็กเกอร์ที่รู้เกี่ยวกับแพลตฟอร์มของคุณดีเท่าไหร่สำหรับคุณ

บริษัท ต่างๆก็ไม่กระตือรือร้นที่จะเปิดเผยว่าแฮ็กเกอร์เจาะเข้าไปในระบบของพวกเขาอย่างไร

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

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

ในทางกลับกันหากจำนวนที่เกิดขึ้นจริงไม่เป็นศูนย์คุณต้องใช้ข้อมูลนี้อย่างยิ่งและไม่ควรพึ่งพาลูกค้าเพื่อส่งให้คุณ 99.99% ของเวลาที่พวกเขาจะไม่ คุณควรติดตั้งระบบ reporing ที่ส่งข้อมูลโดยอัตโนมัติโดยมีเพียง "ok" จากลูกค้า