Secure Coding Awareness Training
เริ่ม!
บทเรียนนี้จะกล่าวถึงช่องโหว่ทางไซเบอร์ 10 อันดับจาก OWASP TOP 10 ปี 2021 โดยผู้เรียนจะต้องทำการศึกษาช่องโหว่ทั้ง 10 อันดับ โดยเรียงลำดับจากอันดับที่ 1 ไปจนถึงอันดับที่ 10
คลิกที่ชื่อช่องโหว่เพื่อทำการเริ่มเรียนเกี่ยวกับช่องโหว่นั้น
ผู้เรียนสามารถปิดเสียงเพลง Background ได้ที่ปุ่มนี้
ถัดไป
OWASP TOP 10 คืออะไร
OWASP หรือ Open Web Application Security Project จัดตั้งโดย OWASP Foundation เป็นองค์กรไม่แสวงหาผลกำไรที่ดูแลด้านความปลอดภัยบนเว็บแอปพลิเคชัน
OWASP TOP 10 คือ 10 อันดับของความเสี่ยงของเว็บแอปพลิเคชัน ที่จัดอันดับโดย OWASP ซึ่งจะมีการจัดอันดับทุก ๆ 4 ปี และเวอร์ชันล่าสุดคือ OWASP TOP 10 - 2021
ไปต่อ
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
01 Broken Access Control
อันดับที่ 1 การควบคุมสิทธิ์ที่ผิดพลาด
01 Broken Access Control
เป็นช่องโหว่ด้านไซเบอร์อย่างหนึ่งที่พบได้ตาม Application ทั่วไปหากไม่มีการกำหนดสิทธิ์และควบคุมการเขาถึงข้อมูลต่างๆให้ดีตัวอย่างเช่น การไม่กำหนดสิทธิ์ Admin/User ให้ชัดเจน ทำให้ผู้ใช้งานทั่วไป
สามารถเข้าถึงหน้าใช้งานของ User อื่น หรือ Admin ได้ ซึ่งแฮกเกอร์อาจใช้ช่องโหว่นี้ในการโจมตี ระบบหรือขโมยข้อมูลสำคัญออกไป โดยอาจ Login เป็น User ปกติ และทำการเข้าถึงหน้าระบบของ Admin เพื่อขโมยข้อมูลสำคัญ
ถัดไป
01 Broken Access Control
Question 01
Broken Access Control หมายถึงอะไร
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การขาดการตรวจสอบข้อมูล Input
การป้องกันการส่งข้อมูลไม่ดีพอ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com
เว็บไซต์นี้มี Role ของ User อยู่ 2 รูปแบบ
1. Normal User
ลอง Log in ด้วย username ที่มีอยู่ ชื่อ user123 ดีกว่า
2. Admin User
ถ้า Log in ด้วยบัญชี User ก็จะสามารถเข้าถึงหน้าของ User ได้เท่านั้น
ถ้า Log in ด้วยบัญชี Admin ก็จะสามารถเข้าถึงหน้าของ Admin ได้
Username
Password
Log in
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com/user123
Normal User Page
user: user123
หลังจากที่ Log in เข้ามาแล้ว จะเห็นได้ว่าเว็บไซต์นี้ใช้ชื่อของ user ที่ Log in ต่อท้ายบน URL เพื่อกำหนดให้ไปยังหน้าของ User นั้น
ดูรายการที่ 1
ดูรายการที่ 2
ดูรายการที่ 3
ทำให้สามารถคาดเดาได้ว่าถ้าเปลี่ยน user123 บน URL เป็นค่าอื่นเช่น admin อาจทำให้สามารถเข้าถึงหน้าของ admin ได้
ย้อนกลับ
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com/admin
Admin Page
Admin
เมื่อลองทำการเปลี่ยนค่า user123 เป็น admin บน URL แล้วทำให้สามารถเข้าถึงหน้าของ Admin ได้
เพิ่ม User
เรียกดูข้อมูล User
ตรวจสอบ User
จะเห็นได้ว่าผู้โจมตีสามารถ Login เข้า User ธรรมดาแล้วสามารถเข้าถึงหน้าของ Admin ได้ นับว่าเป็นช่องโหว่ Broken Access Control
ลบ User
ย้อนกลับ
ถัดไป
01
Question 02
การเข้าถึงสิทธิ์ของ User อื่น ๆ นอกเหนือจาก Admin ถือเป็นช่องโหว่ Broken Access Control
ถูก
ผิด
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
01 Broken Access Control
Java
จากตัวอย่างโค้ดด้านบน จะเห็นได้ว่ามีการ mapped path /admin แต่ไม่มีการตรวจเช็ค
สิทธิ์การเข้าถึงและใช้งานหน้านี้ ทำให้เกิดช่องโหว่ Broken Access Control
ถัดไป
01 Broken Access Control
Java
จากตัวอย่างโค้ดด้านบน จะเห็นได้ว่ามีการ mapped path /admin และมีการตรวจเช็ค
สิทธิ์การเข้าถึงและใช้งานหน้านี้ โดยใช้ @PreAuthorize(hasRole('ADMIN')")
โดยคำสั่งนี้สามารถเรียกใช้งานได้จาก Spring Security ของ Java
ทั้งนี้ เราไม่ควรใช้ path ที่สามารถคาดเดาได้ง่ายเช่น https://www.example.com/admin
เพื่อทำการเข้าถึงหน้า Admin รวมถึงหน้าอื่นๆด้วย
ย้อนกลับ
ถัดไป
01 Broken Access Control
สรุปการป้องกันช่องโหว่ Broken Access Control
1. มีการทำ Authentication ที่ถูกต้อง และสามารถตรวจสอบตัวตนของผู้ใช้งานที่ Log in เข้ามาได้
2. มีการทำ Authorization หรือการกำหนดสิทธิ์หรือ Role ต่างๆให้ User แต่ละประเภท ว่าสามารถทำอะไรกับระบบได้บ้าง
3. มีการทำ Permission Checking หรือทำการตรวจสอบสิทธิ์ก่อนให้เข้าถึงข้อมูลหรือหน้าต่างบนเว็บไซต์บางหน้า เช่นหน้าของ Admin
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
02 Cryptographic Failures
อันดับที่ 2 ความล้มเหลวในการเข้ารหัส
02 Cryptographic Failures
เป็นอีกช่องโหว่ด้านไซเบอร์อย่างหนึ่งของ Application ที่เกิดจาก1. การไม่เข้ารหัสข้อมูลที่มีความสำคัญ 2. ใช้อัลกอริทึมในการเข้ารหัสที่ไม่แข็งแรง 3. การใช้ Protocol ที่ไม่มีการเข้ารหัสข้อมูลในการส่งข้อมูลระหว่าง Client-Server ซึ่งหากข้อมูลเหล่านั้นถูกผู้ไม่หวังดีดักจับไปได้ จะทำให้เกิดการรั่วไหลของข้อมูลซึ่งสร้างผลกระทบในทางที่ไม่ดีได้
ถัดไป
02 Cryptographic Failures
Question 01
Cryptographic Failures หมายถึงอะไร
ใช้อัลกอริทึมที่ไม่ปลอดภัยในการเข้ารหัส หรือการไม่เข้ารหัสข้อมูลที่จัดเก็บไว้
ข้อมูลสำคัญของระบบถูกส่งไปในช่องทางที่ไม่ปลอดภัย
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
WiFi ของร้านกาแฟ
ผู้ใช้งานทำการเชื่อมต่อผิด ไปเชื่อมต่อ WiFi ของโจร
WiFi ของโจร
ตัวอย่างนี้แสดงถึงการที่ผู้ไม่หวังดีปล่อยสัญญาณ WiFi ในที่สาธารณะ เช่นในร้านกาแฟ โดยผู้ไม่หวังดีอาจทำการตั้งชื่อ WiFi ของตัวเองเป็นชื่อ WiFi ร้านกาแฟ เพื่อหลอกล่อเหยื่อให้เชื่อมต่อผิด
ถัดไป
WiFi ของร้านกาแฟ
ผู้ใช้งานเข้าใช้งานเว็บไซต์ด้วย HTTP
WiFi ของโจร
Username
Password
ผู้ไม่หวังดีสามารถดักจับข้อมูลที่เหยื่อส่งไปยังปลายทางได้ ดังนั้นถ้าเหยื่อใช้งาน HTTP ซึ่งเป็น Protocol ที่ไม่มีการเข้ารหัสข้อมูลเพื่อส่งข้อมูล จึงทำให้ผู้ไม่หวังดีสามารถมองเห็นข้อมูลสำคัญที่เหยื่อส่งไปได้ เช่น Username และ Password
ย้อนกลับ
ถัดไป
ตัวอย่างก่อนหน้า แสดงให้เห็นถึงการส่งข้อมูลด้วย Protocol HTTP ซึ่งไม่มีความปลอดภัย ในปัจจุบันจึงมีการแนะนำให้ใช้ HTTPS แทน เพราะมีการเข้ารหัสข้อมูลก่อนที่จะส่ง
นอกเหนือจากการใช้ Protocol ที่มีความปลอดภัยแล้ว ผู้พัฒนาไม่ควรละเลยการเข้ารหัสข้อมูลสำคัญที่จัดเก็บไว้ในฐานข้อมูล รวมถึงควรใช้อัลกอริทึมเข้ารหัสที่มีความแข็งแรงอีกด้วย
อัลกอริทึมเข้ารหัสที่ปลอดภัย เช่น AES, SHA-256, RSA ...
ย้อนกลับ
ถัดไป
จากตัวอย่างโค้ดด้านซ้าย จะเห็นได้ว่า ฟังก์ชัน transmit() ที่ใช้ส่งข้อมูล ไม่มีการเข้ารหัส และส่งข้อมูลออกไปแบบ Plaintext ฟังก์ชัน receive() ที่ใช้รับข้อมูล ก็ไม่มีการถอดรหัสข้อมูลที่ได้รับมา
การส่งและรับข้อมูลแบบ Plaintext ถือว่าไม่ปลอดภัย!
Java
ย้อนกลับ
ถัดไป
แบบนี้สิถึงปลอดภัย
จากโค้ดด้านซ้าย จะเห็นว่า ฟังก์ชัน generateAESKey() ทำการสร้าง secret key 256 bit โดยใช้อัลกอริทึม AES ฟังก์ชัน encrypt() ใช้ข้อความต้นทางและ secret key ในการเข้ารหัสโดยใช้อัลกอริทึม AES และค่า return ที่ได้จะอยู่ในรูปของ Base64-encoded ciphertext ฟังก์ชัน decrypt() ใช้ข้อความที่ถูกเข้ารหัสมาทำการถอดรหัสโดยใช้ secret key และค่า return ที่ได้จะออกมาในรูปของข้อความต้นทาง (Plaintext)
ย้อนกลับ
ถัดไป
Java
02
Question 02
อัลกอริทึมเข้ารหัสใดที่ไม่ปลอดภัย
DES
SHA-256
AES
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
02 Cryptographic Failures
สรุปการป้องกันช่องโหว่ Cryptographic Failures
1. เลือกใช้งาน HTTPS แทนการใช้ HTTP เนื่องจาก Web servers โดยทั่วไปจะสามารถใช้งานได้เหมือนเดิมไม่ว่าจะใช้ HTTP (port 80) หรือ HTTPS (port 443) ดังนั้นจึงควรใช้ HTTPS และต้องแน่ใจว่ามีการบังคับให้ Web servers ยกระดับเป็น secure connection เมื่อมีการทำ Authentication หรือการเชื่อมต่อ session โดยวิธีทั่วไปคือการ set cookies ให้เป็น secure จะทำให้การเชื่อมต่อ session สามารถทำได้ผ่าน HTTPS เท่านั้น
2. เข้ารหัสข้อมูล และใช้งานอัลกอริทึมการเข้ารหัสที่มีประสิทธิภาพใน Application หรือ Website ที่เขียนซึ่งมีอัลกอริทึมมากมายที่ถูกพิสูจน์แล้วว่ามีความปลอดภัย เช่น AES, RSA และ SHA-256 เป็นต้น และหลีกเลี่ยงการใช้งานอัลกอริทึมที่ไม่ปลอดภัย เช่น DES, MD5 และ SHA-1 เป็นต้น โดยในปัจจุบัน ผู้พัฒนาสามารถเลือกใช้งานอัลกอริทึมที่ปลอดภัยเหล่านี้ได้ผ่านการเรียกใช้งานโดยอาศัย libraries, frameworks และ extension ต่างๆ เช่น Java Cryptography Architecture (JCA) และ Java Cryptography Extension (JCE)
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
03 Injection
อันดับที่ 3 การแทรกคำสั่งที่เป็นอันตราย
03 Injection
ช่องโหว่นี้เกิดจากการโจมตีโดยแทรกคำสั่ง (code) เข้าไปที่ Application เป้าหมายด้วยเทคนิคต่างๆ เช่น SQL injection, NoSQL injection, LDAP injection, OS Command injection และอื่นๆ ทั้งนี้ได้มีการนำ Cross-site Scripting (XSS) จาก OWASP TOP 10 - 2017 มาเป็นส่วนหนึ่งของข้อนี้ด้วยช่องโหว่ Injection มักเกิดขึ้นถ้าไม่มีการตรวจสอบข้อมูล Input จาก User
ถัดไป
03 Injection
Question 01
ช่องโหว่ Injection มักเกิดจากข้อใด
การป้องกันการส่งข้อมูลไม่ดีพอ
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การขาดการตรวจสอบและการจัดการข้อมูล Inputs
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
เว็บไซต์นี้มีช่องโหว่ SQL Injection หรือก็คือการแทรกคำสั่ง SQL ลงในช่องกรอกข้อมูล เพื่อให้ระบบทำงานผิดพลาดไปจากที่ควรจะเป็น โดยเกิดจากการนำข้อมูล Input จาก User ไปทำการ Query โดยที่ไม่มีการตรวจสอบและจัดการข้อมูลที่ User กรอกในช่อง Input ข้อมูล เช่น Email และ Password ของเว็บไซต์นี้
ลอง Log in ด้วย Email และ Password ตามนี้
user@email.com
password
Log in
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
จากด้านล่าง หน้าเว็บแสดงให้เห็นว่า Log in ไม่สำเร็จเนื่องจาก Email หรือ Password ที่กรอกนั้นผิด และถ้าหากดูจากการ Query ข้อมูล User เพื่อทำการ Login จากรูปด้านขวามือ จะเห็นได้ว่าระบบรับข้อมูล user@email.com และ password มาทำการ Query
Email หรือ Password ไม่ถูกต้อง
user@email.com
password
Log in
ย้อนกลับ
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
จากด้านล่าง ถ้าหากลองทำการแก้ไขข้อมูลช่อง Password ใหม่ โดยเปลี่ยนจาก password เป็น ' or 1=1-- ลองสังเกตที่การ Query ข้อมูล จะเห็นได้ว่าเมื่อแทรกคำสั่ง SQL ข้างต้นลงไป เมื่อนำไป Query ข้อมูล ทำให้เกิดเงื่อนไข ' ' or 1=1 ซึ่งทำให้เงื่อนไข 1=1 เป็นจริง ระบบจึงไม่สนใจเงื่อนไข ' ' ด้านหน้า or อีกทั้งยังไม่สนใจ LIMIT 1 ด้านหลังด้วย เพราะการใส่ -- ถือเป็นการบอกว่าทุกข้อความหลังจากเครื่องหมาย -- ถือเป็น comment ของภาษา SQL ซึ่งจะไม่ถูกนำมาประมวลผล
user@email.com
' or 1=1--
Log in
ย้อนกลับ
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/user
ผู้ไม่หวังดีสามารถเข้ามาสู่หน้าของ User ที่ใช้ user@email.com เป็นอีเมล์ในการ Log in ได้ โดยที่ไม่จำเป็นต้องรู้รหัสผ่านของ User นี้เลย
Welcome!
User: user@email.com
ย้อนกลับ
ถัดไป
03 Injection
Parameterized queries หรือ Prepared statements
เป็นการประกาศค่า placeholder ให้กับตัวแปรที่จะนำมารับค่า Input จาก User เพื่อให้ระบบมองสิ่งที่ User กรอกมาเป็น Data แทนที่จะถูกมองเป็นคำสั่ง Query หากมีการใส่ Input เป็นคำสั่ง Query ซึ่งจะทำให้คำสั่งที่ป้อนเข้ามา ไม่ถูกนำไปประมวลผล ช่วยป้องกันช่องโหว่ SQL Injection ได้ โดยทั้ง Parameterized queries และ Prepared statements มีความหมายเหมือนกัน
Escaping Inputs
เป็นการปรับเปลี่ยนค่า Input ที่ได้รับจาก User เพื่อให้แน่ใจว่าตัวอักษรบางตัวต้องถูกมองเป็นข้อมูลตามตัวอักษรนั้นแทนที่จะเป็น คำสั่งที่ประมวลผลได้
ย้อนกลับ
ถัดไป
ตัวอย่างของ Parameterized queries/Prepared statements
จากโค้ดด้านซ้าย จะเห็นว่ามีการใช้ placeholder คือ const sqlQuery = 'SELECT * FROM users WHERE username = ?'; ทำให้ข้อมูล username ที่ถูกกรอกจาก User ถูกนำมาใส่เป็นค่าของตัวแปรก่อน แทนที่จะนำไปประมวลผลโดยตรง ทำให้มีความปลอดภัยมากขึ้น
ย้อนกลับ
ถัดไป
JavaScript
ตัวอย่างของ Escaping Inputs
จากโค้ดด้านซ้าย จะเห็นว่ามีการแทนที่เครื่องหมาย ' ด้วย ' ' โดยใช้ Regular Expression ดังนี้ const escapedUsername = username.replace(/'/g, "' '"); หรือก็คือใช้เครื่องหมาย ' ติดกันสองตัว (ไม่ใช่เครื่องหมาย ") ในภาษา JavaScript การใช้เครื่องหมาย ' ติดกันสองตัว เทียบเท่ากับ การใช้เครื่องหมาย ' เพียงตัวเดียว ซึ่งทำให้ผลลัพธ์จากการประมวลผลไม่ผิดไปจากเดิม แต่สามารถช่วยป้องกันการกรอกข้อมูล Input ที่ใส่เครื่องหมาย ' เข้ามา ไม่ให้ข้อมูลนั้นถูกมองว่าเป็นคำสั่ง แต่จะถูกมองเป็นข้อมูลทั่วไปแทน
JavaScript
ย้อนกลับ
ถัดไป
03
Question 02
ข้อใดเป็นวิธีการป้องกันช่องโหว่ Injection
Escaping Inputs
Encryption
Authentication
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
03 Injection
สรุปการป้องกันช่องโหว่ Injection เบื้องต้น
การป้องกันช่องโหว่นี้ สามารถทำได้หลายวิธี เช่นการใช้ Parameterized queries หรือ Prepared statements, การใช้ Escape input ตามที่ได้แสดงตัวอย่างให้เห็นก่อนหน้านี้ นอกจากนี้ยังมีวิธีอื่นๆที่สามารถใช้เพื่อป้องกันช่องโหว่ Injection อีกหลายวิธี เช่น การใช้ Object Relational Mapping (ORM) และ การ Sanitizing Input เป็นต้น ช่องโหว่นี้เคยเป็นช่องโหว่ที่ถูกจัดเป็นอันดับที่ 1 ของ OWASP TOP 10 - 2017 แต่ในปี 2021 ถูกจัดไว้ที่อันดับที่ 3 ซึ่งก็ยังถือว่าเป็นช่องโหว่ที่พบได้บ่อยและผู้พัฒนาควรคำนึงถึงช่องโหว่นี้เสมอ เมื่อเขียนโปรแกรมที่มีการรับค่า Input จาก User
ตัวอย่างที่แสดงและวิธีการป้องกัน มีเพียง SQL Injection ซึ่งเป็นส่วนหนึ่งของช่องโหว่ Injection เท่านั้น โดยยังมีช่องโหว่ Injection อื่น ๆ อีกมากมาย เช่น Cross-Site Scripting (XSS) (เกี่ยวข้องกับการขโมย session cookies), Command Injection, LDAP Injection, XML Injection และ Path Traversal ผู้เรียนสามารถไปศึกษาเพิ่มเติมเกี่ยวกับช่องโหว่ Injection เหล่านี้ได้
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
04 Insecure Design
อันดับที่ 4 การออกแบบที่ไม่ปลอดภัย
04 Insecure Design
เป็นช่องโหว่การออกแบบสถาปัตยกรรมของระบบที่ผิดพลาด โดยช่องโหว่นี้เป็นช่องโหว่ใหม่ที่เพิ่มเข้ามา ไม่เคยถูกจัดอันดับติด 10 อันดับแรกมาก่อน ซึ่งไม่ใช่ปัญหาที่เกิดจากการเขียนโปรแกรมที่ผิดพลาดโดยตรง แต่เป็นปัญหาที่มักเกิดจากการที่ผู้พัฒนาไม่ได้คำนึงถึงมุมมองด้านความปลอดภัยของระบบในขั้นตอนการออกแบบระบบ รวมไปจนถึงรูปแบบวงจรชีวิตการพัฒนา หรือ Software Development Life Cycle (SDLC) ที่การคำนึงด้านความปลอดภัย
ถัดไป
04 Insecure Design
04
Question 01
Insecure Design หมายถึงอะไร
ปัญหาที่เกิดจากการออกแบบและวางแผนการพัฒนาระบบที่ไม่ดี
ปัญหาของการพัฒนาระบบแบบ Water Fall
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างกรณีการเกิดช่องโหว่เนื่องจากการออกแบบที่ไม่ดี
1. เก็บข้อมูล Secret ใดๆ เช่น API Key, Private Key ไว้ที่ Client แม้ว่าจะมีการเข้ารหัสไว้แน่นหนาก็ตาม ควรเลือกไปเก็บบน Server แทน หากเป็นไปได้
2. การอนุญาตให้แก้ไขข้อมูลสำคัญเช่น Email โดยไม่ได้ถาม Password ก่อน ทำให้บุคคลอื่นสามารถกด Forgot Password เพื่อตั้งค่ารหัสผ่านใหม่ได้ทันทีที่เซ็ต Email ใหม่ได้
3. ใช้ระบบคำถามลืมรหัสผ่านที่ง่ายเกินไป เช่น วันเดือนปีเกิด ในการเข้าสู่ระบบเมื่อจำรหัสผ่านไม่ได้
4. การไม่กำหนดขนาดของ Input ที่ชัดเจน ทำให้อาจเกิดปัญหา Buffer Overflows (การเขียนข้อมูลไปยังบัฟเฟอร์เกินหน่วยความจำที่มีอยู่ของบัฟเฟอร์)
5. การใช้ API หรือฟังก์ชันที่มีช่องโหว่ เนื่องจากขาดการตรวจสอบความปลอดภัยของ API นั้น
ยังมีช่องโหว่อีกมากมายที่มักเกิดจากการออกแบบระบบที่ไม่ดี ทั้งหมดข้างต้นเป็นเพียงตัวอย่างเท่านั้น!
ถัดไป
วงจรชีวิตการพัฒนาซอฟต์แวร์ Software Development Life Cycle (SDLC)
1.วางแผน
6.บำรุงรักษา
2.ออกแบบ
โดยปกติแล้วผู้พัฒนาจะพบว่าระบบมีช่องโหว่ในขั้นตอนทดสอบ
5.ใช้งาน
3.ดำเนินการ
4.ทดสอบ
ย้อนกลับ
ถัดไป
Shift Left Mentality in SDLC
คือการนำหลักการของการรักษาความปลอดภัยไซเบอร์มาใช้ตั้งแต่การเริ่มออกแบบการพัฒนาระบบ เพื่อให้ผู้พัฒนาสามารถรู้และแก้ไขช่องโหว่ที่มีในระหว่างการพัฒนาได้เร็วขึ้น เช่น 1. การตรวจสอบ API ที่จะนำมาใช้ว่ามีความปลอดภัยหรือไม่ก่อนนำมาใช้งาน 2. การเลือกเก็บ API Key ไว้บน Server แทน Client 3. วางแผนให้มีการตรวจสอบตัวตนก่อนอนุญาตแก้ไขข้อมูลสำคัญ 4. การออกแบบรูปแบบของข้อมูล Input จาก User ว่าไม่ควรมีขนาดเกินเท่าไร เพื่อป้องกัน Buffer Overflows และให้ระบบทำงานได้ตามที่ต้องการ
การพัฒนาซอฟต์แวร์ในยุคปัจจุบัน หลาย ๆ องค์กรเริ่มนำหลักการ DevSecOps เข้ามาใช้งาน คือการขยับจากการที่ผู้พัฒนาจะรู้ช่องโหว่ของระบบในขั้นตอนทดสอบ ให้ผู้พัฒนารู้ถึงช่องโหว่ที่ต้องแก้ไขเร็วขึ้น เช่นรับรู้และแก้ไขตั้งแต่ขั้นตอนดำเนินการและการออกแบบ
ย้อนกลับ
ถัดไป
04
Question 03
Shift Left Mentality in SDLC คืออะไร
การออกแบบการทำงานของระบบให้มีความปลอดภัยมากขึ้น
การปรับลักษณะการพัฒนาระบบให้มีการทดสอบความปลอดภัยที่รัดกุมยิ่งขึ้น
การปรับลักษณะการพัฒนาระบบให้ผู้พัฒนารู้ถึงช่องโหว่ที่ต้องแก้ไขได้เร็วขึ้น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
04 Insecure Design
สรุปการป้องกันเรื่อง Insecure Design
1. การพัฒนาซอฟต์แวร์ใด ๆ ควรมีการคำนึงถึงความปลอดภัยของระบบเสมอ รวมถึงควรนับเป็น Requirements อย่างหนึ่งในการพัฒนาซอฟต์แวร์ด้วย นอกเหนือจาก Requirements ด้านธุรกิจและการใช้งานทั่วไป 2. ควรมีการนำหลักการ Shift Left Mentality in SDLC มาใช้งาน เพื่อให้การพัฒนาซอฟต์แวร์มีความปลอดภัยมากขึ้น และลดปัญหาการแก้ไข Source code ที่เขียนในขั้นตอนการทดสอบลง
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
05 Security Misconfiguration
อันดับที่ 5 การตั้งค่าความปลอดภัยที่ไม่ถูกต้อง
05 Security Misconfiguration
ช่องโหว่เกี่ยวกับการตั้งค่าความมั่นคงปลอดภัย โดยสามารถเกิดได้ทุกที่ในระบบ ซึ่งสาเหตุหลักเกิดจากการตั้งค่าไม่ดี ทำให้เกิด Attack Surface หรือช่องทางการโจมตีระบบ โดยทุก ๆ ระบบสามารถเกิดการตั้งค่าความปลอดภัยที่ไม่ถูกต้องขึ้นได้ ตัวอย่างเช่น 1. การใช้ Username และ Password ที่ติดตั้งมาพร้อมกับตัวอุปกรณ์ ทำให้ผู้ไม่หวังดีสามารถเข้ามาภายในระบบได้โดยที่ไม่ต้องทำการเจาะระบบอะไรเลย เนื่องจากรู้ Username และ Password ตั้งต้นของอุปกรณ์นั้น ๆ อยู่แล้ว 2. ไม่ทำการปิด Config บางอย่างที่ใช้ในขั้นตอนการพัฒนาก่อนนำขึ้น Production ทำให้มีข้อมูลบางอย่างหลุดไปอยู่บน Production ได้
ถัดไป
05 Security Misconfiguration
Question 01
Security Misconfiguration หมายถึงอะไร
การตั้งค่าระบบมีความไม่เสถียร
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การตั้งค่าระบบบางอย่างทำให้เกิดช่องโหว่ขึ้น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
05 Security Misconfiguration
สรุปการป้องกันเรื่อง Security Misconfiguration เบื้องต้น
1. ตรวจสอบ Software Components ใหม่ที่จะใช้และแก้ไขข้อมูลละเอียดอ่อนที่เป็นค่าเริ่มต้นให้เป็นค่าอื่นที่คาดเดาได้ยากโดยเร็วที่สุด 2. ทำการแยก Environment ของ Codebase และ ไฟล์หรือค่า Configuration ต่าง ๆ ออกจากกันอย่างชัดเจน เนื่องจากข้อมูลสำคัญในค่า Configuration ไม่ควรอยู่รวมกันกับ Source code 3. สร้างบัญชีสำหรับจัดการระบบบน Production โดยใช้หลัก Least Privilege หรือคือการให้สิทธิ์ในการกระทำต่าง ๆ บนระบบเท่าที่จำเป็นเท่านั้น
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
06 Vulnerable and Outdated Components
อันดับที่ 6 การใช้งานส่วนประกอบของซอฟต์แวร์เก่าหรือมีช่องโหว่
06 Vulnerable and Outdated Components
เป็นช่องโหว่ที่เกิดจากการใช้งาน Software Components ที่มีช่องโหว่ หรือใช้งาน Software Components เวอร์ชันเก่าที่มีช่องโหว่ ถือเป็นปัญหาที่พบเจอได้ทั่วไปในการพัฒนาซอฟต์แวร์ ตัวอย่างเช่น 1. การเลือก Software Components ที่ต้องการนำมาใช้งานโดยไม่ตรวจสอบให้แน่ใจว่า Software Components นั้น ๆ มีช่องโหว่อะไรหรือไม่ เมื่อ Software Components นั้น ๆ มีช่องโหว่ ทำให้ผู้ไม่หวังดีสามารถใช้ประโยชน์จากช่องโหว่นั้น ๆ ได้ 2. การใช้งาน Software Components เวอร์ชันเดิม โดยไม่มีการอัปเดตเพื่อป้องกันช่องโหว่ที่ถูกพบในเวอร์ชันเดิม ซึ่งในบางครั้งเมื่อมีการตรวจพบช่องโหว่ ทางผู้พัฒนาของ Software Components นั้น ๆ จะต้องออกแพทช์เพื่ออัปเดตและแก้ไขช่องโหว่ที่พบ การที่เราไม่อัปเดตตาม ทำให้ผู้ไม่หวังดีสามารถโจมตีโดยอาศัยช่องโหว่ที่ถูกประกาศออกมาจากทางผู้พัฒนา Software Components นั้น ๆ ได้
ถัดไป
06 Vulnerable and Outdated Components
Question 01
ข้อใดมักเป็นสาเหตุที่ทำให้เกิดความเสี่ยงด้าน Vulnerable and Outdated Components
การใช้งาน Libraries โดยไม่ได้ตรวจสอบก่อนว่ามีช่องโหว่หรือไม่
การใช้งาน Framework เวอร์ชันเก่า
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
06 Vulnerable and Outdated Components
สรุปการป้องกันเรื่อง Vulnerable and Outdated Components
1. ตรวจสอบ Software Components ใหม่ที่จะใช้ว่ามีช่องโหว่อะไรหรือไม่ ถ้าหากพบว่ามีช่องโหว่ อาจต้องเลือกใช้ Software Components ตัวอื่น ๆ แทน 2. Software Components ใหม่ที่จะเลือกใช้ ควรเป็นเวอร์ชันล่าสุด และมีการพัฒนาอยู่ ไม่ควรเลือกใช้ Software Components ที่หยุดพัฒนาไปแล้ว 3. หมั่นตรวจสอบ Software Components ต่าง ๆ ที่ใช้งานอยู่ ว่ามีการอัปเดทเวอร์ชันใหม่บ้างหรือไม่ หากมีการอัปเดทเพื่อแก้ไขปัญหาด้าน Security ควรรีบทำการอัปเดทใหม่โดยเร็วที่สุด
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
07 Identification and Authentication Failures
อันดับที่ 7 ความล้มเหลวในการระบุและการตรวจสอบตัวตน
07 Identification and Authentication Failures
ช่องโหว่นี้เกิดจากฟังก์ชันของ Application ที่เกี่ยวข้องกับการทำ Authentication และการจัดการ Session ที่ไม่ถูกต้อง ทำให้ผู้โจมตีสามารถใช้ประโยชน์จากช่องโหว่นี้ในการสวมรอยเป็นผู้ใช้งานอื่น ทั้งชั่วคราวและถาวร โดยในหัวข้อนี้จะอธิบายถึงการป้องกัน User Enumeration ไปจนถึงการจัดการ Password และ การป้องกัน Privilege Escalation
ถัดไป
07 Identification and Authentication Failures
07
Question 01
ช่องโหว่ Identification and Authentication Failures หมายถึงอะไร
การถูกผู้โจมตีสวมรอยเป็นผู้ใช้งานอื่นได้
การถูกผู้โจมตีทำให้ระบบใช้งานไม่ได้
ผิดทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
User Enumeration
เป็นเทคนิคอย่างหนึ่งที่ผู้โจมตีมักใช้เพื่อให้สามารถระบุได้ว่ามีชื่อผู้ใช้อะไรอยู่ในระบบ ซึ่งถ้าผู้โจมตีสามารถรู้ถึงชื่อผู้ใช้ต่าง ๆ ของระบบก็หมายถึงการที่ผู้โจมตีมีข้อมูลที่จำเป็นครึ่งหนึ่งแล้วในการเข้าสู่ระบบเพื่อสวมรอยเป็นผู้ใช้งานอื่น
หากผู้โจมตีรู้ถึง Username แล้ว การคาดเดา Password สามารถทำได้หลากหลายวิธี เช่นการใช้ Brute-Force Attack ในการคาดเดา Password หรือหาก Username ที่ใช้เข้าสู่ระบบเป็น Email ผู้โจมตีก็สามารถส่ง Email ล่อลวง (Social Engineering) เพื่อให้ผู้ใช้งานหลงกลและบอกรหัสผ่านให้ได้
ดังนั้น การปกปิดชื่อ Username ของผู้ใช้งานระบบให้ดี จึงเป็นสิ่งที่ควรกระทำ และควรคำนึงถึงเสมอ
ถัดไป
User Enumeration
ผู้โจมตีอาจใช้ลักษณะการทำงานของระบบเพื่อหาข้อมูลเกี่ยวกับชื่อผู้ใช้งาน (Username) ของผู้ใช้งานได้ ตัวอย่างเช่น 1. หากกรอกชื่อ Username ผิดในขั้นตอนการ Authentication แล้วระบบแจ้งเตือนว่า Username ผิด ก็จะทำให้ผู้โจมตีรู้ได้ว่า Username นั้นไม่มีอยู่ในระบบ และในทางกลับกัน หากระบบแจ้งว่า Password ผิด นั่นหมายความว่า Username นั้นมีอยู่ในระบบ 2. ระบบ Reset Password อาจให้มีการกรอก Username ที่ต้องการ Reset Password ซึ่งถ้ากรอก Username ที่ไม่มีอยู่ลงไปแล้วระบบแจ้งว่า ไม่พบ Username นี้ ก็จะทำให้รู้ได้ว่าไม่มี Username นี้ และในทางกลับกันหากพบ Username ที่กรอกแล้วแจ้งว่าส่ง Email สำหรับ Reset Password ไปให้แล้ว นั่นหมายความว่ามี Username นั้นในระบบ 3. ระบบ Registration ก็เช่นกัน หากในขั้นตอนการสมัครสมาชิกระบบมีการแจ้งว่า Username ที่ใช้นั้นมีผู้อื่นใช้ไปแล้ว ก็จะทำให้รู้ได้ว่ามี Username นั้น ๆ อยู่ในระบบ
ระบบบอกว่าไม่มีชื่อ David ถ้างั้นลองชื่ออื่น ระบบน่าจะบอกว่า Password ผิดแทน ถ้าเดา Username ถูก
https://www.example.com/login
ถัดไป
Log in failed! Username is incorrect
David
ย้อนกลับ
********
Log in
การป้องกัน User Enumeration
1. ขั้นตอน Authentication ของระบบ ควรแจ้งว่า Username หรือ Password ไม่ถูกต้องแทนการแจ้งว่าข้อมูลส่วนไหนผิด เมื่อมีการ Log in ไม่สำเร็จ 2. ขั้นตอน Reset Password ไม่ควรแสดงชื่อ Username เลย ถึงแม้ Email หรือ Username ที่กรอก จะมีอยู่ในระบบหรือไม่ก็ตาม เช่น แจ้งว่าได้ส่ง Email สำหรับเปลี่ยนรหัสผ่านไปยัง Email แล้ว และทำการส่ง Email สำหรับเปลี่ยนรหัสผ่านไปยัง Email ของผู้ใช้ ถ้ามีอยู่จริง และไม่ต้องส่ง ถ้าไม่มีอยู่จริง 3. ขั้นตอน Registration ก็ไม่ควรมีการแสดงชื่อ Username และบอกว่ามี Username นี้แล้วหรือไม่เช่นกัน
นอกจากนี้ ควรจัดการระยะเวลาของ HTTP Response และระยะเวลาในการแสดงผลว่า Log in สำเร็จหรือไม่ ให้มีระยะเวลาเท่า ๆ กัน ทั้งแบบที่ Username ถูกแต่ Password ผิด และ แบบ Username และ Password ผิดทั้งคู่ เพื่อปกปิดระยะเวลาใน Query Username และ Password
ย้อนกลับ
ถัดไป
07
Question 02
เพราะเหตุใดช่องโหว่ User Enumeration ถึงมีความอันตราย
ทำให้ Password รั่วไหล
เป็นการเปิดช่องให้ผู้โจมตีอัปโหลดไวรัส
เป็นการเปิดช่องให้ผู้โจมตีทำการโจมตีด้วย Brute-Force Attack กับ Password
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
Password Management
การจัดการ Password ที่ดี ถือเป็นหนึ่งในปัจจัยหลักของการทำระบบ Authentication แต่หลาย ๆ Application ยังคงจัดการได้ไม่ดี
เมื่อคำนึงถึงการทำ Authentication อย่างแรกที่ควรคำนึงถึงคือ เราจะเป็นต้องสร้างระบบ Authentication เองหรือไม่?
เนื่องจากในปัจจุบัน มีการใช้งาน Account ของ Google, Facebook, Github และอื่น ๆ ในการทำ Authentication
โดยบริษัทเหล่านี้ต่างมี OAuth Implementations ให้ใช้งาน ซึ่งปลอดภัยและน่าเชื่อถือ อีกทั้งยังช่วยลดเวลาในการพัฒนาลงเนื่องจากผู้พัฒนาไม่จำเป็นต้องสร้างระบบ Authentication เอง
ถ้าหากผู้พัฒนาจำเป็นต้องพัฒนาระบบ Authentication เอง จะมีวิธีการจัดการ Password ยังไงบ้าง?
อย่างไรก็ตาม การใช้ Social Media Authentication อาจไม่ใช่วิธีที่เหมาะสมสำหรับทุก Application
ถัดไป
Password Management
หากต้องพัฒนาระบบ Authentication เอง สิ่งแรกที่ต้องนึกถึงคือกฏบังคับเรื่องความยากของ Password เพื่อเพิ่มความยากในการคาดเดา เช่นการบังคับให้ 1. Password ที่ยอมรับได้ต้องมีความยาวอย่างน้อย 8 ตัวอักษร
2. ต้องมีตัวพิมพ์ใหญ่, ตัวพิมพ์เล็ก, ตัวเลข และ ตัวอักษรพิเศษ
ถัดมาคือ ข้อควรระวังในการจัดการ Password
การบังคับให้ใช้ Password ที่ยากต่อการคาดเดามากๆ ทำให้ยากต่อการจำของผู้ใช้งานด้วย ส่งผลให้ผู้ใช้งานส่วนใหญ่
อาจเพียงแค่ใช้ตัวพิมพ์ใหญ่แค่ตัวอักษรตัวแรก รวมถึงใส่ตัวเลขและตัวอักษรพิเศษต่อท้ายเท่านั้น และที่แย่กว่านั้นคือการที่ Password ยากมากๆ ทำให้ผู้ใช้งานบางคนอาจจด Password ของตัวเองไว้บนกระดาษหรือโน๊ตในโทรศัพท์ ซึ่งทำให้เกิดความไม่ปลอดภัยมากกว่าเดิม รวมไปจนถึงกฏการ Reset Password ที่บาง Application บังคับห้ามใช้ Password ที่เคยใช้ จุดประสงค์ถือว่าดี แต่ในทางกลับกัน ผู้ใช้งานมักใช้วิธีการใส่ตัวเลขต่อท้าย Password เดิมแทน ซึ่งไม่ได้ช่วยให้มีความปลอดภัยมากขึ้นสักเท่าไหร่
ถัดไป
ย้อนกลับ
การออกแบบระบบ Authentication และ Password Management ที่ดี
1. ควรมีการบังคับให้ใช้ Password ที่มีความยากต่อการคาดเดา แต่ไม่ควรบังคับด้วยกฏที่มากจนเกินไป ทั้งนี้ขึ้นกับรูปแบบของแต่ละ Application
ว่าควรออกแบบอย่างไร เช่น ควรมีการบังคับเรื่องการเปลี่ยน Password ไม่ให้ใช้ซ้ำย้อนหลังไปได้กี่ครั้ง 2. ระบบ Reset Password
ควรใช้วิธีส่ง link สำหรับ reset password ไปยัง Email ของผู้ใช้งาน โดย link นั้นต้องมีระยะเวลาหมดอายุ เพื่อป้องกันหาก
ผู้โจมตีสามารถเข้าถึง Email ของผู้ใช้งานได้ ก็จะทำให้ reset password ของผู้ใช้งานของ Application เราไม่ได้ถ้า link
นั้นหมดอายุไปแล้ว 3. จำกัดจำนวนครั้งในการ Log in ที่ผิดพลาดก็เป็นสิ่งที่ควรนำมาใช้กับระบบ Authentication เพื่อป้องกันการสุ่มเดา
Password ไปเรื่อย ๆ หลาย ๆ ครั้ง (Brute-Force Attack) 4. มีการทำ Session Timeout หาก Log in ทิ้งไว้นานโดยไม่มีการใช้งาน 5. เลือกใช้ HTTPS และ mark cookies เป็น "Secure" เพื่อป้องกันการดักจับข้อมูลระหว่างการส่งข้อมูล เช่น การส่ง password ในขั้นตอน Authentication 6. การจัดเก็บ Passsword
ไม่ควรจัดเก็บ Password ในรูปของ Plaintext ควรใช้อัลกอริทึม one-way hashing เพื่อเข้ารหัส Password ที่จัดเก็บไว้เสมอ (one-way hashing เป็นอัลกอริทึมเข้ารหัสทางเดียว ที่ไม่สามารถถอดกลับมาเป็นข้อความต้นทางได้)
เพื่อป้องกันหาก database ถูก hack รวมถึงการใส่ค่า Salt เพิ่มเข้าไปในขั้นตอนการ hash ด้วย
(Salt คือค่า random ที่มักถูกใช้เพิ่มเข้าไปในการทำ hashing password เพื่อป้องกันการโจมตีด้วย dictionary attack และ rainbow table attack)
ย้อนกลับ
ถัดไป
07
Question 03
Password Hashing คืออะไร
อัลกอริทึมการเข้ารหัสทางเดียว ใช้เพื่อเข้ารหัสและเก็บค่า hash ไว้แทนการเก็บค่า password โดยตรง
อัลกอริทึมการเข้ารหัสทางเดียว ใช้เพื่อเข้ารหัสระหว่างส่งข้อมูลระหว่าง Client-Server
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
Privilege Escalation
คือการโจมตีอีกรูปแบบของช่องโหว่ Identitification and Authentication Failures โดยคือ การที่ผู้โจมตีสามารถหลอกระบบเพื่อให้ระบบมอบสิทธิ์หรือการเข้าถึงข้อมูลของ User อื่น ในบริบทของเว็บไซต์ การเพิ่มระดับสิทธิ์อาจเกิดขึ้นเมื่อเซิร์ฟเวอร์ทำการตัดสินใจในการควบคุมการเข้าถึงโดยอิงตาม Input ที่ไม่น่าเชื่อถือที่ return โดยเบราว์เซอร์
ถัดไป
Privilege Escalation
มาดูวิธีการที่ผู้โจมตีอาจใช้ HTTP request เพื่อทำการยกระดับสิทธิ์ เมื่อ User Login เข้าสู่เว็บไซต์ จะเกิดการสร้าง Session โดย Browser กับ Server จะแลกเปลี่ยน Session Identifier กัน เพื่อให้ Server รู้ว่ากำลังติดต่ออยู่กับใครผ่าน HTTP request โดยทั่วไป Session State จะถูกส่งผ่านไปยัง Browser ใน Set-Cookie header HTTP request และ Browser จะส่งคืนข้อมูลเดิมกลับมาที่ Cookie header อย่างไรก็ตาม Cookies ถือเป็น Input ที่ไม่น่าเชื่อถือ ผู้โจมตีสามารถแก้ไขค่าของ Cookie ที่ return ได้อย่างง่ายดาย เว้นแต่จะมีการทำการป้องกันการปลอมแปลง Cookie
Note: เมื่อผู้โจมตีสามารถสวมรอยเป็น User อื่นได้ จะเรียกการยกระดับสิทธิ์ที่เป็นการเข้าถึง User อื่นในระดับเดียวกันนี้ว่า Horizontal Escalation
ผู้โจมตีสามารถแก้ไขค่า user_id ให้เป็นค่าอื่นได้ ทำให้สามารถปลอมแปลงหรือสวมรอยเป็น User อื่นได้
ย้อนกลับ
ถัดไป
Privilege Escalation
อีกหนึ่งวิธีที่ใช้ส่ง State ระหว่าง Client-Server คือการใช้ HTML forms โดย User เป็นคน submit form และ POST request จะถูกส่งไปยัง Server ซึ่งค่าที่ทำการส่งผ่าน HTML forms ก็สามารถถูกปลอมแปลงหรือแก้ไขได้เช่นกัน ดังนั้นเราจึงควรมองข้อมูลที่ได้รับจาก forms เป็นข้อมูลที่ไม่น่าเชื่อถือด้วย จนกว่าเราจะสามารถตรวจสอบให้แน่ชัดได้ว่าข้อมูลที่ส่งเข้ามาไม่เป็นอันตราย ตัวอย่างเช่นการเขียน HTML form ให้ระบุถึงข้อมูลการเข้าถึงภายใน hidden form field ดังภาพ
Note: เมื่อผู้โจมตีสามารถสวมรอยเป็น Admin ได้ จะเรียกการยกระดับสิทธิ์ที่เป็นการเข้าถึงสิทธิ์ที่สูงกว่าเดิมนี้ว่า Vertical Escalation
ภายใน hidden form field มีการแสดงถึง role ที่เป็น user ถ้าหากผู้โจมตีทำการแก้ไขค่า value จาก "user" เป็น "admin" ก็อาจทำให้สามาถเข้าถึงสิทธิ์ Admin ได้
ย้อนกลับ
ถัดไป
07
Question 04
Vertical Escalation คืออะไร
การยกระดับสิทธิ์ที่เป็นการเข้าถึง User อื่นในระดับเดียวกัน
การยกระดับสิทธิ์ที่เป็นการเข้าถึงสิทธิ์ที่สูงกว่าเดิม
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Privilege Escalation
1. ไม่ควรตัดสินการให้การเข้าถึงต่าง ๆ โดยอิงจากข้อมูลที่ไม่น่าเชื่อถือ (เช่นข้อมูล Cookies และ ข้อมูล Input จาก HTML forms) 2. ควรจัดเก็บ Session State ไว้ที่ฝั่ง Server 3. ควรมีการตรวจสอบให้แน่ใจว่า Cookies มีการป้องกันการปลอมแปลงโดยใช้ Digital Signature (ในปัจจุบัน หลาย ๆ frameworks สามารถเข้ารหัส Session State ด้วย Digital Signature ได้) 4. ไม่ควรส่งข้อมูลที่สำคัญไปยังฝั่ง Client หากไม่จำเป็นจริง ๆ
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
08 Software and Data Integrity Failures
อันดับที่ 8 ความล้มเหลวของซอฟต์แวร์และความถูกต้องของข้อมูล
08 Software and Data Integrity Failures
ช่องโหว่นี้เป็นช่องโหว่ที่ถูกเพิ่มเข้ามาใหม่ใน 2021 เนื่องจากในปัจจุบัน มีการใช้งาน CI/CD pipelines ที่แพร่หลาย โดยช่องโหว่นี้เป็นช่องโหว่ของการติดตั้ง software หรือการถูกสอดแทรก Code บางอย่างมารันตอน integration โดยไม่ได้ตั้งใจ ซึ่งจะโฟกัสไปที่ CI/CD pipelines ที่สามารถใส่คำสั่ง (code) เพื่อทำการควบคุมทั้งระบบได้ ซึ่งในหลายๆ Application ได้ทำ Auto Update Function ไว้แต่ไม่มีการตรวจสอบความถูกต้องของ Function ทำให้ผู้โจมตีสามารถอัพโหลด Code สำหรับอัพเดทขึ้นไปเพื่อรันทั้งแอพพลิเคชันได้
ถัดไป
CI/CD Pipelines คืออะไร
CI/CD คือ กระบวนการหนึ่งที่ช่วยในการพัฒนา Software ให้มีประสิทธิภาพมากขึ้น โดยช่วยลดระยะเวลาและเพิ่มคุณภาพในการพัฒนา Application
CI หมายถึง Continuous Integration คือกระบวนการที่จัดการ Source Code ของเราให้ผ่านกระบวนการการ Testing, Building เพื่อให้แน่ใจว่า Source Code สามารถใช้งานได้จริง ไม่มีข้อผิดพลาด
CD ย่อมาจาก Continuous Deployment คือกระบวนการที่ช่วยเหลือให้เราสามารถ Deploy Software ของเราได้อย่างมีประสิทธิภาพ โดยการนำ Source Code ที่ผ่านการ Build และ Testing มาแล้ว ซึ่งอาจอยู่ในรูปแบบที่แตกต่างกัน เช่น JAR file, Static file หรือแม้กระทั่ง Container Image ให้จัดการ Deploy ขึ้นไปอยู่บน Server ตามที่เราต้องการและสามารถใช้งานได้อย่างถูกต้อง
ย้อนกลับ
ถัดไป
ช่องโหว่ที่มักเกิดขึ้น
Note: checksums คือข้อมูลขนาดคงที่ ที่ถูกคำนวณขึ้นจากกลุ่มข้อมูลดิจิทัลที่ถูกเลือกมาโดยเจตนา โดยมีเพื่อประโยชน์ในการหาข้อผิดพลาดที่อาจเกิดขึ้นได้ระหว่างการรับส่งหรือการจัดเก็บข้อมูล
1. การ Upgrade Software โดยไม่ตรวจสอบความเข้ากันได้ของ Software 2. การทำ CI/CD Pipelines ที่ไม่ได้มีการทดสอบการทำงานร่วมกัน หรือปล่อยให้คนนอกเข้าถึงได้ 3. ไม่ได้ทำการตรวจสอบ Digital Signature เวลาลง Software ใดๆ ว่ามาจากต้นทางตัวจริง 4. ไม่มีการใช้ checksums เพื่อตรวจสอบความสมบูรณ์ของข้อมูล
ย้อนกลับ
ถัดไป
08 Software and Data Integrity Failures
08
Question 01
ข้อใดถือเป็นช่องโหว่ Software and Data Integrity Failures
การทำ CI/CD Pipelines ที่ไม่ได้มีการทดสอบการทำงานร่วมกัน
การทำ CI/CD Piplines ที่มีกำหนดสิทธิ์ผู้ที่เข้าถึงได้
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Software and Data Integrity Failures
1. ไม่ใช้ Software ที่ Version ยังไม่ Stable 2. ใช้งาน Software Repository ที่เชื่อถือได้เท่านั้น 3. มีการ Review กระบวนการ CI/CD และการเปลี่ยน configuration ให้สิทธิ์เฉพาะบุคคลที่ควรเข้าถึงได้เท่านั้น เพื่อป้องกันการแทรก Code ที่เป็นอันตรายเข้ามาโดยผู้โจมตี 4. checksum hashes file ที่ Download มาทุกครั้งก่อน Install
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
09 Security Logging and Monitoring Failures
อันดับที่ 9 ความล้มเหลวของการทำบันทึกเหตุการณ์และการเฝ้าระวัง
09 Security Logging and Monitoring Failures
ช่องโหว่นี้เป็นช่องโหว่ที่เกิดจากการ Monitor logs ที่ไม่เหมาะสม ไม่มีการเก็บ log ของ API และข้อมูล Log ถูกจัดเก็บไว้ในที่จัดเก็บข้อมูลของเครื่องเท่านั้นโดยตัว Application ไม่มีการ log แบบ real time ทำให้ไม่สามารถตรวจสอบและแจ้งเตือนการโจมตีได้ในขณะที่ใช้งานได้ การจัดทำ Log Server เพื่อใช้เก็บ Log หรือบันทึกเหตุการณ์ที่เกิดขึ้นจึงเป็นสิ่งที่ควรกระทำ โดยเฉพาะ Log ที่เกี่ยวข้องกับด้าน Security โดย Log Server มีหน้าที่รวมศูนย์และจัดเก็บไฟล์ log จากแหล่งต่างๆเพื่อให้สามารถดูได้ในที่เดียว แต่ไม่ได้มีหน้าที่ตรวจสอบเครือข่ายหรือระบบเพื่อหากิจกรรมที่เป็นอันตราย (การตรวจสอบเครือข่ายเป็นหน้าที่ของ IPS/IDS)
ถัดไป
09 Security Logging and Monitoring Failures
09
Question 01
ข้อใดเป็นการป้องกันช่องโหว่ในด้าน Security Logging and Monitoring
Failures
ลดความถี่ในการตรวจสอบ log เพื่อให้ workload ลดลง
ดำเนินการทำ log บันทึกที่ครอบคลุมเหตุการณ์ด้านความปลอดภัย
ปิดใช้งานการแจ้งเตือนเพื่อหลีกเลี่ยงการรบกวนที่ไม่จำเป็น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Security Logging and Monitoring Failures
1. ควรมีการจัดทำ Log Server เพื่อใช้เก็บ Log หรือบันทึกเหตุการณ์ที่เกิดขึ้นจึงเป็นสิ่งที่ควรกระทำ โดยเฉพาะ Log ที่เกี่ยวข้องกับด้าน Security 2. ควรจัดให้มีการ Monitor หรือการสอดส่องตรวจสอบ Log ว่ามีสิ่งผิดปกติเกิดขึ้นหรือไม่และอย่างไร 3. การใช้ IPS/IDS ซึ่งเป็นเครื่องมือตรวจสอบแบบ Automate ก็เป็นสิ่งที่ควรคำนึงถึง เพื่อลดการทำงานของบุคลากรลง 4. ควรมีการจัดทำแผนการรับมือ หากเจอเหตุการณ์ที่ผิดปกติจาก Log ว่าควรมีมาตรการรับมืออย่างไร
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
10 Server-Side Request Forgery (SSRF)
อันดับที่ 10 การปลอมแปลง Request ฝั่ง Server
10 Server-Side Request Forgery (SSRF)
ช่องโหว่นี้เกี่ยวข้องกับการปลอมแปลง request ฝั่ง server ซึ่งเกิดจากการอนุญาตให้มีการ fetch ข้อมูลจากฝั่ง server เองจากภายนอกมาใช้งาน
โดยช่องโหว่นี้มีความคล้ายกับช่องโหว่ Injection เนื่องจากเกี่ยวข้องกับการรับข้อมูล Input จาก User เข้ามาประมวลผลโดยไม่ได้ทำการตรวจสอบและจัดการข้อมูล Input ให้ดี ทำให้ผู้โจมตีสามารถ fetch ข้อมูลของ Server ออกมาได้ ซึ่งทำให้ข้อมูลนั้นรั่วไหลหรือถูกบิดเบือนโดยผู้โจมตีได้
ถัดไป
10 Server-Side Request Forgery (SSRF)
10
Question 01
ข้อใดคือลักษณะหลักของการโจมตีด้วย Server-Side Request Forgery (SSRF)
การกระจายการตอบกลับของ Server ปลอม ไปยัง Client
ใช้วิธี Brute-Force Attack ในการโจมตี Server
การเข้าถึงและบิดเบือนทรัพยากรฝั่ง Server โดยผู้โจมตีภายนอก
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com
เว็บไซต์นี้อนุญาตให้กรอก URL ลงในช่องกรอกข้อมูล เพื่อทำการ fetch คอนเทนต์ ที่อยู่ใน URL นั้น เช่น รูปภาพ โดยเว็บไซต์นี้มีช่องโหว่ Server-Side Request Forgery (SSRF) เนื่องจากไม่มีการตรวจสอบและจัดการข้อมูล Input ที่เป็น URL นั้นให้ดี
ลองใส่ค่า URL แปลกๆลงไปดีกว่า
Please enter URL
View
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com
ผู้โจมตีกรอก URL ลงบนช่องกรอกข้อมูล URL ของเว็บไซต์ เช่น http://localhost/admin_panel ซึ่งเป็น URL ที่เข้าถึงหน้าการดูแลระบบภายในเซิร์ฟเวอร์ (URL นี้เป็นเพียงตัวอย่างเท่านั้น ในการโจมตีจริง อาจไม่ใช่ URL นี้ที่สามารถเข้าถึงหน้าการดูแลระบบได้)
http://localhost/admin_panel
View
ย้อนกลับ
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com/view
ผู้โจมตีสามารถมองเห็นข้อมูลในหน้าการดูแลระบบภายในเซิร์ฟเวอร์ได้ เนื่องจากระบบไม่มีการตรวจสอบข้อมูล Input URL ให้ดี ทำให้หน้าต่างนี้ถูก fetch ออกมาและมองเห็นได้โดยผู้ที่ไม่มีสิทธิ์
ย้อนกลับ
ถัดไป
10
Question 02
ข้อความด้านล่าง ถูกหรือผิด เกี่ยวกับความแตกต่างระหว่างช่องโหว่ Server-Side Request Forgery (SSRF) และ Injection
Injection คือการใส่ Code, Command หรือ Query เพื่อให้ระบบประมวลผลและทำงานผิดไปจากที่ควรจะเป็น ส่วน SSRF เป็นการหลอก Server โดยทำการขอ Request ไปยังทรัพยากรภายนอกหรือภายในเพื่อเข้าถึงข้อมูลหรือแก้ไขข้อมูลสำคัญ
ถูก
ผิด
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Server-Side Request Forgery (SSRF)
1. การทำ Input Validation หรือการตรวจสอบ Input ของ User เพื่อให้แน่ใจว่า URL ที่กรอกเข้ามานั้นปลอดภัย และมีจุดประสงค์ที่ถูกต้องตามที่ควรจะเป็น 2. การทำ Whitelisting หรือการกำหนด Domains หรือ URL ที่อนุญาตให้ Server เข้าถึงและ fetch ข้อมูลได้ โดยกำหนด Domains หรือ URL ให้เฉพาะที่เชื่อถือได้เท่านั้น ทั้งนี้รวมถึงการทำ Blacklisting เพื่อทำการบล็อค Domains หรือ URL ที่อาจเป็นอันตราย 3. การทำ URL Parsing โดยใช้ Libraries ที่มีอยู่ของภาษาที่เขียนโปรแกรมหรือ Framework ที่ใช้ เพื่อให้แน่ใจว่า URL ที่รับมานั้นอยู่ในรูปแบบที่ถูกต้องและเป็นที่ยอมรับ 4. การใช้หลัก Least Privilege หรือการให้สิทธิ์การเข้าถึงเท่าที่จำเป็น โดยอาจกำหนดว่าข้อมูลสำคัญบน Server สามารถเข้าถึงได้เฉพาะ Admin และจะปฏิเสธ Request เพื่อเข้าถึงข้อมูลนั้นหากไม่สามารถระบุได้ว่าผู้ร้องขอคือ Admin จริง
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
ถัดไป
Congratulation
ยอดเยี่ยมมาก! คุณได้ผ่านเนื้อหาครบทุกบทเรียนแล้ว!
เราหวังเป็นอย่างยิ่งว่า เนื้อหาความรู้ที่คุณได้เรียนไปในบทเรียนนี้ จะเป็นประโยชน์แก่คุณ เราขออวยพรให้คุณโชคดีในการสอบวัดผล
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
Secure Coding Awareness Training
IS
Created on February 13, 2024
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Halloween escape
View
Adventure Breakout
View
Team Building Mission Escape Game
View
Onboarding Escape Game
View
Flags Challenge
View
Museum Escape Room
View
Education Escape Room
Explore all templates
Transcript
Secure Coding Awareness Training
เริ่ม!
บทเรียนนี้จะกล่าวถึงช่องโหว่ทางไซเบอร์ 10 อันดับจาก OWASP TOP 10 ปี 2021 โดยผู้เรียนจะต้องทำการศึกษาช่องโหว่ทั้ง 10 อันดับ โดยเรียงลำดับจากอันดับที่ 1 ไปจนถึงอันดับที่ 10
คลิกที่ชื่อช่องโหว่เพื่อทำการเริ่มเรียนเกี่ยวกับช่องโหว่นั้น
ผู้เรียนสามารถปิดเสียงเพลง Background ได้ที่ปุ่มนี้
ถัดไป
OWASP TOP 10 คืออะไร
OWASP หรือ Open Web Application Security Project จัดตั้งโดย OWASP Foundation เป็นองค์กรไม่แสวงหาผลกำไรที่ดูแลด้านความปลอดภัยบนเว็บแอปพลิเคชัน
OWASP TOP 10 คือ 10 อันดับของความเสี่ยงของเว็บแอปพลิเคชัน ที่จัดอันดับโดย OWASP ซึ่งจะมีการจัดอันดับทุก ๆ 4 ปี และเวอร์ชันล่าสุดคือ OWASP TOP 10 - 2021
ไปต่อ
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
01 Broken Access Control
อันดับที่ 1 การควบคุมสิทธิ์ที่ผิดพลาด
01 Broken Access Control
เป็นช่องโหว่ด้านไซเบอร์อย่างหนึ่งที่พบได้ตาม Application ทั่วไปหากไม่มีการกำหนดสิทธิ์และควบคุมการเขาถึงข้อมูลต่างๆให้ดีตัวอย่างเช่น การไม่กำหนดสิทธิ์ Admin/User ให้ชัดเจน ทำให้ผู้ใช้งานทั่วไป สามารถเข้าถึงหน้าใช้งานของ User อื่น หรือ Admin ได้ ซึ่งแฮกเกอร์อาจใช้ช่องโหว่นี้ในการโจมตี ระบบหรือขโมยข้อมูลสำคัญออกไป โดยอาจ Login เป็น User ปกติ และทำการเข้าถึงหน้าระบบของ Admin เพื่อขโมยข้อมูลสำคัญ
ถัดไป
01 Broken Access Control
Question 01
Broken Access Control หมายถึงอะไร
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การขาดการตรวจสอบข้อมูล Input
การป้องกันการส่งข้อมูลไม่ดีพอ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com
เว็บไซต์นี้มี Role ของ User อยู่ 2 รูปแบบ
1. Normal User
ลอง Log in ด้วย username ที่มีอยู่ ชื่อ user123 ดีกว่า
2. Admin User
ถ้า Log in ด้วยบัญชี User ก็จะสามารถเข้าถึงหน้าของ User ได้เท่านั้น
ถ้า Log in ด้วยบัญชี Admin ก็จะสามารถเข้าถึงหน้าของ Admin ได้
Username
Password
Log in
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com/user123
Normal User Page
user: user123
หลังจากที่ Log in เข้ามาแล้ว จะเห็นได้ว่าเว็บไซต์นี้ใช้ชื่อของ user ที่ Log in ต่อท้ายบน URL เพื่อกำหนดให้ไปยังหน้าของ User นั้น
ดูรายการที่ 1
ดูรายการที่ 2
ดูรายการที่ 3
ทำให้สามารถคาดเดาได้ว่าถ้าเปลี่ยน user123 บน URL เป็นค่าอื่นเช่น admin อาจทำให้สามารถเข้าถึงหน้าของ admin ได้
ย้อนกลับ
ถัดไป
ตัวอย่างของ Broken Access Control
https://www.example.com/admin
Admin Page
Admin
เมื่อลองทำการเปลี่ยนค่า user123 เป็น admin บน URL แล้วทำให้สามารถเข้าถึงหน้าของ Admin ได้
เพิ่ม User
เรียกดูข้อมูล User
ตรวจสอบ User
จะเห็นได้ว่าผู้โจมตีสามารถ Login เข้า User ธรรมดาแล้วสามารถเข้าถึงหน้าของ Admin ได้ นับว่าเป็นช่องโหว่ Broken Access Control
ลบ User
ย้อนกลับ
ถัดไป
01
Question 02
การเข้าถึงสิทธิ์ของ User อื่น ๆ นอกเหนือจาก Admin ถือเป็นช่องโหว่ Broken Access Control
ถูก
ผิด
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
01 Broken Access Control
Java
จากตัวอย่างโค้ดด้านบน จะเห็นได้ว่ามีการ mapped path /admin แต่ไม่มีการตรวจเช็ค สิทธิ์การเข้าถึงและใช้งานหน้านี้ ทำให้เกิดช่องโหว่ Broken Access Control
ถัดไป
01 Broken Access Control
Java
จากตัวอย่างโค้ดด้านบน จะเห็นได้ว่ามีการ mapped path /admin และมีการตรวจเช็ค สิทธิ์การเข้าถึงและใช้งานหน้านี้ โดยใช้ @PreAuthorize(hasRole('ADMIN')")
โดยคำสั่งนี้สามารถเรียกใช้งานได้จาก Spring Security ของ Java
ทั้งนี้ เราไม่ควรใช้ path ที่สามารถคาดเดาได้ง่ายเช่น https://www.example.com/admin
เพื่อทำการเข้าถึงหน้า Admin รวมถึงหน้าอื่นๆด้วย
ย้อนกลับ
ถัดไป
01 Broken Access Control
สรุปการป้องกันช่องโหว่ Broken Access Control
1. มีการทำ Authentication ที่ถูกต้อง และสามารถตรวจสอบตัวตนของผู้ใช้งานที่ Log in เข้ามาได้
2. มีการทำ Authorization หรือการกำหนดสิทธิ์หรือ Role ต่างๆให้ User แต่ละประเภท ว่าสามารถทำอะไรกับระบบได้บ้าง
3. มีการทำ Permission Checking หรือทำการตรวจสอบสิทธิ์ก่อนให้เข้าถึงข้อมูลหรือหน้าต่างบนเว็บไซต์บางหน้า เช่นหน้าของ Admin
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
02 Cryptographic Failures
อันดับที่ 2 ความล้มเหลวในการเข้ารหัส
02 Cryptographic Failures
เป็นอีกช่องโหว่ด้านไซเบอร์อย่างหนึ่งของ Application ที่เกิดจาก1. การไม่เข้ารหัสข้อมูลที่มีความสำคัญ 2. ใช้อัลกอริทึมในการเข้ารหัสที่ไม่แข็งแรง 3. การใช้ Protocol ที่ไม่มีการเข้ารหัสข้อมูลในการส่งข้อมูลระหว่าง Client-Server ซึ่งหากข้อมูลเหล่านั้นถูกผู้ไม่หวังดีดักจับไปได้ จะทำให้เกิดการรั่วไหลของข้อมูลซึ่งสร้างผลกระทบในทางที่ไม่ดีได้
ถัดไป
02 Cryptographic Failures
Question 01
Cryptographic Failures หมายถึงอะไร
ใช้อัลกอริทึมที่ไม่ปลอดภัยในการเข้ารหัส หรือการไม่เข้ารหัสข้อมูลที่จัดเก็บไว้
ข้อมูลสำคัญของระบบถูกส่งไปในช่องทางที่ไม่ปลอดภัย
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
WiFi ของร้านกาแฟ
ผู้ใช้งานทำการเชื่อมต่อผิด ไปเชื่อมต่อ WiFi ของโจร
WiFi ของโจร
ตัวอย่างนี้แสดงถึงการที่ผู้ไม่หวังดีปล่อยสัญญาณ WiFi ในที่สาธารณะ เช่นในร้านกาแฟ โดยผู้ไม่หวังดีอาจทำการตั้งชื่อ WiFi ของตัวเองเป็นชื่อ WiFi ร้านกาแฟ เพื่อหลอกล่อเหยื่อให้เชื่อมต่อผิด
ถัดไป
WiFi ของร้านกาแฟ
ผู้ใช้งานเข้าใช้งานเว็บไซต์ด้วย HTTP
WiFi ของโจร
Username
Password
ผู้ไม่หวังดีสามารถดักจับข้อมูลที่เหยื่อส่งไปยังปลายทางได้ ดังนั้นถ้าเหยื่อใช้งาน HTTP ซึ่งเป็น Protocol ที่ไม่มีการเข้ารหัสข้อมูลเพื่อส่งข้อมูล จึงทำให้ผู้ไม่หวังดีสามารถมองเห็นข้อมูลสำคัญที่เหยื่อส่งไปได้ เช่น Username และ Password
ย้อนกลับ
ถัดไป
ตัวอย่างก่อนหน้า แสดงให้เห็นถึงการส่งข้อมูลด้วย Protocol HTTP ซึ่งไม่มีความปลอดภัย ในปัจจุบันจึงมีการแนะนำให้ใช้ HTTPS แทน เพราะมีการเข้ารหัสข้อมูลก่อนที่จะส่ง
นอกเหนือจากการใช้ Protocol ที่มีความปลอดภัยแล้ว ผู้พัฒนาไม่ควรละเลยการเข้ารหัสข้อมูลสำคัญที่จัดเก็บไว้ในฐานข้อมูล รวมถึงควรใช้อัลกอริทึมเข้ารหัสที่มีความแข็งแรงอีกด้วย
อัลกอริทึมเข้ารหัสที่ปลอดภัย เช่น AES, SHA-256, RSA ...
ย้อนกลับ
ถัดไป
จากตัวอย่างโค้ดด้านซ้าย จะเห็นได้ว่า ฟังก์ชัน transmit() ที่ใช้ส่งข้อมูล ไม่มีการเข้ารหัส และส่งข้อมูลออกไปแบบ Plaintext ฟังก์ชัน receive() ที่ใช้รับข้อมูล ก็ไม่มีการถอดรหัสข้อมูลที่ได้รับมา
การส่งและรับข้อมูลแบบ Plaintext ถือว่าไม่ปลอดภัย!
Java
ย้อนกลับ
ถัดไป
แบบนี้สิถึงปลอดภัย
จากโค้ดด้านซ้าย จะเห็นว่า ฟังก์ชัน generateAESKey() ทำการสร้าง secret key 256 bit โดยใช้อัลกอริทึม AES ฟังก์ชัน encrypt() ใช้ข้อความต้นทางและ secret key ในการเข้ารหัสโดยใช้อัลกอริทึม AES และค่า return ที่ได้จะอยู่ในรูปของ Base64-encoded ciphertext ฟังก์ชัน decrypt() ใช้ข้อความที่ถูกเข้ารหัสมาทำการถอดรหัสโดยใช้ secret key และค่า return ที่ได้จะออกมาในรูปของข้อความต้นทาง (Plaintext)
ย้อนกลับ
ถัดไป
Java
02
Question 02
อัลกอริทึมเข้ารหัสใดที่ไม่ปลอดภัย
DES
SHA-256
AES
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
02 Cryptographic Failures
สรุปการป้องกันช่องโหว่ Cryptographic Failures
1. เลือกใช้งาน HTTPS แทนการใช้ HTTP เนื่องจาก Web servers โดยทั่วไปจะสามารถใช้งานได้เหมือนเดิมไม่ว่าจะใช้ HTTP (port 80) หรือ HTTPS (port 443) ดังนั้นจึงควรใช้ HTTPS และต้องแน่ใจว่ามีการบังคับให้ Web servers ยกระดับเป็น secure connection เมื่อมีการทำ Authentication หรือการเชื่อมต่อ session โดยวิธีทั่วไปคือการ set cookies ให้เป็น secure จะทำให้การเชื่อมต่อ session สามารถทำได้ผ่าน HTTPS เท่านั้น
2. เข้ารหัสข้อมูล และใช้งานอัลกอริทึมการเข้ารหัสที่มีประสิทธิภาพใน Application หรือ Website ที่เขียนซึ่งมีอัลกอริทึมมากมายที่ถูกพิสูจน์แล้วว่ามีความปลอดภัย เช่น AES, RSA และ SHA-256 เป็นต้น และหลีกเลี่ยงการใช้งานอัลกอริทึมที่ไม่ปลอดภัย เช่น DES, MD5 และ SHA-1 เป็นต้น โดยในปัจจุบัน ผู้พัฒนาสามารถเลือกใช้งานอัลกอริทึมที่ปลอดภัยเหล่านี้ได้ผ่านการเรียกใช้งานโดยอาศัย libraries, frameworks และ extension ต่างๆ เช่น Java Cryptography Architecture (JCA) และ Java Cryptography Extension (JCE)
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
03 Injection
อันดับที่ 3 การแทรกคำสั่งที่เป็นอันตราย
03 Injection
ช่องโหว่นี้เกิดจากการโจมตีโดยแทรกคำสั่ง (code) เข้าไปที่ Application เป้าหมายด้วยเทคนิคต่างๆ เช่น SQL injection, NoSQL injection, LDAP injection, OS Command injection และอื่นๆ ทั้งนี้ได้มีการนำ Cross-site Scripting (XSS) จาก OWASP TOP 10 - 2017 มาเป็นส่วนหนึ่งของข้อนี้ด้วยช่องโหว่ Injection มักเกิดขึ้นถ้าไม่มีการตรวจสอบข้อมูล Input จาก User
ถัดไป
03 Injection
Question 01
ช่องโหว่ Injection มักเกิดจากข้อใด
การป้องกันการส่งข้อมูลไม่ดีพอ
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การขาดการตรวจสอบและการจัดการข้อมูล Inputs
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
เว็บไซต์นี้มีช่องโหว่ SQL Injection หรือก็คือการแทรกคำสั่ง SQL ลงในช่องกรอกข้อมูล เพื่อให้ระบบทำงานผิดพลาดไปจากที่ควรจะเป็น โดยเกิดจากการนำข้อมูล Input จาก User ไปทำการ Query โดยที่ไม่มีการตรวจสอบและจัดการข้อมูลที่ User กรอกในช่อง Input ข้อมูล เช่น Email และ Password ของเว็บไซต์นี้
ลอง Log in ด้วย Email และ Password ตามนี้
user@email.com
password
Log in
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
จากด้านล่าง หน้าเว็บแสดงให้เห็นว่า Log in ไม่สำเร็จเนื่องจาก Email หรือ Password ที่กรอกนั้นผิด และถ้าหากดูจากการ Query ข้อมูล User เพื่อทำการ Login จากรูปด้านขวามือ จะเห็นได้ว่าระบบรับข้อมูล user@email.com และ password มาทำการ Query
Email หรือ Password ไม่ถูกต้อง
user@email.com
password
Log in
ย้อนกลับ
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/login
จากด้านล่าง ถ้าหากลองทำการแก้ไขข้อมูลช่อง Password ใหม่ โดยเปลี่ยนจาก password เป็น ' or 1=1-- ลองสังเกตที่การ Query ข้อมูล จะเห็นได้ว่าเมื่อแทรกคำสั่ง SQL ข้างต้นลงไป เมื่อนำไป Query ข้อมูล ทำให้เกิดเงื่อนไข ' ' or 1=1 ซึ่งทำให้เงื่อนไข 1=1 เป็นจริง ระบบจึงไม่สนใจเงื่อนไข ' ' ด้านหน้า or อีกทั้งยังไม่สนใจ LIMIT 1 ด้านหลังด้วย เพราะการใส่ -- ถือเป็นการบอกว่าทุกข้อความหลังจากเครื่องหมาย -- ถือเป็น comment ของภาษา SQL ซึ่งจะไม่ถูกนำมาประมวลผล
user@email.com
' or 1=1--
Log in
ย้อนกลับ
ถัดไป
ตัวอย่างของ SQL Injection
https://www.example.com/user
ผู้ไม่หวังดีสามารถเข้ามาสู่หน้าของ User ที่ใช้ user@email.com เป็นอีเมล์ในการ Log in ได้ โดยที่ไม่จำเป็นต้องรู้รหัสผ่านของ User นี้เลย
Welcome!
User: user@email.com
ย้อนกลับ
ถัดไป
03 Injection
Parameterized queries หรือ Prepared statements
เป็นการประกาศค่า placeholder ให้กับตัวแปรที่จะนำมารับค่า Input จาก User เพื่อให้ระบบมองสิ่งที่ User กรอกมาเป็น Data แทนที่จะถูกมองเป็นคำสั่ง Query หากมีการใส่ Input เป็นคำสั่ง Query ซึ่งจะทำให้คำสั่งที่ป้อนเข้ามา ไม่ถูกนำไปประมวลผล ช่วยป้องกันช่องโหว่ SQL Injection ได้ โดยทั้ง Parameterized queries และ Prepared statements มีความหมายเหมือนกัน
Escaping Inputs
เป็นการปรับเปลี่ยนค่า Input ที่ได้รับจาก User เพื่อให้แน่ใจว่าตัวอักษรบางตัวต้องถูกมองเป็นข้อมูลตามตัวอักษรนั้นแทนที่จะเป็น คำสั่งที่ประมวลผลได้
ย้อนกลับ
ถัดไป
ตัวอย่างของ Parameterized queries/Prepared statements
จากโค้ดด้านซ้าย จะเห็นว่ามีการใช้ placeholder คือ const sqlQuery = 'SELECT * FROM users WHERE username = ?'; ทำให้ข้อมูล username ที่ถูกกรอกจาก User ถูกนำมาใส่เป็นค่าของตัวแปรก่อน แทนที่จะนำไปประมวลผลโดยตรง ทำให้มีความปลอดภัยมากขึ้น
ย้อนกลับ
ถัดไป
JavaScript
ตัวอย่างของ Escaping Inputs
จากโค้ดด้านซ้าย จะเห็นว่ามีการแทนที่เครื่องหมาย ' ด้วย ' ' โดยใช้ Regular Expression ดังนี้ const escapedUsername = username.replace(/'/g, "' '"); หรือก็คือใช้เครื่องหมาย ' ติดกันสองตัว (ไม่ใช่เครื่องหมาย ") ในภาษา JavaScript การใช้เครื่องหมาย ' ติดกันสองตัว เทียบเท่ากับ การใช้เครื่องหมาย ' เพียงตัวเดียว ซึ่งทำให้ผลลัพธ์จากการประมวลผลไม่ผิดไปจากเดิม แต่สามารถช่วยป้องกันการกรอกข้อมูล Input ที่ใส่เครื่องหมาย ' เข้ามา ไม่ให้ข้อมูลนั้นถูกมองว่าเป็นคำสั่ง แต่จะถูกมองเป็นข้อมูลทั่วไปแทน
JavaScript
ย้อนกลับ
ถัดไป
03
Question 02
ข้อใดเป็นวิธีการป้องกันช่องโหว่ Injection
Escaping Inputs
Encryption
Authentication
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
03 Injection
สรุปการป้องกันช่องโหว่ Injection เบื้องต้น
การป้องกันช่องโหว่นี้ สามารถทำได้หลายวิธี เช่นการใช้ Parameterized queries หรือ Prepared statements, การใช้ Escape input ตามที่ได้แสดงตัวอย่างให้เห็นก่อนหน้านี้ นอกจากนี้ยังมีวิธีอื่นๆที่สามารถใช้เพื่อป้องกันช่องโหว่ Injection อีกหลายวิธี เช่น การใช้ Object Relational Mapping (ORM) และ การ Sanitizing Input เป็นต้น ช่องโหว่นี้เคยเป็นช่องโหว่ที่ถูกจัดเป็นอันดับที่ 1 ของ OWASP TOP 10 - 2017 แต่ในปี 2021 ถูกจัดไว้ที่อันดับที่ 3 ซึ่งก็ยังถือว่าเป็นช่องโหว่ที่พบได้บ่อยและผู้พัฒนาควรคำนึงถึงช่องโหว่นี้เสมอ เมื่อเขียนโปรแกรมที่มีการรับค่า Input จาก User
ตัวอย่างที่แสดงและวิธีการป้องกัน มีเพียง SQL Injection ซึ่งเป็นส่วนหนึ่งของช่องโหว่ Injection เท่านั้น โดยยังมีช่องโหว่ Injection อื่น ๆ อีกมากมาย เช่น Cross-Site Scripting (XSS) (เกี่ยวข้องกับการขโมย session cookies), Command Injection, LDAP Injection, XML Injection และ Path Traversal ผู้เรียนสามารถไปศึกษาเพิ่มเติมเกี่ยวกับช่องโหว่ Injection เหล่านี้ได้
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
04 Insecure Design
อันดับที่ 4 การออกแบบที่ไม่ปลอดภัย
04 Insecure Design
เป็นช่องโหว่การออกแบบสถาปัตยกรรมของระบบที่ผิดพลาด โดยช่องโหว่นี้เป็นช่องโหว่ใหม่ที่เพิ่มเข้ามา ไม่เคยถูกจัดอันดับติด 10 อันดับแรกมาก่อน ซึ่งไม่ใช่ปัญหาที่เกิดจากการเขียนโปรแกรมที่ผิดพลาดโดยตรง แต่เป็นปัญหาที่มักเกิดจากการที่ผู้พัฒนาไม่ได้คำนึงถึงมุมมองด้านความปลอดภัยของระบบในขั้นตอนการออกแบบระบบ รวมไปจนถึงรูปแบบวงจรชีวิตการพัฒนา หรือ Software Development Life Cycle (SDLC) ที่การคำนึงด้านความปลอดภัย
ถัดไป
04 Insecure Design
04
Question 01
Insecure Design หมายถึงอะไร
ปัญหาที่เกิดจากการออกแบบและวางแผนการพัฒนาระบบที่ไม่ดี
ปัญหาของการพัฒนาระบบแบบ Water Fall
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างกรณีการเกิดช่องโหว่เนื่องจากการออกแบบที่ไม่ดี
1. เก็บข้อมูล Secret ใดๆ เช่น API Key, Private Key ไว้ที่ Client แม้ว่าจะมีการเข้ารหัสไว้แน่นหนาก็ตาม ควรเลือกไปเก็บบน Server แทน หากเป็นไปได้
2. การอนุญาตให้แก้ไขข้อมูลสำคัญเช่น Email โดยไม่ได้ถาม Password ก่อน ทำให้บุคคลอื่นสามารถกด Forgot Password เพื่อตั้งค่ารหัสผ่านใหม่ได้ทันทีที่เซ็ต Email ใหม่ได้
3. ใช้ระบบคำถามลืมรหัสผ่านที่ง่ายเกินไป เช่น วันเดือนปีเกิด ในการเข้าสู่ระบบเมื่อจำรหัสผ่านไม่ได้
4. การไม่กำหนดขนาดของ Input ที่ชัดเจน ทำให้อาจเกิดปัญหา Buffer Overflows (การเขียนข้อมูลไปยังบัฟเฟอร์เกินหน่วยความจำที่มีอยู่ของบัฟเฟอร์)
5. การใช้ API หรือฟังก์ชันที่มีช่องโหว่ เนื่องจากขาดการตรวจสอบความปลอดภัยของ API นั้น
ยังมีช่องโหว่อีกมากมายที่มักเกิดจากการออกแบบระบบที่ไม่ดี ทั้งหมดข้างต้นเป็นเพียงตัวอย่างเท่านั้น!
ถัดไป
วงจรชีวิตการพัฒนาซอฟต์แวร์ Software Development Life Cycle (SDLC)
1.วางแผน
6.บำรุงรักษา
2.ออกแบบ
โดยปกติแล้วผู้พัฒนาจะพบว่าระบบมีช่องโหว่ในขั้นตอนทดสอบ
5.ใช้งาน
3.ดำเนินการ
4.ทดสอบ
ย้อนกลับ
ถัดไป
Shift Left Mentality in SDLC
คือการนำหลักการของการรักษาความปลอดภัยไซเบอร์มาใช้ตั้งแต่การเริ่มออกแบบการพัฒนาระบบ เพื่อให้ผู้พัฒนาสามารถรู้และแก้ไขช่องโหว่ที่มีในระหว่างการพัฒนาได้เร็วขึ้น เช่น 1. การตรวจสอบ API ที่จะนำมาใช้ว่ามีความปลอดภัยหรือไม่ก่อนนำมาใช้งาน 2. การเลือกเก็บ API Key ไว้บน Server แทน Client 3. วางแผนให้มีการตรวจสอบตัวตนก่อนอนุญาตแก้ไขข้อมูลสำคัญ 4. การออกแบบรูปแบบของข้อมูล Input จาก User ว่าไม่ควรมีขนาดเกินเท่าไร เพื่อป้องกัน Buffer Overflows และให้ระบบทำงานได้ตามที่ต้องการ
การพัฒนาซอฟต์แวร์ในยุคปัจจุบัน หลาย ๆ องค์กรเริ่มนำหลักการ DevSecOps เข้ามาใช้งาน คือการขยับจากการที่ผู้พัฒนาจะรู้ช่องโหว่ของระบบในขั้นตอนทดสอบ ให้ผู้พัฒนารู้ถึงช่องโหว่ที่ต้องแก้ไขเร็วขึ้น เช่นรับรู้และแก้ไขตั้งแต่ขั้นตอนดำเนินการและการออกแบบ
ย้อนกลับ
ถัดไป
04
Question 03
Shift Left Mentality in SDLC คืออะไร
การออกแบบการทำงานของระบบให้มีความปลอดภัยมากขึ้น
การปรับลักษณะการพัฒนาระบบให้มีการทดสอบความปลอดภัยที่รัดกุมยิ่งขึ้น
การปรับลักษณะการพัฒนาระบบให้ผู้พัฒนารู้ถึงช่องโหว่ที่ต้องแก้ไขได้เร็วขึ้น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
04 Insecure Design
สรุปการป้องกันเรื่อง Insecure Design
1. การพัฒนาซอฟต์แวร์ใด ๆ ควรมีการคำนึงถึงความปลอดภัยของระบบเสมอ รวมถึงควรนับเป็น Requirements อย่างหนึ่งในการพัฒนาซอฟต์แวร์ด้วย นอกเหนือจาก Requirements ด้านธุรกิจและการใช้งานทั่วไป 2. ควรมีการนำหลักการ Shift Left Mentality in SDLC มาใช้งาน เพื่อให้การพัฒนาซอฟต์แวร์มีความปลอดภัยมากขึ้น และลดปัญหาการแก้ไข Source code ที่เขียนในขั้นตอนการทดสอบลง
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
05 Security Misconfiguration
อันดับที่ 5 การตั้งค่าความปลอดภัยที่ไม่ถูกต้อง
05 Security Misconfiguration
ช่องโหว่เกี่ยวกับการตั้งค่าความมั่นคงปลอดภัย โดยสามารถเกิดได้ทุกที่ในระบบ ซึ่งสาเหตุหลักเกิดจากการตั้งค่าไม่ดี ทำให้เกิด Attack Surface หรือช่องทางการโจมตีระบบ โดยทุก ๆ ระบบสามารถเกิดการตั้งค่าความปลอดภัยที่ไม่ถูกต้องขึ้นได้ ตัวอย่างเช่น 1. การใช้ Username และ Password ที่ติดตั้งมาพร้อมกับตัวอุปกรณ์ ทำให้ผู้ไม่หวังดีสามารถเข้ามาภายในระบบได้โดยที่ไม่ต้องทำการเจาะระบบอะไรเลย เนื่องจากรู้ Username และ Password ตั้งต้นของอุปกรณ์นั้น ๆ อยู่แล้ว 2. ไม่ทำการปิด Config บางอย่างที่ใช้ในขั้นตอนการพัฒนาก่อนนำขึ้น Production ทำให้มีข้อมูลบางอย่างหลุดไปอยู่บน Production ได้
ถัดไป
05 Security Misconfiguration
Question 01
Security Misconfiguration หมายถึงอะไร
การตั้งค่าระบบมีความไม่เสถียร
การกำหนดสิทธิ์การเข้าถึงที่ผิดพลาด
การตั้งค่าระบบบางอย่างทำให้เกิดช่องโหว่ขึ้น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
05 Security Misconfiguration
สรุปการป้องกันเรื่อง Security Misconfiguration เบื้องต้น
1. ตรวจสอบ Software Components ใหม่ที่จะใช้และแก้ไขข้อมูลละเอียดอ่อนที่เป็นค่าเริ่มต้นให้เป็นค่าอื่นที่คาดเดาได้ยากโดยเร็วที่สุด 2. ทำการแยก Environment ของ Codebase และ ไฟล์หรือค่า Configuration ต่าง ๆ ออกจากกันอย่างชัดเจน เนื่องจากข้อมูลสำคัญในค่า Configuration ไม่ควรอยู่รวมกันกับ Source code 3. สร้างบัญชีสำหรับจัดการระบบบน Production โดยใช้หลัก Least Privilege หรือคือการให้สิทธิ์ในการกระทำต่าง ๆ บนระบบเท่าที่จำเป็นเท่านั้น
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
06 Vulnerable and Outdated Components
อันดับที่ 6 การใช้งานส่วนประกอบของซอฟต์แวร์เก่าหรือมีช่องโหว่
06 Vulnerable and Outdated Components
เป็นช่องโหว่ที่เกิดจากการใช้งาน Software Components ที่มีช่องโหว่ หรือใช้งาน Software Components เวอร์ชันเก่าที่มีช่องโหว่ ถือเป็นปัญหาที่พบเจอได้ทั่วไปในการพัฒนาซอฟต์แวร์ ตัวอย่างเช่น 1. การเลือก Software Components ที่ต้องการนำมาใช้งานโดยไม่ตรวจสอบให้แน่ใจว่า Software Components นั้น ๆ มีช่องโหว่อะไรหรือไม่ เมื่อ Software Components นั้น ๆ มีช่องโหว่ ทำให้ผู้ไม่หวังดีสามารถใช้ประโยชน์จากช่องโหว่นั้น ๆ ได้ 2. การใช้งาน Software Components เวอร์ชันเดิม โดยไม่มีการอัปเดตเพื่อป้องกันช่องโหว่ที่ถูกพบในเวอร์ชันเดิม ซึ่งในบางครั้งเมื่อมีการตรวจพบช่องโหว่ ทางผู้พัฒนาของ Software Components นั้น ๆ จะต้องออกแพทช์เพื่ออัปเดตและแก้ไขช่องโหว่ที่พบ การที่เราไม่อัปเดตตาม ทำให้ผู้ไม่หวังดีสามารถโจมตีโดยอาศัยช่องโหว่ที่ถูกประกาศออกมาจากทางผู้พัฒนา Software Components นั้น ๆ ได้
ถัดไป
06 Vulnerable and Outdated Components
Question 01
ข้อใดมักเป็นสาเหตุที่ทำให้เกิดความเสี่ยงด้าน Vulnerable and Outdated Components
การใช้งาน Libraries โดยไม่ได้ตรวจสอบก่อนว่ามีช่องโหว่หรือไม่
การใช้งาน Framework เวอร์ชันเก่า
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
06 Vulnerable and Outdated Components
สรุปการป้องกันเรื่อง Vulnerable and Outdated Components
1. ตรวจสอบ Software Components ใหม่ที่จะใช้ว่ามีช่องโหว่อะไรหรือไม่ ถ้าหากพบว่ามีช่องโหว่ อาจต้องเลือกใช้ Software Components ตัวอื่น ๆ แทน 2. Software Components ใหม่ที่จะเลือกใช้ ควรเป็นเวอร์ชันล่าสุด และมีการพัฒนาอยู่ ไม่ควรเลือกใช้ Software Components ที่หยุดพัฒนาไปแล้ว 3. หมั่นตรวจสอบ Software Components ต่าง ๆ ที่ใช้งานอยู่ ว่ามีการอัปเดทเวอร์ชันใหม่บ้างหรือไม่ หากมีการอัปเดทเพื่อแก้ไขปัญหาด้าน Security ควรรีบทำการอัปเดทใหม่โดยเร็วที่สุด
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
07 Identification and Authentication Failures
อันดับที่ 7 ความล้มเหลวในการระบุและการตรวจสอบตัวตน
07 Identification and Authentication Failures
ช่องโหว่นี้เกิดจากฟังก์ชันของ Application ที่เกี่ยวข้องกับการทำ Authentication และการจัดการ Session ที่ไม่ถูกต้อง ทำให้ผู้โจมตีสามารถใช้ประโยชน์จากช่องโหว่นี้ในการสวมรอยเป็นผู้ใช้งานอื่น ทั้งชั่วคราวและถาวร โดยในหัวข้อนี้จะอธิบายถึงการป้องกัน User Enumeration ไปจนถึงการจัดการ Password และ การป้องกัน Privilege Escalation
ถัดไป
07 Identification and Authentication Failures
07
Question 01
ช่องโหว่ Identification and Authentication Failures หมายถึงอะไร
การถูกผู้โจมตีสวมรอยเป็นผู้ใช้งานอื่นได้
การถูกผู้โจมตีทำให้ระบบใช้งานไม่ได้
ผิดทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
User Enumeration
เป็นเทคนิคอย่างหนึ่งที่ผู้โจมตีมักใช้เพื่อให้สามารถระบุได้ว่ามีชื่อผู้ใช้อะไรอยู่ในระบบ ซึ่งถ้าผู้โจมตีสามารถรู้ถึงชื่อผู้ใช้ต่าง ๆ ของระบบก็หมายถึงการที่ผู้โจมตีมีข้อมูลที่จำเป็นครึ่งหนึ่งแล้วในการเข้าสู่ระบบเพื่อสวมรอยเป็นผู้ใช้งานอื่น
หากผู้โจมตีรู้ถึง Username แล้ว การคาดเดา Password สามารถทำได้หลากหลายวิธี เช่นการใช้ Brute-Force Attack ในการคาดเดา Password หรือหาก Username ที่ใช้เข้าสู่ระบบเป็น Email ผู้โจมตีก็สามารถส่ง Email ล่อลวง (Social Engineering) เพื่อให้ผู้ใช้งานหลงกลและบอกรหัสผ่านให้ได้
ดังนั้น การปกปิดชื่อ Username ของผู้ใช้งานระบบให้ดี จึงเป็นสิ่งที่ควรกระทำ และควรคำนึงถึงเสมอ
ถัดไป
User Enumeration
ผู้โจมตีอาจใช้ลักษณะการทำงานของระบบเพื่อหาข้อมูลเกี่ยวกับชื่อผู้ใช้งาน (Username) ของผู้ใช้งานได้ ตัวอย่างเช่น 1. หากกรอกชื่อ Username ผิดในขั้นตอนการ Authentication แล้วระบบแจ้งเตือนว่า Username ผิด ก็จะทำให้ผู้โจมตีรู้ได้ว่า Username นั้นไม่มีอยู่ในระบบ และในทางกลับกัน หากระบบแจ้งว่า Password ผิด นั่นหมายความว่า Username นั้นมีอยู่ในระบบ 2. ระบบ Reset Password อาจให้มีการกรอก Username ที่ต้องการ Reset Password ซึ่งถ้ากรอก Username ที่ไม่มีอยู่ลงไปแล้วระบบแจ้งว่า ไม่พบ Username นี้ ก็จะทำให้รู้ได้ว่าไม่มี Username นี้ และในทางกลับกันหากพบ Username ที่กรอกแล้วแจ้งว่าส่ง Email สำหรับ Reset Password ไปให้แล้ว นั่นหมายความว่ามี Username นั้นในระบบ 3. ระบบ Registration ก็เช่นกัน หากในขั้นตอนการสมัครสมาชิกระบบมีการแจ้งว่า Username ที่ใช้นั้นมีผู้อื่นใช้ไปแล้ว ก็จะทำให้รู้ได้ว่ามี Username นั้น ๆ อยู่ในระบบ
ระบบบอกว่าไม่มีชื่อ David ถ้างั้นลองชื่ออื่น ระบบน่าจะบอกว่า Password ผิดแทน ถ้าเดา Username ถูก
https://www.example.com/login
ถัดไป
Log in failed! Username is incorrect
David
ย้อนกลับ
********
Log in
การป้องกัน User Enumeration
1. ขั้นตอน Authentication ของระบบ ควรแจ้งว่า Username หรือ Password ไม่ถูกต้องแทนการแจ้งว่าข้อมูลส่วนไหนผิด เมื่อมีการ Log in ไม่สำเร็จ 2. ขั้นตอน Reset Password ไม่ควรแสดงชื่อ Username เลย ถึงแม้ Email หรือ Username ที่กรอก จะมีอยู่ในระบบหรือไม่ก็ตาม เช่น แจ้งว่าได้ส่ง Email สำหรับเปลี่ยนรหัสผ่านไปยัง Email แล้ว และทำการส่ง Email สำหรับเปลี่ยนรหัสผ่านไปยัง Email ของผู้ใช้ ถ้ามีอยู่จริง และไม่ต้องส่ง ถ้าไม่มีอยู่จริง 3. ขั้นตอน Registration ก็ไม่ควรมีการแสดงชื่อ Username และบอกว่ามี Username นี้แล้วหรือไม่เช่นกัน
นอกจากนี้ ควรจัดการระยะเวลาของ HTTP Response และระยะเวลาในการแสดงผลว่า Log in สำเร็จหรือไม่ ให้มีระยะเวลาเท่า ๆ กัน ทั้งแบบที่ Username ถูกแต่ Password ผิด และ แบบ Username และ Password ผิดทั้งคู่ เพื่อปกปิดระยะเวลาใน Query Username และ Password
ย้อนกลับ
ถัดไป
07
Question 02
เพราะเหตุใดช่องโหว่ User Enumeration ถึงมีความอันตราย
ทำให้ Password รั่วไหล
เป็นการเปิดช่องให้ผู้โจมตีอัปโหลดไวรัส
เป็นการเปิดช่องให้ผู้โจมตีทำการโจมตีด้วย Brute-Force Attack กับ Password
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
Password Management
การจัดการ Password ที่ดี ถือเป็นหนึ่งในปัจจัยหลักของการทำระบบ Authentication แต่หลาย ๆ Application ยังคงจัดการได้ไม่ดี
เมื่อคำนึงถึงการทำ Authentication อย่างแรกที่ควรคำนึงถึงคือ เราจะเป็นต้องสร้างระบบ Authentication เองหรือไม่? เนื่องจากในปัจจุบัน มีการใช้งาน Account ของ Google, Facebook, Github และอื่น ๆ ในการทำ Authentication โดยบริษัทเหล่านี้ต่างมี OAuth Implementations ให้ใช้งาน ซึ่งปลอดภัยและน่าเชื่อถือ อีกทั้งยังช่วยลดเวลาในการพัฒนาลงเนื่องจากผู้พัฒนาไม่จำเป็นต้องสร้างระบบ Authentication เอง
ถ้าหากผู้พัฒนาจำเป็นต้องพัฒนาระบบ Authentication เอง จะมีวิธีการจัดการ Password ยังไงบ้าง?
อย่างไรก็ตาม การใช้ Social Media Authentication อาจไม่ใช่วิธีที่เหมาะสมสำหรับทุก Application
ถัดไป
Password Management
หากต้องพัฒนาระบบ Authentication เอง สิ่งแรกที่ต้องนึกถึงคือกฏบังคับเรื่องความยากของ Password เพื่อเพิ่มความยากในการคาดเดา เช่นการบังคับให้ 1. Password ที่ยอมรับได้ต้องมีความยาวอย่างน้อย 8 ตัวอักษร 2. ต้องมีตัวพิมพ์ใหญ่, ตัวพิมพ์เล็ก, ตัวเลข และ ตัวอักษรพิเศษ
ถัดมาคือ ข้อควรระวังในการจัดการ Password การบังคับให้ใช้ Password ที่ยากต่อการคาดเดามากๆ ทำให้ยากต่อการจำของผู้ใช้งานด้วย ส่งผลให้ผู้ใช้งานส่วนใหญ่ อาจเพียงแค่ใช้ตัวพิมพ์ใหญ่แค่ตัวอักษรตัวแรก รวมถึงใส่ตัวเลขและตัวอักษรพิเศษต่อท้ายเท่านั้น และที่แย่กว่านั้นคือการที่ Password ยากมากๆ ทำให้ผู้ใช้งานบางคนอาจจด Password ของตัวเองไว้บนกระดาษหรือโน๊ตในโทรศัพท์ ซึ่งทำให้เกิดความไม่ปลอดภัยมากกว่าเดิม รวมไปจนถึงกฏการ Reset Password ที่บาง Application บังคับห้ามใช้ Password ที่เคยใช้ จุดประสงค์ถือว่าดี แต่ในทางกลับกัน ผู้ใช้งานมักใช้วิธีการใส่ตัวเลขต่อท้าย Password เดิมแทน ซึ่งไม่ได้ช่วยให้มีความปลอดภัยมากขึ้นสักเท่าไหร่
ถัดไป
ย้อนกลับ
การออกแบบระบบ Authentication และ Password Management ที่ดี
1. ควรมีการบังคับให้ใช้ Password ที่มีความยากต่อการคาดเดา แต่ไม่ควรบังคับด้วยกฏที่มากจนเกินไป ทั้งนี้ขึ้นกับรูปแบบของแต่ละ Application ว่าควรออกแบบอย่างไร เช่น ควรมีการบังคับเรื่องการเปลี่ยน Password ไม่ให้ใช้ซ้ำย้อนหลังไปได้กี่ครั้ง 2. ระบบ Reset Password ควรใช้วิธีส่ง link สำหรับ reset password ไปยัง Email ของผู้ใช้งาน โดย link นั้นต้องมีระยะเวลาหมดอายุ เพื่อป้องกันหาก ผู้โจมตีสามารถเข้าถึง Email ของผู้ใช้งานได้ ก็จะทำให้ reset password ของผู้ใช้งานของ Application เราไม่ได้ถ้า link นั้นหมดอายุไปแล้ว 3. จำกัดจำนวนครั้งในการ Log in ที่ผิดพลาดก็เป็นสิ่งที่ควรนำมาใช้กับระบบ Authentication เพื่อป้องกันการสุ่มเดา Password ไปเรื่อย ๆ หลาย ๆ ครั้ง (Brute-Force Attack) 4. มีการทำ Session Timeout หาก Log in ทิ้งไว้นานโดยไม่มีการใช้งาน 5. เลือกใช้ HTTPS และ mark cookies เป็น "Secure" เพื่อป้องกันการดักจับข้อมูลระหว่างการส่งข้อมูล เช่น การส่ง password ในขั้นตอน Authentication 6. การจัดเก็บ Passsword ไม่ควรจัดเก็บ Password ในรูปของ Plaintext ควรใช้อัลกอริทึม one-way hashing เพื่อเข้ารหัส Password ที่จัดเก็บไว้เสมอ (one-way hashing เป็นอัลกอริทึมเข้ารหัสทางเดียว ที่ไม่สามารถถอดกลับมาเป็นข้อความต้นทางได้) เพื่อป้องกันหาก database ถูก hack รวมถึงการใส่ค่า Salt เพิ่มเข้าไปในขั้นตอนการ hash ด้วย (Salt คือค่า random ที่มักถูกใช้เพิ่มเข้าไปในการทำ hashing password เพื่อป้องกันการโจมตีด้วย dictionary attack และ rainbow table attack)
ย้อนกลับ
ถัดไป
07
Question 03
Password Hashing คืออะไร
อัลกอริทึมการเข้ารหัสทางเดียว ใช้เพื่อเข้ารหัสและเก็บค่า hash ไว้แทนการเก็บค่า password โดยตรง
อัลกอริทึมการเข้ารหัสทางเดียว ใช้เพื่อเข้ารหัสระหว่างส่งข้อมูลระหว่าง Client-Server
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
Privilege Escalation
คือการโจมตีอีกรูปแบบของช่องโหว่ Identitification and Authentication Failures โดยคือ การที่ผู้โจมตีสามารถหลอกระบบเพื่อให้ระบบมอบสิทธิ์หรือการเข้าถึงข้อมูลของ User อื่น ในบริบทของเว็บไซต์ การเพิ่มระดับสิทธิ์อาจเกิดขึ้นเมื่อเซิร์ฟเวอร์ทำการตัดสินใจในการควบคุมการเข้าถึงโดยอิงตาม Input ที่ไม่น่าเชื่อถือที่ return โดยเบราว์เซอร์
ถัดไป
Privilege Escalation
มาดูวิธีการที่ผู้โจมตีอาจใช้ HTTP request เพื่อทำการยกระดับสิทธิ์ เมื่อ User Login เข้าสู่เว็บไซต์ จะเกิดการสร้าง Session โดย Browser กับ Server จะแลกเปลี่ยน Session Identifier กัน เพื่อให้ Server รู้ว่ากำลังติดต่ออยู่กับใครผ่าน HTTP request โดยทั่วไป Session State จะถูกส่งผ่านไปยัง Browser ใน Set-Cookie header HTTP request และ Browser จะส่งคืนข้อมูลเดิมกลับมาที่ Cookie header อย่างไรก็ตาม Cookies ถือเป็น Input ที่ไม่น่าเชื่อถือ ผู้โจมตีสามารถแก้ไขค่าของ Cookie ที่ return ได้อย่างง่ายดาย เว้นแต่จะมีการทำการป้องกันการปลอมแปลง Cookie
Note: เมื่อผู้โจมตีสามารถสวมรอยเป็น User อื่นได้ จะเรียกการยกระดับสิทธิ์ที่เป็นการเข้าถึง User อื่นในระดับเดียวกันนี้ว่า Horizontal Escalation
ผู้โจมตีสามารถแก้ไขค่า user_id ให้เป็นค่าอื่นได้ ทำให้สามารถปลอมแปลงหรือสวมรอยเป็น User อื่นได้
ย้อนกลับ
ถัดไป
Privilege Escalation
อีกหนึ่งวิธีที่ใช้ส่ง State ระหว่าง Client-Server คือการใช้ HTML forms โดย User เป็นคน submit form และ POST request จะถูกส่งไปยัง Server ซึ่งค่าที่ทำการส่งผ่าน HTML forms ก็สามารถถูกปลอมแปลงหรือแก้ไขได้เช่นกัน ดังนั้นเราจึงควรมองข้อมูลที่ได้รับจาก forms เป็นข้อมูลที่ไม่น่าเชื่อถือด้วย จนกว่าเราจะสามารถตรวจสอบให้แน่ชัดได้ว่าข้อมูลที่ส่งเข้ามาไม่เป็นอันตราย ตัวอย่างเช่นการเขียน HTML form ให้ระบุถึงข้อมูลการเข้าถึงภายใน hidden form field ดังภาพ
Note: เมื่อผู้โจมตีสามารถสวมรอยเป็น Admin ได้ จะเรียกการยกระดับสิทธิ์ที่เป็นการเข้าถึงสิทธิ์ที่สูงกว่าเดิมนี้ว่า Vertical Escalation
ภายใน hidden form field มีการแสดงถึง role ที่เป็น user ถ้าหากผู้โจมตีทำการแก้ไขค่า value จาก "user" เป็น "admin" ก็อาจทำให้สามาถเข้าถึงสิทธิ์ Admin ได้
ย้อนกลับ
ถัดไป
07
Question 04
Vertical Escalation คืออะไร
การยกระดับสิทธิ์ที่เป็นการเข้าถึง User อื่นในระดับเดียวกัน
การยกระดับสิทธิ์ที่เป็นการเข้าถึงสิทธิ์ที่สูงกว่าเดิม
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Privilege Escalation
1. ไม่ควรตัดสินการให้การเข้าถึงต่าง ๆ โดยอิงจากข้อมูลที่ไม่น่าเชื่อถือ (เช่นข้อมูล Cookies และ ข้อมูล Input จาก HTML forms) 2. ควรจัดเก็บ Session State ไว้ที่ฝั่ง Server 3. ควรมีการตรวจสอบให้แน่ใจว่า Cookies มีการป้องกันการปลอมแปลงโดยใช้ Digital Signature (ในปัจจุบัน หลาย ๆ frameworks สามารถเข้ารหัส Session State ด้วย Digital Signature ได้) 4. ไม่ควรส่งข้อมูลที่สำคัญไปยังฝั่ง Client หากไม่จำเป็นจริง ๆ
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
08 Software and Data Integrity Failures
อันดับที่ 8 ความล้มเหลวของซอฟต์แวร์และความถูกต้องของข้อมูล
08 Software and Data Integrity Failures
ช่องโหว่นี้เป็นช่องโหว่ที่ถูกเพิ่มเข้ามาใหม่ใน 2021 เนื่องจากในปัจจุบัน มีการใช้งาน CI/CD pipelines ที่แพร่หลาย โดยช่องโหว่นี้เป็นช่องโหว่ของการติดตั้ง software หรือการถูกสอดแทรก Code บางอย่างมารันตอน integration โดยไม่ได้ตั้งใจ ซึ่งจะโฟกัสไปที่ CI/CD pipelines ที่สามารถใส่คำสั่ง (code) เพื่อทำการควบคุมทั้งระบบได้ ซึ่งในหลายๆ Application ได้ทำ Auto Update Function ไว้แต่ไม่มีการตรวจสอบความถูกต้องของ Function ทำให้ผู้โจมตีสามารถอัพโหลด Code สำหรับอัพเดทขึ้นไปเพื่อรันทั้งแอพพลิเคชันได้
ถัดไป
CI/CD Pipelines คืออะไร
CI/CD คือ กระบวนการหนึ่งที่ช่วยในการพัฒนา Software ให้มีประสิทธิภาพมากขึ้น โดยช่วยลดระยะเวลาและเพิ่มคุณภาพในการพัฒนา Application
CI หมายถึง Continuous Integration คือกระบวนการที่จัดการ Source Code ของเราให้ผ่านกระบวนการการ Testing, Building เพื่อให้แน่ใจว่า Source Code สามารถใช้งานได้จริง ไม่มีข้อผิดพลาด
CD ย่อมาจาก Continuous Deployment คือกระบวนการที่ช่วยเหลือให้เราสามารถ Deploy Software ของเราได้อย่างมีประสิทธิภาพ โดยการนำ Source Code ที่ผ่านการ Build และ Testing มาแล้ว ซึ่งอาจอยู่ในรูปแบบที่แตกต่างกัน เช่น JAR file, Static file หรือแม้กระทั่ง Container Image ให้จัดการ Deploy ขึ้นไปอยู่บน Server ตามที่เราต้องการและสามารถใช้งานได้อย่างถูกต้อง
ย้อนกลับ
ถัดไป
ช่องโหว่ที่มักเกิดขึ้น
Note: checksums คือข้อมูลขนาดคงที่ ที่ถูกคำนวณขึ้นจากกลุ่มข้อมูลดิจิทัลที่ถูกเลือกมาโดยเจตนา โดยมีเพื่อประโยชน์ในการหาข้อผิดพลาดที่อาจเกิดขึ้นได้ระหว่างการรับส่งหรือการจัดเก็บข้อมูล
1. การ Upgrade Software โดยไม่ตรวจสอบความเข้ากันได้ของ Software 2. การทำ CI/CD Pipelines ที่ไม่ได้มีการทดสอบการทำงานร่วมกัน หรือปล่อยให้คนนอกเข้าถึงได้ 3. ไม่ได้ทำการตรวจสอบ Digital Signature เวลาลง Software ใดๆ ว่ามาจากต้นทางตัวจริง 4. ไม่มีการใช้ checksums เพื่อตรวจสอบความสมบูรณ์ของข้อมูล
ย้อนกลับ
ถัดไป
08 Software and Data Integrity Failures
08
Question 01
ข้อใดถือเป็นช่องโหว่ Software and Data Integrity Failures
การทำ CI/CD Pipelines ที่ไม่ได้มีการทดสอบการทำงานร่วมกัน
การทำ CI/CD Piplines ที่มีกำหนดสิทธิ์ผู้ที่เข้าถึงได้
ถูกทั้ง 2 ข้อ
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Software and Data Integrity Failures
1. ไม่ใช้ Software ที่ Version ยังไม่ Stable 2. ใช้งาน Software Repository ที่เชื่อถือได้เท่านั้น 3. มีการ Review กระบวนการ CI/CD และการเปลี่ยน configuration ให้สิทธิ์เฉพาะบุคคลที่ควรเข้าถึงได้เท่านั้น เพื่อป้องกันการแทรก Code ที่เป็นอันตรายเข้ามาโดยผู้โจมตี 4. checksum hashes file ที่ Download มาทุกครั้งก่อน Install
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
09 Security Logging and Monitoring Failures
อันดับที่ 9 ความล้มเหลวของการทำบันทึกเหตุการณ์และการเฝ้าระวัง
09 Security Logging and Monitoring Failures
ช่องโหว่นี้เป็นช่องโหว่ที่เกิดจากการ Monitor logs ที่ไม่เหมาะสม ไม่มีการเก็บ log ของ API และข้อมูล Log ถูกจัดเก็บไว้ในที่จัดเก็บข้อมูลของเครื่องเท่านั้นโดยตัว Application ไม่มีการ log แบบ real time ทำให้ไม่สามารถตรวจสอบและแจ้งเตือนการโจมตีได้ในขณะที่ใช้งานได้ การจัดทำ Log Server เพื่อใช้เก็บ Log หรือบันทึกเหตุการณ์ที่เกิดขึ้นจึงเป็นสิ่งที่ควรกระทำ โดยเฉพาะ Log ที่เกี่ยวข้องกับด้าน Security โดย Log Server มีหน้าที่รวมศูนย์และจัดเก็บไฟล์ log จากแหล่งต่างๆเพื่อให้สามารถดูได้ในที่เดียว แต่ไม่ได้มีหน้าที่ตรวจสอบเครือข่ายหรือระบบเพื่อหากิจกรรมที่เป็นอันตราย (การตรวจสอบเครือข่ายเป็นหน้าที่ของ IPS/IDS)
ถัดไป
09 Security Logging and Monitoring Failures
09
Question 01
ข้อใดเป็นการป้องกันช่องโหว่ในด้าน Security Logging and Monitoring Failures
ลดความถี่ในการตรวจสอบ log เพื่อให้ workload ลดลง
ดำเนินการทำ log บันทึกที่ครอบคลุมเหตุการณ์ด้านความปลอดภัย
ปิดใช้งานการแจ้งเตือนเพื่อหลีกเลี่ยงการรบกวนที่ไม่จำเป็น
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Security Logging and Monitoring Failures
1. ควรมีการจัดทำ Log Server เพื่อใช้เก็บ Log หรือบันทึกเหตุการณ์ที่เกิดขึ้นจึงเป็นสิ่งที่ควรกระทำ โดยเฉพาะ Log ที่เกี่ยวข้องกับด้าน Security 2. ควรจัดให้มีการ Monitor หรือการสอดส่องตรวจสอบ Log ว่ามีสิ่งผิดปกติเกิดขึ้นหรือไม่และอย่างไร 3. การใช้ IPS/IDS ซึ่งเป็นเครื่องมือตรวจสอบแบบ Automate ก็เป็นสิ่งที่ควรคำนึงถึง เพื่อลดการทำงานของบุคลากรลง 4. ควรมีการจัดทำแผนการรับมือ หากเจอเหตุการณ์ที่ผิดปกติจาก Log ว่าควรมีมาตรการรับมืออย่างไร
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
ทำการศึกษาช่องโหว่ทั้ง 10 อันดับ
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
10 Server-Side Request Forgery (SSRF)
อันดับที่ 10 การปลอมแปลง Request ฝั่ง Server
10 Server-Side Request Forgery (SSRF)
ช่องโหว่นี้เกี่ยวข้องกับการปลอมแปลง request ฝั่ง server ซึ่งเกิดจากการอนุญาตให้มีการ fetch ข้อมูลจากฝั่ง server เองจากภายนอกมาใช้งาน
โดยช่องโหว่นี้มีความคล้ายกับช่องโหว่ Injection เนื่องจากเกี่ยวข้องกับการรับข้อมูล Input จาก User เข้ามาประมวลผลโดยไม่ได้ทำการตรวจสอบและจัดการข้อมูล Input ให้ดี ทำให้ผู้โจมตีสามารถ fetch ข้อมูลของ Server ออกมาได้ ซึ่งทำให้ข้อมูลนั้นรั่วไหลหรือถูกบิดเบือนโดยผู้โจมตีได้
ถัดไป
10 Server-Side Request Forgery (SSRF)
10
Question 01
ข้อใดคือลักษณะหลักของการโจมตีด้วย Server-Side Request Forgery (SSRF)
การกระจายการตอบกลับของ Server ปลอม ไปยัง Client
ใช้วิธี Brute-Force Attack ในการโจมตี Server
การเข้าถึงและบิดเบือนทรัพยากรฝั่ง Server โดยผู้โจมตีภายนอก
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com
เว็บไซต์นี้อนุญาตให้กรอก URL ลงในช่องกรอกข้อมูล เพื่อทำการ fetch คอนเทนต์ ที่อยู่ใน URL นั้น เช่น รูปภาพ โดยเว็บไซต์นี้มีช่องโหว่ Server-Side Request Forgery (SSRF) เนื่องจากไม่มีการตรวจสอบและจัดการข้อมูล Input ที่เป็น URL นั้นให้ดี
ลองใส่ค่า URL แปลกๆลงไปดีกว่า
Please enter URL
View
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com
ผู้โจมตีกรอก URL ลงบนช่องกรอกข้อมูล URL ของเว็บไซต์ เช่น http://localhost/admin_panel ซึ่งเป็น URL ที่เข้าถึงหน้าการดูแลระบบภายในเซิร์ฟเวอร์ (URL นี้เป็นเพียงตัวอย่างเท่านั้น ในการโจมตีจริง อาจไม่ใช่ URL นี้ที่สามารถเข้าถึงหน้าการดูแลระบบได้)
http://localhost/admin_panel
View
ย้อนกลับ
ถัดไป
ตัวอย่างของ Server-Side Request Forgery (SSRF)
http://www.example.com/view
ผู้โจมตีสามารถมองเห็นข้อมูลในหน้าการดูแลระบบภายในเซิร์ฟเวอร์ได้ เนื่องจากระบบไม่มีการตรวจสอบข้อมูล Input URL ให้ดี ทำให้หน้าต่างนี้ถูก fetch ออกมาและมองเห็นได้โดยผู้ที่ไม่มีสิทธิ์
ย้อนกลับ
ถัดไป
10
Question 02
ข้อความด้านล่าง ถูกหรือผิด เกี่ยวกับความแตกต่างระหว่างช่องโหว่ Server-Side Request Forgery (SSRF) และ Injection
Injection คือการใส่ Code, Command หรือ Query เพื่อให้ระบบประมวลผลและทำงานผิดไปจากที่ควรจะเป็น ส่วน SSRF เป็นการหลอก Server โดยทำการขอ Request ไปยังทรัพยากรภายนอกหรือภายในเพื่อเข้าถึงข้อมูลหรือแก้ไขข้อมูลสำคัญ
ถูก
ผิด
ยอดเยี่ยม! คำตอบถูกต้อง
ไปกันต่อได้เลย!
ถัดไป
การป้องกันช่องโหว่ Server-Side Request Forgery (SSRF)
1. การทำ Input Validation หรือการตรวจสอบ Input ของ User เพื่อให้แน่ใจว่า URL ที่กรอกเข้ามานั้นปลอดภัย และมีจุดประสงค์ที่ถูกต้องตามที่ควรจะเป็น 2. การทำ Whitelisting หรือการกำหนด Domains หรือ URL ที่อนุญาตให้ Server เข้าถึงและ fetch ข้อมูลได้ โดยกำหนด Domains หรือ URL ให้เฉพาะที่เชื่อถือได้เท่านั้น ทั้งนี้รวมถึงการทำ Blacklisting เพื่อทำการบล็อค Domains หรือ URL ที่อาจเป็นอันตราย 3. การทำ URL Parsing โดยใช้ Libraries ที่มีอยู่ของภาษาที่เขียนโปรแกรมหรือ Framework ที่ใช้ เพื่อให้แน่ใจว่า URL ที่รับมานั้นอยู่ในรูปแบบที่ถูกต้องและเป็นที่ยอมรับ 4. การใช้หลัก Least Privilege หรือการให้สิทธิ์การเข้าถึงเท่าที่จำเป็น โดยอาจกำหนดว่าข้อมูลสำคัญบน Server สามารถเข้าถึงได้เฉพาะ Admin และจะปฏิเสธ Request เพื่อเข้าถึงข้อมูลนั้นหากไม่สามารถระบุได้ว่าผู้ร้องขอคือ Admin จริง
ยอดเยี่ยม! คุณได้ผ่านหัวข้อนี้แล้ว!
ไปกันต่อได้เลย!
ถัดไป
OWASP TOP 10 - 2021
01 Broken Access Control
02 Cryptographic Failures
04 Insecure Design
03 Injection
05 Security Misconfiguratoin
07 Identification and Authentication Failures
08 Software and Data Integrity Failures
09 Security Logging and Monitoring Failures
10 Server-Side Request Forgery (SSRF)
06 Vulnerable and Outdated Components
ถัดไป
Congratulation
ยอดเยี่ยมมาก! คุณได้ผ่านเนื้อหาครบทุกบทเรียนแล้ว!
เราหวังเป็นอย่างยิ่งว่า เนื้อหาความรู้ที่คุณได้เรียนไปในบทเรียนนี้ จะเป็นประโยชน์แก่คุณ เราขออวยพรให้คุณโชคดีในการสอบวัดผล
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ
น่าเสียดาย! คำตอบผิด
ลองใหม่อีกครั้ง!
กลับ