10 ช่องโหว่ด้านความปลอดภัยของเว็บที่พบบ่อยที่สุด

สำหรับบริษัทจำนวนมากเกินไป จนกระทั่ง หลังจาก เกิดการละเมิดความปลอดภัย แนวทางปฏิบัติด้านความปลอดภัยของเว็บจึงกลายเป็นสิ่งสำคัญอันดับแรก ในระหว่างที่ฉันทำงานเป็นผู้เชี่ยวชาญด้าน IT Security ฉันได้เห็นครั้งแล้วครั้งเล่าว่าโลกของปัญหาด้านความปลอดภัยในการพัฒนาเว็บนั้นไม่ชัดเจนสำหรับนักโปรแกรมเมอร์หลายคนของฉัน

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

โดยเฉพาะอย่างยิ่ง คู่มือนี้เน้นที่ข้อผิดพลาดด้านความปลอดภัยของเว็บทั่วไปและที่สำคัญ 10 ประการที่ควรทราบ รวมถึงคำแนะนำเกี่ยวกับวิธีการบรรเทาปัญหาเหล่านั้น โดยมุ่งเน้นที่ช่องโหว่ 10 อันดับแรกของเว็บที่ระบุโดย Open Web Application Security Project (OWASP) ซึ่งเป็นองค์กรระดับนานาชาติที่ไม่แสวงหาผลกำไรซึ่งมีเป้าหมายในการปรับปรุงความปลอดภัยของซอฟต์แวร์ทั่วโลก

ไพรเมอร์ความปลอดภัยทางไซเบอร์เล็กน้อยก่อนที่เราจะเริ่ม – การพิสูจน์ตัวตนและการอนุญาต

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

ก่อนที่เราจะดำเนินการต่อ เรามาชี้แจงความแตกต่างระหว่างคำสองคำนี้:

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

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

ข้อผิดพลาดทั่วไปในการรักษาความปลอดภัยเว็บ #1: ข้อบกพร่องในการฉีด

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

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

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

ในระบบที่มีอินพุต 1,000 รายการ เช่น การกรองสำเร็จ 999 รายการนั้นไม่เพียงพอ เนื่องจากยังเหลือฟิลด์เดียวที่สามารถทำหน้าที่เป็น Achilles ฮีลเพื่อทำให้ระบบของคุณล่ม และคุณอาจคิดว่าการใส่ผลลัพธ์การสืบค้น SQL ลงในแบบสอบถามอื่นเป็นความคิดที่ดี เนื่องจากฐานข้อมูลนั้นเชื่อถือได้ แต่ถ้าขอบเขตไม่เป็นเช่นนั้น ข้อมูลที่ป้อนเข้ามาทางอ้อมจากผู้ที่มีเจตนาร้าย นี่เรียกว่า Second Order SQL Injection ในกรณีที่คุณสนใจ

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

ข้อผิดพลาดด้านความปลอดภัยของเว็บทั่วไป #2: การตรวจสอบสิทธิ์ใช้งานไม่ได้

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

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

1. URL อาจมีรหัสเซสชันและรั่วไหลในส่วนหัวอ้างอิงถึงบุคคลอื่น
2. รหัสผ่านอาจไม่ได้รับการเข้ารหัสในที่จัดเก็บหรือการขนส่ง
3. รหัสเซสชันอาจคาดเดาได้ ดังนั้นการเข้าถึงจึงเป็นเรื่องเล็กน้อย
4. การแก้ไขเซสชันอาจเป็นไปได้
5. อาจมีการจี้เซสชัน หมดเวลาใช้งานไม่ถูกต้อง หรือใช้ HTTP (ไม่มีความปลอดภัย SSL) ฯลฯ...

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

ข้อผิดพลาดทั่วไปในการรักษาความปลอดภัยเว็บ #3: Cross Site Scripting (XSS)

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

การป้องกัน: มีวิธีแก้ปัญหาความปลอดภัยของเว็บอย่างง่าย: อย่าส่งคืนแท็ก HTML ให้กับลูกค้า สิ่งนี้มีประโยชน์เพิ่มเติมในการป้องกันการฉีด HTML ซึ่งเป็นการโจมตีที่คล้ายกันโดยที่ผู้โจมตีแทรกเนื้อหา HTML ธรรมดา (เช่น รูปภาพหรือโปรแกรมเล่นแฟลชที่มองไม่เห็นดัง ๆ ) – ไม่ได้ส่งผลกระทบสูงแต่น่ารำคาญอย่างแน่นอน (“โปรดหยุดด้วย!”) โดยปกติ วิธีแก้ปัญหาเป็นเพียงการแปลงเอนทิตี HTML ทั้งหมด เพื่อให้ <script> ถูกส่งกลับเป็น <script> . วิธีการฆ่าเชื้อที่ใช้บ่อยอีกวิธีหนึ่งคือการใช้นิพจน์ทั่วไปเพื่อแยกแท็ก HTML ออกโดยใช้นิพจน์ทั่วไปใน < และ > แต่นี่เป็นสิ่งที่อันตรายเนื่องจากเบราว์เซอร์จำนวนมากจะตีความ HTML ที่เสียหายอย่างรุนแรงได้ดี ดีกว่าที่จะแปลงอักขระทั้งหมดเป็นคู่ที่หลบหนี

ข้อผิดพลาดทั่วไปในการรักษาความปลอดภัยเว็บ #4: การอ้างอิงอ็อบเจ็กต์โดยตรงที่ไม่ปลอดภัย

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

ตัวอย่างเช่น โค้ดมีโมดูล download.php ที่อ่านและให้ผู้ใช้ดาวน์โหลดไฟล์ โดยใช้พารามิเตอร์ CGI เพื่อระบุชื่อไฟล์ (เช่น download.php?file=something.txt ) โดยความผิดพลาดหรือเนื่องจากความเกียจคร้าน นักพัฒนาละเว้นการอนุญาตจากรหัส ผู้โจมตีสามารถใช้สิ่งนี้เพื่อดาวน์โหลดไฟล์ระบบที่ผู้ใช้เรียกใช้ PHP เข้าถึงได้ เช่น โค้ดของแอปพลิเคชันเอง หรือข้อมูลอื่นๆ ที่เหลืออยู่บนเซิร์ฟเวอร์ เช่น ข้อมูลสำรอง เอ่อโอ้.

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

อนึ่ง ตัวอย่างทั้งสองนี้เป็นสิ่งที่ตัวฉันเองเคยเห็นบ่อยครั้ง "ในป่า"

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

ข้อผิดพลาดทั่วไปด้านความปลอดภัยของเว็บ #5: การกำหนดค่าความปลอดภัยผิดพลาด

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

1. การรันแอปพลิเคชันโดยเปิดใช้งานการดีบักในการผลิต
2. การเปิดใช้งานรายการไดเร็กทอรีบนเซิร์ฟเวอร์ ซึ่งทำให้ข้อมูลที่มีค่ารั่วไหล
3. ใช้งานซอฟต์แวร์ที่ล้าสมัย (คิดว่าเป็นปลั๊กอิน WordPress, PhpMyAdmin เก่า)
4. มีการเรียกใช้บริการที่ไม่จำเป็นบนเครื่อง
5. ไม่เปลี่ยนคีย์และรหัสผ่านเริ่มต้น (เกิดขึ้นบ่อยกว่าที่คุณคิด!)
6. เปิดเผยข้อมูลการจัดการข้อผิดพลาดแก่ผู้โจมตี เช่น การติดตามสแต็ก

การป้องกัน: มีกระบวนการ "สร้างและปรับใช้" ที่ดี (ควรเป็นแบบอัตโนมัติมากกว่า) ซึ่งสามารถเรียกใช้การทดสอบในการปรับใช้ โซลูชันการกำหนดค่าความปลอดภัยที่ผิดพลาดของคนจนคือ hooks หลังการคอมมิต เพื่อป้องกันไม่ให้รหัสออกไปพร้อมกับรหัสผ่านเริ่มต้นและ/หรือสิ่งที่พัฒนาอยู่ภายใน

ข้อผิดพลาดทั่วไปด้านความปลอดภัยของเว็บ #6: การเปิดเผยข้อมูลที่ละเอียดอ่อน

ช่องโหว่ด้านความปลอดภัยของเว็บนี้เกี่ยวกับการเข้ารหัสและการปกป้องทรัพยากร ข้อมูลที่ละเอียดอ่อนควรได้รับการเข้ารหัสตลอดเวลา รวมทั้งระหว่างส่งและพัก ไม่มีข้อยกเว้น. ข้อมูลบัตรเครดิตและรหัสผ่านของผู้ใช้ ไม่ ควรเดินทางหรือจัดเก็บโดยไม่ได้เข้ารหัส และควรแฮชรหัสผ่านเสมอ เห็นได้ชัดว่าอัลกอริธึมการเข้ารหัส/การแฮชต้องไม่ใช่อัลกอริธึมที่อ่อนแอ – หากมีข้อสงสัย มาตรฐานความปลอดภัยของเว็บแนะนำ AES (256 บิตขึ้นไป) และ RSA (2048 บิตขึ้นไป)

และในขณะที่มันไปโดยไม่บอกว่า ID เซสชันและข้อมูลที่ละเอียดอ่อนไม่ควรเดินทางใน URL และคุกกี้ที่มีความละเอียดอ่อนควรมีแฟล็กที่ปลอดภัยอยู่ สิ่งนี้สำคัญมากและไม่สามารถเน้นมากเกินไปได้

การป้องกัน:

• ระหว่างทาง: ใช้ HTTPS ที่มีใบรับรองและ PFS ที่เหมาะสม (Perfect Forward Secrecy) อย่ายอมรับสิ่งใด ๆ ผ่านการเชื่อมต่อที่ไม่ใช่ HTTPS มีแฟล็กที่ปลอดภัยบนคุกกี้

• ในการจัดเก็บ: สิ่งนี้ยากกว่า ก่อนอื่นคุณต้องลดการเปิดรับแสง หากคุณไม่ต้องการข้อมูลที่ละเอียดอ่อน ให้ทำลายทิ้ง ข้อมูลที่คุณไม่มีไม่สามารถถูกขโมยได้ อย่าจัดเก็บข้อมูลบัตรเครดิต เพราะคุณอาจ ไม่ ต้องการจัดการกับการปฏิบัติตามข้อกำหนดของ PCI ลงทะเบียนด้วยตัวประมวลผลการชำระเงิน เช่น Stripe หรือ Braintree ประการที่สอง หากคุณมีข้อมูลที่ละเอียดอ่อนซึ่งจำเป็นจริงๆ ให้จัดเก็บข้อมูลนั้นเข้ารหัสและตรวจดูให้แน่ใจว่ามีการแฮชรหัสผ่านทั้งหมดแล้ว สำหรับการแฮช แนะนำให้ใช้ bcrypt หากคุณไม่ได้ใช้ bcrypt ให้เรียนรู้เกี่ยวกับโต๊ะเกลือและโต๊ะสีรุ้ง

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

ข้อผิดพลาดทั่วไปด้านความปลอดภัยของเว็บ #7: ไม่มีการควบคุมการเข้าถึงระดับฟังก์ชัน

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

การป้องกัน: ทางฝั่งเซิร์ฟเวอร์ จะต้องทำการอนุญาต เสมอ ใช่เสมอ. ไม่มีข้อยกเว้นหรือจุดอ่อนจะส่งผลให้เกิดปัญหาร้ายแรง

ข้อผิดพลาดทั่วไปในการรักษาความปลอดภัยเว็บ #8: การปลอมแปลงคำขอข้ามไซต์ (CSRF)

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

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

พิจารณาตัวอย่างนี้:

ผู้โจมตีอลิซต้องการแบ่งเบาเป้าหมายกระเป๋าสตางค์ของทอดด์โดยโอนเงินบางส่วนให้กับเธอ ธนาคารของทอดด์มีความเสี่ยงต่อ CSRF ในการส่งเงิน Todd ต้องเข้าถึง URL ต่อไปนี้:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

หลังจากเปิด URL นี้แล้ว หน้าความสำเร็จจะแสดงต่อ Todd และการโอนเสร็จสิ้น อลิซยังรู้ด้วยว่าทอดด์มักจะเข้าชมไซต์ภายใต้การควบคุมของเธอที่ blog.aliceisawesome.com ซึ่งเธอวางข้อมูลโค้ดต่อไปนี้:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

เมื่อเยี่ยมชมเว็บไซต์ของ Alice เบราว์เซอร์ของ Todd คิดว่า Alice เชื่อมโยงกับรูปภาพ และออกคำขอ HTTP GET เพื่อดึงรูปภาพโดยอัตโนมัติ แต่สิ่งนี้จะแนะนำให้ธนาคารของ Todd โอนเงิน $1500 ให้กับ Alice

อนึ่ง นอกเหนือจากการแสดงให้เห็นถึงช่องโหว่ของ CSRF แล้ว ตัวอย่างนี้ยังแสดงให้เห็นถึงการเปลี่ยนแปลงสถานะเซิร์ฟเวอร์ด้วยคำขอ HTTP GET idempotent ซึ่งเป็นช่องโหว่ที่ร้ายแรง คำขอ HTTP GET ต้อง เป็น idempotent (ปลอดภัย) ซึ่งหมายความว่าไม่สามารถเปลี่ยนแปลงทรัพยากรที่เข้าถึงได้ ไม่เคยใช้วิธีการ idempotent เพื่อเปลี่ยนสถานะเซิร์ฟเวอร์

เกร็ดน่ารู้: CSRF เป็นวิธีที่ผู้คนใช้ในการบรรจุคุกกี้ในอดีต จนกระทั่งบริษัทในเครือฉลาดขึ้น

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

ข้อผิดพลาดทั่วไปในการรักษาความปลอดภัยเว็บ #9: การใช้ส่วนประกอบที่มีช่องโหว่ที่รู้จัก

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

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

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

การป้องกัน:

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

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

ข้อผิดพลาดทั่วไปด้านความปลอดภัยของเว็บ #10: การเปลี่ยนเส้นทางและส่งต่อที่ไม่ผ่านการตรวจสอบ

นี่เป็นปัญหาการกรองข้อมูลเข้าอีกครั้ง สมมติว่าไซต์เป้าหมายมีโมดูล 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) และช่องโหว่ด้านความปลอดภัยด้านไอทีของโรงเรียนเก่า (ไม่ใช่เว็บ) หากคุณมีคำขอเฉพาะเกี่ยวกับประเภทของการปกป้องเว็บที่จะเขียน โปรดติดต่อฉันได้โดยตรงที่ [email protected]

นี่คือความปลอดภัยของเว็บไซต์! ไชโย