10 ช่องโหว่ด้านความปลอดภัยบนเว็บที่พบบ่อยที่สุด
โอลิเวอร์โจนส์
OWASP หรือ Open Web Security Project เป็นองค์กรการกุศลที่ไม่แสวงหากำไรซึ่งมุ่งเน้นไปที่การปรับปรุงความปลอดภัยของซอฟต์แวร์และแอปพลิเคชันเว็บ
องค์กรเผยแพร่รายการช่องโหว่ด้านความปลอดภัยบนเว็บอันดับต้น ๆ โดยอิงตามข้อมูลจากองค์กรความปลอดภัยต่างๆ
ช่องโหว่ด้านความปลอดภัยบนเว็บจะได้รับการจัดลำดับความสำคัญโดยขึ้นอยู่กับความสามารถในการใช้ประโยชน์ การตรวจจับได้ และผลกระทบต่อซอฟต์แวร์
- การใช้ประโยชน์ –สิ่งที่จำเป็นในการใช้ประโยชน์จากช่องโหว่ด้านความปลอดภัย? ความสามารถในการเอารัดเอาเปรียบสูงสุดเมื่อการโจมตีต้องการเพียงเว็บเบราว์เซอร์และต่ำสุดคือการเขียนโปรแกรมและเครื่องมือขั้นสูง
- การตรวจจับ – การตรวจจับภัยคุกคามทำได้ง่ายเพียงใด ข้อมูลที่แสดงใน URL แบบฟอร์มหรือข้อความแสดงข้อผิดพลาดนั้นง่ายที่สุด และรหัสต้นทางนั้นง่ายที่สุด
- ผลกระทบหรือความเสียหาย –ความเสียหายจะเกิดขึ้นมากน้อยเพียงใดหากช่องโหว่ด้านความปลอดภัยถูกเปิดเผยหรือถูกโจมตี? สูงสุดคือความผิดพลาดของระบบโดยสมบูรณ์ และต่ำสุดคือไม่มีอะไรเลย
วัตถุประสงค์หลักของ OWASP Top 10 คือการให้ความรู้แก่นักพัฒนา นักออกแบบ ผู้จัดการ สถาปนิก และองค์กรต่างๆ เกี่ยวกับช่องโหว่ด้านความปลอดภัยที่สำคัญที่สุด
ช่องโหว่ด้านความปลอดภัย 10 อันดับแรกตาม OWASP Top 10 ได้แก่:
ด้วย SQL Injection
Descriptไอออน
การแทรกเป็นช่องโหว่ด้านความปลอดภัยที่ช่วยให้ผู้โจมตีสามารถแก้ไขแบ็กเอนด์ได้ SQL คำสั่งโดยการจัดการข้อมูลที่ผู้ใช้ให้มา
การแทรกเกิดขึ้นเมื่ออินพุตของผู้ใช้ถูกส่งไปยังล่ามโดยเป็นส่วนหนึ่งของคำสั่งหรือการสืบค้น และหลอกให้ล่ามดำเนินการคำสั่งที่ไม่ได้ตั้งใจและให้สิทธิ์การเข้าถึงข้อมูลที่ไม่ได้รับอนุญาต
คำสั่ง SQL ซึ่งเมื่อดำเนินการโดยเว็บแอปพลิเคชันยังสามารถเปิดเผยฐานข้อมูลส่วนหลังได้
นัย
- ผู้โจมตีสามารถแทรกเนื้อหาที่เป็นอันตรายลงในช่องที่มีช่องโหว่
- ข้อมูลที่ละเอียดอ่อน เช่น ชื่อผู้ใช้ รหัสผ่าน ฯลฯ สามารถอ่านได้จากฐานข้อมูล
- ข้อมูลฐานข้อมูลสามารถแก้ไขได้ (แทรก/อัปเดต/ลบ)
- การบริหารจัดการ Operaสามารถดำเนินการบนฐานข้อมูลได้
วัตถุที่มีความเสี่ยง
- ช่องใส่
- URL ที่โต้ตอบกับฐานข้อมูล
ตัวอย่าง:
- การแทรก SQL ในหน้าเข้าสู่ระบบ
เข้าสู่ระบบแอปพลิเคชันโดยไม่มีข้อมูลประจำตัวที่ถูกต้อง
ชื่อผู้ใช้ที่ถูกต้องสามารถใช้ได้ และไม่มีรหัสผ่าน
URL ทดสอบ: http://demo.testfire.net/default.aspx
ชื่อผู้ใช้: sjones
รหัสผ่าน: 1=1′ หรือ pass123
แบบสอบถาม SQL ที่สร้างและส่งไปยังล่ามดังต่อไปนี้
เลือก * จากผู้ใช้ โดยที่ User_Name = sjones และรหัสผ่าน = 1=1′ หรือ pass123;
แนะนำ
- สีขาวแสดงรายการช่องป้อนข้อมูล
- หลีกเลี่ยงการแสดงข้อความแสดงข้อผิดพลาดโดยละเอียดที่เป็นประโยชน์ต่อผู้โจมตี
การเขียนสคริปต์ข้ามไซต์
Descriptไอออน
Cross Site Scripting มีชื่อเรียกสั้นๆ ว่า XSS
สคริปต์เป้าหมายช่องโหว่ XSS ที่ฝังอยู่ในเพจที่ดำเนินการบนฝั่งไคลเอ็นต์ เช่น เบราว์เซอร์ผู้ใช้ แทนที่จะดำเนินการที่ฝั่งเซิร์ฟเวอร์ ข้อบกพร่องเหล่านี้สามารถเกิดขึ้นเมื่อแอปพลิเคชันนำข้อมูลที่ไม่น่าเชื่อถือและส่งไปยังเว็บเบราว์เซอร์โดยไม่มีการตรวจสอบที่เหมาะสม
ผู้โจมตีสามารถใช้ XSS เพื่อรันสคริปต์ที่เป็นอันตรายกับผู้ใช้ในกรณีนี้คือเบราว์เซอร์เหยื่อ เนื่องจากเบราว์เซอร์ไม่สามารถรู้ได้ว่าสคริปต์เชื่อถือได้หรือไม่ สคริปต์จะถูกเรียกใช้งาน และผู้โจมตีสามารถขโมยคุกกี้เซสชัน ทำให้เว็บไซต์เสียหาย หรือเปลี่ยนเส้นทางผู้ใช้ไปยังเว็บไซต์ที่ไม่พึงประสงค์และเป็นอันตรายได้
XSS คือการโจมตีที่ช่วยให้ผู้โจมตีสามารถรันสคริปต์บนเบราว์เซอร์ของเหยื่อได้
ความหมาย:
- การใช้ช่องโหว่ด้านความปลอดภัยนี้ ผู้โจมตีสามารถแทรกสคริปต์ลงในแอปพลิเคชัน สามารถขโมยคุกกี้เซสชัน ทำลายเว็บไซต์ และสามารถเรียกใช้มัลแวร์บนเครื่องของเหยื่อได้
วัตถุที่มีความเสี่ยง
- ช่องใส่
- URL ที่
ตัวอย่าง
1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>
สคริปต์ด้านบนเมื่อรันบนเบราว์เซอร์ จะมีกล่องข้อความปรากฏขึ้นหากไซต์นั้นมีความเสี่ยงต่อ XSS
การโจมตีที่รุนแรงยิ่งขึ้นสามารถทำได้หากผู้โจมตีต้องการแสดงหรือจัดเก็บคุกกี้เซสชัน
2. http://demo.testfire.net/search.aspx?txtSearch <iframe- http://google.com ความกว้าง = 500 สูง 500>
สคริปต์ด้านบนเมื่อทำงาน เบราว์เซอร์จะโหลดเฟรมที่มองไม่เห็นซึ่งชี้ไป http://google.com.
การโจมตีสามารถร้ายแรงได้โดยการเรียกใช้สคริปต์ที่เป็นอันตรายบนเบราว์เซอร์
แนะนำ
- ช่องป้อนข้อมูลรายการสีขาว
- การเข้ารหัสอินพุตเอาต์พุต
การรับรองความถูกต้องและการจัดการเซสชันที่ใช้งานไม่ได้
Descriptไอออน
โดยปกติเว็บไซต์จะสร้างคุกกี้เซสชันและรหัสเซสชันสำหรับแต่ละเซสชันที่ถูกต้อง และคุกกี้เหล่านี้ประกอบด้วยข้อมูลที่ละเอียดอ่อน เช่น ชื่อผู้ใช้ รหัสผ่าน ฯลฯ เมื่อเซสชันสิ้นสุดลงโดยการออกจากระบบหรือปิดเบราว์เซอร์อย่างกะทันหัน คุกกี้เหล่านี้ควรจะใช้งานไม่ได้ กล่าวคือ สำหรับแต่ละเซสชัน ควรมีคุกกี้ใหม่
หากคุกกี้ไม่ถูกต้อง ข้อมูลที่ละเอียดอ่อนจะมีอยู่ในระบบ ตัวอย่างเช่น ผู้ใช้ที่ใช้คอมพิวเตอร์สาธารณะ (Cyber Cafe) คุกกี้ของไซต์ที่มีช่องโหว่จะอยู่บนระบบและเปิดเผยต่อผู้โจมตี ผู้โจมตีใช้คอมพิวเตอร์สาธารณะเครื่องเดิมหลังจากนั้น ข้อมูลที่ละเอียดอ่อนจะถูกบุกรุก
ในทำนองเดียวกัน ผู้ใช้ที่ใช้คอมพิวเตอร์สาธารณะ แทนที่จะออกจากระบบ เขาจะปิดเบราว์เซอร์ทันที ผู้โจมตีใช้ระบบเดียวกัน เมื่อเรียกดูไซต์ที่มีช่องโหว่เดียวกัน เซสชันก่อนหน้าของเหยื่อจะถูกเปิดขึ้น ผู้โจมตีสามารถทำอะไรก็ได้ที่เขาต้องการ ตั้งแต่การขโมยข้อมูลโปรไฟล์ ข้อมูลบัตรเครดิต ฯลฯ
ควรทำการตรวจสอบเพื่อค้นหาจุดแข็งของการรับรองความถูกต้องและการจัดการเซสชัน คีย์ โทเค็นเซสชัน คุกกี้ควรได้รับการติดตั้งอย่างถูกต้องโดยไม่กระทบต่อรหัสผ่าน
วัตถุที่มีความเสี่ยง
- รหัสเซสชันที่ถูกเปิดเผยบน URL อาจทำให้เกิดการโจมตีแบบตรึงเซสชันได้
- รหัสเซสชันเหมือนกันก่อนและหลังออกจากระบบและเข้าสู่ระบบ
- การหมดเวลาของเซสชันไม่ได้ถูกนำมาใช้อย่างถูกต้อง
- แอปพลิเคชันกำลังกำหนด ID เซสชันเดียวกันสำหรับเซสชันใหม่แต่ละเซสชัน
- ส่วนที่ได้รับการรับรองความถูกต้องของแอปพลิเคชันได้รับการป้องกันโดยใช้ SSL และรหัสผ่านจะถูกจัดเก็บในรูปแบบแฮชหรือเข้ารหัส
- ผู้ใช้ที่มีสิทธิ์ระดับต่ำสามารถนำเซสชันนี้กลับมาใช้ใหม่ได้
นัย
- การใช้ช่องโหว่นี้ ผู้โจมตีสามารถจี้เซสชั่น เข้าถึงระบบโดยไม่ได้รับอนุญาต ซึ่งช่วยให้สามารถเปิดเผยและแก้ไขข้อมูลที่ไม่ได้รับอนุญาตได้
- เซสชันอาจถูกแจ็คสูงโดยใช้คุกกี้ที่ถูกขโมย หรือเซสชันที่ใช้ XSS
ตัวอย่าง
- แอปพลิเคชันจองสายการบินรองรับการเขียน URL ใหม่ โดยใส่รหัสเซสชันใน URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (การขายตั๋วไปมัลดีฟส์) ผู้ใช้เว็บไซต์ที่ผ่านการรับรองต้องการแจ้งให้เพื่อนทราบเกี่ยวกับการขายและส่งอีเมลถึงเพื่อน เพื่อนจะได้รับ ID เซสชันและสามารถใช้แก้ไขโดยไม่ได้รับอนุญาตหรือใช้ข้อมูลบัตรเครดิตที่บันทึกไว้ในทางที่ผิด
- แอปพลิเคชันมีความเสี่ยงต่อ XSS ซึ่งผู้โจมตีสามารถเข้าถึงรหัสเซสชันและสามารถใช้เพื่อจี้เซสชันได้
- แอปพลิเคชันไม่ได้ตั้งค่าเวลาหมดเวลาอย่างเหมาะสม ผู้ใช้ใช้คอมพิวเตอร์สาธารณะและปิดเบราว์เซอร์แทนที่จะออกจากระบบและเดินจากไป ผู้โจมตีใช้เบราว์เซอร์เดียวกันในเวลาต่อมา และเซสชันก็ได้รับการรับรอง
แนะนำ
- ข้อกำหนดการตรวจสอบสิทธิ์และการจัดการเซสชันทั้งหมดควรได้รับการกำหนดตามมาตรฐานการตรวจสอบความปลอดภัยของแอปพลิเคชัน OWASP
- อย่าเปิดเผยข้อมูลประจำตัวใด ๆ ใน URL หรือบันทึก
- ควรพยายามอย่างเต็มที่เพื่อหลีกเลี่ยงข้อบกพร่อง XSS ซึ่งอาจใช้ในการขโมย ID เซสชันได้
การอ้างอิงวัตถุโดยตรงที่ไม่ปลอดภัย
Descriptไอออน
มันเกิดขึ้นเมื่อนักพัฒนาเปิดเผยการอ้างอิงไปยังออบเจ็กต์การใช้งานภายใน เช่น ไฟล์ ไดเร็กทอรี หรือคีย์ฐานข้อมูลใน URL หรือเป็นพารามิเตอร์ FORM ผู้โจมตีสามารถใช้ข้อมูลนี้เพื่อเข้าถึงวัตถุอื่น ๆ และสามารถสร้างการโจมตีในอนาคตเพื่อเข้าถึงข้อมูลที่ไม่ได้รับอนุญาตได้
นัย
- การใช้ช่องโหว่นี้ ผู้โจมตีสามารถเข้าถึงออบเจ็กต์ภายในที่ไม่ได้รับอนุญาต สามารถแก้ไขข้อมูล หรือโจมตีแอปพลิเคชันได้
วัตถุที่มีความเสี่ยง
- ใน URL
ตัวอย่าง:
การเปลี่ยนแปลง “รหัสผู้ใช้” ใน URL ต่อไปนี้สามารถทำให้ผู้โจมตีสามารถดูข้อมูลของผู้ใช้รายอื่นได้
http://www.vulnerablesite.com/userid=123 แก้ไขเป็น http://www.vulnerablesite.com/userid=124
ผู้โจมตีสามารถดูข้อมูลอื่น ๆ ได้โดยการเปลี่ยนค่ารหัสผู้ใช้
ข้อแนะนำ:
- ใช้การตรวจสอบการควบคุมการเข้าถึง
- หลีกเลี่ยงการเปิดเผยการอ้างอิงวัตถุใน URL
- ตรวจสอบการอนุญาตสำหรับวัตถุอ้างอิงทั้งหมด
การปลอมแปลงคำขอข้ามไซต์
Descriptไอออน
การปลอมแปลงคำขอข้ามไซต์เป็นคำขอปลอมที่มาจากไซต์ข้าม
การโจมตี CSRF คือการโจมตีที่เกิดขึ้นเมื่อเว็บไซต์ อีเมล หรือโปรแกรมที่เป็นอันตรายทำให้เบราว์เซอร์ของผู้ใช้ดำเนินการที่ไม่ต้องการบนเว็บไซต์ที่เชื่อถือได้ซึ่งผู้ใช้ได้รับการรับรองความถูกต้องอยู่แล้ว
การโจมตี CSRF บังคับให้เบราว์เซอร์ของเหยื่อที่เข้าสู่ระบบส่งคำขอ HTTP ปลอม รวมถึงคุกกี้เซสชันของเหยื่อและข้อมูลการตรวจสอบความถูกต้องอื่น ๆ ที่รวมไว้โดยอัตโนมัติ ไปยังเว็บแอปพลิเคชันที่มีช่องโหว่
ผู้โจมตีจะส่งลิงก์ไปยังเหยื่อเมื่อผู้ใช้คลิกที่ URL เมื่อเข้าสู่เว็บไซต์เดิม ข้อมูลจะถูกขโมยจากเว็บไซต์
นัย
- การใช้ช่องโหว่นี้ในฐานะผู้โจมตีสามารถเปลี่ยนข้อมูลโปรไฟล์ผู้ใช้ เปลี่ยนสถานะ สร้างผู้ใช้ใหม่ในนามของผู้ดูแลระบบ ฯลฯ
วัตถุที่มีความเสี่ยง
- หน้าโปรไฟล์ผู้ใช้
- แบบฟอร์มบัญชีผู้ใช้
- หน้าธุรกรรมทางธุรกิจ
ตัวอย่าง
เหยื่อเข้าสู่ระบบเว็บไซต์ธนาคารโดยใช้ข้อมูลประจำตัวที่ถูกต้อง เขาได้รับอีเมลจากผู้โจมตีที่แจ้งว่า "กรุณาคลิกที่นี่เพื่อบริจาค 1 ดอลลาร์เพื่อการกุศล"
เมื่อเหยื่อคลิกที่มัน จะมีการสร้างคำขอที่ถูกต้องเพื่อบริจาค $1 ให้กับบัญชีใดบัญชีหนึ่ง
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
ผู้โจมตีจับคำขอนี้และสร้างคำขอด้านล่างและฝังไว้ในปุ่มที่ระบุว่า “ฉันสนับสนุนสาเหตุ”
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
เนื่องจากเซสชันได้รับการรับรองความถูกต้องและคำขอถูกส่งผ่านเว็บไซต์ของธนาคาร เซิร์ฟเวอร์จะโอนเงิน 1000 ดอลลาร์ให้กับผู้โจมตี
แนะนำ
- กำหนดการแสดงตนของผู้ใช้ในขณะที่ดำเนินการที่ละเอียดอ่อน
- นำกลไกเช่น CA มาใช้PTCHA การตรวจสอบสิทธิ์ซ้ำ และโทเค็นคำขอเฉพาะ
การกำหนดค่าความปลอดภัยผิดพลาด
Descriptไอออน
จำเป็นต้องกำหนดและปรับใช้การกำหนดค่าความปลอดภัยสำหรับแอปพลิเคชัน เฟรมเวิร์ก เซิร์ฟเวอร์แอปพลิเคชัน เซิร์ฟเวอร์เว็บ เซิร์ฟเวอร์ฐานข้อมูล และแพลตฟอร์ม หากกำหนดค่าเหล่านี้อย่างถูกต้อง ผู้โจมตีสามารถเข้าถึงข้อมูลหรือฟังก์ชันการทำงานที่ละเอียดอ่อนโดยไม่ได้รับอนุญาต
บางครั้งข้อบกพร่องดังกล่าวส่งผลให้ระบบเสียหายโดยสิ้นเชิง การปรับปรุงซอฟต์แวร์ให้ทันสมัยอยู่เสมอก็เป็นการรักษาความปลอดภัยที่ดีเช่นกัน
นัย
- ผู้โจมตีสามารถระบุเทคโนโลยีพื้นฐานและข้อมูลเวอร์ชันของแอปพลิเคชันเซิร์ฟเวอร์ ข้อมูลฐานข้อมูล และรับข้อมูลเกี่ยวกับแอปพลิเคชันเพื่อติดตั้งการโจมตีเพิ่มเติมอีกสองสามรายการโดยใช้ช่องโหว่นี้
วัตถุที่มีความเสี่ยง
- URL
- เขตข้อมูลฟอร์ม
- ช่องป้อนข้อมูล
ตัวอย่าง
- คอนโซลผู้ดูแลระบบแอปพลิเคชันเซิร์ฟเวอร์ได้รับการติดตั้งโดยอัตโนมัติและไม่ถูกลบออก บัญชีเริ่มต้นจะไม่เปลี่ยนแปลง ผู้โจมตีสามารถเข้าสู่ระบบด้วยรหัสผ่านเริ่มต้นและสามารถเข้าถึงโดยไม่ได้รับอนุญาตได้
- รายชื่อไดเรกทอรีไม่ได้ถูกปิดใช้งานบนเซิร์ฟเวอร์ของคุณ ผู้โจมตีค้นพบและสามารถแสดงรายการไดเร็กทอรีเพื่อค้นหาไฟล์ใดก็ได้
แนะนำ
- สถาปัตยกรรมแอปพลิเคชันที่แข็งแกร่งซึ่งให้การแยกและการรักษาความปลอดภัยที่ดีระหว่างส่วนประกอบต่างๆ
- เปลี่ยนชื่อผู้ใช้และรหัสผ่านเริ่มต้น
- ปิดใช้งานรายการไดเรกทอรีและใช้การตรวจสอบการควบคุมการเข้าถึง
ที่เก็บข้อมูลการเข้ารหัสลับที่ไม่ปลอดภัย
Descriptไอออน
พื้นที่จัดเก็บข้อมูลการเข้ารหัสลับที่ไม่ปลอดภัยเป็นช่องโหว่ทั่วไปซึ่งเกิดขึ้นเมื่อข้อมูลที่ละเอียดอ่อนไม่ได้เก็บไว้อย่างปลอดภัย
ข้อมูลประจำตัวผู้ใช้ ข้อมูลโปรไฟล์ รายละเอียดสุขภาพ ข้อมูลบัตรเครดิต ฯลฯ ถือเป็นข้อมูลที่ละเอียดอ่อนบนเว็บไซต์
ข้อมูลนี้จะถูกเก็บไว้ในฐานข้อมูลแอปพลิเคชัน เมื่อข้อมูลนี้ถูกจัดเก็บอย่างไม่เหมาะสมโดยไม่ใช้การเข้ารหัสหรือการแฮช* จะเสี่ยงต่อผู้โจมตี
(*การแฮชคือการแปลงอักขระสตริงให้เป็นสตริงที่สั้นกว่าซึ่งมีความยาวคงที่หรือคีย์ ในการถอดรหัสสตริง ควรใช้อัลกอริธึมที่ใช้ในการสร้างคีย์)
นัย
- ด้วยการใช้ช่องโหว่นี้ ผู้โจมตีสามารถขโมย ปรับเปลี่ยนข้อมูลที่ได้รับการป้องกันอย่างอ่อนแอเพื่อดำเนินการขโมยข้อมูลประจำตัว การฉ้อโกงบัตรเครดิต หรืออาชญากรรมอื่น ๆ
วัตถุที่มีความเสี่ยง
- ฐานข้อมูลแอปพลิเคชัน
ตัวอย่าง
ในแอปพลิเคชันธนาคารแห่งหนึ่ง ฐานข้อมูลรหัสผ่านใช้แฮชที่ไม่ใส่เกลือ * เพื่อจัดเก็บรหัสผ่านของทุกคน ข้อบกพร่องของการแทรก SQL ช่วยให้ผู้โจมตีสามารถเรียกค้นไฟล์รหัสผ่านได้ แฮชที่ไม่ใส่เกลือทั้งหมดสามารถบังคับได้ในเวลาไม่นาน ในขณะที่รหัสผ่านที่ใส่เกลือจะใช้เวลาหลายพันปี
(*แฮช Unsalted – Salt เป็นข้อมูลสุ่มที่ต่อท้ายข้อมูลต้นฉบับ Salt จะถูกต่อท้ายรหัสผ่านก่อนแฮช)
แนะนำ
- ให้แน่ใจว่ามีอัลกอริทึมมาตรฐานที่เหมาะสมและแข็งแกร่ง อย่าสร้างอัลกอริทึมการเข้ารหัสของตัวเอง ใช้เฉพาะอัลกอริทึมสาธารณะที่ได้รับการอนุมัติ เช่น AES, การเข้ารหัสคีย์สาธารณะ RSA และ SHA-256 เป็นต้น
- ตรวจสอบให้แน่ใจว่าการสำรองข้อมูลนอกสถานที่ได้รับการเข้ารหัส แต่คีย์ได้รับการจัดการและสำรองข้อมูลแยกต่างหาก
ความล้มเหลวในการจำกัดการเข้าถึง URL
Descriptไอออน
แอปพลิเคชันเว็บตรวจสอบสิทธิ์การเข้าถึง URL ก่อนที่จะแสดงลิงก์และปุ่มที่ได้รับการป้องกัน แอปพลิเคชันจำเป็นต้องดำเนินการตรวจสอบการควบคุมการเข้าถึงที่คล้ายกันทุกครั้งที่มีการเข้าถึงเพจเหล่านี้
ในแอปพลิเคชันส่วนใหญ่ เพจที่มีสิทธิ์ ตำแหน่ง และทรัพยากรจะไม่ถูกนำเสนอต่อผู้ใช้ที่มีสิทธิ์
ด้วยการคาดเดาอันชาญฉลาด ผู้โจมตีสามารถเข้าถึงหน้าสิทธิพิเศษได้ ผู้โจมตีสามารถเข้าถึงเพจที่ละเอียดอ่อน เรียกใช้ฟังก์ชัน และดูข้อมูลที่เป็นความลับได้
นัย
- การใช้ผู้โจมตีที่มีช่องโหว่นี้สามารถเข้าถึง URL ที่ไม่ได้รับอนุญาตโดยไม่ต้องลงชื่อเข้าใช้แอปพลิเคชันและใช้ประโยชน์จากช่องโหว่ ผู้โจมตีสามารถเข้าถึงเพจที่ละเอียดอ่อน เรียกใช้ฟังก์ชัน และดูข้อมูลที่เป็นความลับได้
วัตถุที่มีช่องโหว่:
- URL ที่
ตัวอย่าง
- ผู้โจมตีสังเกตเห็นว่า URL ระบุบทบาทเป็น “/user/getaccounts” เขาแก้ไขเป็น “/admin/getaccounts”
- ผู้โจมตีสามารถผนวกบทบาทเข้ากับ URL ได้
http://www.vulnerablsite.com สามารถปรับเปลี่ยนได้เป็น http://www.vulnerablesite.com/admin
แนะนำ
- ดำเนินการตรวจสอบการควบคุมการเข้าถึงที่เข้มแข็ง
- นโยบายการรับรองความถูกต้องและการอนุญาตควรเป็นไปตามบทบาท
- จำกัดการเข้าถึง URL ที่ไม่ต้องการ
การป้องกันชั้นการขนส่งไม่เพียงพอ
Descriptไอออน
ทำหน้าที่แลกเปลี่ยนข้อมูลระหว่างผู้ใช้ (ไคลเอนต์) และเซิร์ฟเวอร์ (แอปพลิเคชัน) แอปพลิเคชันมักจะส่งข้อมูลที่ละเอียดอ่อน เช่น รายละเอียดการรับรองความถูกต้อง ข้อมูลบัตรเครดิต และโทเค็นเซสชันผ่านเครือข่าย
การใช้อัลกอริทึมที่อ่อนแอ ใบรับรองที่หมดอายุหรือไม่ถูกต้อง หรือการไม่ใช้ SSL อาจทำให้การสื่อสารถูกเปิดเผยต่อผู้ใช้ที่ไม่น่าเชื่อถือ ซึ่งอาจส่งผลต่อแอปพลิเคชันเว็บและ/หรือขโมยข้อมูลที่ละเอียดอ่อนได้
นัย
- การใช้ช่องโหว่ด้านความปลอดภัยบนเว็บนี้ ผู้โจมตีสามารถดมข้อมูลประจำตัวของผู้ใช้ที่ถูกต้องและเข้าถึงแอปพลิเคชันได้
- สามารถขโมยข้อมูลบัตรเครดิตได้
วัตถุที่มีความเสี่ยง
- ข้อมูลที่ส่งผ่านเครือข่าย
แนะนำ
- เปิดใช้งาน HTTP ที่ปลอดภัยและบังคับใช้การถ่ายโอนข้อมูลรับรองผ่าน HTTPS เท่านั้น
- ตรวจสอบให้แน่ใจว่าใบรับรองของคุณถูกต้องและไม่หมดอายุ
ตัวอย่าง:
1. แอปพลิเคชันที่ไม่ได้ใช้ SSL ผู้โจมตีจะตรวจสอบการรับส่งข้อมูลเครือข่ายและสังเกตคุกกี้เซสชันของเหยื่อที่ได้รับการตรวจสอบสิทธิ์ ผู้โจมตีสามารถขโมยคุกกี้นั้นและทำการโจมตีแบบ Man-in-the-Middle
การเปลี่ยนเส้นทางและการส่งต่อที่ไม่ถูกต้อง
Descriptไอออน
เว็บแอปพลิเคชันใช้วิธีการไม่กี่วิธีในการเปลี่ยนเส้นทางและส่งต่อผู้ใช้ไปยังหน้าอื่นตามวัตถุประสงค์ที่ตั้งใจไว้
หากไม่มีการตรวจสอบที่เหมาะสมในขณะที่เปลี่ยนเส้นทางไปยังหน้าอื่น ผู้โจมตีสามารถใช้สิ่งนี้และสามารถเปลี่ยนเส้นทางเหยื่อไปยังไซต์ฟิชชิ่งหรือมัลแวร์ หรือใช้การส่งต่อเพื่อเข้าถึงหน้าที่ไม่ได้รับอนุญาต
นัย
- ผู้โจมตีสามารถส่ง URL ไปยังผู้ใช้ที่มี URL ของแท้ต่อท้ายด้วย URL ที่เป็นอันตรายที่เข้ารหัส ผู้ใช้เพียงเห็นส่วนที่แท้จริงของผู้โจมตีส่ง URL ก็สามารถเรียกดูและอาจตกเป็นเหยื่อได้
ตัวอย่าง
1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
แก้ไขเป็น
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
แนะนำ
- เพียงหลีกเลี่ยงการใช้การเปลี่ยนเส้นทางและการส่งต่อในแอปพลิเคชัน หากใช้ ไม่ต้องใช้พารามิเตอร์ผู้ใช้ในการคำนวณปลายทาง
- หากไม่สามารถหลีกเลี่ยงพารามิเตอร์ปลายทางได้ ตรวจสอบให้แน่ใจว่าค่าที่ให้มานั้นถูกต้อง และได้รับอนุญาตสำหรับผู้ใช้
