คือโปรแกรมที่ีวิธีติดต่อกันโดยผู้ใช้เป็นคนส่ง และผู้รับตอบกลับมา เช่น ผู้รับอาจหมายถึง Server ของ Google ที่ค้นหาข้อมูลให้เราก็ถือว่าเป็นโปรแกรมใหญ่ๆตัวหนึ่ง Server ของ Facebook ก็เป็นโปรแกรมตัวหนึ่ง Server ธนาคารก็เป็นโปรแกรมตัวหนึ่ง ผู้ส่งคือตัวเราเองที่ใช้เครื่อง (computer , smartphone)
กดปุ่มส่งไปบ้าง หรือป้อนข้อความแล้วกดปุ่มตกลง ผู้รับได้รับก็จะประมวลผลและทำตามส่งผลลัพธ์กลับ
มาที่ผู้ส่ง เป็นต้น
ปัจจุบันคนทำเว็บเพจแบบ API คงหนีไม่พ้นการทำเว็บAPI หลังบ้าน (backend) เพื่อให้ระบบหน้าบ้าน เว็บส่วน frontend หรือแอปพลิเคชันมือถือหรือระบบอื่น ๆ มาเรียกใช้งาน เวลาเราจะเขียนเว็บ API ขึ้นมาใช้สักตัวปกติแล้วก็จะเริ่มจากออกแบบ จากความต้องการจะนำข้อมูลอะไรเข้า-ออกจากระบบของเรา จะประมวลผลอะไร แต่สิ่งนึงที่มักจะถูกมองข้ามคือเรื่องของความปลอดภัย เพราะจุดประสงค์หลักคือเน้นเขียนให้แค่ใช้งานได้ งานเสร็จเร็ว รีบปิดงาน รับเงิน ไปทำโปรเจ็คอื่นต่อ ในมุมมองอีกด้านหนึ่งแล้วเว็บ API ที่ปลอดภัย มันควรจะเป็นยังไง เราควรหาทางป้องกันแก้ไข เพื่อพัฒนาระบบที่เราสร้างให้เกิดความปลอดภัยไปด้วยไม่ใช้แค่สร้างให้ไช้งานได้เฉยๆ มีแนวทางดังนี้
1. ใช้การเชื่อมต่อเป็น HTTPS ทุกกรณี
HTTPS คือการเข้ารหัสข้อมูลระหว่างผู้ใช้งานกับเว็บ server เรื่องนี้น่าจะเป็นพื้นฐานความปลอดภัยที่นักพัฒนาทุกคนควรนำไปใช้ได้แล้ว เพราะ server แต่ละบริษัทที่ให้บริการจะเริ่มจรืงจังกับระบบความปลอดภัย เช่น ตั้งแต่เดือนกรกฏาคม 2561 ที่จะถึงนี้ Chrome เวอร์ชั่น 68 จะแจ้งเตือนเว็บทุกเว็บที่ไม่ได้ใช้ HTTPS ว่าไม่ปลอดภัย “Not Secure” เป็นต้น
2. เก็บรหัสผ่านในรูปแบบที่ผ่านฟังก์ชันแฮชที่มีความปลอดภัยเสมอ
ถ้าเว็บเรามีระบบสมาชิก ให้คนเข้ามาสมัครได้ แน่นอนว่าเราจะต้องทำการเก็บ ชื่อผู้ใช้ กับ รหัสผ่าน แต่จะเกิดอะไรขึ้นถ้า ระบบของเราโดนแฮก หรือผู้ดูแลระบบ คนในองค์กรไม่หวังดี นำข้อมูลรหัสผ่านออกไป? หนึ่งในวิธีลดความเสี่ยงของปัญหานี้คือเราสามารถ แปลงรหัสผ่านโดยการใช้ฟังก์ชันแฮชที่มีความปลอดภัยเช่น bcrypt ไปเป็นรูปแบบที่ไม่สามารถย้อนกลับไปเป็นรหัสผ่านจริง ๆ ได้โดยง่าย ถ้าไม่เคยทำมาก่อน ฟังดูเหมือนซับซ้อนแต่ ถ้าคุณใช้ framework เขียนเว็บ มั่นใจได้ว่าเกือบทุกยี้ห้อมีฟังก์ชันการแฮชรหัสผ่านให้แน่นอน เปิดคู่มืออ่านแล้วรีบแก้ไข ถ้าไม่มีตัวภาษาที่ใช้เขียนก็มีความสามารถทำได้ และอีกอย่างคือควรใส่ค่าสุ่มที่เรียกว่า salt ลงไปก่อนจะทำการแฮชด้วย เพื่อป้องกันการแฮชค่าเดียวกันของต่างผู้ใช้งานแล้วได้แฮชค่าเดิม ซึ่งบางอัลกอริทึมเช่น bcrypt จะใส่ไว้ให้อัตโนมัติแล้วไม่ต้องทำเองให้ยุ่งยาก เพิ่มเติมข้อควรระวังคือ อย่าใช้ ฟังก์ชันแฮชที่มีความปลอดภัยต่ำเมื่อเทียบกับตัวเลือกอื่นในยุคนี้แล้วอย่าง MD5 หรือ SHA1 โดยเด็ดขาด เพื่อสร้างความตระหนักทีมพัฒนาให้เลือกใช้แฮชที่ปลอดภัย เวลาเขียนโปรแกรม
3. ใช้การสร้างค่าสุ่มที่มีความปลอดภัย
เวลาเราเขียนเว็บขึ้นมา อีกสิ่งที่หนีไม่พ้นแน่ ๆ คือการสร้างค่าสุ่มที่มีความปลอดภัยมีความสำคัญมาก เราควรจะกำหนดความยาวเพื่อไม่ให้ถูกเดาได้โดยง่ายเช่นตั้งแต่ 12 ตัวขึ้นไป พร้อมทั้งใช้ฟังก์ชันที่สร้างเลขสุ่มที่ปลอดภัยด้วยอย่างในภาษา Java ก็จะมี class ที่ใช้สร้าง object สำหรับสร้างค่าสุ่มคือ java.util.Random แต่หารู้ไม่ว่า ฟังก์ชันนี้ไม่ปลอดภัยเพียงพอสำหรับการสร้างค่าที่ต้องใช้เป็นความลับ ซึ่งจะมีฟังก์ชันที่เหมาะสมกว่าสำหรับการสร้างค่าสุ่มที่มีความปลอดภัยคือ java.security.SecureRandom ส่วนถ้าคุณใช้ภาษาอื่น หรือเว็บ framework ก็ปรึกษาคู่มือว่าจะสร้างเลขสุ่มที่ปลอดภัยได้อย่างไร หนึ่งในวิธีที่แนะนำคืออาจจะใช้ฟังก์ชันที่สร้างค่าสุ่มที่เรียกว่า UUID version 4 จะหน้าตาประมาณนี้
123e4567-e89b-12d3-a456-426655440000
ก็ได้ถือว่ามีความปลอดภัยเพียงพอและยากต่อการเดา
4. ตัวอย่างการออกแบบชื่อ path ของเว็บ API ที่ช่วยลดโอกาสจะเกิดช่องโหว่
วิธีการเขียนการตรวจสอบสิทธิ์ทั้ง การยืนยันตัวผู้ใช้และการยืนยันสิทธิ์ของผู้ใช้งาน ที่ดีคือใช้ framework หรือเทคนิคที่สามารถ รวมการเช็คสิทธิ์แบบศูนย์กลางที่เดียวกันได้ คือตั้งที่เดียวให้มันเช็คสิทธิ์ทั้งหมดทุกจุด อย่าพยายามแยกไปเช็คหลาย ๆ ที่ เพราะแยกแล้วโอกาสพลาดสูงกว่า
5. การเก็บข้อมูลที่อัปโหลดจากผู้ใช้งานที่ปลอดภัย
ถ้าระบบเรายอมให้ผู้ใช้งานอัปโหลดรูปหรือเอกสาร ภายใต้เงื่อนไขข้อมูลเก็บบน cloud ได้มีงบและระบบสเกลขนาดกลางขึ้นไป ควรแยกไปไว้ระบบเก็บไฟล์ static
6. นอกจาก API สำหรับผู้ใช้งานแล้ว API ที่คุยกันระหว่าง server ก็ต้องออกแบบให้ปลอดภัย
ระบบขนาดกลางถึงขนาดใหญ่ นอกจากจะมีการให้ ผู้ใช้งานฝั่ง end-user เรียก API เพื่อใช้ฟีเจอร์ต่าง ๆ แล้ว ตัวระบบใน API นั้น ๆ เอง มักจะต้องไปเรียก API ที่ server อื่นต่ออีกที เพื่อทำงานอะไรบางอย่างที่ทำเองในระบบตัวเองไม่ได้ เช่นการดึงข้อมูลจากระบบอื่นมาใช้ การคุยกันระหว่าง API สองตัวโดยไม่ผ่านผู้ใช้งานฝั่ง end-user เราเรียกว่า server-to-server communication บ่อยครั้งในกระบวนการออกแบบซอฟต์แวร์ มีการออกแบบมาอย่างไม่ปลอดภัย โดยให้ผู้ใช้งานฝั่ง end-user ยิงเข้า API ตัวที่ควรทำเป็น server-to-server communication ได้โดยตรง ผลคือ การตรวจสอบค่าต่าง ๆ ที่ควรทำกลับไม่ได้ถูกตรวจสอบ นี่คือจุดที่ต้องควรระมัดระวังอย่างยิ่ง
7. ควรทำการตรวจสอบค่าที่รับเข้ามาจากผู้ใช้งานเสมอ
การเขียนโค้ดที่ต้องตรวจสอบค่าของผู้ใช้งานนั้น ควรมีการเรียกใช้งาน utility class หรือ library ที่พิสูจน์และเป็นที่ยอมรับแล้วว่าปลอดภัย และทุก ๆ ครั้งที่จะทำการตรวจสอบในกรณีเดียวกันควรจะต้องเรียกใช้งานจากutility class นั้น ๆ ที่เดียว เพื่อป้องกันในทุกจุดในกรณีเดียวกันให้เหมือนกัน สมมุติถ้า มีช่องโหว่เกิดขึ้นใน utility class นั้นเราก็จะได้แก้จุดเดียว เพื่อว่าให้ง่ายต่อการ maintenance การเพิ่มฟีเจอร์ การ test การ integration กับระบบอื่นและลดข้อผิดพลาดจากกรณีว่า ถ้าเราเขียนไว้หลาย ๆ ที่จาก 100 ที่ อาจจะมีสัก 1 ที่ ๆ ลืมหรือเขียนผิด ถ้าเราบังคับให้ใช้จากที่เดียวเลยก็จะแก้ปัญหานี้ได้ดีขึ้น
8. คอยตามข่าวช่องโหว่ใน component ที่เราใช้งาน
เวลาเราจะสร้างเว็บ API หรือระบบขึ้นมาสักอย่าง มีโอกาสน้อยมากที่เราจะเขียนโค้ดเองทั้งหมด เรามักจะใช้เว็บ framework หรือ library ของคนอื่นเข้ามาในโค้ดด้วยเสมอ เช่นใช้เพื่อทำฟีเจอร์อ่าน QR code ใช้เพื่อทำ rich-text editor หรืออ่านค่ามาจากเอกสาร Excel ที่ผู้ใช้งานอัปโหลดมาบนเว็บเป็นต้นเวลาเราออกแบบ พัฒนาระบบ เราก็ควรจะใช้งานเวอร์ชั่นล่าสุดในขณะนั้นเสมอเพื่อความปลอดภัยสูงสุด พร้อมทั้ง ทำเอกสารบอกถึงรายชื่อและเวอร์ชันของ component ที่เราใช้ เพื่อว่าถ้าในอนาคตถ้า component ที่เราใช้มีช่องโหว่เราจะได้ ตรวจสอบได้ง่าย และนำเวอร์ชันใหม่มาสับเปลี่ยนกันได้สะดวกมากยิ่งขึ้น เพื่อความปลอดภัยนั้นเอง
เทคนิคต่างๆ เรื่องของความปลอดภัยใน WEB API ยังมีอีกหลายจุดหลายเทคนิค ฉะนั้นการหาความรู้เพิ่มเติมจากโค้ดต่างๆ ยอมมีประโยชน์ มุมมองนักพัฒนา นักทดสอบซอฟต์แวร์ว่าเราควรจะทำยังไงให้ แอปพลิเคชันและเว็บ API เรามีความปลอดภัยมากยิ่งขึ้นก็เป็นหน้าที่ของนักพัฒนาซอฟต์แวร์ทุกคนที่ควรจะตระหนักถึงผู้ใช้งานและอัพเดทความรู้เกี่ยวกับภัยคุกคามและช่องโหว่ใหม่ ๆ อยู่เสมอ
ref ; www.catcyfence.com , medium.com
