สำหรับ บริษัท ที่มีจำนวนมากเกินไปก็ยังไม่ถึง หลังจาก เกิดการละเมิดความปลอดภัย แนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยบนเว็บกลายเป็นสิ่งสำคัญ ในช่วงหลายปีที่ทำงานในฐานะผู้เชี่ยวชาญด้านความปลอดภัยด้านไอทีฉันได้เห็นครั้งแล้วครั้งเล่าว่าโลกของปัญหาด้านความปลอดภัยในการพัฒนาเว็บเป็นอย่างไร เพื่อนโปรแกรมเมอร์ .
แนวทางที่มีประสิทธิภาพในการคุกคามความปลอดภัยบนเว็บจะต้องเป็นเชิงรุกและเชิงป้องกัน ในตอนท้ายโพสต์นี้มีจุดมุ่งหมายเพื่อจุดประกายความคิดด้านความปลอดภัยหวังว่าจะทำให้ผู้อ่านรู้สึกหวาดระแวงในปริมาณที่เหมาะสม
โดยเฉพาะอย่างยิ่งคู่มือนี้มุ่งเน้นไปที่ 10 ข้อผิดพลาดด้านความปลอดภัยของเว็บที่พบบ่อยและมีนัยสำคัญที่ต้องระวังรวมถึงคำแนะนำเกี่ยวกับวิธีการบรรเทา โฟกัสอยู่ที่ ช่องโหว่ของเว็บ 10 อันดับแรก ระบุโดย เปิดโครงการความปลอดภัยของโปรแกรมประยุกต์บนเว็บ (OWASP) ซึ่งเป็นองค์กรระหว่างประเทศที่ไม่แสวงหาผลกำไรซึ่งมีเป้าหมายในการปรับปรุงความปลอดภัยของซอฟต์แวร์ทั่วโลก
เมื่อพูดคุยกับโปรแกรมเมอร์และผู้เชี่ยวชาญด้านไอทีคนอื่น ๆ ฉันมักพบความสับสนเกี่ยวกับความแตกต่างระหว่างการอนุญาตและการพิสูจน์ตัวตน และแน่นอนความจริงแล้วตัวย่อ รับรองความถูกต้อง มักใช้สำหรับทั้งสองอย่างช่วยซ้ำเติมความสับสนที่พบบ่อยนี้ ความสับสนนี้เกิดขึ้นบ่อยมากจนอาจรวมปัญหานี้ไว้ในโพสต์นี้ว่า“ Common Web Vulnerability Zero”
ดังนั้นก่อนที่เราจะดำเนินการต่อเรามาชี้แจงความแตกต่างระหว่างคำศัพท์ทั้งสองนี้:
ระบุวิธีอื่น การรับรองความถูกต้อง คือการรู้ว่าใครคือเอนทิตีในขณะที่ การอนุญาต คือการรู้ว่าหน่วยงานที่กำหนดสามารถทำอะไรได้บ้าง ด้วยเหตุนี้เรามาดูปัญหาด้านความปลอดภัยอินเทอร์เน็ต 10 อันดับแรกกัน
ข้อบกพร่องในการฉีดเป็นผลมาจากความล้มเหลวแบบคลาสสิกในการกรองอินพุตที่ไม่น่าเชื่อถือ อาจเกิดขึ้นได้เมื่อคุณส่งข้อมูลที่ไม่มีการกรองไปยังเซิร์ฟเวอร์ SQL (การแทรก SQL) ไปยังเบราว์เซอร์ (XSS - เราจะพูดถึงเรื่องนี้ ในภายหลัง ) ไปยังเซิร์ฟเวอร์ LDAP (การฉีด LDAP) หรือที่อื่น ๆ ปัญหาคือผู้โจมตีสามารถแทรกคำสั่งไปยังเอนทิตีเหล่านี้ส่งผลให้ข้อมูลสูญหายและขโมยเบราว์เซอร์ของลูกค้า
สิ่งใดก็ตามที่ใบสมัครของคุณได้รับจากแหล่งที่มาที่ไม่น่าเชื่อถือจะต้องถูกกรอง ควรเป็นไปตามรายการที่อนุญาตพิเศษ คุณแทบไม่ควรใช้บัญชีดำเนื่องจากการได้รับสิทธิ์นั้นยากมากและโดยปกติจะข้ามได้ง่าย โดยทั่วไปผลิตภัณฑ์ซอฟต์แวร์ป้องกันไวรัสจะมีตัวอย่างที่เป็นตัวเอกของบัญชีดำที่ล้มเหลว การจับคู่รูปแบบไม่ทำงาน
การป้องกัน: ข่าวดีก็คือการป้องกันการฉีดเป็น 'เพียง' เรื่องของการกรองข้อมูลที่คุณป้อนให้เหมาะสมและคิดว่าข้อมูลนั้นเชื่อถือได้หรือไม่ แต่ข่าวร้ายก็คือ ทั้งหมด ข้อมูลที่ป้อนจะต้องได้รับการกรองอย่างเหมาะสมเว้นแต่จะสามารถเชื่อถือได้อย่างไม่มีข้อสงสัย (แต่คำพูดที่ว่า 'ไม่เคยพูดว่าไม่เคย' จะอยู่ในใจที่นี่)
ตัวอย่างเช่นในระบบที่มีอินพุต 1,000 อินพุตการกรอง 999 รายการที่ประสบความสำเร็จนั้นไม่เพียงพอเนื่องจากยังคงเหลือหนึ่งฟิลด์ที่สามารถใช้เป็นฮีล Achilles เพื่อทำให้ระบบของคุณล้มลง และคุณอาจคิดว่าการใส่ผลลัพธ์การสืบค้น SQL ลงในแบบสอบถามอื่นเป็นความคิดที่ดีเนื่องจากฐานข้อมูลได้รับความเชื่อถือ แต่ถ้าขอบเขตไม่ใช่ข้อมูลนั้นจะมาจากคนที่มีเจตนาร้ายโดยทางอ้อม นี้เรียกว่า ลำดับที่สอง SQL Injection ในกรณีที่คุณสนใจ
เนื่องจากการกรองเป็นเรื่องยากที่จะทำอย่างถูกต้อง (เช่น crypto) สิ่งที่ฉันมักแนะนำคือให้พึ่งพาฟังก์ชันการกรองของเฟรมเวิร์กของคุณซึ่งได้รับการพิสูจน์แล้วว่าใช้งานได้และได้รับการกลั่นกรองอย่างละเอียด หากคุณไม่ใช้เฟรมเวิร์กคุณต้องคิดอย่างหนักว่า ไม่ การใช้สิ่งเหล่านี้เหมาะสมกับบริบทความปลอดภัยของเซิร์ฟเวอร์ของคุณ 99% ของเวลาที่ไม่ได้
นี่คือชุดของปัญหาหลายประการที่อาจเกิดขึ้นระหว่างการตรวจสอบสิทธิ์เสีย แต่ปัญหาทั้งหมดไม่ได้เกิดจากสาเหตุเดียวกัน
สมมติว่าใคร ๆ ก็ยังต้องการที่จะม้วนรหัสรับรองความถูกต้องของตัวเองในปี 2014 (คุณคิดอะไรอยู่ ??) ฉันไม่แนะนำให้ทำเช่นนั้น เป็นเรื่องยากมากที่จะทำให้ถูกต้องและมีข้อผิดพลาดมากมายที่อาจเกิดขึ้นเพียงพูดถึง:
การป้องกัน: วิธีที่ตรงไปตรงมาที่สุดในการหลีกเลี่ยงช่องโหว่ด้านความปลอดภัยของเว็บนี้คือการใช้กรอบ คุณอาจจะนำสิ่งนี้ไปใช้ได้อย่างถูกต้อง แต่ก่อนหน้านี้ง่ายกว่ามาก ในกรณีที่คุณต้องการม้วนรหัสของคุณเองให้หวาดระแวงอย่างมากและให้ความรู้กับตัวเองว่าหลุมพรางคืออะไร มีค่อนข้างน้อย
นี่เป็นความล้มเหลวในการฆ่าเชื้ออินพุตที่ค่อนข้างแพร่หลาย (โดยพื้นฐานแล้วเป็นกรณีพิเศษของ ข้อผิดพลาดทั่วไป # 1 ). ผู้โจมตีให้แท็ก JavaScript ของเว็บแอปพลิเคชันของคุณในการป้อนข้อมูล เมื่ออินพุตนี้ถูกส่งกลับไปยังผู้ใช้ที่ไม่ได้รับการตรวจสอบเบราว์เซอร์ของผู้ใช้จะดำเนินการ อาจทำได้ง่ายเพียงแค่สร้างลิงก์และชักชวนให้ผู้ใช้คลิกหรืออาจเป็นเรื่องที่น่ากลัวกว่านั้นก็ได้ บนหน้าโหลดสคริปต์จะรันและตัวอย่างเช่นสามารถใช้เพื่อโพสต์คุกกี้ของคุณไปยังผู้โจมตี
การป้องกัน: มีวิธีแก้ปัญหาการรักษาความปลอดภัยบนเว็บอย่างง่าย: อย่าส่งคืนแท็ก HTML ให้กับไคลเอ็นต์ สิ่งนี้มีประโยชน์เพิ่มเติมในการป้องกันการฉีด HTML ซึ่งเป็นการโจมตีที่คล้ายกันโดยผู้โจมตีจะฉีดเนื้อหา HTML ธรรมดา (เช่นรูปภาพหรือโปรแกรมเล่นแฟลชที่มองไม่เห็นเสียงดัง) - ไม่ส่งผลกระทบสูง แต่น่ารำคาญอย่างแน่นอน (“ โปรดหยุด!”) โดยปกติวิธีแก้ปัญหาคือการแปลงทั้งหมด เอนทิตี HTML ดังนั้นจึงส่งคืนเป็น วิธีอื่น ๆ ที่มักใช้ในการฆ่าเชื้อคือการใช้นิพจน์ทั่วไปเพื่อตัดแท็ก HTML ออกโดยใช้นิพจน์ทั่วไปบน
<
และ >
แต่สิ่งนี้อันตรายเนื่องจากเบราว์เซอร์จำนวนมากจะตีความ HTML ที่เสียหายอย่างรุนแรงได้ดี ดีกว่าที่จะแปลงอักขระทั้งหมดเป็นคู่ที่หลบหนี
นี่เป็นกรณีคลาสสิกของการไว้วางใจการป้อนข้อมูลของผู้ใช้และการจ่ายราคาซึ่งทำให้เกิดช่องโหว่ด้านความปลอดภัย การอ้างอิงอ็อบเจ็กต์โดยตรงหมายความว่าอ็อบเจ็กต์ภายในเช่นไฟล์หรือคีย์ฐานข้อมูลถูกเปิดเผยต่อผู้ใช้ ปัญหานี้คือผู้โจมตีสามารถให้ข้อมูลอ้างอิงนี้ได้และหากไม่มีการบังคับใช้การอนุญาต (หรือใช้งานไม่ได้) ผู้โจมตีสามารถเข้าถึงหรือทำสิ่งต่างๆที่ควรถูกกีดกัน
ตัวอย่างเช่นรหัสมี download.php
โมดูลที่อ่านและอนุญาตให้ผู้ใช้ดาวน์โหลดไฟล์โดยใช้พารามิเตอร์ CGI เพื่อระบุชื่อไฟล์ (เช่น download.php?file=something.txt
) ไม่ว่าจะโดยไม่ได้ตั้งใจหรือเกิดจากความเกียจคร้านนักพัฒนาก็ละเว้นการอนุญาตจากโค้ด ขณะนี้ผู้โจมตีสามารถใช้สิ่งนี้เพื่อดาวน์โหลดไฟล์ระบบใด ๆ ที่ผู้ใช้ที่ใช้ PHP สามารถเข้าถึงได้เช่นรหัสแอปพลิเคชันเองหรือข้อมูลอื่น ๆ ที่วางทิ้งไว้บนเซิร์ฟเวอร์เช่นการสำรองข้อมูล เอ่อโอ้.
ac corp vs s corp คืออะไร
ตัวอย่างช่องโหว่ที่พบบ่อยอีกอย่างคือฟังก์ชันรีเซ็ตรหัสผ่านที่อาศัยการป้อนข้อมูลของผู้ใช้เพื่อกำหนดรหัสผ่านที่เราจะรีเซ็ต หลังจากคลิก URL ที่ถูกต้องผู้โจมตีสามารถแก้ไข username
ได้ ใน URL เพื่อพูดว่า 'ผู้ดูแลระบบ'
อนึ่งทั้งสองตัวอย่างนี้เป็นสิ่งที่ฉันเองเคยเห็นปรากฏอยู่บ่อยครั้ง“ ในป่า”
การป้องกัน: ดำเนินการอนุญาตผู้ใช้อย่างถูกต้องและสม่ำเสมอและกำหนดตัวเลือกที่อนุญาตพิเศษ บ่อยกว่านั้นปัญหาทั้งหมดสามารถหลีกเลี่ยงได้โดยการจัดเก็บข้อมูลภายในและไม่ต้องอาศัยการส่งผ่านจากไคลเอนต์ผ่านพารามิเตอร์ CGI ตัวแปรเซสชันในเฟรมเวิร์กส่วนใหญ่เหมาะสำหรับวัตถุประสงค์นี้
จากประสบการณ์ของฉันเว็บเซิร์ฟเวอร์และแอปพลิเคชันที่กำหนดค่าไม่ถูกต้องเป็นวิธีที่พบได้บ่อยกว่าที่ได้รับการกำหนดค่าอย่างเหมาะสม บางทีอาจเป็นเพราะไม่มีปัญหาในการทำให้เสียหาย ตัวอย่างบางส่วน:
การป้องกัน: มีกระบวนการ 'สร้างและปรับใช้' ที่ดี (โดยเฉพาะอย่างยิ่งอัตโนมัติ) ซึ่งสามารถเรียกใช้การทดสอบในการทำให้ใช้งานได้ โซลูชันการกำหนดค่าความปลอดภัยที่ไม่เหมาะสมของคนยากจนคือการเชื่อมต่อแบบโพสต์คอมมิตเพื่อป้องกันไม่ให้รหัสออกไปพร้อมกับรหัสผ่านเริ่มต้นและ / หรือสิ่งที่พัฒนาในตัว
ช่องโหว่ด้านความปลอดภัยของเว็บนี้เกี่ยวกับการเข้ารหัสลับและการปกป้องทรัพยากร ข้อมูลที่ละเอียดอ่อนควรได้รับการเข้ารหัสตลอดเวลารวมถึงระหว่างการขนส่งและในขณะพัก ไม่มีข้อยกเว้น. ข้อมูลบัตรเครดิตและรหัสผ่านผู้ใช้ควร ไม่เคย เดินทางหรือเก็บไว้โดยไม่เข้ารหัสและควรแฮชรหัสผ่านเสมอ เห็นได้ชัดว่าอัลกอริทึมการเข้ารหัส / การแฮชต้องไม่เป็นขั้นตอนที่อ่อนแอ - หากมีข้อสงสัยแนะนำให้ใช้มาตรฐานความปลอดภัยของเว็บ AES (256 บิตขึ้นไป) และ RSA (2048 บิตขึ้นไป) .
และแม้ว่าจะดำเนินไปโดยไม่ได้บอกว่ารหัสเซสชันและข้อมูลที่ละเอียดอ่อนไม่ควรเดินทางใน URL และคุกกี้ที่ละเอียดอ่อนควรมีการตั้งค่าสถานะความปลอดภัยสิ่งนี้มีความสำคัญมากและไม่สามารถเน้นมากเกินไปได้
การป้องกัน:
ในการขนส่ง: ใช้ HTTPS พร้อมใบรับรองที่เหมาะสมและ PFS (Perfect Forward Secrecy) . อย่ายอมรับสิ่งใด ๆ ผ่านการเชื่อมต่อที่ไม่ใช่ HTTPS ตั้งค่าสถานะความปลอดภัยบนคุกกี้
ในการจัดเก็บ: นี่มันยากกว่า ก่อนอื่นคุณต้องลดการเปิดรับแสง หากคุณไม่ต้องการข้อมูลที่ละเอียดอ่อนให้ฉีกทิ้ง ข้อมูลที่คุณไม่มีไม่สามารถเป็นได้ ถูกขโมย . อย่าเก็บข้อมูลบัตรเครดิต เคย อย่างที่คุณอาจไม่ต้องการที่จะต้องรับมือกับการเป็นอยู่ สอดคล้องกับ PCI . ลงทะเบียนกับผู้ประมวลผลการชำระเงินเช่น ลาย หรือ เบรนทรี . ประการที่สองหากคุณมีข้อมูลที่ละเอียดอ่อนที่คุณต้องการจริง ๆ ให้จัดเก็บข้อมูลที่เข้ารหัสและตรวจสอบให้แน่ใจว่ามีการแฮชรหัสผ่านทั้งหมด สำหรับการแฮชให้ใช้ bcrypt ขอแนะนำ หากคุณไม่ได้ใช้ bcrypt ให้ศึกษาเกี่ยวกับตัวเอง เกลือ และ โต๊ะสายรุ้ง .
และเสี่ยงต่อการระบุสิ่งที่ชัดเจน อย่าเก็บคีย์เข้ารหัสไว้ข้างข้อมูลที่มีการป้องกัน . นั่นเหมือนกับการจัดเก็บจักรยานของคุณด้วยตัวล็อกที่มีกุญแจอยู่ ปกป้องข้อมูลสำรองของคุณด้วยการเข้ารหัสและเก็บคีย์ของคุณไว้เป็นส่วนตัว และแน่นอนว่าอย่าทำกุญแจหาย!
นี่เป็นเพียงความล้มเหลวในการให้สิทธิ์ หมายความว่าเมื่อมีการเรียกใช้ฟังก์ชันบนเซิร์ฟเวอร์จะไม่มีการอนุญาตที่เหมาะสม หลายครั้งที่นักพัฒนาอาศัยความจริงที่ว่าฝั่งเซิร์ฟเวอร์สร้าง UI ขึ้นมาและพวกเขาคิดว่าไคลเอนต์ไม่สามารถเข้าถึงฟังก์ชันการทำงานที่เซิร์ฟเวอร์ไม่ได้ให้มา ไม่ง่ายอย่างนั้นเนื่องจากผู้โจมตีสามารถปลอมแปลงคำขอไปยังฟังก์ชัน 'ซ่อน' ได้ตลอดเวลาและจะไม่ถูกขัดขวางโดยข้อเท็จจริงที่ว่า UI ไม่ได้ทำให้ฟังก์ชันนี้เข้าถึงได้ง่าย ลองนึกภาพว่ามี /admin
แผงควบคุมและปุ่มจะปรากฏใน UI หากผู้ใช้เป็นผู้ดูแลระบบจริงๆ ไม่มีสิ่งใดป้องกันไม่ให้ผู้โจมตีค้นพบฟังก์ชันนี้และนำไปใช้ในทางที่ผิดหากไม่มีการให้สิทธิ์
การป้องกัน: ในฝั่งเซิร์ฟเวอร์ต้องได้รับอนุญาต เสมอ เสร็จแล้ว ใช่เสมอ. ไม่มีข้อยกเว้นหรือช่องโหว่ที่จะส่งผลให้เกิดปัญหาร้ายแรง
นี่เป็นตัวอย่างที่ดีของไฟล์ รองผู้สับสน โจมตีโดยที่เบราว์เซอร์ถูกหลอกโดยบุคคลอื่นให้ใช้อำนาจในทางที่ผิด ตัวอย่างเช่นไซต์ของบุคคลที่สามสามารถทำให้เบราว์เซอร์ของผู้ใช้ใช้งานในทางที่ผิดเนื่องจากมีอำนาจในการดำเนินการบางอย่างเพื่อผู้โจมตี
ในกรณีของ CSRF ไซต์ของบุคคลที่สามจะส่งคำขอไปยังไซต์เป้าหมาย (เช่นธนาคารของคุณ) โดยใช้เบราว์เซอร์ของคุณกับคุกกี้ / เซสชันของคุณ ตัวอย่างเช่นหากคุณเข้าสู่ระบบบนแท็บเดียวในหน้าแรกของธนาคารและพวกเขาเสี่ยงต่อการโจมตีนี้แท็บอื่นอาจทำให้เบราว์เซอร์ของคุณใช้ข้อมูลประจำตัวในนามของผู้โจมตีในทางที่ผิดซึ่งส่งผลให้เกิดความสับสน รองคือเบราว์เซอร์ที่ใช้อำนาจในทางมิชอบ (คุกกี้เซสชัน) เพื่อทำบางสิ่งที่ผู้โจมตีสั่งให้ทำ
ลองพิจารณาตัวอย่างนี้:
Attacker Alice ต้องการแบ่งเบากระเป๋าสตางค์ของ Todd โดยโอนเงินบางส่วนให้เธอ ธนาคารของ Todd มีความเสี่ยงต่อ CSRF ในการส่งเงิน Todd ต้องเข้าถึง URL ต่อไปนี้:
img / back-end / 29/10-most-common-web-security-riskrabilities.jpg
หลังจากเปิด URL นี้แล้วหน้าความสำเร็จจะถูกนำเสนอต่อ Todd และการถ่ายโอนจะเสร็จสิ้น อลิซยังรู้ด้วยว่าทอดด์มักจะเข้าชมไซต์ที่อยู่ภายใต้การควบคุมของเธอที่ blog.aliceisawesome.com ซึ่งเธอวางตัวอย่างข้อมูลต่อไปนี้:
เมื่อไปที่เว็บไซต์ของ Alice เบราว์เซอร์ของ Todd จะคิดว่า Alice เชื่อมโยงไปยังรูปภาพและส่งคำขอ HTTP GET เพื่อดึงภาพโดยอัตโนมัติ แต่จริงๆแล้วธนาคารของ Todd จะโอนเงิน 1,500 ดอลลาร์ให้กับ Alice
อนึ่งนอกเหนือจากการแสดงช่องโหว่ CSRF แล้วตัวอย่างนี้ยังแสดงให้เห็นถึงการเปลี่ยนแปลงสถานะของเซิร์ฟเวอร์ด้วยคำขอ HTTP GET ที่ไม่ได้ใช้งานซึ่งถือเป็นช่องโหว่ที่ร้ายแรง คำขอ HTTP GET ต้อง เป็น idempotent (ปลอดภัย) หมายความว่าไม่สามารถเปลี่ยนแปลงทรัพยากรที่เข้าถึงได้ ไม่เคยใช้วิธี idempotent เพื่อเปลี่ยนสถานะเซิร์ฟเวอร์เลย
ข้อเท็จจริงที่น่าสนใจ: CSRF เป็นวิธีที่ผู้คนใช้ในการบรรจุคุกกี้ในอดีตจนกระทั่ง บริษัท ในเครือมีความฉลาดขึ้น
ค่าใช้จ่ายนายจ้างสำหรับเครื่องคิดเลขค่าตอบแทนพนักงาน
การป้องกัน: จัดเก็บโทเค็นลับในช่องแบบฟอร์มที่ซ่อนอยู่ซึ่งไม่สามารถเข้าถึงได้จากไซต์ของบุคคลที่สาม แน่นอนคุณต้องตรวจสอบช่องที่ซ่อนอยู่นี้เสมอ บางไซต์ขอรหัสผ่านของคุณเช่นกันเมื่อแก้ไขการตั้งค่าที่ละเอียดอ่อน (เช่นอีเมลเตือนรหัสผ่านเป็นต้น) แม้ว่าฉันจะสงสัยว่ามีไว้เพื่อป้องกันการใช้เซสชันที่ละทิ้งของคุณในทางที่ผิด (เช่นในร้านอินเทอร์เน็ต)
ชื่อเรื่องบอกทุกอย่าง ฉันจะจัดอีกครั้งว่านี่เป็นปัญหาการบำรุงรักษา / การทำให้ใช้งานได้ ก่อนที่จะรวมโค้ดใหม่ให้ทำการวิจัยบางอย่างอาจจะมีการตรวจสอบบ้าง ใช้รหัสที่คุณได้รับจากบุคคลที่สุ่ม GitHub หรือบางฟอรัมอาจสะดวกมาก แต่ก็ไม่เสี่ยงต่อความเสี่ยงด้านความปลอดภัยของเว็บที่ร้ายแรง
ฉันเคยเห็นหลายกรณีตัวอย่างเช่นไซต์มี เป็นเจ้าของ (กล่าวคือในกรณีที่บุคคลภายนอกสามารถเข้าถึงระบบระดับผู้ดูแลระบบได้) ไม่ใช่เพราะโปรแกรมเมอร์โง่ แต่เป็นเพราะซอฟต์แวร์ของบุคคลที่สามยังคงไม่ได้รับการแก้ไขเป็นเวลาหลายปีในการผลิต สิ่งนี้เกิดขึ้นตลอดเวลากับปลั๊กอิน WordPress เช่น หากคุณคิดว่าพวกเขาจะไม่พบ phpmyadmin
ของคุณที่ซ่อนอยู่ การติดตั้งให้ฉันแนะนำคุณกับ dirbuster
บทเรียนในที่นี้คือการพัฒนาซอฟต์แวร์จะไม่สิ้นสุดเมื่อมีการปรับใช้แอปพลิเคชัน จะต้องมีเอกสารการทดสอบและแผนเกี่ยวกับวิธีการบำรุงรักษาและอัปเดตโดยเฉพาะอย่างยิ่งหากมีส่วนประกอบของบุคคลที่สามหรือโอเพนซอร์ส
การป้องกัน:
ใช้ความระมัดระวัง นอกเหนือจากการใช้ความระมัดระวังอย่างเห็นได้ชัดเมื่อใช้ส่วนประกอบดังกล่าวแล้วอย่าเป็นตัวคัดลอกวางโค้ด ตรวจสอบชิ้นส่วนของโค้ดที่คุณกำลังจะใส่ลงในซอฟต์แวร์ของคุณอย่างถี่ถ้วนเนื่องจากอาจเสียหายเกินกว่าจะซ่อมแซมได้ (หรือในบางกรณีอาจมีเจตนาที่เป็นอันตราย - บางครั้งการโจมตีด้านความปลอดภัยของเว็บจะได้รับเชิญโดยไม่เจตนา)
ติดตามข่าวสารล่าสุด ตรวจสอบให้แน่ใจว่าคุณใช้เวอร์ชันล่าสุดของทุกสิ่งที่คุณเชื่อถือและมีแผนที่จะอัปเดตเป็นประจำ อย่างน้อยสมัครรับจดหมายข่าวเกี่ยวกับช่องโหว่ด้านความปลอดภัยใหม่ ๆ เกี่ยวกับผลิตภัณฑ์
นี่เป็นปัญหาการกรองอินพุตอีกครั้ง สมมติว่าไซต์เป้าหมายมี redirect.php
โมดูลที่ใช้ URL เป็น GET
พารามิเตอร์. การจัดการพารามิเตอร์สามารถสร้าง URL บน targetsite.com
ที่เปลี่ยนเส้นทางเบราว์เซอร์ไปที่ malwareinstall.com
เมื่อผู้ใช้เห็นลิงก์ก็จะเห็น targetsite.com/blahblahblah
ซึ่งผู้ใช้คิดว่าเชื่อถือได้และปลอดภัยที่จะคลิก พวกเขาไม่ค่อยรู้ว่าสิ่งนี้จะถ่ายโอนไปยังหน้าดรอปมัลแวร์ (หรือหน้าเว็บที่เป็นอันตรายอื่น ๆ ) หรืออีกวิธีหนึ่งผู้โจมตีอาจเปลี่ยนเส้นทางเบราว์เซอร์ไปที่ targetsite.com/deleteprofile?confirm=1
เป็นเรื่องที่ควรค่าแก่การกล่าวถึงว่าการบรรจุอินพุตที่ผู้ใช้กำหนดเองที่ไม่ได้รับการรับรองลงในส่วนหัว HTTP อาจนำไปสู่ การฉีดส่วนหัว ซึ่งค่อนข้างแย่
การป้องกัน: ตัวเลือก ได้แก่ :
ฉันหวังว่าฉันจะสามารถกระตุ้นสมองของคุณได้เล็กน้อยด้วยโพสต์นี้และเพื่อแนะนำการรับรู้เกี่ยวกับความหวาดระแวงและช่องโหว่ด้านความปลอดภัยของเว็บไซต์
ประเด็นหลักที่นี่คือการปฏิบัติของซอฟต์แวร์ที่มีอายุเก่าแก่มีอยู่ด้วยเหตุผลและสิ่งที่นำกลับมาใช้ในวันนี้สำหรับการล้นบัฟเฟอร์ยังคงใช้กับสตริงดองใน Python ในปัจจุบัน โปรโตคอลความปลอดภัยช่วยให้คุณเขียนโปรแกรมที่ถูกต้อง (เพิ่มเติม) ซึ่งโปรแกรมเมอร์ทุกคนควรปรารถนา
โปรดใช้ความรู้นี้อย่างมีความรับผิดชอบและอย่าทดสอบหน้าเว็บโดยไม่ได้รับอนุญาต!
สำหรับข้อมูลเพิ่มเติมและอื่น ๆ การโจมตีฝั่งเซิร์ฟเวอร์เฉพาะ , มองไปที่: https://www.owasp.org/index.php/Category:Attack .
ยินดีรับข้อเสนอแนะเกี่ยวกับโพสต์นี้และคำแนะนำในการบรรเทาทุกข์ มีการวางแผนโพสต์ที่เกี่ยวข้องในอนาคตโดยเฉพาะอย่างยิ่งในประเด็นของ การปฏิเสธการให้บริการแบบกระจาย (DDoS) และช่องโหว่ด้านความปลอดภัยไอทีแบบเก่า (ไม่ใช่เว็บ) หากคุณมีคำขอเฉพาะเกี่ยวกับประเภทของการป้องกันเว็บที่จะเขียนเกี่ยวกับโปรดอย่าลังเลที่จะติดต่อฉันโดยตรงที่ [ป้องกันอีเมล]
นี่คือความปลอดภัยของเว็บไซต์! ไชโย
ที่เกี่ยวข้อง:ภัยคุกคามด้านความปลอดภัยทางอินเทอร์เน็ตเป็นวิธีการใช้เทคโนโลยีเว็บในทางที่ผิดเพื่อสร้างความเสียหายให้กับเว็บไซต์ผู้ใช้หรือแม้แต่อินเทอร์เน็ตโดยรวม เกิดขึ้นจากเว็บไซต์ที่มีการกำหนดค่าไม่ถูกต้องถูกตั้งโปรแกรมโดยไม่ได้ตั้งใจโดยมีช่องโหว่หรืออาศัยส่วนประกอบที่มีช่องโหว่
ภัยคุกคามด้านความปลอดภัยทางอินเทอร์เน็ต 10 อันดับแรก ได้แก่ ข้อบกพร่องในการแทรกและการตรวจสอบสิทธิ์ XSS การอ้างอิงวัตถุโดยตรงที่ไม่ปลอดภัยการกำหนดค่าความปลอดภัยการเปิดเผยข้อมูลที่ละเอียดอ่อนการขาดการอนุญาตระดับฟังก์ชัน CSRF องค์ประกอบที่ไม่ปลอดภัยและการเปลี่ยนเส้นทางที่ไม่มีการกรอง
ตรวจสอบให้แน่ใจว่าการเปลี่ยนเส้นทางใด ๆ ที่เว็บไซต์ของคุณทำ (ผ่านส่วนหัว HTTP, เมตาแท็ก, JavaScript ฯลฯ ) ไม่ต้องอาศัยการป้อนข้อมูลของผู้ใช้หรือหากเป็นเช่นนั้นการป้อนข้อมูลของผู้ใช้จะได้รับการชำระล้างเช่นผ่านรายการที่อนุญาตพิเศษ
โทเค็น CSRF ช่วยให้เซิร์ฟเวอร์ทราบว่าคำขอนั้นมาจากผู้ใช้ไซต์ของตนเองไม่ใช่จากเว็บไซต์อื่นที่ผู้ใช้กำลังเยี่ยมชม เนื่องจากมีการส่งคำขอทุกครั้งผ่านช่องแบบฟอร์มที่ซ่อนอยู่เพื่อป้องกันไม่ให้ไซต์ที่เป็นอันตรายดำเนินการในนามของผู้ชมผ่านการโจมตี CSRF
หรือที่เรียกว่าอินพุต 'สกปรก' หรือ 'ไม่น่าเชื่อถือ' อินพุตที่ไม่ผ่านการตรวจสอบคืออินพุตใด ๆ ที่ส่งไปยังเซิร์ฟเวอร์ของคุณ ชิ้นส่วนของโค้ดใด ๆ ที่ใช้ข้อมูลดังกล่าวโดยไม่ได้รับการฆ่าเชื้อก่อนถือเป็นช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้นกับคุณผู้ใช้ของคุณและแม้แต่ผู้ที่ไม่รู้อิโหน่อิเหน่
การแทรก SQL คือการที่โค้ดของคุณใส่อินพุตที่ไม่ได้รับการตรวจสอบลงในคำสั่ง SQL โดยตรงแทนที่จะใช้เคียวรีที่กำหนดพารามิเตอร์ (เช่นหนึ่งที่มีตัวยึดตำแหน่ง) โชคดีที่การโจมตีด้วยการแทรก SQL เป็นวิธีที่ง่ายที่สุดในการบรรเทาเนื่องจากการสนับสนุนการสืบค้นแบบกำหนดพารามิเตอร์ถูกสร้างขึ้นในทุกฐานข้อมูล เข้าถึงห้องสมุด
XSS ใช้ประโยชน์จากการใช้งาน 'คุณลักษณะ' ของเว็บแอปพลิเคชันทั่วไปโดยเข้าใจผิด: เพื่อรับ HTML จากผู้ใช้รายหนึ่งและนำเสนอต่อผู้ใช้รายอื่น เนื่องจาก HTML ที่ไม่มีการกรองสามารถมี JavaScript ผู้โจมตีจึงสามารถเรียกใช้โค้ดในนามของผู้ใช้รายอื่นเมื่อพวกเขาใช้เว็บแอปพลิเคชันที่เป็นปัญหาในครั้งต่อไป
การกำหนดค่าความปลอดภัยผิดมักเกี่ยวข้องกับการใช้ค่าเริ่มต้นที่ควรเปลี่ยน: คีย์และรหัสผ่านการเข้าถึงข้อมูลและบริการซึ่งในตอนแรกเปิดกว้างสำหรับการตั้งค่าและทดสอบความสะดวกและละเลยการอัปเดตความปลอดภัยอย่างต่อเนื่อง
นี่คือเมื่อเซิร์ฟเวอร์ไม่ได้ตั้งโปรแกรมเพื่อตรวจสอบการอนุญาตสำหรับฟังก์ชันที่กำหนด บ่อยครั้งที่สิ่งนี้มาจากความคิด 'การรักษาความปลอดภัยผ่านความคลุมเครือ': มีการสันนิษฐานอย่างผิด ๆ ว่าหากไม่แสดงคุณลักษณะที่ละเอียดอ่อนต่อทุกคนผู้ที่อาจโจมตีจะไม่ทราบข้อมูลเกี่ยวกับเรื่องนี้
การเปิดเผยข้อมูลที่ละเอียดอ่อนเกิดขึ้นเมื่อแอป (ไม่ว่าจะโดยข้อบกพร่องของตัวเองหรือโดยการใช้ช่องโหว่ของผู้โจมตี) เปิดเผยข้อมูลส่วนตัวของผู้ใช้ (เช่นหมายเลขบัตรเครดิต) แก่บุคคลที่สามที่ไม่ได้รับอนุญาต: ผู้ใช้รายอื่นหุ้นส่วนทางธุรกิจพนักงานหรือ สาธารณะ.