การรักษาความปลอดภัยแบบ OWASP

การรักษาความปลอดภัยระบบเว็บแอพพลิเคชันตามวิธีการ OWASP

ความเป็นมา

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

แนวทาง OWASP

จุดอ่อนทางด้านการรักษาความปลอดภัยข้อมูล 10 อันดับแรก ที่ OWASP แนะนำไว้มีดังต่อไปนี้

1.    Cross Site Scripting

2.    Injection Flaws

3.    Malicious File Execution

4.    Insecure Direct Object Reference

5.    Cross Site Request Forgery (CSRF)

6.    Information Leakage and Improper Error Handling

7.    Broken Authentication and Session Management

8.    Insecure Cryptographic Storage

9.    Insecure Communication

10. Failure to Restrict URL Access

OWASP และแนวทางปฏิบัติเพื่อป้องกันการจู่โจมเว็บแอพพลิเคชัน

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

1. Cross Site Scripting

1.1 ความเป็นมา

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

1.2 สาเหตุทางด้านเทคนิค

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

รูปภาพ 1 การจู่โจมแบบ Cross-Site Scripting ด้วยวิธี JavaScript Reflection

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

1.3 แนวทางป้องกัน

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

1.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

มีความเป็นไปได้น้อยที่จะเกิดขึ้นกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนาและส่งมอบเนื่องจาก

มีการใช้เฟรมเวิร์ค (Framework) Jakarta Struts พัฒนาระบบเว็บแอพพลิเคชัน ซึ่งจะต้องแสดงผลด้วยวิธีการใช้ Custom Tag ของ Struts และจะถูกใส่ HTML Entity เข้าไปเสมอ ทำให้ข้อมูลที่ส่งมาเป็นสคริปต์โปรแกรมไม่สามารถรันขึ้นมาได้ เพราะจะถูกมองว่าเป็นข้อมูลตัวอักษรสแตติคทั่วไป

มีการใช้เฟรมเวิร์ค Common Validator (http://commons.apache.org/validator/) ซึ่งข้อมูลอินพุตจะต้องผ่านการตรวจสอบตามกฏที่ตั้งไว้ทั้งที่เป็น JavaScript ที่ฝั่งไคลเอ็นต์ และโปรแกรมตรวจสอบที่เป็น Java ที่ฝั่งเซิร์ฟเวอร์ ทำให้ยากต่อการผ่านด่านการตรวจสอบเข้าสู่โปรแกรมได้

2. Injection Flaws

2.1 ความเป็นมา

เป็นวิธีการที่มักจะเกิดกับการใช้คำสั่ง SQL เพื่อให้โปรแกรมดึงข้อมูลจากระบบฐานข้อมูลและนำมาแสดงผลในหน้าเว็บ แต่อาจจะเกิดขึ้นกับสคริปต์แบบอื่นๆได้ไม่เฉพาะกับ SQL เช่น LDAP, XPath, XSLT, HTML, XML ซึ่งเป็นสคริปต์ที่ใช้รันเพื่อค้นหาและดึงข้อมูลจากระบบอะไรบ้างอย่าง

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

2.2 สาเหตุทางด้านเทคนิค

สิ่งที่สร้างความฉงนให้กับนักพัฒนาระบบก็คือ แล้วแฮคเกอร์สามารถต่อเติมสตริงที่เป็นคำสั่ง SQL ได้อย่างไร ในเมื่อไม่ได้เป็นผู้เขียนโปรแกรมโดยตรง คำตอบก็คือแฮคเกอร์อาศัยความรู้พื้นฐานเรื่องการต่อสตริง (String Concatenation) เนื่องจากปกติโปรแกรมมักจะรับอินพุตมาและนำอินพุตนั้นไปต่อเข้ากับคำสั่ง SQL ที่เตรียมไว้เป็นแม่แบบ

รูปภาพ 2 การจู่โจมแบบ SQL Injection

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

2.3 แนวทางป้องกัน

แนวทางปฏิบิติที่เหมาะสมคือโปรแกรมควรใช้คำสั่ง SQL ที่เป็นแบบส่งผ่านพารามิเตอร์ (Parameterized Query) เช่นถ้าเป็นภาษาจาวาก็คือ PreparedStatement เนื่องจากมีการตรวจสอบอยู่แล้วว่าพารามิเตอร์ที่ส่งเข้ามาต้องเป็นชนิดข้อมูลที่ตรงกับที่ระบุเท่านั้น

และหากมีการสืบค้นด้วยสตริง สตริงพารามิเตอร์ที่ส่งให้กับ SQL จะถูกแปลง (Escape) ให้กลายเป็นสตริงธรรมดาใน SQL ทำให้สตริงที่ส่งเข้ามาไม่สามารถทำตัวเป็นคำสั่ง SQL ซ้อนอยู่ใน SQL ตัวแม่ได้ โดยเฉพาะอย่างยิ่ง หากสตริงอะไรก็ตามที่ไปตรงเข้ากับคำสั่ง SQL ก็จะถูกเปลี่ยนให้อยู่ในรูปแบบสตริงธรรมดา เพราะถือว่าเป็นเป็นเนื้อหา (Content) เท่านั้น โดยไม่ถือว่าเป็นสคริปต์โปรแกรม ตัวอย่างเช่น ถ้าสตริงที่ส่งมาปะปนด้วยคำว่า likes ‘admin%’ จะถูก Escape กลายเป็น “likes \’admin%\’” ซึ่งไม่มีผลใดๆทั้งสิ้นกับ DBMS เพราะเหลือสภาพเป็นเพียงสตริงธรรมดาเท่านั้น

2.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

บริษัทใช้เฟรมเวิร์ค ORM (Object Relational Mapping) ในการสืบค้นฐานข้อมูล โดยเฉพาะอย่างยิ่งมีการใช้งาน PreparedStatement ของจาวา ดังนั้นจะไม่มีคำสั่ง SQL ใดที่ไปใช้งาน Statement โดยตรงและไม่มีการต่อสตริง SQL ด้วยตนเอง ทำให้มั่นใจได้ว่าบริเวณเงื่อนไขของคำสั่ง SQL จะต้องผ่านกระบวนการ Escape ของ PreparedStatement ของจาวาก่อนอย่างแน่นอน ดังนั้นความเป็นไปได้ที่จะถูกจู่โจมด้วยวิธี SQL Injection จึงเป็นไปได้น้อยมาก

3. Malicious File Execution

3.1 ความเป็นมา

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

แม้ว่าในเอกสารของ OWASP จะมุ่งประเด็นไปที่คำสั่ง include $_REQUEST[‘filename’] ของ PHP แต่วิธีการนี้ไม่จำเป็นต้องเกิดกับ PHP เสมอไป เช่นในระบบที่อนุญาตให้ผู้ใช้ใส่เนื้อหา XML เข้าไปได้ แฮคเกอร์สามารถกำหนดส่วน DTD หรือ xsi:schemaLocation ชี้ไปที่ไฟล์ DTD หรือไฟล์ XSD ที่อยู่ในโฮสต์ของตัวเองและให้รันคำสั่งที่แทรกไว้ในไฟล์ DTD หรือ XSD ของตนเองได้ เช่นกัน

3.2 สาเหตุทางด้านเทคนิค

เนื่องจากมีการรับชื่อไฟล์มาจากผู้ใช้ และนำชื่อไฟล์นั้นมาใช้กับคำสั่งรวมไฟล์ เช่นคำสั่ง include ของ PHP หรือคำสั่ง <c:import> ของ JSTL ใน Java

รูปภาพ 3 การจู่โจมแบบ Malicious File Execution

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

3.3 แนวทางป้องกัน

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

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

วิธีการป้องกันขั้นพื้นฐานอีกวิธีหนึ่งคือหลีกเลี่ยงการใช้ HTTP GET และมาใช้ HTTP POST พร้อมกับ SSL แทน ซึ่งวิธีการนี้จะทำให้แฮคเกอร์ไม่สามารถสืบทราบพารามิเตอร์ที่จะรับเข้าหรือส่งออกได้ ทำให้ยากต่อการสอดแทรกชื่อไฟล์เข้าไปในสคริปต์

3.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

เนื่องจากแอพพลิเคชันที่บริษัทพัฒนาส่วนใหญ่ใช้ Jakarta Struts เป็นเครื่องมือในการพัฒนา จึงมักจะส่งข้อมูลด้วยวิธี HTTP POST เป็นหลัก อีกทั้งไม่มีการสร้างหน้าเว็บแบบรวมไฟล์จากภายนอก วิธีการประกอบหน้าเว็บมักจะใช้ <jsp:include> หรือ Jakarta Tile ซึ่งมีกฏป้องกันพื้นฐานคือไม่รับไฟล์จากภายนอกระบบเว็บแอพพลิเคชันอยู่แล้ว ดังนั้นจึงยากที่แฮคเกอร์จะสอดแทรกไฟล์ของตนเองเข้ามาได้

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

4. Insecure Direct Object Reference

4.1 ความเป็นมา

เนื่องจากมีการเปิดให้ผู้ใช้เห็นโครงสร้างการอ้างอิงข้อมูลต่างๆที่อยู่ในระบบทำให้ แฮคเกอร์สามารถเปลี่ยนการอ้างอิงไปที่ข้อมูลอื่นๆที่อยู่ในระบบได้โดยใช้รูปแบบที่พบบนหน้าเว็บ ตัวอย่างเช่น หากแฮคเกอร์เห็นวิธีการการเบราซ์ที่ URL เป็น http://www.myweb.com/User.jsp?id=10 แฮคเกอร์อาจจะทดลองเปลี่ยนเลข 10 ให้กลายเป็นเลขอื่น เพื่อดึงข้อมูลของผู้ใช้คนอื่นในระบบออกมาดูได้เช่นกัน เช่น แฮคเกอร์อาจจะพิมพ์ URL เข้าไปตรงๆใหม่เป็น http://www.myweb.com/User.jsp?id=1 โดยคาดหมายว่า 1 เป็นรหัสประจำตัวผู้ดูแลระบบ เช่นนี้เป็นต้น

4.2 สาเหตุทางด้านเทคนิค

เป็นเพราะมีการเปิดเผยวิธีการสืบค้นข้อมูลให้ผู้ใช้เห็นผ่านทาง URL ของ HTTP GET หรือผ่านทาง Hidden Field ที่อยู่ในโค้ด HTML ของหน้าเว็บ ทำให้แฮคเกอร์สามารถคาดเดาโครงสร้างการเก็บข้อมูลภายในระบบ และนำรูปแบบ URL หรือ Hidden Field ไปใช้กับรหัสอื่นๆและดึงข้อมูลอื่นในระบบออกมาดูได้

รูปภาพ 4 การจู่โจมแบบ Insecure Direct Object Reference

4.3 แนวทางป้องกัน

การจู่โจมแบบนี้สามารถป้องกันได้โดยแปลงรหัสที่ใช้อ้างอิงข้อมูลไปเป็นรูปแบบที่ยากต่อการคาดเดาเช่น http://www.myweb.com/User.jsp?id=293AF983943874827BF ซึ่งเลขที่อ้างอิงนี้จะไปจับคู่กับรหัสจริงในระบบอีกทีหนึ่ง

นอกจากวิธีการแปลงรหัสอ้างอิงแล้ว อีกวิธีหนึ่งก็คือใช้ HTTP POST คู่กับ SSL ซึ่งจะทำให้แฮคเกอร์ไม่สามารถตรวจสอบรูปแบบของรหัสอ้างอิงข้อมูลได้เพราะไม่เปิดให้เห็นบน URL และไม่สามารถดูโค้ด HTML ได้เนื่องจากเข้ารหัส SSL ไว้

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

4.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

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

5. Cross Site Request Forgery (CSRF)

5.1 ความเป็นมา

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

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

ตัวอย่างที่เห็นได้ค่อนข้างบ่อย เช่นการใช้งาน Report Server เพื่อขอดูรายงาน ทางฝั่งรีพอร์ตเซิร์ฟเวอร์อนุญาตให้โปรแกรมขอดูรายงานได้ผ่านทาง URL แบบ HTTP GET เช่น http://report.myweb.abc/report?name=AnnualReport&user=admin&password=abc ซึ่งหากแฮคเกอร์สำรวจพบ URL ลักษณะนี้แฮคเกอร์ก็สามารถเลียนแบบ (นี่ยังไม่นับข้อมูล user และ password ที่มองเห็นได้จากการ View Source HTML ที่หน้าเว็บ) URL แล้วยิงรีเควสต์มาจากเครื่องของแฮคเกอร์เพื่อดึงข้อมูลที่ต้องการได้

5.2 สาเหตุทางด้านเทคนิค

เนื่องจากมีการเปิดให้ใช้ Automatic Login หรือจดจำผู้ใช้ค้างไว้ที่ฝั่งไคลเอ็นต์ด้วย Cookies รวมทั้งเปิด URL ให้ดึงข้อมูลจากระบบได้ทั้งแบบ GET และแบบ POST โดยไม่จำเป็นต้องผ่านการตรวจสอบผู้ใช้หรือผ่านระบบควบคุมสิทธิ

5.3 แนวทางป้องกัน

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

5.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

มีความเป็นไปได้น้อยที่จะเกิดขึ้นกับแอพพลิเคชันที่บริษัทพัฒนาและส่งมอบเนื่องจากไม่พบว่ามีการใช้ Automatic Login หรือการจดจำผู้ใช้ไว้ใน Cookies ยกเว้นแต่มีการใช้ Session ของ Java เอง ซึ่ง Session จะไม่ฝังจำค้างไว้นานเกินระยะเวลาที่เปิดเบราเซอร์อยู่ หากปิดเบราเซอร์ไปเมื่อไร Session จะหมดและการเข้าใช้ครั้งต่อไปต้องผ่านการตรวจสอบผู้ใช้ก่อนเสมอ

แม้ว่าในแอพพลิเคชันของบริษัทจะไม่ได้ใช้ UserToken แต่การใช้ Session ของ Java ได้ผลใกล้เคียงกับ UserToken นอกจากนี้ยังใช้ร่วมกับ Servlet Filter ที่มีการป้องกันการเข้าถึงบริเวณสำคัญในเว็บแอพพลิเคชันด้วยรูปแบบ URL เป็น /* ซึ่งจะทำให้รีเควสต์ทุกรีเควสต์ที่เข้ามาต้องผ่านการตรวจสอบผู้ใช้ก่อนเสมอ

6. Information Leakage and Improper Error Handling

6.1 ความเป็นมา

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

6.2 สาเหตุทางด้านเทคนิค

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

6.3 แนวทางป้องกัน

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

6.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

7. Broken Authentication and Session Management

7.1 ความเป็นมา

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

7.2 สาเหตุทางด้านเทคนิค

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

7.3 แนวทางป้องกัน

แนวทางปฏิบัติที่สำคัญเพื่อป้องกันการจู่โจมมีดังต่อไปนี้

·      ใช้กรรมวิธีการรักษาเซสชันที่มีมากับระบบเว็บเซิร์ฟเวอร์ หลีกเลี่ยงการสร้างขึ้นมาใหม่เอง

·      อย่ายอมรับเซสชันที่จู่ๆก็ส่งเข้ามาใหม่ โดยไม่ได้ถูกสร้างขึ้นในระบบ แม้ว่ารหัสเซสชันจะถูกต้องก็ตาม

·      ลดการใช้ Cookies หรือโปรแกรมที่ใช้จัดการควบคุมเซสชันซึ่งเขียนขึ้นเอง

·      ใช้วิธีการเดียวในการตรวจสอบความเป็นผู้ใช้

·      ไม่อนุญาตให้เข้าสู่ระบบด้วยวิธีการล็อกอินมาจากหน้าเว็บที่ไม่เข้ารหัส (หน้าล็อกอินจำเป็นต้อง SSL)

·      ให้ทุกหน้ามีลิงค์สำหรับ Logout ออกจากระบบ เพื่อให้ผู้ใช้ออกจากระบบได้ง่าย การออกจากระบบจะช่วยเคลียร์ค่าทุกอย่าง ทำให้ยากต่อการกลับเข้ามาใหม่ของแฮคเกอร์

·      ตั้งกำหนดเวลาหมดอายุ (Timeout) เพื่อทำให้เซสชันของผู้ใช้หมดอายุและต้องล็อกอินใหม่

·      ตรวจสอบรหัสผ่านเก่าก่อน ในขณะที่ผู้ใช้ขอเปลี่ยนรหัสผ่านใหม่

7.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

8. Insecure Cryptographic Storage

8.1 ความเป็นมา

มีการเก็บข้อมูลสำคัญไว้ในรูปแบบเปิดเผย ไม่เข้ารหัส หรือเข้ารหัสไว้ด้วยกรรมวิธีที่ไม่มีความปลอดภัยเพียงพอ เช่น ใช้อัลกอริธึมที่ล้าสมัยในการเข้ารหัส อย่าง MD5, SHA-1, RC3, RC4 เป็นต้น

8.2 สาเหตุทางด้านเทคนิค

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

8.3 แนวทางป้องกัน

แนวทางปฏิบัติที่ OWASP ได้นำเสนอไว้มีดังต่อไปนี้

·      อย่าพยายามสร้างวิธีการเข้ารหัสด้วยตนเอง แต่ให้ใช้วิธีการเข้ารหัสที่เป็นมาตรฐานสากลเช่น AES, RSA เป็นต้น

·      อย่าใช้กรรมวิธีที่มีผู้พิสูจน์แล้วว่าง่ายต่อการจู่โจมเช่น MD5 หรือ SHA-1 แต่ไปใช้วิธีการอื่นที่รัดกุมกว่าเช่น SHA-256 เป็นต้น

·      เก็บรักษา Private Key อย่างระมัดระวังและไม่ส่งต่อ Private Key ผ่านทางการสื่อสารที่ไม่ปลอดภัยเพียงพอ (เช่นก็อปปีผ่าน Thumb Drive เป็นต้น)

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

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

8.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

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

9. Insecure Communication

9.1 ความเป็นมา

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

9.2 สาเหตุทางด้านเทคนิค

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

9.3 แนวทางป้องกัน

ติดตั้งระบบ SSL/TLS เพื่อใช้ข้อมูลรับส่งผ่านทางการเข้ารหัสของ SSL โดยมีทางเลือก 2 แบบคือ

·      SSL แบบไม่ใช้ Client Authentication Certificate เป็นแบบที่ทางฝั่งผู้ใช้ที่ไคลเอ็นต์ไม่จำเป็นต้องส่ง X509 Certificate กลับมาให้ฝั่งเซิร์ฟเวอร์ตรวจสอบ แบบนี้ผู้ใช้จะง่ายต่อการใช้งาน แต่มีข้อเสียคือความปลอดภัยยังอยู่ในระดับต่ำ

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

9.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

10. Failure to Restrict URL Access

10.1 ความเป็นมา

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

10.2 สาเหตุทางด้านเทคนิค

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

10.3 แนวทางป้องกัน

แนวทางปฏิบัติที่ OWASP ได้นำเสนอไว้มีดังต่อไปนี้

·      แน่ใจว่ามีระบบตรวจสอบผู้ใช้และควบคุมสิทธิการใช้งานในทุกๆฟังก์ชันของแอพพลิเคชัน

·      แน่ใจว่าทุก URL ทุกรูปแบบต้องผ่านการตรวจสอบโดยระบบควบคุมการเข้าถึงเสมอ

·      ทดสอบการเจาะระบบ โดยพยายามเจาะระบบตนเอง

·      ให้ความสำคัญและระมัดระวังการใช้ไฟล์และไลบรารีจากภายนอก

·      อย่าคิดว่าผู้ใช้จะไม่รู้ว่ามี URL พิเศษสำหรับเข้าถึงพื้นที่เฉพาะอยู่ (เพราะเค้าสามารถคาดเดาและทดลองได้)

·      ตั้งกฏไม่ให้ผู้ใช้เบราซ์ไฟล์ชนิดอื่นๆ ยกเว้นชนิดที่เว็บแอพพลิเคชันรับผิดชอบดูแลอยู่

·      พยายามอัพเดตโปรแกรมป้องกันไวรัสอยู่เสมอ

10.4 ความเป็นไปได้ที่จะเกิดกับแอพพลิเคชันที่บริษัทเป็นผู้พัฒนา

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

บทสรุป

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

·     Java Keystore and SSL                    Java Keystore สามารถใช้สร้าง Certificate เพื่อใช้กับ SSL ได้โดยสะดวกพร้อมทั้งเก็บรักษาคีย์ได้อย่างปลอดภัย

·     Servlet Filter                                      สามารถป้องกันการเข้าถึง URL ได้ตลอดทั้งเว็บแอพพลิเคชัน

·     JavaServer Faces                             ใช้แต่วิธีการ HTTP POST ในการเข้าถึงฟังก์ชันในระบบทำให้จุดอ่อนเกี่ยวกับ Cross Site Scripting และ Injection หายไป นอกจากนี้ข้อมูลที่แสดงที่หน้าเว็บด้วย h:outputText จะต้องถูก Escape ให้กลายเป็นข้อมูลตัวอักษรธรรมดาเสมอ

·     Common Validator                            ป้องกันข้อมูลผิดเข้าสู่แอพพลิเคชันได้ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์

·     Java Cryptography Extension          เข้ารหัสข้อมูลได้ทั้งแบบ SHA-256 และ RSA ทำให้เข้ารหัสข้อมูลสำคัญไว้ได้อย่างปลอดภัย

·     Hibernate and JPA                           ใช้วิธีการรันคำสั่ง SQL ผ่านทาง PreparedStatement ดังนั้นจึงปลอดภัยจาก SQL Injection

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