22 ช่องโหว่ของเว็บแอปพลิเคชันทั่วไปที่ควรทราบ

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

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

1. ระบบควบคุมการเข้าออกเสียหาย

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

2. การรับรองความถูกต้องที่เสียหาย

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

3. การฉีดกลับและป้อนบรรทัด (CRLF) ของสายการบิน

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

4. การแปลงรหัสไม่ปลอดภัย

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

5. ส่วนประกอบที่มีช่องโหว่ที่ชัดเจน

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

6. นโยบายการแบ่งปันทรัพยากรข้ามแหล่งกำเนิด (CORS)

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

   • โปรโตคอล: HTTP
   • โดเมน: Company.com
   • สคีมาเส้นทาง: /page#

   แม้ว่าจะมีความปลอดภัย แต่นโยบาย Same Origin ก็เข้มงวดเมื่อต้องจัดการกับแอปบนเว็บที่ต้องการการเข้าถึงทรัพยากรที่เชื่อมต่อกับบุคคลที่สามหรือโดเมนย่อย

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

7. การจัดการ ข้อมูลประจำตัว

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

8. การปลอมแปลงคำขอข้ามไซต์ (CSRF)

   การโจมตี CSRF ใช้วิธีวิศวกรรมทางสังคมเพื่อผลักดันให้ผู้ใช้แก้ไขข้อมูล เช่น รหัสผ่านหรือชื่อผู้ใช้ในแอปพลิเคชัน CSRF ซึ่งแตกต่างจากการโจมตีแบบ cross-site scripting (XXS) หรือมัลแวร์ กำหนดให้ผู้ใช้ลงชื่อเข้าใช้แอปพลิเคชันที่ใช้เฉพาะคุกกี้เซสชันเพื่อตรวจสอบคำขอของผู้ใช้หรือติดตามเซสชัน ทันทีที่ผู้ใช้ดำเนินการตามที่คาดไว้ ผู้ประสงค์ร้ายจะใช้เบราว์เซอร์เพื่อดำเนินการส่วนที่เหลือของการโจมตี เช่น การย้ายเงิน โดยที่ผู้ใช้ไม่รู้ว่าเกิดอะไรขึ้น

9. การเขียนสคริปต์ข้ามไซต์ (XXS)

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

10. การจัดทำดัชนีไดเรกทอรี

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

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

11. การข้ามไดเรกทอรี

    หรือที่เรียกว่าการโจมตีย้อนรอย, dot-dot-slash และการปีนไดเรกทอรี ช่องโหว่การข้ามผ่านไดเรกทอรีใช้ประโยชน์จากลักษณะที่แอปพลิเคชันได้รับข้อมูลจากเว็บเซิร์ฟเวอร์ รายการควบคุมการเข้าถึง (ACL) โดยทั่วไปจะจำกัดการเข้าถึงของผู้ใช้ในไฟล์ที่กำหนดบางไฟล์ภายในไดเร็กทอรีราก ผู้โจมตีที่เป็นอันตรายซึ่งใช้โหมดช่องโหว่การข้ามผ่านไดเรกทอรีจะระบุรูปแบบ URL ที่แอปพลิเคชันใช้ในการขอไฟล์

12. การห่อหุ้ม

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

    

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

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

13. การอ้างอิงวัตถุโดยตรงที่ไม่ปลอดภัย (IDOR)

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

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

    ช่องโหว่ของเว็บแอปพลิเคชัน ทั่วไปอื่นๆ ที่คุณควรรู้คือ:

14. การแยกการตอบสนอง HTTP

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

15. ข้อบกพร่องในการฉีด

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

16. ช่องโหว่ย่อยข้อความที่ไม่ปลอดภัย

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

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

17. การป้องกันชั้นการขนส่งไม่เพียงพอ

    Transport Layer Security (TLS) หมายถึงกระบวนการที่แอปพลิเคชันคอมพิวเตอร์สามารถ "สื่อสาร" ระหว่างกันบนอินเทอร์เน็ตได้อย่างปลอดภัย แอปพลิเคชันจำนวนหนึ่งใช้ TLS ในระหว่างกระบวนการตรวจสอบสิทธิ์เท่านั้น ซึ่งทำให้ข้อมูลและเซสชัน ID มีความเสี่ยงเมื่อมีบุคคลใช้แอปพลิเคชัน

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

18. การเรียกใช้โค้ดจากระยะไกล (RCE)

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

19. การรวมไฟล์ระยะไกล (RFI)

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

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

20. การกำหนดค่าความปลอดภัยผิดพลาด

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

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

21. การฉีด SQL

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

22. การเปิดใช้งานห้องสมุดอัตโนมัติที่ไม่ผ่านการตรวจสอบ

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

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

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

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