เราควร debug เว็บแอปพลิเคชั่น PHP อย่างปลอดภัยโดยไม่เปิดเผยความลับต่อคู่แข่งอย่างไร

เมื่อเร็ว ๆ นี้ฉันทำโปรแกรม ฉันลืมลบรหัส 2 บรรทัด ความผิดพลาดนั้นมีค่าฉัน $ 800 ต่อวันทุกวัน

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

ดังนั้นฉันจึงใส่ข้อมูลการแก้ไขข้อบกพร่องทุกที่ ฉันคิดว่าฉันจะลบพวกเขาในภายหลัง

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

ฉันคิดว่ามีโหมดการแก้ไขข้อบกพร่อง อย่างไรก็ตามฉันกลัวว่าฉันจะลืมลบข้อมูลการดีบัก

ฉันถือว่ามีโหมดการดีบักหากผู้ใช้ทำเช่น? debuggingmode = 1 เช่น อย่างไรก็ตามฉันรู้สึกหวาดระแวงว่าคู่แข่งของฉันสามารถเดาคำหลักลับได้

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

คู่แข่งของฉันใช้พรอกซีดูรหัสการดีบัก เขาคัดลอกความคิดและนั่นคือวิธีที่ฉันสูญเสีย $ 800 ต่อวัน

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

เราควร debug เว็บแอปพลิเคชั่น PHP อย่างปลอดภัยโดยไม่เปิดเผยความลับต่อคู่แข่งอย่างไร

ฉันมีช่วงเวลาที่ยากลำบากในการดูว่าฉันไปไหนผิด

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

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

■ดูว่าพวกเขาเขียนสิ่งที่ถูกต้องในนิตยสาร Fast Company
_{บทความนี้อธิบายถึงวิธีการที่นาซ่าใช้รวมถึงต้นทุนในการผลิตซอฟต์แวร์ด้วยวิธีนี้}

■ดูการพิสูจน์กลไก (Mackenzie 2004)
_{หนังสือสรุปประวัติความเป็นมาของการพิสูจน์ซอฟต์แวร์โดยอัตโนมัติอธิบายข้อดีข้อเสียของการพิสูจน์ดังกล่าวรวมถึงเหตุผลที่ธุรกิจทั่วไปไม่ได้ใช้เพื่อเขียนซอฟต์แวร์ที่เชื่อถือได้}

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

• ความคิดเห็นเกี่ยวกับรหัสอย่างไม่เป็นทางการ
• การตรวจสอบรหัสอย่างเป็นทางการ
• การทดสอบ
• โต๊ะตรวจสอบรหัสส่วนตัว
• เป็นต้น

■ดูรหัสที่สมบูรณ์ (McConnell 2004), ประสิทธิภาพการเขียนโปรแกรม (Jones 1986a), ประสิทธิภาพการกำจัดข้อบกพร่องของซอฟต์แวร์ (Jones 1996) และสิ่งที่เราได้เรียนรู้เกี่ยวกับการต่อสู้ข้อบกพร่อง (Shull et al. 2002)

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

■ดูความลับในการปรับใช้อย่างต่อเนื่องอย่างปลอดภัย (วิดีโอ)
_{มันอธิบายถึงเทคนิคการตั้งค่าที่ Google เพื่อป้องกันข้อผิดพลาดที่ไม่สามารถหาได้ก่อนที่จะนำไปใช้งานนานเกินไปในการผลิต นอกจากนี้ยังอธิบายpdiffและวิธีการใช้ในการจับข้อบกพร่องรวมถึงสิ่งที่ไม่เกี่ยวข้องกับเลเยอร์การนำเสนอ}

คุณไม่ควรตรวจแก้จุดบกพร่องในการผลิต

คุณควรมีสภาพแวดล้อมการทดสอบที่เหมือนกันกับสภาพแวดล้อมการผลิตและการดีบักที่นั่น

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

การตั้งค่ามืออาชีพมักจะมีลักษณะเช่นนี้:

Production
   ^
Staging
   ^
Development

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

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

การควบคุมเวอร์ชันและระบบการจัดการบิลด์ที่เหมาะสมสามารถช่วยคุณได้

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

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

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

ฉันใช้เทคนิค& debugging = 1มาแล้ว ฉันสงสัยว่านักพัฒนา PHP ส่วนใหญ่มี ที่พลิกสวิตช์ในรหัสที่เปิดใช้งานการดีบัก verbose เพิ่มเติมในแอปพลิเคชัน ข้อมูลดังกล่าวมักจะถูกเททิ้งไปยังไฟล์บันทึก - โดยทั่วไปแล้วบันทึก apache (โดยใช้ error_log ()) แต่คุณยังสามารถส่งออกได้ ตัวอย่างเช่นผู้สร้างโปรไฟล์ของเราจะรวบรวมข้อมูลแล้วส่งออกเกณฑ์มาตรฐานต่างๆที่ด้านล่างของหน้า คุณยังสามารถแสดงผลข้อมูลการดีบักเป็นความคิดเห็น HTML หรือในองค์ประกอบที่ซ่อนอยู่ซึ่งสามารถดูได้เฉพาะเมื่อคุณดูแหล่งที่มาของหน้า

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

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

คนอื่น ๆ ได้ครอบคลุมกรณีทั่วไปแล้ว:

การตรวจสอบอย่างเป็นทางการ (/ รหัสที่พิสูจน์แล้ว):ไม่เป็นไปได้สำหรับโปรแกรมในโลกแห่งความเป็นจริงแม้ว่าจะมี kernal ระบบปฏิบัติการ 4000 บรรทัดซึ่งได้รับการพิสูจน์อย่างเป็นทางการแล้วก็ใช้เวลานักศึกษารัสเซียปริญญาเอก CS หลายคนหลายเดือน

การทดสอบ CI << การทดสอบอัตโนมัติ << การทดสอบ : ตรวจสอบให้แน่ใจว่าคุณใช้เครื่องมือครอบคลุมเพื่อตรวจสอบกรณีทดสอบของคุณมีความครอบคลุม 100%

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

1. ลบออกในเวลารวบรวม ตัดรหัสการดีบักในโครงสร้างเช่น C # และ C #ifdef DEBUGเพื่อตรวจสอบเป้าหมายการสร้าง (ทั้ง Debug หรือ Release) และเพื่อลบออกโดยอัตโนมัติในเวลารวบรวม

2. ตั้งค่าสถานะเวลาการปรับใช้ ใส่ความคิดเห็นใกล้โค้ดที่ต้องไม่เรียกใช้ในสภาพแวดล้อมจริง เช่น//TODO: Remove This Before Deploymentจากนั้นเมื่อมีการโยกย้าย (ปรับใช้) ไปยัง Staging ก่อนที่จะรวบรวมรหัสให้รันผ่านสคริปต์ง่าย ๆ ที่ตรวจสอบเพื่อให้แน่ใจว่าไม่มีความคิดเห็นตั้งค่าสถานะ (เช่น //TODO:) ในซอร์สโค้ด

ฉันขอแนะนำก่อนหน้านี้สำหรับถ้ามันเป็นระยะยาวและคุณจะต้องการอีกครั้ง (เช่นโหมดการบันทึก verbose) และต่อมาถ้ามันเป็นแฮ็คอย่างรวดเร็วในขณะที่คุณกำลังแก้จุดบกพร่อง (เช่น printfs ต่างๆกระจัดกระจายผ่านรหัสของคุณ)

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

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

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

ฉันไม่ต้องการความปลอดภัยสูงเช่นกันฉันไม่ต้องการให้ผู้ใช้เห็นหน้าจอพูดพล่อยๆ

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

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

หรือคุณสามารถสร้างdebugคลาสหรือฟังก์ชั่นที่จะตรวจสอบว่าได้รับอนุญาตการพิมพ์หรือไม่ขึ้นอยู่กับเกณฑ์ของคุณ นั่นคือสิ่งที่ฉันทำ.

บางสิ่งเช่นนี้

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

สำหรับโปรแกรมของฉันที่จะทำให้ฉัน $ 800 / วัน (อยู่ระหว่างการพัฒนา) ฉันใช้ apache mod auth เพื่อขอรหัสผ่านในการเข้าถึงส่วนใด ๆ ของเว็บไซต์รวมถึงการ จำกัด ข้อมูลการแก้ปัญหาให้กับ IP บางตัว คำถามของคุณทำให้ฉันคิดว่าฉันควรจะมองความปลอดภัยที่ดีขึ้น

จริงๆแล้วฉันจะมีการตรวจสอบพิเศษสองอย่างที่นี่ หนึ่งคือ&debug=1พารามิเตอร์ในคำขอ คุณยังสามารถใช้ตัวแปรเซสชั่นพิเศษหรือการตั้งค่าคุกกี้ที่มีเพียงคุณเท่านั้นที่สามารถเปิดใช้งานผ่านการโทรไปยังหน้า"ความลับ" (ควรมีการตรวจสอบสิทธิ์)

การตรวจสอบความถูกต้องครั้งที่สองจะมีในไฟล์กำหนดค่าอาร์เรย์ที่มีช่วงของ IP และการโทรจาก IP ในอาร์เรย์นั้นเท่านั้นที่สามารถเรียกใช้ฟังก์ชันการดีบักได้ สิ่งที่ต้องการ

ในการกำหนดค่า:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

มีวิธีการต่อไปนี้บางที่สามารถเข้าถึงได้ทั่วโลก:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

และในรหัสของคุณเรียกสิ่งที่ชอบ:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

โปรดทราบว่ารหัสในgetClientIp()วิธีนี้ไม่ปลอดภัยเนื่องจากค่าสำหรับการ$_SERVER['HTTP_X_FORWARDED_FOR']ปลอมแปลงได้ง่าย แต่ควรใช้เพื่อจุดประสงค์ในการตอบคำถามของคุณ