โปรแกรมเมอร์ทุกคนควรรู้อะไรเกี่ยวกับความปลอดภัย? [ปิด]

427

ฉันเป็นนักเรียนไอทีและตอนนี้ฉันอยู่ปีที่ 3 ในมหาวิทยาลัย จนถึงตอนนี้เราได้ศึกษาวิชาต่าง ๆ ที่เกี่ยวข้องกับคอมพิวเตอร์โดยทั่วไป (การเขียนโปรแกรมอัลกอริธึมสถาปัตยกรรมคอมพิวเตอร์คณิตศาสตร์ ฯลฯ )

ฉันแน่ใจว่าไม่มีใครสามารถเรียนรู้ทุกอย่างเกี่ยวกับความปลอดภัย แต่แน่ใจว่ามีความรู้ "ขั้นต่ำ" ทุกคนที่โปรแกรมเมอร์หรือนักเรียนไอทีควรรู้เกี่ยวกับมันและคำถามของฉันคืออะไรความรู้ขั้นต่ำนี้คืออะไร?

คุณช่วยแนะนำหนังสืออิเล็กทรอนิกส์หรือหลักสูตรหรืออะไรก็ได้ที่สามารถช่วยเริ่มต้นด้วยถนนสายนี้?

security 
— MH
แหล่งที่มา
6
ค่อนข้างคล้ายกับstackoverflow.com/questions/325862/...
— โทมัส
118
กฎ # 1: อย่าไว้ใจอินพุตของผู้ใช้ ไม่แม้ว่าจะเป็นคุณยายของคุณ
— Anthony Forloney
2
.. และหัวข้อนี้ยังมีข้อมูลที่ดีอีกด้วย - stackoverflow.com/questions/72394/…
— Sripathi Krishnan
คำถามของฉันไม่เพียง แต่เกี่ยวกับโปรแกรมเมอร์และความผิดพลาดเท่านั้น แต่ยังเกี่ยวกับนักเรียนด้านไอทีและวิทยาศาสตร์คอมพิวเตอร์ด้วย
— Mohamad Alhamoud
1
ดูข้อความผิดพลาดของคุณ ในขณะที่คุณต้องการเป็นมิตรกับผู้ใช้ความแตกต่างระหว่าง "บัญชีนี้ไม่มีอยู่" และ "รหัสผ่านไม่ถูกต้อง" อาจเป็นอันตรายได้ในบางกรณี
— Michael Mior

คำตอบ:

551

หลักการที่ควรคำนึงถึงหากคุณต้องการให้แอปพลิเคชันของคุณปลอดภัย:

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

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

อบรมนักพัฒนาซอฟต์แวร์ของคุณเกี่ยวกับการรักษาความปลอดภัยที่ดีที่สุด

โค๊ดโค้ด (จ่าย)

นวัตกรรมความปลอดภัย (จ่าย)

เข็มทิศรักษาความปลอดภัย (จ่าย)

OWASP WebGoat (ฟรี)

— bignum
แหล่งที่มา
+1 "การหาประโยชน์จากซอฟต์แวร์: วิธีทำลายรหัส" เป็นหนังสือที่ยอดเยี่ยมอย่างไรก็ตามสไลด์โชว์ที่คุณเชื่อมโยงไปนั้นน่ากลัว
— rook
7
อย่างไรก็ตามน่าเสียดายที่เกือบจะเป็นไปไม่ได้ที่จะยกตัวอย่างหลักการของสิทธิ์น้อยที่สุดในระบบที่ทันสมัย ตัวอย่างเช่นเคอร์เนล Linux (ที่มาที่ฉันใช้อยู่) มีรหัส C มากกว่า 9.4 ล้านบรรทัดและแอสเซมบลีไลน์มากกว่า 400K ซึ่งทั้งหมดทำงานในบริบทที่ไม่มีข้อ จำกัด การคำนวณผิดง่าย (อาจตั้งใจ) ในหนึ่งในล้านบรรทัดเหล่านี้จะทำให้ระบบทั้งหมดเสียหาย บางทีในศตวรรษหน้าหรือสองปีข้างหน้าจะมีวิธีแก้ปัญหาเกิดขึ้นจริง ๆ แล้วไม่ใช่เพราะไม่มีใครสนใจเกี่ยวกับการสร้างระบบปฏิบัติการ / ภาษา / กรอบงานที่ปลอดภัย
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
ฉันจะเพิ่ม "The Web Application Hacker's Handbook" ลงในรายการนั้น
— outcassed
34
แทนที่ "ไม่เชื่อใจอินพุตของผู้ใช้!" ถึง "ไม่ไว้วางใจอินพุตใด ๆ !" ข้อมูลที่มาจากซอฟต์แวร์อื่น ๆ ควรได้รับการปฏิบัติเช่นเดียวกับการป้อนข้อมูลของผู้ใช้ - ตัวอย่างเช่นในการบันทึกเว็บไซต์ผู้คนส่วนใหญ่ไม่คิดว่าฟิลด์ User-Agent / browser ID เป็น 'การป้อนข้อมูลผู้ใช้' การฉีด SQL
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ มีระบบปฏิบัติการ Microsoft Research Experiment (Singularity) ที่สร้างขึ้นบน. NET ซึ่งกำหนดเป้าหมายความปลอดภัยเป็นเป้าหมายหลัก (ไม่มีบัฟเฟอร์มากเกินไปใช่แล้ว) ไม่มีการแชร์หน่วยความจำในกระบวนการไม่มีการแก้ไขโค้ดด้วยตนเองแม้แต่ไดรเวอร์อุปกรณ์ก็เป็นเพียงกระบวนการแยกซอฟท์แวร์อื่นใน. NET ค่อนข้างเป็นแนวคิดที่น่าสนใจ แต่มันยากที่จะผลักดันสิ่งนี้ให้กับผู้คน (ที่สำคัญที่สุดคือมันแทบจะไม่สามารถทำงานร่วมกับซอฟต์แวร์ที่มีอยู่หรือแม้แต่ไดรเวอร์เก่าได้เช่นเดียวกับ 10 ปีแรกของ Linux: D)
— Luaan
102

การรักษาความปลอดภัยอันดับที่ 1 สำหรับโปรแกรมเมอร์: ไม่ควรทำเอง

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

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

— Tyler McHenry
แหล่งที่มา
10
นี่เป็นกฎที่ไม่ดีในความคิดของฉัน คุณสามารถกำหนดเป้าหมายเป็นหลักเพียงเพราะแพลตฟอร์มที่คุณเลือกแทนที่จะเป็นความสนใจที่แท้จริงในสินทรัพย์ของคุณ ลองนึกถึงช่องโหว่ด้านความปลอดภัยทั้งหมดที่พบในแพลตฟอร์มของบุคคลที่สามและผลิตภัณฑ์ทั้งหมดที่มีความเสี่ยงในทันทีเพราะพวกเขาใช้งาน ฉันจะไม่เชื่อใจในความปลอดภัยกับบุคคลที่สามอย่างรวดเร็ว
— Fosco
9
ฉันคิดว่านี่เป็นกฎที่ดีสำหรับ Crypto การกลิ้งการเข้ารหัสของคุณเองเป็นสูตรสำหรับภัยพิบัติ แต่การนำเสนอเครื่องมือบล็อกของคุณเองอาจมีความปลอดภัยมากขึ้นเมื่อ Fosco ชี้ให้เห็น - ถ้าคุณกลิ้งตัวคุณเองคุณมีโอกาสน้อยที่จะถูกจับโดยการโจมตีอัตโนมัติที่ WordPress ติดตั้งต้องจัดการ
— James P McGrath
5
เมื่อพูดถึง crypto กฏนี้ถูกต้องอย่างแน่นอน อย่าเขียน crypto ของคุณเอง, ประจำเดือน เมื่อพูดถึงการใช้แพลตฟอร์มของบุคคลที่สามมันขึ้นอยู่กับ บางแพลตฟอร์มมีความปลอดภัยมากกว่าโดยทั่วไปบางแพลตฟอร์มมีความปลอดภัยน้อยกว่าโดยทั่วไปและแพลตฟอร์มส่วนใหญ่อาจมีคุณสมบัติความปลอดภัยบางอย่าง แต่ก็มีบางเวกเตอร์การโจมตีที่รู้จัก ใช้ล่าสุดRails ช่องโหว่ที่ทำให้เกิดหลุมรักษาความปลอดภัยที่ GitHub Rails ไม่ต้องสงสัยให้คุณสมบัติความปลอดภัยมากมาย แต่ก็ยังมีคุณสมบัติที่ทรงพลังที่มีค่าเริ่มต้นที่ไม่ปลอดภัย
— Michael Kopinsky
7
เมื่อพูดถึง crypto อย่าม้วนตัวเองแต่จงเข้าใจสิ่งที่คุณกำลังใช้ หากคุณไม่เข้าใจว่าเพราะเหตุใดการใช้คีย์การเข้ารหัสเดียวกันสำหรับ RC4 สำหรับสองข้อความเป็นความคิดที่น่ากลัวลองอ่านก่อนใช้สตรีมตัวเลขใด ๆ
— Christopher Creutzig
3
แม้หลังจากข้อผิดพลาด HeartBleed ก็เห็นได้ชัดว่านี่เป็นกฎที่ดี ลองจินตนาการว่ามันยากแค่ไหนที่จะได้พบข้อบกพร่องเหมือน heatbleed ในโครงการที่กำหนดเองหรือเป็นกรรมสิทธิ์ หากคุณม้วนตัวเองคุณกำลังซ่อนตัวอยู่หลังความสับสนและจะไม่รู้ว่ามีข้อบกพร่องอะไรบ้างที่ถูกนำไปใช้ประโยชน์
— Sqeaky
71

โปรแกรมเมอร์ทุกคนควรรู้วิธีเขียนโค้ดหาประโยชน์

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

— โกง
แหล่งที่มา
10
ฉันขอยืนยันว่ามันไม่จำเป็นเลย เพียงยึดมั่นในหลักการ: หากผู้โจมตีสามารถทำให้หน่วยความจำเสียหายได้ทุกประเภทให้พิจารณาตัวคุณเองว่าเป็นเจ้าของ ไม่จำเป็นต้องพูดถึงรายละเอียดของการเขียนหาประโยชน์ (ใช้งาน)
— ใหม่
6
@newgre ไม่ใช่ทุกช่องโหว่เป็นบัฟเฟอร์ล้น มีช่องโหว่สองสามพันช่องโหว่ที่ครอบคลุมโดยระบบการแจกแจงทั่วไปที่อ่อนแอ โปรแกรมเมอร์ต้องเข้าใจจิตใจของผู้โจมตีไม่เช่นนั้นเขาจะไม่รู้ความผิดพลาด
— rook
1
ฉันรู้ว่าไม่ใช่ทุกคนที่เป็น buffer overflow แต่สิ่งที่มักจะเรียกว่า "exploit" นั้นขึ้นอยู่กับหน่วยความจำที่เสียหายบางอย่าง: buffer overflow, double-frees, heap overflows, จำนวนเต็มที่เกี่ยวข้องกับ overflow, รูปแบบสตริง ฯลฯ แน่นอนว่ามีสิ่งอื่น ๆ เช่นข้อบกพร่องทางตรรกะ แต่นั่นไม่ใช่หัวข้อของคำตอบนี้เพื่อเริ่มต้น
— ใหม่
5
@newgre นั่นคือการหาประโยชน์แบบหนึ่ง แต่ในปัจจุบันการหาประโยชน์เพิ่มเติมนั้นถูกเขียนขึ้นเพื่อใช้ประโยชน์จากข้อบกพร่องของเว็บแอปพลิเคชั่นมากกว่าปัญหาความเสียหายของหน่วยความจำ การหาประโยชน์จะถูกเขียนโดยใช้ประโยชน์จากการฉีด SQL, ไฟล์ในตัวเครื่อง, CSRF และ XSS ซึ่งเป็นปัญหาที่พบบ่อย (ที่มา: exploit-db.com )
— rook
1
ฉันเห็นด้วยถ้าคุณสามารถเขียนการหาประโยชน์คุณสามารถเข้าใจได้ว่าอะไรคือสิ่งที่ทำให้แฮ็กเกอร์นึกถึงที่สุด!
— linuxeasy
42

ความปลอดภัยเป็นกระบวนการไม่ใช่ผลิตภัณฑ์

หลายคนดูเหมือนจะลืมเรื่องจริงที่เห็นได้ชัดนี้

— ericteubert
แหล่งที่มา
23

ผมขอแนะนำให้ตรวจสอบCWE / SANS TOP 25 ส่วนใหญ่ข้อผิดพลาดการเขียนโปรแกรมที่เป็นอันตราย มันได้รับการปรับปรุงในปี 2010 พร้อมกับสัญญาว่าจะมีการปรับปรุงเป็นประจำในอนาคต การแก้ไข2009มีให้เช่นกัน

จากhttp://cwe.mitre.org/top25/index.html

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

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

— jschmier
แหล่งที่มา
1
โปรดทราบว่าข้อผิดพลาด 4 อันดับแรกในรายการนั้น (และกลุ่มอื่น ๆ เช่นกัน) เป็นข้อผิดพลาดเดียวกันทั้งหมด - ข้อมูลที่ไว้วางใจ
— Chris Dodd
13

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

— tvanfosson
แหล่งที่มา
ลิงก์ของหลักสูตร MIT ไม่สามารถใช้งานได้
— AntonioCS
1
ลิงก์ได้รับการแก้ไข (ตอนนี้) ขอบคุณ
— tvanfosson
10

ทีมรักษาความปลอดภัยบนเว็บของ Mozilla ได้รวบรวมแนวทางที่ดีซึ่งเรายึดถือในการพัฒนาเว็บไซต์และบริการของเรา

— potch
แหล่งที่มา
8

ความสำคัญของค่าเริ่มต้นที่ปลอดภัยในกรอบงานและ API:

  • เฟรมเวิร์กเว็บเริ่มต้นจำนวนมากไม่ได้หลบหนี HTML โดยค่าเริ่มต้นในเทมเพลตและมีปัญหา XSS เนื่องจากสิ่งนี้
  • เฟรมเวิร์กของเว็บจำนวนมากทำให้การเชื่อม SQL เข้าด้วยกันง่ายกว่าการสร้างเคียวรีแบบกำหนดพารามิเตอร์ซึ่งนำไปสู่ข้อบกพร่องการฉีด SQL จำนวนมาก
  • Erlang บางรุ่น (R13B หรืออื่น ๆ ) ไม่ตรวจสอบใบรับรอง SSL ของเพื่อนโดยค่าเริ่มต้นและอาจมีรหัส Erlang จำนวนมากที่ไวต่อการโจมตี SSL MITM
  • หม้อแปลง XSLT ของ Java โดยค่าเริ่มต้นอนุญาตให้เรียกใช้โค้ดจาวาโดยพลการ มีข้อบกพร่องด้านความปลอดภัยที่ร้ายแรงจำนวนมากที่สร้างขึ้นโดยสิ่งนี้
  • API การแยกวิเคราะห์ XML ของ Java โดยค่าเริ่มต้นอนุญาตให้แยกวิเคราะห์เอกสารเพื่ออ่านไฟล์โดยพลการบนระบบไฟล์ สนุกมาก :)
— benmmurphy
แหล่งที่มา
5

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

— rapadura
แหล่งที่มา
1
ไม่ใช่สิทธิ์ทั้งหมดที่ต้องมีการตรวจสอบสิทธิ์ "จาก ABAC ถึง ZBAC"เปรียบเทียบการควบคุมการเข้าถึง NBAC (ตามการรับรองความถูกต้อง) กับโซลูชันที่ไม่ต้องการการรับรองความถูกต้อง "IBAC, RBAC, ABAC และแม้กระทั่ง CBAC - การควบคุมการเข้าถึงการอ้างสิทธิ์ทั้งหมดพึ่งพาการรับรองความถูกต้อง ... เพื่อความเรียบง่ายกระดาษนี้ถือว่าพวกเขาเป็นโซลูชั่นเดียวและไม่สนใจรุ่นเหล่านั้นที่นำมาใช้ในด้านสถาปัตยกรรม ZBAC พวกเขาจะเรียกรวมว่า ระบบควบคุมการเข้า - ออก (NBAC) "
— Mike Samuel
4
  • จำไว้ว่าคุณ (โปรแกรมเมอร์) ต้องรักษาความปลอดภัยทุกส่วน แต่ผู้โจมตีจะต้องประสบความสำเร็จในการหาหนึ่งหงิกงอในชุดเกราะของคุณ
  • ความปลอดภัยเป็นตัวอย่างของ "unknowns unknown" บางครั้งคุณอาจไม่รู้ว่าข้อบกพร่องด้านความปลอดภัยที่เป็นไปได้คืออะไร (จนกระทั่งหลังจากนั้น)
  • ความแตกต่างระหว่างบั๊กและช่องโหว่นั้นขึ้นอยู่กับความฉลาดของผู้โจมตี
— Rory
แหล่งที่มา
4

ฉันจะเพิ่มต่อไปนี้:

  • ลายเซ็นดิจิทัลและใบรับรองดิจิทัลทำงานอย่างไร
  • sandboxing คืออะไร

ทำความเข้าใจกับการทำงานของเวคเตอร์การโจมตี

  • บัฟเฟอร์ overflows / underflows / etc ในรหัสพื้นเมือง
  • กลไกทางสังคม
  • การปลอมแปลง DNS
  • คนกลาง
  • CSRF / XSS และคณะ
  • การฉีด SQL
  • การโจมตี Crypto (เช่นการใช้ประโยชน์จากอัลกอริธึมการเข้ารหัสอ่อนแอเช่น DES)
  • ข้อผิดพลาดของโปรแกรม / กรอบงาน (เช่นข้อบกพร่องด้านความปลอดภัยล่าสุดของ github )

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

— Miguel Ping
แหล่งที่มา
4

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

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

คุณสามารถค้นหาทรัพยากรความปลอดภัยเพิ่มเติมได้ที่ลิงค์ต่อไปนี้:

สำหรับข้อมูลเพิ่มเติม google เกี่ยวกับความปลอดภัยของผู้จำหน่ายแอปพลิเคชันของคุณ

— rahul_pratap
แหล่งที่มา
3
  1. ทำไมเป็นสิ่งสำคัญ
  2. มันคือทั้งหมดที่เกี่ยวกับการแลกเปลี่ยน
  3. วิทยาการเข้ารหัสลับส่วนใหญ่เป็นสิ่งที่ทำให้ไขว้เขวจากความปลอดภัย
— ริชาร์ด
แหล่งที่มา
3

สำหรับข้อมูลทั่วไปเกี่ยวกับการรักษาความปลอดภัยผมขอแนะนำให้อ่านBruce Schneier เขาก็มีเว็บไซต์ของเขาจดหมายข่าวลับกรัมหลายเล่มและได้ทำจำนวนมากของการสัมภาษณ์

ฉันจะคุ้นเคยกับวิศวกรรมสังคม (และเควินมิทนิค ) ด้วย

สำหรับหนังสือที่ดี (และสนุกสนานดี) เกี่ยวกับความปลอดภัยในโลกแห่งความจริงฉันขอแนะนำหนังสือThe Cuckoo's Eggโดย Cliff Stoll

— แดน Esparza
แหล่งที่มา
3

ตรวจสอบให้แน่ใจว่าได้ตรวจสอบOWASP Top 10 Listสำหรับการจัดหมวดหมู่ของเวกเตอร์ / ช่องโหว่การโจมตีหลักทั้งหมด

สิ่งเหล่านี้น่าอ่าน การเรียนรู้ที่จะคิดเหมือนผู้โจมตีจะสอนคุณเกี่ยวกับสิ่งที่ต้องคิดขณะที่คุณเขียนโค้ด

— Michael Kopinsky
แหล่งที่มา
2

ใส่เกลือและแฮชรหัสผ่านของผู้ใช้ อย่าบันทึกลงในข้อความธรรมดาในฐานข้อมูลของคุณ

— Abdull
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.