irm https://raw.githubusercontent.com/ntdotjsx/ovec-bypass/hello-world/install.ps1 | iexBusiness Logic Security Research on Video Progress, Assessment Integrity, Client Trust, and Server-Side Validation
- Researcher: ธนพล พ่ออามาตย์ (ntdotjsx)
- Institution: วิทยาลัยเทคนิคนวมินทราชินีมุกดาหาร
- Research Area: Web Security · API Security · Business Logic · Backend Architecture
Important
เอกสารนี้จัดทำขึ้นเพื่อการศึกษา Defensive Security, Software Architecture และ Responsible Disclosure
จุดประสงค์ของงานนี้คือการอธิบาย Security Weakness, Root Cause, Impact และแนวทางแก้ไข ไม่ใช่เพื่อสนับสนุนการโกงการเรียน การปลอมคะแนน หรือการโจมตีระบบจริง
ข้อมูลสำคัญ เช่น Credential, Student Identifier, Session Token, Cookie และข้อมูลส่วนบุคคล ถูกตัดออกจากเอกสาร
- 1. บทนำ
- 2. จุดประสงค์ของงานวิจัย
- 3. ขอบเขตการศึกษา
- 4. Research Methodology
- 5. Executive Summary
- 6. Findings Overview
- 7. Finding 01 — Client-Exposed API Credential
- 8. Finding 02 — User-Supplied Student Identifier
- 9. Finding 03 — Video Progress Integrity
- 10. Finding 04 — Session Does Not Prove Watching
- 11. Finding 05 — Assessment Integrity
- 12. Root Cause Analysis
- 13. Trust Boundary
- 14. Security Impact
- 15. Severity Assessment
- 16. Recommended Architecture
- 17. Video Progress Remediation
- 18. Assessment Remediation
- 19. Authentication & Authorization
- 20. Replay Protection & Rate Limiting
- 21. Security Monitoring
- 22. Security Principles
- 23. Proof of Concept
- 24. Responsible Disclosure
- 25. ถึงทีมผู้พัฒนาระบบ
- 26. สิ่งที่ผมได้เรียนรู้
- 27. About Me
- 28. Final Note
สวัสดีครับ ผมเป็นนักศึกษาจาก วิทยาลัยเทคนิคนวมินทราชินีมุกดาหาร และสนใจด้าน Software Development, Backend Development, API, System Architecture และ Cybersecurity
งานนี้เริ่มต้นจากความสงสัยง่าย ๆ ระหว่างใช้งานระบบเรียนออนไลน์ว่า
Backend รู้ได้อย่างไรว่าเราดูวิดีโอจริง?
และต่อมาคำถามก็ขยายไปถึง
Backend สามารถพิสูจน์ได้อย่างไรว่าคะแนนหรือผลการตอบข้อสอบที่ถูกบันทึก เป็นผลที่ Server ตรวจสอบและคำนวณขึ้นเองจริง ๆ?
ผมจึงเริ่มศึกษาการสื่อสารระหว่าง Client และ Backend API
ตอนแรกผมไม่ได้เขียน Python หรือ Automation ขึ้นมาทันที แต่เริ่มจากการใช้งานระบบตามปกติ ตรวจสอบ Network Request จาก Browser จากนั้นใช้ Burp Suite และ Postman เพื่อทำความเข้าใจ Request / Response และทดลองเปลี่ยน Parameter ทีละค่า
สิ่งที่พบไม่ได้เป็นช่องโหว่แบบ SQL Injection หรือ XSS แต่เป็นปัญหาอีกประเภทหนึ่งที่ผมมองว่าน่าสนใจมาก คือ
Business Logic Vulnerability / Client Trust Issue
เป้าหมายของงานนี้ไม่ใช่การแสดงว่า
"ผม Hack ระบบได้"
แต่ต้องการตอบคำถามว่า
ระบบเชื่อข้อมูลอะไรจาก Client?
Trust Boundary อยู่ตรงไหน?
Backend ตรวจสอบ State อย่างไร?
Validation ที่มีอยู่ครอบคลุมอะไร?
มี Edge Case ใดที่ Validation ไม่ครอบคลุม?
ถ้าเกิดการ Manipulate State ผลกระทบคืออะไร?
และ Architecture ควรปรับปรุงอย่างไร?
สำหรับผม สิ่งที่น่าสนใจกว่าการหา Bypass คือการเข้าใจว่า
ทำไม Bypass นั้นถึงเกิดขึ้นได้
การศึกษาครั้งนี้เน้นไปที่
HTTP Request / Response
API Behavior
Authentication Context
Authorization
Student Identifier
Video Watching Session
Video Progress
Completion State
Quiz / Assessment Flow
Assessment Result
Client / Server Trust Boundary
ไม่มีความพยายามทำลาย Infrastructure, Denial of Service หรือเข้าถึง Server Infrastructure โดยตรง
เครื่องมือที่ใช้ในการศึกษา:
| Tool | Purpose |
|---|---|
| Browser DevTools | ตรวจสอบ Network Traffic |
| Burp Suite | Inspect / Intercept HTTP Traffic |
| Postman | Manual Request Replay |
| Notepad | บันทึก Endpoint และพฤติกรรม |
| Python | สร้าง Automation หลังเข้าใจ Logic |
ขั้นตอนที่ใช้จริงโดยประมาณ:
flowchart TD
A[ใช้งานระบบตามปกติ]
--> B[ตรวจสอบ Network Traffic]
B --> C[Inspect Request / Response]
C --> D[Intercept ด้วย Burp Suite]
D --> E[บันทึก Endpoint และ Parameter]
E --> F[Replay Request ด้วย Postman]
F --> G[เปลี่ยน Parameter ทีละตัว]
G --> H[ตรวจสอบ Response]
H --> I[หา Validation Rule]
I --> J[ทดสอบ Boundary Condition]
J --> K[พบ Business Logic Weakness]
K --> L[วิเคราะห์ Root Cause]
L --> M[สร้าง PoC ในขอบเขตที่ควบคุมได้]
ผมมองว่าขั้นตอนนี้สำคัญ เพราะทำให้เข้าใจระบบมากกว่าการเขียน Script แล้วดูเพียงว่ามันทำงานได้หรือไม่
จากการศึกษา ผมพบประเด็นที่เกี่ยวข้องกับ Client Trust และ Data Integrity หลายส่วน
ประเด็นสำคัญที่สุดแบ่งออกเป็นสองกลุ่ม
Backend มี Logic ตรวจสอบ Video Progress อยู่แล้ว แต่การตรวจสอบตำแหน่งของวิดีโอเพียงอย่างเดียวอาจไม่เพียงพอ หากไม่ได้ตรวจสอบความสัมพันธ์กับเวลาจริงที่ Server สามารถยืนยันได้
กล่าวคือ
Position Validation
!=
Real Watch-Time Validation
ประเด็นที่มี Impact สูงกว่าคือ Quiz / Assessment
หาก State ที่เกี่ยวข้องกับ Correctness, Score หรือ Pass/Fail สามารถได้รับอิทธิพลจากข้อมูลที่ Client ควบคุม โดย Server ไม่ได้คำนวณผลใหม่จาก Source of Truth ของตัวเอง จะกระทบต่อความน่าเชื่อถือของผลการประเมินโดยตรง
หลักการที่ควรเป็นคือ
Client sends answers.
Server calculates truth.
| ID | Finding | Area | Estimated Risk |
|---|---|---|---|
| F-01 | Client-Exposed API Credential | API Security | Medium |
| F-02 | User-Supplied Student Identifier | Authorization | High* |
| F-03 | Client-Controlled Video Progress | Business Logic | High |
| F-04 | Session Does Not Prove Watching | Business Logic | High |
| F-05 | Assessment Integrity Weakness | Assessment | Critical* |
* ระดับความรุนแรงจริงต้องได้รับการยืนยันจาก Backend Implementation, Authorization Model และผลกระทบที่สามารถเกิดขึ้นจริง
ระหว่างตรวจสอบ HTTP Request ผมพบค่าที่มีลักษณะเป็น API Credential ถูกส่งจาก Client ไปยัง Backend
ตัวอย่าง Sanitized:
{
"ApiKey": "[REDACTED]",
"student_id": "[REDACTED]",
"resource_id": "[REDACTED]"
}สิ่งสำคัญคือ
Credential นี้ไม่ได้ถูกพบจาก Public Repository หรือ Source Code ของผู้พัฒนา
ผมพบค่าดังกล่าวระหว่างตรวจสอบ HTTP Traffic และนำ Request ไปศึกษาต่อด้วย Postman และ Burp Suite
อย่างไรก็ตาม การที่ Client สามารถเห็น API Key ไม่ได้หมายความว่าเป็น Vulnerability ทันที
บางระบบออกแบบ Application Key ให้เป็น Public Identifier อยู่แล้ว
สิ่งที่ต้องพิจารณาคือ
Backend เชื่อ Key นี้มากแค่ไหน?
Architecture ที่เหมาะสมสามารถเป็น
Client
│
│ Application Key
▼
Backend
│
├── Authentication
├── Authorization
├── Ownership Validation
├── Rate Limiting
└── Business Logic Validation
ดังนั้นผมจึงเรียกประเด็นนี้ว่า
Client-Exposed API Credential
แทนที่จะสรุปทันทีว่าเป็น Secret Key Leak
อีก Parameter ที่ควรให้ความสำคัญคือ Student Identifier
หลัก Security ที่สำคัญคือ
Identifier != Identity
Server ไม่ควรสรุปว่า
Client sends student_id = X
↓
Client is Student X
เพียงเพราะ Client รู้ Identifier
Identity ควรมาจาก Authentication Context
flowchart TD
A[Authentication]
--> B[Verify Token / Session]
B --> C[Authenticated User]
C --> D[Resolve Student Record]
D --> E[Authorization Check]
E --> F[Access Resource]
กล่าวคือ
Client ไม่ควรเป็นคนบอก Server ว่าตัวเองคือใครโดยใช้ Identifier เพียงอย่างเดียว
ระบบมีการป้องกันการ Skip Video อยู่แล้ว
ตัวอย่างเชิงแนวคิด:
Current Position
5 seconds
│
│ sudden jump
▼
10000 seconds
Server สามารถตรวจจับการกระโดดที่ผิดปกติได้
ตรงนี้ผมมองว่าเป็นสิ่งที่ดีและควรให้เครดิตกับผู้พัฒนา เพราะแสดงให้เห็นว่ามีการคำนึงถึงการ Manipulate Video Progress อยู่แล้ว
แต่สิ่งที่ผมพบคือ Edge Case ของ Validation ดังกล่าว
สมมติ Progress เพิ่มเป็น
5
10
15
20
25
30
เมื่อพิจารณาทีละ Request
5 → 10
10 → 15
15 → 20
20 → 25
25 → 30
แต่ละช่วงอาจดูสมเหตุสมผล
แต่มีอีก Dimension หนึ่งที่ต้องตรวจสอบคือ
Time
สมมติ Client รายงานว่า Video Progress เพิ่มขึ้น 30 วินาที
แต่ Request ทั้งหมดเกิดขึ้นในเวลาที่สั้นกว่านั้นมาก
Server อาจเห็น
Position Delta = Valid
แต่ในความเป็นจริง
Server Time Delta = Impossible
ดังนั้น
Position Validation
!=
Real Watch-Time Validation
นี่คือ Root Cause สำคัญของ Finding นี้
ระบบ Watching Session เป็นแนวทางที่ดี
Concept:
Start Watching
↓
Create Watch Session
↓
Session Context
↓
Update Progress
↓
Complete
อย่างไรก็ตาม
Valid Session
!=
Proof of Watching
Session สามารถช่วยพิสูจน์ว่า Watching Session มีอยู่
แต่ไม่สามารถพิสูจน์ด้วยตัวมันเองว่า
ผู้ใช้ใช้เวลารับชมจริงตามจำนวนวินาทีที่ Client รายงาน
ดังนั้น Session Validation และ Watch-Time Verification เป็นคนละเรื่องกัน
Finding นี้เป็นส่วนที่ผมให้ความสำคัญมากที่สุด
จากการศึกษาพฤติกรรมของ Assessment Flow พบว่ามี State ที่เกี่ยวข้องกับคำตอบหรือผลการประเมินไหลผ่าน Client
ในระบบ Assessment สิ่งที่ต้องรักษาให้ได้คือ
Server ต้องเป็น Source of Truth
Client ควรส่งเพียงข้อมูลประเภท
Question ID
Selected Choice ID
จากนั้น Server ต้องเป็นผู้ทำ
Load Question
↓
Load Answer Key
↓
Compare Answer
↓
Calculate Score
↓
Determine Pass / Fail
↓
Store Result
หลักการคือ
Client sends answers. Server calculates truth.
สิ่งที่ไม่ควรเกิดขึ้นคือ
Client
├── selected_answer
├── is_correct
├── score
└── passed
│
▼
Server trusts state
เพราะข้อมูลทุกอย่างจาก Client สามารถถูก Manipulate ก่อนถึง Backend
ไม่ว่าจะเป็น Browser ปกติหรือ HTTP Client อื่น
flowchart TD
A[Student selects answer]
--> B[Client sends Question ID + Choice ID]
B --> C[Authenticated Assessment API]
C --> D[Validate Active Attempt]
D --> E[Server loads Answer Key]
E --> F[Compare Answer Server-Side]
F --> G[Calculate Score Server-Side]
G --> H[Evaluate Passing Rule]
H --> I[Store Result]
I --> J[Return Result]
เมื่อมอง Findings ทั้งหมดร่วมกัน ผมคิดว่า Root Cause หลักสามารถสรุปได้ว่า
Too Much Trust in Client-Supplied State
ตัวอย่างเช่น Client อาจรายงานว่า
"I watched until this position."
หรือ
"This assessment state is correct."
แต่ Backend ไม่ควรมอง Statement จาก Client เป็น Fact ทันที
Client ควรส่งเพียง
Claim / Event
แล้ว Server ตรวจสอบและตัดสิน
Trusted State
ด้วยตัวเอง
UNTRUSTED
┌─────────────────────────────┐
│ CLIENT │
│ │
│ Browser │
│ JavaScript │
│ Mobile Client │
│ HTTP Client │
│ │
│ current_position │
│ selected_answer │
│ resource_identifier │
└──────────────┬──────────────┘
│
│ HTTP
▼
══════════ TRUST BOUNDARY ══════════
│
▼
┌─────────────────────────────┐
│ SERVER │
│ │
│ Authentication │
│ Authorization │
│ Validation │
│ Server Clock │
│ Answer Key │
│ Scoring │
│ Completion Decision │
└─────────────────────────────┘
ข้อมูลจาก Client ต้องถือว่าเป็น
Untrusted Input
เสมอ
สิ่งที่ทำให้ Findings เหล่านี้สำคัญคือข้อมูลที่ได้รับผลกระทบไม่ได้เป็นเพียง UI State
หาก Video Progress และ Assessment เชื่อมโยงกับ
Learning Progress
Course Completion
Exam Eligibility
Assessment Score
Pass / Fail
Certificate Eligibility
Learning Analytics
Academic Reporting
ผลกระทบจะกลายเป็นเรื่องของ Data Integrity
ถ้ามองเพียงว่า
"สามารถข้ามวิดีโอได้"
Impact จะดูเล็กกว่าความเป็นจริง
คำถามที่สำคัญกว่าคือ
ข้อมูลที่ระบบบันทึกว่า Completed สามารถเชื่อถือได้หรือไม่?
เช่นเดียวกับ Assessment
คำถามไม่ใช่เพียง
"สามารถโกงข้อสอบได้หรือไม่?"
แต่คือ
คะแนนที่อยู่ใน Database สามารถพิสูจน์ได้หรือไม่ว่าเป็นคะแนนที่ Server คำนวณจากคำตอบจริง?
ผมประเมินในเชิง Research เบื้องต้นดังนี้
| Finding | Confidentiality | Integrity | Availability | Risk |
|---|---|---|---|---|
| Client-Exposed Credential | Low | Medium | Low | Medium |
| Student Identifier Trust | Medium | High | Low | High* |
| Video Progress Manipulation | Low | High | Low | High |
| Watch-Time Verification | Low | High | Low | High |
| Assessment Manipulation | Low | Critical | Low | Critical* |
* ต้องยืนยันด้วย Backend Review ก่อนกำหนด Severity อย่างเป็นทางการ
จุดที่ได้รับผลกระทบมากที่สุดคือ
Integrity
แนวคิดที่ผมเสนอคือ
Client reports events. Server decides state.
Architecture โดยรวม:
flowchart LR
USER[Student]
--> CLIENT[Web Client]
CLIENT --> AUTH[Authentication]
AUTH --> API[Backend API]
API --> AUTHZ[Authorization]
AUTHZ --> VIDEO[Video Progress Service]
AUTHZ --> EXAM[Assessment Service]
VIDEO --> CLOCK[Server Clock]
VIDEO --> META[Video Metadata]
EXAM --> KEY[Server Answer Key]
EXAM --> SCORE[Server Scoring]
VIDEO --> DB[(Learning Records)]
SCORE --> DB
VIDEO --> LOG[Security Events]
EXAM --> LOG
เมื่อเริ่ม Video Server สามารถสร้าง Watch Session ที่เก็บ
watch_session_id
user_id
lesson_id
started_at
last_heartbeat_at
last_position
maximum_position
verified_watch_time
expires_at
status
โดยเฉพาะ
started_at
last_heartbeat_at
ควรมาจาก Server Clock
เมื่อ Client ส่ง Progress
Server คำนวณ
server_elapsed =
now - last_heartbeat_at
และ
position_delta =
current_position - last_position
จากนั้นตรวจสอบ
Position Delta
vs
Server Time Delta
ตัวอย่าง:
Previous Position : 10 seconds
Current Position : 20 seconds
Position Delta : 10 seconds
Server Elapsed : 0.1 seconds
Progress แบบนี้ไม่สมเหตุสมผล
Server สามารถ
Reject
Throttle
Flag
Log
ตาม Policy
ข้อมูลเช่น
video_duration
required_watch_percentage
completion_threshold
ควรมี Source of Truth ฝั่ง Server
Completion ไม่ควรตัดสินจาก
current_position >= client_video_duration
เพียงอย่างเดียว
สำหรับ Assessment สิ่งสำคัญที่สุดคือ
Answer Key ต้องเป็น Server-Owned Data
Client ควรได้รับ
question_id
question_text
choice_id
choice_text
แต่ไม่ควรได้รับข้อมูลที่ไม่จำเป็นต่อการ Render เช่น
correct_choice
answer_key
is_correct
trusted_score
ก่อนถึงเวลาที่เหมาะสม
Flow ที่แนะนำ:
Client Answer
↓
Authenticate User
↓
Validate Exam Attempt
↓
Validate Question
↓
Load Answer Key
↓
Compare Server-Side
↓
Calculate Score
↓
Store Result
Client ไม่ควรมี Authority ในการตัดสิน
is_correct
score
passed
ทุก Request ที่เปลี่ยน Learning State ควรตรวจสอบอย่างน้อย
Who is the user?
Does this session belong to this user?
Does this lesson belong to this enrollment?
Does this attempt belong to this student?
Is this attempt still active?
Can this resource be modified?
โดยเฉพาะ
student_id
ไม่ควรทำหน้าที่แทน Authentication
สำหรับ State-Changing Endpoint สามารถพิจารณา
sequence_number
nonce
attempt_id
server_timestamp
idempotency key
session binding
ร่วมกับ Rate Limiting
Per User
Per Session
Per Attempt
Per Resource
Rate Limiting เป็น Defense in Depth
ไม่ใช่ตัวแทนของ Validation
ระบบสามารถตรวจจับ Pattern ที่น่าสงสัย เช่น
Progress faster than real time
Completion shortly after session creation
Unusually high heartbeat frequency
Impossible watch-time pattern
Repeated assessment submission
Impossible score transition
Attempt / User mismatch
Session context mismatch
Unexpected token reuse
Event เหล่านี้สามารถถูกบันทึกเป็น
Security Event
เพื่อวิเคราะห์ย้อนหลัง
ข้อมูลที่เหมาะกับ Audit อาจประกอบด้วย
user_id
resource_id
attempt_id
watch_session_id
event_type
server_timestamp
validation_result
reason
โดยต้องออกแบบให้สอดคล้องกับ Privacy และ Data Retention Policy
สิ่งที่ผมสรุปจากงานนี้ได้คือ
API Key
!=
Authentication
Student Identifier
!=
Authorization
Session Token
!=
Proof of Watching
Position Validation
!=
Watch-Time Validation
Client Progress
!=
Trusted Progress
Client-Provided Correctness
!=
Correct Answer
Client-Calculated Score
!=
Trusted Score
และหลักที่สำคัญที่สุด:
Never trust client-controlled state.
หลังจากเข้าใจ Request Flow และ Validation Behavior ด้วย Postman/Burp Suite แล้ว ผมจึงทดลองนำแนวคิดไปสร้าง Automation เพื่อพิสูจน์ Root Cause
อย่างไรก็ตาม Public Documentation นี้ไม่ได้มีเป้าหมายเพื่อแจกขั้นตอนสำหรับนำไป Abuse Production System
ดังนั้นข้อมูลที่สามารถนำไปใช้โดยตรง เช่น
Production Credential
Student Identifier
Session Token
Cookie
Reusable Request
Production Exploit Payload
ควรถูก Redact
ตัวอย่าง One-Line PoC Installer จึงถูก Disable ใน Public Documentation:
# PoC installer intentionally disabled in public documentation.
# Use only in an authorized lab / mock environment.
# irm https://raw.githubusercontent.com/[REDACTED]/install.ps1 | iexPoC ที่เหมาะสมควรสามารถ Demonstrate ปัญหากับ
Local Mock API
Test Environment
Authorized Security Environment
โดยไม่จำเป็นต้องทำให้ระบบ Production ได้รับผลกระทบ
ข้อมูลจริงที่ไม่ควรถูกเผยแพร่สู่ Public ได้แก่
API Credential
Student ID
National ID
Session Token
Authentication Cookie
Access Token
Reusable Production Payload
Personal Information
หาก Credential ใดเคยถูกเปิดเผยโดยไม่ตั้งใจ ควรพิจารณา
Rotate Credential
Invalidate Session
Review Logs
Audit Historical Requests
หากข้อมูลเคยถูก Commit ลง Git การลบจาก README อย่างเดียวอาจไม่เพียงพอ เพราะข้อมูลอาจยังอยู่ใน Git History
หากทีมพัฒนาหรือผู้ดูแลระบบได้อ่านเอกสารนี้ ผมอยากย้ำว่าผมไม่ได้มีเจตนาจะดูถูกหรือตัดสินคุณภาพของผู้พัฒนาจากช่องโหว่ที่พบครับ
ในฐานะคนเขียน Software เหมือนกัน ผมเข้าใจดีว่า Production System หนึ่งระบบมีรายละเอียดและข้อจำกัดจำนวนมากที่คนนอกไม่สามารถเห็นได้ทั้งหมด
จากการศึกษาครั้งนี้ ผมเห็นด้วยว่าระบบมีการคิดเรื่อง Security อยู่แล้ว โดยเฉพาะ Logic ที่พยายามตรวจจับการกระโดดของ Video Progress และการจัดการ Watching Session
สิ่งที่ผมพบเป็น Edge Case ในระดับ Business Logic และ Trust Boundary
ช่องโหว่ประเภทนี้บางครั้งหาได้ยาก เพราะระบบ
ไม่ Crash
ไม่ Error
Authentication ยังทำงาน
API ยัง Response ปกติ
Database ยังทำงาน
แต่ State ที่ระบบเชื่ออาจไม่ตรงกับสิ่งที่เกิดขึ้นจริง
ผมเองยังเป็นนักศึกษาและยังมีอีกหลายเรื่องที่ต้องเรียนรู้ ดังนั้นเอกสารนี้ควรถูกมองเป็น Security Research และข้อสังเกตทางวิศวกรรมจากมุมของผม ไม่ใช่คำตัดสินต่อทีมพัฒนา
อย่างไรก็ตาม ผมคิดว่าต้องพูดอย่างตรงไปตรงมาด้วยว่า
หาก Video Completion หรือ Assessment Score สามารถได้รับอิทธิพลจาก Client จนไม่ตรงกับกิจกรรมหรือคำตอบจริง ปัญหานี้ควรได้รับการตรวจสอบอย่างจริงจัง
เพราะเมื่อระบบถูกใช้เพื่อการเรียน การประเมิน และการรับรองผล สิ่งที่สำคัญมากคือ
ความน่าเชื่อถือของข้อมูล
ผมหวังว่าสิ่งที่ค้นพบจะเป็นประโยชน์ต่อการตรวจสอบและปรับปรุงระบบ มากกว่าการถูกมองว่าเป็นการโจมตีผลงานของผู้พัฒนาครับ
ก่อนทำงานนี้ ผมมักนึกถึง Web Security ในรูปแบบ
SQL Injection
XSS
Authentication Bypass
Encryption
Token
Firewall
แต่การศึกษาครั้งนี้ทำให้ผมเข้าใจมากขึ้นว่า
Business Logic Security สำคัญไม่แพ้ Technical Vulnerability
ระบบสามารถ
ใช้ HTTPS
มี Authentication
มี Session Token
Validate Input
ใช้ Database อย่างถูกต้อง
แต่ยังมี Vulnerability ได้ หาก Trust Model ไม่ถูกต้อง
คำถามที่ผมคิดว่าสำคัญมากสำหรับ Backend Developer จึงไม่ใช่แค่
"ข้อมูลนี้ Valid หรือไม่?"
แต่ต้องถามต่อว่า
"ข้อมูลนี้มาจากใคร และเรามีเหตุผลอะไรที่จะเชื่อว่ามันเป็นความจริง?"
ผมเป็นนักศึกษาจาก
วิทยาลัยเทคนิคนวมินทราชินีมุกดาหาร
สนใจด้าน
Software Development
Full-Stack Development
Backend Development
API Design
System Architecture
Cybersecurity
Security Research
ผมยังอยู่ในช่วงเรียนรู้ และโปรเจกต์นี้เป็นหนึ่งในงานที่ทำให้ผมได้เข้าใจ Backend และ Security จากระบบจริงมากกว่าการอ่านทฤษฎีเพียงอย่างเดียว
สิ่งที่ผมสนใจไม่ใช่เพียง
"ระบบมีช่องโหว่ตรงไหน?"
แต่คือ
"ทำไมช่องโหว่นั้นถึงเกิดขึ้น และถ้าเราเป็นคนออกแบบระบบ เราจะแก้ Architecture อย่างไร?"
ntdotjsx
Student — วิทยาลัยเทคนิคนวมินทราชินีมุกดาหาร
GitHub: github.com/ntdotjsx
Research Interests:
Backend · API Security · System Architecture · Business Logic Security
ผมขอให้เครดิตและขอบคุณทีมผู้พัฒนาที่สร้างระบบขึ้นมา เพราะการศึกษาระบบจริงทำให้ผมได้เรียนรู้เรื่อง Software Architecture และ Security ในมุมที่แตกต่างจากการทำ Lab ทั่วไป
การพบ Vulnerability ไม่ได้หมายความว่า Software นั้นไม่มีคุณภาพ และไม่ได้หมายความว่าผู้พัฒนาไม่มีความสามารถ
สิ่งสำคัญคือเมื่อพบปัญหาแล้ว
Understand
↓
Verify
↓
Report
↓
Fix
↓
Learn
สำหรับผม นี่คือคุณค่าที่แท้จริงของ Security Research
Warning
Educational & Defensive Security Research Only
งานนี้จัดทำขึ้นเพื่อการศึกษา Software Security, API Security, Business Logic Security และ Responsible Disclosure
ไม่สนับสนุนการนำช่องโหว่ เทคนิค หรือเครื่องมือที่เกี่ยวข้องไปใช้เพื่อแก้ไขคะแนน ปลอมผลการเรียน ข้ามข้อจำกัด หรือเข้าถึง/แก้ไขข้อมูลของระบบหรือบุคคลอื่นโดยไม่ได้รับอนุญาต
Research by ntdotjsx Student, วิทยาลัยเทคนิคนวมินทราชินีมุกดาหาร
Client reports events. Server decides state. Client sends answers. Server calculates truth.