[OWASP] สรุป Security Testing Tools for QA/Tester จากงาน OWASP Monthly (07/2021)

สำหรับหัวข้อ Security Testing Tools for QA/Tester โดย คุณอัมฤทธิ์ ทองทั่ว (2021-07-29) ผมโชคดีที่เหลือบมาเห็น Feed ใน Facebook Group ช่วงเย็นครับ เลยแว๊บมาฟัง และทำงานคู่กันไปด้วยครับ

Security Testing & Software Development Process

• หลายคนมักเข้าใจผิดว่าทำหลัง Software เสร็จ แต่จริงๆ มันมาคู่กันเลยครับ โดยถ้ามีการเก็บ Requirement มีต้องถาม Requirement ในส่วนของ Security Requirement ประกอบคู่กันด้วยครับ
• การทดสอบ Security Testing ตาม OWASP Top Ten อาจจะยังไม่พอ เป็นเพียงแค่ Guideline เบื้องต้น

คนที่เกี่ยวข้องกับ Security Test

• Business Owner : ให้ Requirement ที่เข้าใจพยายามนำ Policy มาปรับใช้ เพื่อให้เกิด Security Requirement ประกอบขึ้นมาด้วย
• Project Manager : จัด และให้มีกิจกรรมของ Security Test ในแผนของโครงการ
• IT Security Team : กำหนดนโยบาย และให้คำปรึกษาแก้ไข Security
• Programmer : แก้ไข Source Code หากมี Issue ด้าน Security
• QA/Tester : ทดสอบระบบตาม Function Requirement และเพิ่ม Security Requirement เพิ่มเติมเข้าไป

Security Testing สามารถทดสอบอะไรได้บ้าง

• Component : พวก Framework / Lib
• Application : ระบบงานที่ทดสอบ หรือ Runtime
• Business Condition and Logic ของระบบงานที่ทดสอบ

ส่วนมาก Application / Business Condition and Logic มักถูกละเลยกัน

รูปแบบการทำ Security Testing

1. Static Application Security Testing (SAST) : Coding Scanting / Review ใช้คน หรือ Tools จะมองเป้น White Box Security Testing เพราะเป็นการทดสอบที่ต้องเข้าใจโครงสร้าง การทำงานด้านในระบบ
2. Dynamic Application Security Testing (DAST) : มองเป็น Black Box Testing เพราะ ต้อง Run เพื่อตรวจสอบผลลัพธ์
3. Interactive application security Testing (IAST) : ผสมระหว่าง SAST+DAST เช่น การตรวจสอบ code และลอง Input Data ตาม Request

Tool vs Manual

• Tools ช่วยลด Effort และเวลาที่ใช้ โดยสามารถดู Tool ที่มีได้จาก
  • Vulnerability Scanning Tools | OWASP
  • Security Tools Benchmarking (sectooladdict.blogspot.com) (ข้อมูลเก่าปี 2018)
• Tools มันมีข้อจำกัด เพราะมันไม่เข้าใจ Business Logic and constraint ทำให้ต้องมี Manual Test เข้ามาช่วยอุดช่องว่างในส่วนนี้

Tool สำหรับทดสอบ Security Testing แต่ละจุด

- Component

• OWASP Dependency Check
  • ตรวจสอบ Lib กับฐานข้อมูลช่องโหว่ ถ้าตรวจพบต้องดูควรรุนแรง โดยมีหน่วย CVSSv2 หรือ CVSSv3 ที่บอกความรุนแรง เพื่อพิจารณาการแก้ไข
  • สนใจเพิ่มเติม dependency-check – About (jeremylong.github.io)
• snyk.io
  • integrate กับ repository อย่าง github / docker hub ได้
  • ถ้าเป็น Java หรือ Docker File ตรวจสอบ Component ที่เรียกใช้ด้วย ซึ่ง เวลา Run ตามขนาด Project จำนวน Dependency

- Application

• Static Application Security Testing (SAST) มี Tool ที่แนะนำ SonarQube ที่มี Rule ครอบคลุมหลากหลายภาษา และสามารถผูกเชื่อมกับ Flow CI/CD ได้ โดยมีทั้งเวอร์ขัน Community และรุ่นเสียเงินครับ
• Dynamic Application Security Testing (DAST) :
  • OWASP ZAP เป็นตัว Open Source Tool สำหรับผู้ที่สนใจเช้ามาตรวจสอบ Security
  • Burp Suite Professional คล้ายกับ OWASP ZAP แต่ที Feature ที่ดีกว่าครับ ส่วนตัวผมคิดว่าตัว Tool น่าจะมี False Positive น้อยกว่า เพราะเสียเงินครับ อ๋อมีแบบ Community Edition ด้วยนะ
  • DirBuster เอาหา Path ของ Web Application ที่ไม่ได้ควบคุมสิทธิ์ไว้ อย่าง Path เพื่อ Test เป็นต้น แต่เท่าที่ดูตัว Project ใน DirBuster | SourceForge.net มัน Inactive แล้ว แต่มี Repo ใหม่บน GitHub - KajanM/DirBuster
• Manual Test:
  • ให้คนทดสอบ เช่น ลองยิง Request เพื่อดูว่าไฟล์ Config หลุดไหม โดยตัว Tools Burp Suite ช่วยในการ Capture Request/Response
  • การทำ Manual มีแนวทาง Check List เพื่อให้ทดสอบได้ครอบคลุม อาทิ เช่น ใช้ OWASP Top Ten มาอ้างอิง

- Business Condition and Logic

• การตรวจในด้านนี้ ต้องมีความรู้ทั้ง Business + Technical โดยแนวทางการตรวจ อาทิ เช่น
  • Boundary Testing: ตรวจค่าขอบ ค่าว่าง หรือติดลบ เป็นต้น
  • ตรวจ State : ถ้าผ่านกระบวนการตาม Business แล้วสถานะของรายการต้องเป็นอย่างไร
  • Concurrent ทำคนเดียวระบบถูก แต่ถ้าทำพร้อมกันเปิดช่องโหว่ หรือทำให้ State ของระบบผิดได้ เป็นต้น
• Use case เคสที่ทำปกติ / Misuse Case เคสที่ทำผิด โดยให้ดูด้านมันมี Action ให้ที่ทำให้เกิดผลกระทบด้าน
  • Confidential
  • Integrity
  • Availability

• Tool ที่ใช้ อาจจะใช้ส่วนของ Tool ที่ในส่วนของ Dynamic Application Security Testing (DAST) อย่าง Burp Suite + Web Browser Capture Request/Response

Security Vulnerability Test Process

• Issue กำหนดความรุนแรง / เวลาที่ควรได้รับการแก้ไข
• Fix
• Re-Test ด้วย Manual หรือ Tool ก็ได้
• Re-Deploy สอบซ้ำสม่ำเสมอ

Q&A

1. การทำ Security Testing เพียงอย่างเดียว การพัฒนา Software ดูมี Security ที่เพียงพอ หรือไม่ ?
   ANS ไม่เพียงพอ ยังมีปัจจัยอื่นที่ต้องตรวจสอบด้วย
2. เราสามารถใช้ Automate Security Tools เพื่อตรวจสอบระบบเพียงอย่างเดียวได้ไหม
   ANS ขึ้นกับความซับซ้อน ความสำคัญ และข้อกำหนด Policy ที่้เกี่ยวข้อง รวมถึงตัว Tools ต้องมีผู้ใช้ที่เชี่ยวชาญด้วย
3. จำเป็นต้องซื้อ Security Tools หรือไม่ ?
   ANS ต้องดูว่า Open Source มี Feature ที่เพียงพอยัง ตอบโจทย์ของลูกค้า และ Policy ไหม
4. ในเมื่อทำ Security Testing จำเป็นต้องทำ Vulnerability Assessment (VA) หรือ Penetration Test (PT) ไหม
   ANS ขึ้นกับข้อกำหนด Policy ที่้เกี่ยวข้อง และความสำคัญของระบบ ว่าใช้งานภายใน หรือมี User เข้าใช้งานจากภายนอกด้วย เป็นต้น
5. Security Test ควรทำบ่อยแค่ไหน ?
   ANS ตามความเหมาะสม และจำเป็น ถ้ามี Flow Automate CI/CD ภายในองค์กรสามารถทำได้เลย
6. วัดความร้ายแรงของช่องโหว่ได้ยังไง ?
   ANS ดูจากมาตรฐานที่ Tool บอก และผลกระทบกับ Business ในกรณีที่เป็น Issue ที่เกิดจาก Manual Test ใช้วิธีการเทียบเคียงกับเคสตัวอย่างที่ Tool เคยพบ เพื่อมาวัด
7. ตอน Re-Test จำเป็นต้องใช้ Automate Tools ไหม
   ANS ขึ้นกับ Step ในการ Reproduce หากใน Tool ได้ช่วยลด Effort ในการทดสอบได้ แต่มี Cost เข้ามาด้วย

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

Reference

• Burp Suite vs OWASP ZAP - Which is Better? - All About Testing