ในปัจจุบันนี้การ ออกแบบ API หลังบ้าน ( backend ) เพื่อให้ระบบหน้าบ้าน เว็บส่วน frontend หรือแอปพลิเคชันมือถือ หรือระบบอื่น ๆ มาใช้งาน ปกติแล้วเราก็จะเริ่มจากออกแบบ จากความต้องการจะนำข้อมูลเข้า-ออกจากระบบของเรา แต่สิ่งนึงที่มักจะถูกมองข้ามคือเรื่องของความปลอดภัย และ ส่วนนี้เป็นส่วนหนึ่งที่อยากนำเสนอคือการมีเว็บ API ที่ปลอดภัย ควรจะเป็นยังไง ในบนความนี้จะแนะนำเทคนิคแบบเข้าใจง่าย ๆพร้อมแนวทางแก้ไขที่ทุกท่านสามารถนำไปประยุกต์ใช้ในการพัฒนาระบบให้ปลอดภัยได้ครับ
1. การเก็บข้อมูลที่อัปโหลดจากผู้ใช้งานที่ปลอดภัย
ถ้าระบบเรายอมให้ผู้ใช้งานอัปโหลดรูปหรือเอกสาร ภายใต้เงื่อนไขข้อมูลเก็บบน cloud ได้มีงบและระบบสเกลขนาดกลางขึ้นไป ควรแยกไปไว้ระบบเก็บไฟล์ static โดยเฉพาะอย่างผู้ให้บริการ CDN เช่น AWS S3 ไม่ควรเก็บในระบบเดียวกันกับแอปพลิเคชัน เพราะมีความเสี่ยงหลายอย่างเช่น harddisk เต็มแล้วระบบจะล่มทั้งหมด
หรือไฟล์ที่อัปโหลดเข้ามามีโค้ดอันตรายต่อแอปพลิเคชันของเรา มันจะดีกว่ามากถ้าเราแบ่งความเสี่ยงตรงนี้ไป
ที่ระบบเก็บฝากโดยเฉพาะเลย แต่ไม่ว่าเราจะเลือกทางนี้หรือไม่ แน่นอนว่าต้องตรวจสอบให้ละเอียดคือผู้ใช้งาน อัปโหลดไฟล์ที่เราต้องการเข้ามาจริง ๆ เช่นเช็คนามสกุลไฟล์ว่าเป็น .png .jpg .gif รึเปล่า มีเนื้อหาถูกต้องตามไฟล์ที่เราอยากได้มี magic numbersขึ้นต้นไฟล์ถูกต้อง ขนาดไม่ใหญ่เกิน จำนวนไฟล์ไม่มากเกิน ถ้านอกเหนือจากเงื่อนไขที่เรากำหนดเหล่านี้จะต้องให้ไม่ยอมให้อัปโหลด หรือดีกว่านั้น ในกรณีที่ยอมให้อัปโหลดแล้ว ควรลบข้อมูลพวก metadataออกจากรูปหรือเอกสารด้วย เพื่อปกป้องผู้งานเว็บเราจาก ข้อมูลส่วนตัวเปิดเผยออกมาจากข้อมูล EXIF รูปถ่ายหรือชื่อ username ชื่อเครื่องที่อาจติดมากับ
ไฟล์เอกสารต่าง ๆ
จุดที่ต้องระวังอย่างนึงของการใช้บริการ public cloud ที่เป็น บุคคลที่สาม โดยเฉพาะ AWS S3 เพราะว่าตัว bucket สำหรับเก็บข้อมูล สามารถตั้งค่าให้ใครก็ได้ อ่าน/เขียน ข้อมูลที่เราเก็บไว้ได้ผลคือมีคนมักง่าย เปิดสิทธิ์
ให้ใครก็ได้เข้าได้ เพื่อว่าจะได้ใช้งานง่าย ๆ หรือไม่เข้าใจว่าการตั้งแบบไหนไม่ปลอดภัย ผลคือโดนคนอื่นมาล้วงข้อมูลไว้ กันรัว ๆ ในช่วงหลายปีที่ผ่านมาทั้ง Uber ข้อมูลผู้ใช้งาน 57 ล้านรายรั่ว,ข้อมูลลูกค้าหลายร้อยกิ๊ก
ของ Accenture และเคสอื่น ๆ อีกมากมาย ทั้งเป็นข่าวและไม่เป็นข่าว ข่าวดีคือมีโปรแกรมชื่อ S3 Inspector
ช่วยตรวจสอบ AWS S3 bucket ที่เราเปิดมาใช้ได้ว่าตั้งค่าไม่ปลอดภัยรึเปล่า
2. เก็บรหัสผ่านในรูปแบบที่ผ่านฟังก์ชันแฮชที่มีความปลอดภัยเสมอ
ถ้าเว็บเรามีระบบสมาชิก ให้คนเข้ามาสมัครได้ แน่นอนว่าเราจะต้องทำการเก็บ ชื่อผู้ใช้ กับ รหัสผ่าน แต่จะเกิดอะไรขึ้นถ้า ระบบของเราโดนแฮก หรือผู้ดูแลระบบ คนในองค์กรไม่หวังดี นำข้อมูลรหัสผ่านออกไป? หนึ่งในวิธี
ลดความเสี่ยงของปัญหานี้คือเราสามารถ แปลงรหัสผ่านโดยการใช้ฟังก์ชันแฮชที่มีความปลอดภัยเช่น bcrypt
ไปเป็นรูปแบบที่ไม่สามารถย้อนกลับไปเป็นรหัสผ่านจริง ๆ ได้โดยง่าย ถ้าไม่เคยทำมาก่อน ฟังดูเหมือนซับซ้อน ออกแบบ API
แต่ ถ้าคุณใช้ framework เขียนเว็บ มั่นใจได้ว่าเกือบทุกยี้ห้อ
มีฟังก์ชันการแฮชรหัสผ่านให้แน่นอน เปิดคู่มืออ่านโล้ด ถ้าไม่มีตัวภาษาที่ใช้เขียนก็มีความสามารถทำได้ และอีกอย่างคือควรใส่ค่าสุ่มที่เรียกว่า salt ลงไปก่อนจะทำการแฮชด้วย เพื่อป้องกันการแฮชค่าเดียวกันของต่างผู้ใช้งานแล้วได้แฮชค่าเดิม ซึ่งบางอัลกอริทึมเช่น bcrypt จะใส่ไว้ให้อัตโนมัติแล้วไม่ต้องทำเองให้ยุ่งยาก เพิ่มเติมข้อควรระวังคือ อย่าใช้ ฟังก์ชันแฮชที่มีความปลอดภัยต่ำเมื่อเทียบกับตัวเลือกอื่นในยุคนี้แล้วอย่าง MD5 หรือ SHA1 โดยเด็ดขาด เรื่องเล่าคือผมไปเจอระบบที่หัวหน้าทีมพัฒนาระบบเค้าป้องกันไม่ให้โปรแกรมเมอร์ใช้ MD5/SHA1 โดยการทำการสแกนโค้ดเพื่อหาสองฟังก์ชันนี้เสมอหลังจากมีการ
ส่งโค้ดมา ใน code repository ขององค์กรด้วย บางที่เด็ดกว่านั้นตั้งชื่อฟังก์ชันใหม่จาก MD5() ทำ wrapper ครอบเป็น VeryInsecureMD5() เพื่อสร้างความตระหนักทีมพัฒนาให้เลือกใช้แฮชที่ปลอดภัย เวลาเขียนโปรแกรม
3. ใช้การเชื่อมต่อเป็น HTTPS เสมอ
HTTPS คือการเข้ารหัสข้อมูลระหว่างผู้ใช้งานกับเว็บ server เรื่องนี้น่าจะเป็นพื้นฐานความปลอดภัยที่นักพัฒนาทุกคนควรนำไปใช้ได้แล้ว เพราะข่าวร้ายคือ ตั้งแต่เดือนกรกฏาคม 2561 ที่จะถึงนี้ Chrome เวอร์ชั่น 68
จะแจ้งเตือนเว็บทุกเว็บที่ไม่ได้ใช้ HTTPS ว่าไม่ปลอดภัย “Not Secure” อีกทั้งจากประสบการณ์ส่วนตัวผมเคยแจ้งประเด็นนี้ให้ระบบที่นึงว่ามันไม่ปลอดภัย
แต่เค้ายังไงก็ไม่ยอมแก้ ข้ออ้างมาเพียบแต่พอบอก สิ่งที่คนส่วนมากอาจยังไม่รู้และถ้ารู้จะรีบเปิดคอมฯเข้าไป
แก้เว็บตัวเองให้เป็น HTTPS เลยทันทีคือ ถ้าเว็บของเรานั้นเป็น HTTPS แล้ว Google จะจัดอันดับ ranking
จากผลการค้นหามาสู่เว็บเราให้ดีขึ้นด้วยนะ! นอกจากเหตุผลด้านความปลอดภัย ก็ยังอาจสร้างรายได้ให้ธุรกิจ
มากขึ้นจากการที่ได้ผลลัพธ์อันดับดีขึ้นด้วย เป็นการทำ SEO ไปในตัว โชคสองชั้นชัด ๆ
ในมุมมองแฮกเกอร์แล้ว ถ้าการเชื่อมต่อเว็บใด ๆ ไม่ใช่ HTTPS จะสามารถอ่านข้อมูลที่ถูกดักมากลางทางได้ ตัวอย่างง่าย ๆ เช่นถ้าเร้าเตอร์หรือ server ระหว่าง เว็บกับผู้ใช้งานโดนแฮก ก็จะโดนดักอ่านรหัสผ่านได้หมดเลย
4. นอกจาก API สำหรับผู้ใช้งานแล้ว API ที่คุยกันระหว่าง server ก็ต้องออกแบบให้ปลอดภัย
ระบบขนาดกลางถึงขนาดใหญ่ นอกจากจะมีการให้ ผู้ใช้งานฝั่ง end-user เรียก API เพื่อใช้ฟีเจอร์ต่าง ๆ แล้ว
ตัวระบบใน API นั้น ๆ เอง มักจะต้องไปเรียก API ที่ server อื่นต่ออีกที เพื่อทำงานอะไรบางอย่างที่ทำเองในระบบตัวเองไม่ได้ เช่นการดึงข้อมูลจากระบบอื่นมาใช้ การคุยกันระหว่าง API สองตัวโดยไม่ผ่านผู้ใช้งานฝั่ง
end-user เราเรียกว่า server-to-server communication
ออกแบบเว็บ API บ่อยครั้งในกระบวนการออกแบบซอฟต์แวร์ มีการออกแบบมาอย่างไม่ปลอดภัย โดยให้ผู้ใช้งานฝั่ง end-user ยิงเข้า API ตัวที่ควรทำเป็น server-to-server communication ได้โดยตรง ผลคือ การตรวจสอบค่าต่าง ๆ ที่ควรทำกลับไม่ได้ถูกตรวจสอบ
5. ควรหลีกเลี่ยงเทคนิคการเขียนโปรแกรมที่ต้องทำการ serialize ตัว object ใด ๆ
ปกติเราเขียนโปรแกรมมีฐานข้อมูล ถ้าเรามี ข้อมูลเช่น abc 123 เราสามารถเก็บค่า primitive type ง่าย ๆ เหล่านั้นลงในฐานข้อมูล หรือไฟล์ธรรมดาได้ แต่มันก็จะมีบางเหตุการณ์ ที่เราอาจจะออกแบบมา ด้วยเหตุผลอะไรไม่รู้แหละ อาจจะเพราะความง่ายก็ได้ อยากจะนำ object ที่เราสร้างมาจาก class อะไรสักอย่าง ซึ่งพ่วงด้วย property ของ object ต่าง ๆ เนี่ย เก็บลงไปใน ไฟล์หรือในฐานข้อมูล ซึ่งเทคนิคการแปลง object ไปเป็นค่าที่เก็บได้พวกนี้เราเรียกว่าการทำ serialize และการแปลงกลับคือการทำ deserialize
วิธีการที่ใช้แทนการ serialize คือเก็บค่าแบบ primitive type แบบเดิมเป็น list / array แล้วแต่ภาษาและแปลงออกมาเป็น JSON มาเก็บแทน เวลาอยาก import คืนก็เอาค่าเหล่านั้นมา assign ให้ property ต่าง ๆสำหรับ object ที่เราต้องการ หรือหาทางออกแบบวิธีอื่นที่ไม่ได้ deserialize ค่าที่รับมาโดยตรงถ้าเลี่ยงไม่ได้จริง ๆ
ใช้ทำการ whitelist เฉพาะ object ที่ต้องการเท่านั้นอย่างระมัดระวังสุด ๆ และการลดความเสี่ยงแบบสุดท้ายคือการทำ blacklist ในส่วนของค่าที่ไม่ปลอดภัย ตัวอย่างเช่นการ deserialization ใน Java มี library ชื่อ SerialKiller ช่วยทำ blacklist/whitelist ได้
6. ควรทำการตรวจสอบค่าที่รับเข้ามาจากผู้ใช้งานเสมอ
ความเสี่ยงที่ระบบมักจะโดนแฮกมากที่สุด จัดอันดับโดย OWASP TOP 10 ปี 2017 คือ ความเสี่ยงของช่องโหว่ในตระกูล Injection ซึ่งมีตั้งแต่ SQL Injection, Command Injection, Code Injection และอื่น ๆ อีกมากมายโดย best practice ของการเขียนโค้ดที่ต้องตรวจสอบค่าของผู้ใช้งานนั้น ควรมีการเรียกใช้งาน utility class หรือ library ที่พิสูจน์และเป็นที่ยอมรับแล้วว่าปลอดภัย และทุก ๆ ครั้งที่จะทำการตรวจสอบในกรณีเดียวกันควรจะต้องเรียกใช้งานจากutility class นั้น ๆ ที่เดียว เพื่อป้องกันในทุกจุดในกรณีเดียวกันให้เหมือนกัน สมมุติถ้า
มีช่องโหว่เกิดขึ้นใน utility class นั้นเราก็จะได้แก้จุดเดียว เพื่อว่าให้ง่ายต่อการ maintenance การเพิ่มฟีเจอร์ ออกแบบ API หลังบ้าน
การ test การ integration กับระบบอื่นและลดข้อผิดพลาดจากกรณีว่า ถ้าเราเขียนไว้หลาย ๆ ที่จาก 100 ที่ อาจจะมีสัก 1 ที่ ๆ ลืมหรือเขียนผิด ถ้าเราบังคับให้ใช้จากที่เดียวเลยก็จะแก้ปัญหานี้ได้ดีขึ้น
สิ่งสุดท้ายคือทำการทดสอบทางด้านความปลอดภัยให้ Web API ก่อนเปิดให้ใช้งาน
ผมเชื่อว่า ยากมากที่เราจะทำระบบใด ๆ ให้ปลอดภัย 100% ขนาด Google, Facebook และ Microsoft ที่มี software engineer ระดับโลก เค้ายังเขียนโค้ดมีช่องโหว่ โดนแฮกกันได้ เหตุผลเพราะอะไรนั้นต้องคุยกันยาว เช่นความซับซ้อนของระบบ, มนุษย์มีข้อผิดพลาดได้, เกิดจากการทำงานร่วมกันที่เข้าใจต่างกัน ฯลฯ ดังนั้นหลังจากเราทำซอฟต์แวร์เสร็จแล้ว ต่อให้เราใส่ใจเรื่องความปลอดภัยในกระบวนการพัฒนามากแค่ไหน ใน SDLC ตอนก่อนจะเปิดให้ใช้งานจริง ควรมีการทดสอบด้านความปลอดภัยก่อนเสมอ โดยอย่างน้อยที่สุดก็อาจจะแค่ว่า
ใช้โปรแกรมเช่น OWASP ZAP หรือw3af มาร่วมautomate หรือ manual ทดสอบความปลอดภัยว่า
ทั้งนี้บริษัทเคแอนด์โอ จึงได้มุ่งเน้นการจัดการแก้ไขปัญหา จัดการเอกสาร ด้านเอกสารขององค์กรมาอย่างยาวนาน และ ให้ความสำคัญกับด้านงานเอกสาร ต่อลูกค้าเป็นอย่างดี จนถึงปัจจุบันก็ได้ความยอมรับจากองค์กร ขนาดใหญ่ ขนาดกลาง และขนาดเล็กมากมาย จึงใคร่ขออาสาดูและปัญหาด้านเอกสารให้กับองค์กรของท่านอย่างสุดความสามารถ เพราะเราเป็นหนึ่งในธุรกิจ ระบบจัดเก็บเอกสาร ที่ท่านไว้ใจได้
สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ เพราะเป็นราคาที่สุด คุ้มที่สุด
เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA ให้คำปรึกษาด้านวางระบบจัดการเอกสารอิเล็กทรอนิกส์ EDMS โดยทีมงานผู้เชี่ยวชาญจาก K&O
ที่มีประสบการณ์มากว่า 15 ปี รวมถึงซอฟต์แวร์ระดับโลก ติดต่อ 0 2 – 8 6 0 – 6 6 5 9 หรือ E m a i l : c s @ k o . i n . t h
หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699
