ตรวจสอบความปลอดภัยของโค้ด

penetration test แบบ black-box มองเห็นได้แค่สิ่งที่แอปพลิเคชันเปิดเผยออกมาตอนรันเท่านั้น ผู้ทดสอบส่ง request เข้าไป สังเกตว่าตอบอะไรกลับมา แล้วอนุมานว่าข้างในทำงานอย่างไร แต่จุดอ่อนบางอย่างไม่เคยโผล่มาถึงขอบระบบเลย Secure code review อ่าน source code ตรง ๆ เป็น white-box โดยนิยาม ทุก branch ทุก dependency ทุกการตัดสินใจเรื่องความไว้ใจที่ทีมพัฒนาของคุณวางไว้ อยู่ในขอบเขตตรวจหมด ไม่ว่าวันนี้ผู้โจมตีจะกระตุ้นมันจากข้างนอกได้ง่ายหรือไม่ก็ตาม

ช่องโหว่ที่เห็นได้จากการอ่าน source code

ทั้งหมดนี้คือช่องโหว่จริง และทั้งหมดนี้ซ่อนตัวอยู่หลัง HTTP interface หน้าตาธรรมดาที่สุดได้สบาย ๆ

สองแนวทางนี้ตอบคนละคำถาม และเสริมกันเมื่อใช้คู่กัน code review ทำงานจากข้างในออกนอก penetration test ทำงานจากข้างนอกเข้าใน จุดที่ทั้งสองทับกันคือประเด็นที่ยืนยันได้จากทั้งสองทิศ

วิธีการทำงานของเรา

ทุกงานตรวจสอบเดินตามสี่ขั้นตอนเดียวกันเสมอ

1. 1

   Application profiling

   เราเริ่มจากตั้งวงกับทีมของคุณ ทำความเข้าใจว่าแอปพลิเคชันทำงานจริงยังไง ทั้งสถาปัตยกรรม framework และภาษาที่ใช้ จุดที่ input เข้าสู่ระบบ ตำแหน่งของ trust boundary และ component ไหนสำคัญต่อธุรกิจมากที่สุด ขั้นนี้เป็นตัวกำหนดว่าจะทุ่มแรงตรวจสอบไปตรงไหน โมดูลจ่ายเงินกับแบนเนอร์การตลาดไม่ควรได้ความสำคัญเท่ากัน

   ขอบเขต ภาษาและ framework ที่ครอบคลุม กับระดับความลึกของการตรวจสอบ ตกลงร่วมกับคุณตรงนี้หมด และ toolchain ปรับตามเทคโนโลยีของคุณ

2. 2

   Static analysis

   เรารันเครื่องมือ static analysis (SAST) ที่เหมาะกับแต่ละภาษาใน codebase static analysis คือสิ่งที่ทำให้ครอบคลุมทั้ง codebase ได้จริง มันไล่ data flow จาก source ที่ไม่น่าเชื่อถือไปจนถึง sink ที่อันตราย จับ tainted input ที่วิ่งไปถึง query หรือ command และดึงจุดที่น่าสงสัยขึ้นมาจากไฟล์ทั่วทั้ง codebase

   ผลลัพธ์ของขั้นนี้คือรายการที่ต้องสงสัย ตั้งใจให้กว้างไว้ก่อน และยังไม่ใช่ finding ที่ยืนยันแล้ว

3. 3

   Manual analysis

   นักวิเคราะห์ไล่ดูรายการที่ต้องสงสัยด้วยมือทีละตัว ตาม code path จริง เพื่อดูว่ามัน exploit ได้จริงในบริบทนั้นไหม หรือเป็นแค่ false positive คือ pattern ที่ดูอันตรายแต่โดน validation ที่เครื่องมือตามไม่ทันปิดไปแล้ว นักวิเคราะห์อ่านเพื่อหาสิ่งที่เครื่องมือมองข้าม ทั้ง false negative และเหนืออื่นใดคือ logic flaw เช่น authorization check ที่หายไป หรือการตัดสินใจเรื่อง crypto ที่ถูกต้องตาม syntax แต่ผิดหลัก crypto เพราะไม่มี pattern matcher ตัวไหนเข้าใจว่าแอปพลิเคชันของคุณตั้งใจจะอนุญาตอะไร

   รายงานมีเฉพาะ finding ที่ผ่านการยืนยันแล้ว

4. 4

   Recommendation

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

   วิธีแก้เขียนสำหรับภาษาและ framework ที่คุณใช้อยู่จริง

ทำไม manual analysis ถึงสำคัญ

เครื่องมือ static analysis ครอบคลุมได้กว้าง แต่ตัดสินบริบทไม่ได้ ถ้าไม่มีคนรีวิวผล SAST scan จะมีปัญหาสองแบบ แบบแรกคือ false positive เครื่องมือจับ data flow ว่า tainted เพราะมันมองไม่เห็นชั้น validation ไม่เห็น encoding ที่ framework มีมาให้ในตัว หรือไม่เห็น business rule ที่ทำให้เส้นทางนั้นไปไม่ถึง เมื่อรายงานมี false positive จำนวนมาก ทีมพัฒนาของคุณก็เริ่มไม่ให้น้ำหนักกับรายงาน แบบที่สองคือ false negative เครื่องมือแค่ match pattern มันไม่เข้าใจเจตนา มันจะไม่สังเกตว่า endpoint เช็คแค่ว่า user ล็อกอินอยู่ไหม แต่ไม่เคยเช็คว่า user คนไหนเป็นเจ้าของ record นั้น หรือฟังก์ชัน signing ใช้ key ที่มาจากค่าที่เดาได้ เพราะไม่มีอะไรในบรรทัดพวกนั้น match กับ signature ที่รู้กันว่าอันตราย ขั้นตอน manual analysis มีไว้แก้ทั้งสองปัญหานี้ คัดให้เหลือแต่ประเด็นที่ยืนยันแล้วว่า exploit ได้จริง พร้อมค้นหา finding ด้านตรรกะที่เครื่องมืออัตโนมัติตรวจไม่พบ ทุกข้อในรายงานของคุณผ่านการยืนยันโดยนักวิเคราะห์ที่อ่านโค้ด

สิ่งที่คุณได้รับ

ทุกรายงานมีอย่างน้อยดังนี้

ทีมและใบรับรอง

บริการที่เกี่ยวข้อง

Secure code review บอกคุณว่าอะไรผิดอยู่ข้างในโค้ด ส่วน penetration test พิสูจน์ว่าผู้โจมตีเข้าถึงอะไรได้จากข้างนอก เอาการตรวจสอบนี้ไปจับคู่กับ penetration test ฝั่ง เว็บแอปพลิเคชัน หรือ แอปพลิเคชันมือถือ แล้วคุณจะได้ทั้งสองทิศทางพร้อมกัน และ finding จากแต่ละฝั่งช่วยให้อีกฝั่งแม่นยำขึ้น