Clear
Lead Graphic Papers

Web Application Security รายสะดวก #2

ผู้เขียน: ไพชยนต์ วิมุกตะนันทน์
วันที่เผยแพร่: 22 มิถุนายน 2555
ปรับปรุงล่าสุดวันที่: 22 มิถุนายน 2555

Share on Facebook Share on Twitter Share on Google+

คราวที่แล้วในบทความ Web Application Security รายสะดวก #1 ผู้เขียนได้กล่าวถึงการป้องกัน Web application ด้วยแนวคิด Defense-in-depth ซึ่งแนวคิดอันนี้ถือว่าเป็นแนวคิดที่นำไปใช้ได้กับการรักษาความมั่นคงปลอดภัยทุกชนิด สำหรับท่านผู้อ่านที่ยังไม่คุ้นเคยกับแนวคิดนี้ ก็ขออธิบายให้เข้าใจง่ายๆ ว่า เปรียบเทียบกับการป้องกันโจรเข้าบ้าน คงไม่มีใครติดกล้องวงจรปิดโดยไม่มีกุญแจประตู หรือเลี้ยงสุนัขโดยไม่มีรั้วบ้าน แต่มาตรการต่างๆ เหล่านี้ ต้องนำมาประกอบกันเพื่อเพิ่มความมั่นคงปลอดภัย การนำมาตรการป้องกันหลายๆ แบบมาใช้ร่วมกันแบบนี้ นอกจากจะช่วยให้ผู้ที่ไม่ประสงค์ดีไม่สามารถทำการได้สะดวกแล้ว ยังอาจทำให้ผู้ที่วางแผนจะบุกรุกหรือโจมตีเปลี่ยนใจไปโจมตีเป้าหมายที่มีการป้องกันน้อยกว่าแทน เนื่องจากมีความเสี่ยงน้อยกว่าก็เป็นได้

ถ้าพูดถึงการป้องกัน Web application ในแบบ Defense-in-depth แล้ว ตัวอย่างที่ผู้เขียนจะกล่าวถึงในครั้งนี้ก็คือการทำ chroot (Change root) หรือที่บางท่านที่คุ้นเคยกับระบบ FreeBSD อาจจะรู้จักในชื่อว่า Jail นั่นเอง วิธีการนี้ไม่ได้ใช้ป้องกันตัว Web application โดยตรง นั่นคือ หาก Web application มีช่องโหว่ การทำ chroot หรือ Jail ก็ไม่ได้ทำให้ช่องโหว่นั้นหมดไป แต่ทำให้ผู้ไม่ประสงค์ดีสามารถใช้ประโยชน์ (Exploit) จากช่องโหว่นั้นได้ยากขึ้น หรือใช้ได้อย่างไม่เต็มที่ ทำให้ลดโอกาสหรือลดความรุนแรงของความเสียหายจากการถูกโจมตีได้ระดับหนึ่ง

รูปแบบของการทำ chroot หรือ Jail ใน Web application นั้น มักจะทำกันที่ระดับของ Web server มากกว่าที่จะทำกันที่ Web application เป็นรายตัว โดยหลักการของ chroot คือการแยก Application ใดๆ (ในที่นี้คือ Web server) ให้ทำงานอยู่ในพื้นที่ Disk เฉพาะตัว ไม่ให้สามารถเข้าถึงพื้นที่ Disk ที่ใช้งานในระบบงานอื่นๆ ได้ ดังนั้นหาก Application ตัวนั้นเกิดความผิดพลาดในการทำงาน หรือถูกผู้ไม่ประสงค์ดีเข้าควบคุม Application นั้นก็จะไม่สามารถเข้าถึงไฟล์ระบบอื่นๆ หรือไฟล์ข้อมูลของระบบงานอื่นๆ ที่อยู่ในเครื่องเดียวกันได้ หลักการนี้เป็นหลักการเดียวกับหลักการ Sandbox ที่มีใช้ใน Web browser สมัยใหม่บางตัว และมีใช้อยู่ในระบบ Android และ iOS ที่ใช้งานบนโทรศัพท์มือถือด้วย รูปแบบการทำงานของแต่ละระบบ ไม่ว่าจะเรียกว่า chroot, Jail หรือ Sandbox ก็ตาม ถึงแม้จะมีจุดประสงค์เดียวกัน แต่วิธีการทำงานอาจจะแตกต่างกันเล็กน้อย ในที่นี้จะขอกล่าวถึง chroot สำหรับ Apache web server ที่อยู่บนระบบปฏิบัติการ Linux เป็นหลัก เพื่อไม่ให้เกิดความสับสน

ในเมื่อเราจำเป็นต้องกำหนดพื้นที่เฉพาะที่ Application แต่ละตัวสามารถใช้งานได้ให้แยกกันอย่างเด็ดขาดแล้ว ใน Application ที่มีความซับซ้อนอย่าง Web server แล้วก็นับว่าเป็นเรื่องที่ยุ่งยากไม่น้อย ในอดีตที่ผ่านมาปัญหาสำคัญของการทำ chroot สำหรับ Web server ก็คือ Shared library และ System file ซึ่ง Web server จำเป็นต้องใช้ในการทำงาน เราจำเป็นต้อง Copy ส่วนประกอบต่างๆ เหล่านี้มาไว้ในพื้นที่ที่จะกำหนดให้เป็นพื้นที่เฉพาะของ Web server เสียก่อน บางครั้งรวมถึง Log file และ Temporary file ต่างๆ ที่ Web server จะต้องเขียนระหว่างการทำงานด้วย และจากที่ได้กล่าวไปข้างต้นว่า การ chroot หรือ Jail ไม่ใช่การป้องกัน Web application โดยตรง เมื่อพิจารณาจากความยุ่งยากของการดำเนินการแล้ว ผู้ดูแลระบบจำนวนไม่น้อยจึงอาจจะคิดว่า เป็นการลงทุนลงแรงที่ไม่ได้ผลดีเท่าที่ควร และอาจจะจัดอันดับเอาไว้เป็นสิ่งท้ายๆ ที่จะนำมาปฏิบัติ

แต่ความเป็นจริงแล้ว การ chroot จะเป็นประโยชน์มากในการลดผลกระทบ (Mitigate) ของการโจมตีบางรูปแบบ ที่ปกติจะมีอันตรายกับระบบอย่างมาก เช่น การโจมตีในรูปแบบ Command injection หรือการฝัง Shell ซึ่งผลลัพธ์ของการโจมตีประเภทนี้คือ การเข้าถึงระบบปฏิบัติการโดยตรง และมีสิทธิ์ในการเข้าถึงไฟล์ต่างๆ รวมถึงคำสั่งของระบบในลักษณะเช่นเดียวกับผู้ใช้คนหนึ่งในระบบ โดยอยู่ภายใต้สิทธิ์ (Privileges) ของ Web server ในกรณีนี้ หาก Web server นั้น ถูก chroot เอาไว้ ถึงแม้คำสั่งจะถูกส่งเข้ามาผ่านช่องโหว่ของ Web application ได้สำเร็จ แต่จะไม่สามารถมีผลกับระบบหรือ Application อื่นที่อยู่ในระบบนั้นได้ ตามภาพที่ 1 และ 2

Pp2012te0010-1.png
ภาพที่ 1 แสดง php shell เมื่อทำงานใน Apache ปกติ

Pp2012te0010-2.png
ภาพที่ 2 แสดง php shell เมื่ออยู่ใน Apache ที่ถูก chroot

จากความแตกต่างของภาพที่ 1 และ 2 จะเห็นได้ว่า เมื่อ Web server (ในที่นี้คือ Apache) ถูก chroot แล้ว ต่อให้ถูกบุกรุกเข้ามาได้ ผู้ไม่ประสงค์ดีก็จะไม่สามารถเข้าถึงไฟล์ระบบหรือคำสั่งต่างๆ ได้เลย เว้นแต่ไฟล์ของ Web application และ Content ที่อยู่ใน Web server เท่านั้น เพราะพื้นที่ที่ระบบปฏิบัติการอนุญาตให้ Web server เข้าถึงได้มีแค่พื้นที่ที่ใช้เก็บ Content ของ Web server เท่านั้น

อย่างไรก็ตาม จุดอ่อนของ chroot ก็ยังมีอยู่ เช่นเดียวกับระบบป้องกันอื่นๆ ทุกชนิด ที่ไม่มีระบบใดสมบูรณ์พร้อมจนไม่สามารถทำลายได้ อันดับแรกคือ chroot จะสามารถป้องกันการเข้าถึงได้เฉพาะ Application ที่ไม่ได้มีสิทธิ์ root เท่านั้น กรณีนี้อาจจะไม่น่ากังวลนัก เนื่องจากในระบบปฏิบัติการสมัยใหม่ มักจะกำหนดให้ Web server ทำงานในสิทธิ์ user ธรรมดาเท่านั้น (เว้นแต่ผู้ไม่ประสงค์ดีใช้เทคนิคขั้นสูงเช่น Privilege escalation ซึ่งจะกล่าวถึงในโอกาสหน้า) อีกข้อหนึ่งคือ chroot ไม่สามารถใช้ป้องกันการที่ผู้ไม่ประสงค์ดีจะทำลาย หรือดัดแปลงแก้ไข Web application ของท่าน ในกรณีนี้ ต้องเข้าใจก่อนว่า การโจมตีประเภท Command injection หรือการสั่งการผ่าน Shell ที่ถูกลักลอบฝังไว้ (ภาพที่ 1) จะสามารถทำงานได้ตามสิทธิ์ของ Web server เท่านั้น ต่อให้เราจำกัดพื้นที่ที่ Web server สามารถเข้าถึงได้ด้วย chroot แล้วก็ตาม Web server ก็ยังจำเป็นต้องเข้าถึง Web application หรือ Content ต่างๆ เช่นรูปภาพ หรือข้อมูลที่ต้องการเผยแพร่ต่างๆ อยู่ดี ซึ่งก็ยังเป็นจุดที่ผู้ไม่ประสงค์ดีสามารถกระทำการมิดีมิร้ายแก่ระบบของท่านได้ นอกจากนี้ การโจมตีที่มีเป้าหมายเป็นข้อมูลใน Database อย่าง SQL Injection ก็ไม่สามารถป้องกันได้ด้วยวิธีนี้เช่นกัน

เมื่อทราบทั้งข้อดีและจุดอ่อนของ chroot แล้ว หากว่าท่านผู้อ่านต้องการนำไปทดลองทำดูบ้าง จะต้องทำอย่างไร? สำหรับท่านที่ใช้ Apache ตั้งแต่ version 2.2.10 ขึ้นไป ก็ค่อนข้างจะง่าย เพราะความสามารถ chroot นั้น ได้ถูกรวมมาอยู่ในตัวอยู่แล้ว สำหรับท่านที่ใช้ version เก่ากว่านี้ ก็มีทางเลือกอีก 2 ทางคือใช้ mod_chroot หรือใช้ mod_security ซึ่งจะไม่ขอพูดถึงในที่นี้

ขั้นตอนการ chroot ใน Apache version 2.2.10 ขึ้นไป จะมีขั้นตอนใหญ่ๆ 4 ขั้น ดังนี้

  1. กำหนดพื้นที่สำหรับทำเป็น root
  2. แก้ไข Apache configuration
  3. ย้าย Web application
  4. ทดสอบการทำงาน
กำหนดพื้นที่สำหรับทำเป็น root

พื้นที่สำหรับเป็น root จะต้องเป็นพื้นที่ที่มีขนาดใหญ่เพียงพอสำหรับเก็บ Web application และข้อมูลทุกชนิดที่ต้องใช้กับ Web application เอง รวมถึงข้อมูลที่ต้องการเผยแพร่ผ่าน Web server ทั้งหมด ในที่นี้กำหนดให้เป็น /var/wwwroot

แก้ไข Apache configuration

เพิ่มบรรทัดดังต่อไปนี้ใน Apache configuration

ChrootDir /var/wwwroot

ย้าย Web application

เนื่องจากเมื่อ chroot แล้ว Apache จะไม่สามารถเข้าถึงสิ่งที่อยู่นอก root ได้เลย ดังนั้นจึงจำเป็นจะต้องย้าย Web application และ Content ต่างๆ เข้ามาอยู่ใน root ใหม่นี้ทั้งหมด เช่นถ้ามี Web application เดิม อยู่ที่ /var/www/application1 ก็ต้องย้าย Web application ดังกล่าวมาไว้เป็น

/var/wwwroot/var/www/application1

ซึ่งอาจจะดูสับสนไม่น้อย แต่ก็เป็นการแลกกับการที่ไม่ต้องแก้ไข Configuration ของ Apache ให้มากจนเกินไปนัก ส่วนตำแหน่งที่เก็บ Log file และ SSL Key/Certificate ที่ใช้กับ Apache จะไม่ได้รับผลกระทบจากการทำ chroot แต่อย่างใด จึงไม่จำเป็นต้องแก้ไขใดๆ ทั้งสิ้น

ทดสอบการทำงาน

เพื่อให้แน่ใจว่า การ chroot เป็นไปอย่างสมบูรณ์ ไม่มีผลกระทบต่อการทำงาน จึงจำเป็นต้องทดลองใช้งานให้แน่ใจ โดยหลังจาก restart Apache แล้ว ให้ทดลองใช้งานพร้อมตรวจสอบ Log file ให้แน่ใจว่าไม่มี 404 not found หรือ Error ของ Web application เกิดขึ้นโดยไม่คาดคิด ซึ่งอาจหมายความว่าการย้าย Web application และ content ต่างๆ ยังไม่สมบูรณ์อย่างที่ควรจะเป็น

Clear