บันทึกการเปลี่ยนแปลง: The OWASP Top 10 Project

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

ในปี 2544 องค์กรใหม่เข้ามาบนเวที เป้าหมายคือการต่อสู้กับปัญหาด้านความปลอดภัยที่ส่งผลต่อเว็บไซต์และแอปพลิเคชัน ได้รับการตั้งชื่ออย่างเหมาะสม Open Web Application Security Project (OWASP) ปัจจุบันนี้เผยแพร่ทรัพยากร จัดการประชุม และเสนอมาตรฐานด้านความปลอดภัยของเว็บและแอปพลิเคชัน มาตรฐานโดยพฤตินัยสำหรับการรักษาความปลอดภัยเว็บแอปพลิเคชันคือ OWASP Top Ten Project มันแสดงรายการภัยคุกคามความปลอดภัยที่แพร่หลายมากที่สุดสิบประการ ปัจจัยที่มีอิทธิพลในการตัดสินใจเลือกสิ่งที่ได้รับคือข้อมูลจำนวนมากและข้อเสนอแนะของชุมชน ปลายปี 2560 มีการปรับปรุงโครงการ ปัญหาใหม่หลายอย่างที่สำคัญสำหรับเว็บแอปพลิเคชันสมัยใหม่จำนวนมากได้รับมาแทนที่ ในขณะที่บางปัญหาก็หลุดออกมาจากรายการ

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

ปัญหาที่ถูกลบออกจาก OWASP Top 10 List

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

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

การปลอมแปลงคำขอข้ามไซต์

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

ไม่ว่า CSRF จะออกจากรายการ ก็ยังดีที่จะรีเฟรชหน่วยความจำของเรา ขอให้แน่ใจว่ามันจะไม่กลับมาแข็งแกร่งกว่าที่เคย

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

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

ตัวอย่างที่โด่งดังที่สุดตัวอย่างหนึ่งคือการหลอกให้ผู้ใช้โอนเงินจากบัญชีของตนไปยังบัญชีที่ผู้โจมตีควบคุม ผู้ใช้ลงชื่อเข้าใช้ระบบ e-banking เพื่อตรวจสอบยอดเงินในบัญชี หลังจากนั้นพวกเขาไปที่ฟอรัมออนไลน์เพื่อตรวจสอบความคิดเห็นของโทรศัพท์มือถือเครื่องใหม่ ผู้โจมตีกำลังตกปลาด้วยระเบิด โพสต์บทวิจารณ์พร้อมรูปภาพที่มีไฮเปอร์ลิงก์ของรูปภาพที่ดูเหมือนพัง แทนที่จะใช้ไฮเปอร์ลิงก์จริง ผู้โจมตีใช้ไฮเปอร์ลิงก์ที่ระบบ e-banking ภายในใช้เพื่อโอนเงินจากบัญชี A ไปยังบัญชี B: https://payments.dummybank.com?receiver=attacker&amount=100 ระบบธนาคารทำให้ผู้ใช้ที่ตรวจสอบสิทธิ์เป็นผู้ส่งและค่าจากพารามิเตอร์ "ผู้รับ" เป็นผู้รับเงิน แน่นอน ผู้โจมตีระบุบัญชีต่างประเทศของตนเป็นผู้รับ

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

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

เมื่อออกแบบระบบของคุณ ให้คำนึงถึงสิ่งต่อไปนี้:

• อย่า ใช้คำขอ HTTP GET สำหรับการดำเนินการห่อหุ้มซึ่งแก้ไขทรัพยากร คุณควรใช้คำขอเหล่านี้เพื่อดึงข้อมูลเท่านั้น โปรดจำไว้ว่า กฎง่ายๆ คือการทำให้คำขอ GET มีประสิทธิภาพ
• Do เมื่อถ่ายโอนข้อมูลภายในโดยใช้คำขอ HTTP POST มักจะส่งข้อมูลในรูปแบบ JSON, XML หรือรูปแบบอื่นนอกเหนือจากการเข้ารหัสพารามิเตอร์เป็นสตริงการสืบค้น การใช้รูปแบบข้อมูลที่ไม่สำคัญช่วยลดความเสี่ยงของบุคคลที่สร้างแบบฟอร์ม HTML ปลอมซึ่งจะส่งข้อมูลไปยังบริการของคุณ
• อย่า ลืมสร้างและรวมโทเค็นที่ไม่ซ้ำใครและคาดเดาไม่ได้ลงในแบบฟอร์ม HTML ของคุณ โทเค็นเหล่านี้ควรไม่ซ้ำกันสำหรับแต่ละคำขอ การตรวจสอบการมีอยู่และความถูกต้องของโทเค็นดังกล่าวจะช่วยลดความเสี่ยงของภัยคุกคามที่เกิดขึ้น ในการค้นหาโทเค็นและใช้ในคำขอปลอม ผู้โจมตีจะต้องเข้าถึงระบบของคุณและรับโทเค็นโดยตรงจากที่นั่น เนื่องจากโทเค็นเป็นแบบใช้ครั้งเดียวเท่านั้น จึงไม่สามารถใช้ซ้ำในโค้ดที่เป็นอันตรายได้

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

โปรดทราบว่า CSRF ไม่ได้หายไป มันไม่ธรรมดาอย่างที่เคยเป็น

การเปลี่ยนเส้นทางและส่งต่อที่ไม่ผ่านการตรวจสอบ

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

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

ตัวอย่างเช่น เว็บแอปพลิเคชันมักใช้การลงชื่อเข้าใช้ด้วยการสนับสนุนการเปลี่ยนเส้นทางไปยังหน้าที่เข้าชมล่าสุด เพื่อให้ทำได้อย่างง่ายดาย แอตทริบิวต์ action ของแบบฟอร์ม HTML อาจมีลักษณะดังนี้ http://myapp.example.com/signin?url=http://myapp.example.com/puppies คุณเป็นแฟนพันธุ์แท้ของลูกสุนัข ดังนั้นจึงควรติดตั้งส่วนขยายเบราว์เซอร์ซึ่งแทนที่ favicons ของเว็บไซต์ด้วยภาพขนาดย่อของลูกสุนัขตัวโปรดของคุณ น่าเสียดายที่มันเป็นโลกของสุนัขกินสุนัข ผู้เขียนส่วนขยายเบราว์เซอร์ตัดสินใจที่จะจ่ายเงินให้กับความรักที่ไม่มีเงื่อนไขของคุณและแนะนำ "คุณสมบัติ" เพิ่มเติม ทุกครั้งที่คุณเยี่ยมชมไซต์แฟนพันธุ์แท้ของลูกสุนัข พารามิเตอร์ "url" จะแทนที่พารามิเตอร์ "url" ในแอตทริบิวต์การกระทำของแบบฟอร์มด้วยลิงก์ไปยังไซต์ของตนเอง เนื่องจากเว็บไซต์มีลักษณะเหมือนกันทุกประการ เมื่อคุณให้รายละเอียดบัตรเครดิตเพื่อซื้อไพ่ลูกสุนัข แท้จริงแล้วคุณเป็นผู้จัดหาเงินให้กับผู้โจมตีที่ประสงค์ร้าย ไม่ใช่งานอดิเรกของคุณ

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

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

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

รวมประเด็น

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

เสียการควบคุมการเข้าถึง

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

การอ้างอิงวัตถุโดยตรง

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

แอปพลิเคชันที่กำหนด URL ของแบบฟอร์มการลบโปรไฟล์ http://myapp.example.com/users/15/delete ทำให้ชัดเจนว่ามีผู้ใช้อื่นอย่างน้อย 14 รายในแอปพลิเคชัน การค้นหาวิธีเข้าถึงรูปแบบการลบของผู้ใช้รายอื่นไม่ใช่วิทยาศาสตร์จรวดในกรณีนี้

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

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

ไม่มีการควบคุมการเข้าถึงระดับฟังก์ชัน

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

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

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

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

ปัญหาใหม่ในรายการ OWASP 10 อันดับแรก

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

XML หน่วยงานภายนอก

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

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

ในระหว่างการแยกวิเคราะห์ การอ้างอิง &bar; ถูกแทนที่ด้วยเนื้อหาจากเอนทิตีที่กำหนดไว้ จึงให้ผล <foo>baz</foo>

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

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

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

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

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

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

การดีซีเรียลไลซ์เซชั่นที่ไม่ปลอดภัย

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

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

หากผู้ใช้ที่อยากรู้อยากเห็นพบคุกกี้ในเครื่องของพวกเขา พวกเขาอาจเห็นสิ่งนี้:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

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

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

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

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

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

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

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

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

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

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

การบันทึกและการตรวจสอบไม่เพียงพอ

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

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

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

เพื่อป้องกันตนเองจากการโจมตีดังกล่าวให้ดีที่สุด ให้ทำตามขั้นตอนต่อไปนี้:

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

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

ขั้นตอนถัดไป

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

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

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

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

หากคุณเพิ่งเริ่มสำรวจความปลอดภัยของเว็บแอปพลิเคชันและต้องการ Sandbox Playground ที่ปลอดภัย ให้ใช้แอปพลิเคชันเว็บจาก OWASP—WebGoat เป็นการใช้งานเว็บแอปพลิเคชันที่ไม่ปลอดภัยโดยเจตนา แอปพลิเคชันจะแนะนำคุณตลอดบทเรียน โดยแต่ละบทเรียนมุ่งเน้นที่ภัยคุกคามด้านความปลอดภัยเพียงอย่างเดียว

ในระหว่างการพัฒนาแอปพลิเคชัน ตรวจสอบให้แน่ใจว่าคุณ:

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

บทสรุป

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

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