# สัปดาห์ที่ 12 Lab: การทดสอบความปลอดภัยแบบปฏิบัติการ

## 📋 ภาพรวม

**วัตถุประสงค์:** ทดสอบระบบจัดการห้องสมุดด้วยตนเองเพื่อหาช่องโหว่ด้านความปลอดภัย 11 ประการ
**ผลผลิต:** รายงานการทดสอบความปลอดภัย (บันทึกการค้นพบ)

---

## ข้อกำหนดการตั้งค่า

### ก่อน Lab เริ่มต้น:

1. **ระบบห้องสมุดกำลังทำงาน:**

   ```bash
   cd Library-Management-Teacher
   docker-compose up
   ```

2. **จุดการเข้าถึง:**
   - หลัก: `http://localhost:8080/`
   - เข้าสู่ระบบ: `http://localhost:8080/login.php`

3. **ทดสอบฐานข้อมูล:**
   - มีข้อมูลตัวอย่างแล้ว
   - ข้อมูลรีเซ็ตเมื่อคอนเทนเนอร์เริ่มต้นใหม่

4. **ทดสอบบัญชี:**

   ```
   ชื่อผู้ใช้: teacher1
   รหัสผ่าน: password123
   ```

5. **เครื่องมืออเบราว์เซอร์:**
   - Chrome หรือ Firefox
   - Developer Tools (F12)
   - Postman (ไม่บังคับ สำหรับการทดสอบ API)

---

---

# Exercise 1: SQL INJECTION ในการเข้าสู่ระบบ (10 นาที)

---

## วัตถุประสงค์

ทดสอบว่า login.php เสี่ยงต่อ SQL Injection

## ข้อมูลอ้างอิงข้อบกพร่องความปลอดภัย

**BUG #5:** SQL Injection ในการเข้าสู่ระบบ (login.php:10)

---

## คำแนะนำทีละขั้นตอน

### ขั้นตอนที่ 1: เปิดหน้าเข้าสู่ระบบ

```
1. นำทางไปที่: http://localhost:8080/login.php
2. คุณเห็นแบบฟอร์มเข้าสู่ระบบที่มี:
   - ฟิลด์ชื่อผู้ใช้
   - ฟิลด์รหัสผ่าน
   - ปุ่มเข้าสู่ระบบ
```

### ขั้นตอนที่ 2: ทดสอบการเข้าสู่ระบบปกติ (ควบคุม)

```
1. ป้อน:
   ชื่อผู้ใช้: teacher1
   รหัสผ่าน: password123
2. คลิกเข้าสู่ระบบ
3. ✅ ควรเห็น: หน้าแดชบอร์ด
4. บันทึก: "การเข้าสู่ระบบปกติใช้งานได้"
```

### ขั้นตอนที่ 3: ออกจากระบบ

```
1. คลิกลิงค์ออกจากระบบ
2. ยืนยันว่าคุณกลับมาที่หน้าเข้าสู่ระบบ
```

### ขั้นตอนที่ 4: ทดสอบ Payload ของ SQL Injection 1

```
1. ป้อน:
   ชื่อผู้ใช้: admin' OR '1'='1
   รหัสผ่าน: admin
2. คลิกเข้าสู่ระบบ
3. สังเกตสิ่งที่เกิดขึ้น:
   - ❌ หากการเข้าสู่ระบบประสบความสำเร็จ → **เสี่ยง!**
   - ✅ หากแสดงข้อผิดพลาด → ไม่ใช่ช่องโหว่
```

### ขั้นตอนที่ 5: บันทึกการค้นพบ

**หากเสี่ยง (คาดว่า):**

```
การค้นพบ: SQL Injection ในการเข้าสู่ระบบ
หน้า: login.php
Payload: admin' OR '1'='1' / admin
ความรุนแรง: 🔴 วิกฤติ
ผลกระทบ: ผู้โจมตีสามารถเข้าสู่ระบบโดยไม่ต้องรหัสผ่าน
สาเหตุปัญหา: อินพุตของผู้ใช้ที่ไม่ได้หนีออกในสืบค้น SQL
```

** SQL ที่ถูกดำเนิน:**

```sql
SELECT * FROM users
WHERE username='admin' OR '1'='1'
AND password='admin'
```

**เหตุใดจึงใช้งานได้:**

- `'admin' OR '1'='1'` ประเมินเป็น TRUE
- ตรวจสอบรหัสผ่านจะถูกข้าม
- ส่วนเก็บข้อมูลผู้ใช้ใด ๆ จะถูกส่งกลับ

---

## ผลลัพธ์ที่คาดไว้

✅ **เสี่ยง** - การเข้าสู่ระบบประสบความสำเร็จโดยไม่ต้องรหัสผ่านที่ถูกต้อง

---

## การแก้ไข (สำหรับการอ้างอิง)

```php
// ห้าม:
$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username='$username'...";

// ใช้แทน:
$username = mysqli_real_escape_string($conn, $_POST['username']);
// หรือ ดีกว่า:
$stmt = $conn->prepare("SELECT * FROM users WHERE username=?");
$stmt->bind_param("s", $_POST['username']);
```

---

---

# Exercise 2: SQL INJECTION ในแบบฟอร์มค้นหาและเพิ่ม (15 นาที)

---

## วัตถุประสงค์

ทดสอบเวกเตอร์ SQL Injection หลายตัวทั่วหน้าต่างๆ

---

## 2A: SQL Injection ในการค้นหาหนังสือ

### ข้อมูลอ้างอิงข้อบกพร่องความปลอดภัย

**BUG #12:** SQL Injection ในการค้นหา (books.php:10-14)

### ขั้นตอน:

1. **เข้าสู่ระบบก่อน:**

   ```
   ชื่อผู้ใช้: teacher1
   รหัสผ่าน: password123
   ```

2. **นำทางไปที่หน้าหนังสือ:**

   ```
   URL: http://localhost:8080/books.php
   หรือ คลิก: Books menu → View Books
   ```

3. **ทดสอบด้วยการค้นหาปกติ (ควบคุม):**

   ```
   ค้นหา: "Programming"
   คลิก: Search
   ✅ ผลลัพธ์: แสดงหนังสือที่ตรงกัน
   บันทึก: "การค้นหาปกติใช้งานได้"
   ```

4. **ทดสอบ SQL Injection payload:**

   ```
   ค้นหา: ' OR '1'='1'--
   คลิก: Search
   ❌ หากแสดงหนังสือทั้งหมด → เสี่ยง!
   ✅ หากแสดง error → ไม่ใช่ช่องโหว่
   ```

5. **บันทึก:**
   ```
   การค้นพบ: SQL Injection ในการค้นหาหนังสือ
   หน้า: books.php
   Payload: ' OR '1'='1'--
   ความรุนแรง: 🔴 วิกฤติ
   ผลกระทบ: ผู้โจมตีสามารถดูหนังสือทั้งหมด (ข้ามข้อ จำกัดการค้นหา)
   ```

---

## 2B: ทดสอบการตรวจสอบความถูกต้องในแบบฟอร์มเพิ่มหนังสือ

### ข้อมูลอ้างอิงข้อบกพร่องความปลอดภัย

**BUG #15:** ยินยอมค่าลบ
**BUG #13:** ไม่มีการตรวจสอบ Available > Total

### ขั้นตอน:

1. **นำทางไปที่เพิ่มหนังสือ:**

   ```
   URL: http://localhost:8080/book_add.php
   หรือ คลิก: Books → Add Book
   ```

2. **ทดสอบจำนวนลบ:**

   ```
   ชื่อ: Test Book
   ผู้เขียน: Test Author
   Total Copies: -5
   Available: -2
   Publication Year: 2024

   คลิก: Add
   ❌ หากระบบอนุญาต → เสี่ยง! (จำนวนลบ)
   ✅ หากแสดงข้อผิดพลาดการตรวจสอบความถูกต้อง → ดี
   ```

3. **ทดสอบ available > total:**

   ```
   ชื่อ: Test Book 2
   ผู้เขียน: Test Author
   Total Copies: 5
   Available: 10  (← มากกว่า total!)

   คลิก: Add
   ❌ หากระบบอนุญาต → เสี่ยง!
   ✅ หากแสดงข้อผิดพลาดการตรวจสอบความถูกต้อง → ดี
   ```

4. **บันทึกทั้งสองการค้นพบ:**

   ```
   การค้นพบที่ 1: ยินยอมค่าลบ
   ความรุนแรง: 🔴 วิกฤติ (ความสมบูรณ์ของข้อมูล)

   การค้นพบที่ 2: Available > Total ยินยอม
   ความรุนแรง: 🟡 ปานกลาง (ความไม่สอดคล้องของข้อมูล)
   ```

---

---

# Exercise 3: XSS (CROSS-SITE SCRIPTING) (15 นาที)

---

## วัตถุประสงค์

ทดสอบว่าระบบเข้ารหัสอินพุตของผู้ใช้อย่างถูกต้อง (ป้องกันการฉีด XSS)

## ข้อมูลอ้างอิงข้อบกพร่องความปลอดภัย

**BUG #16:** ช่องโหว่ XSS (books.php - ฟังก์ชัน JavaScript และการแสดง)

---

## ขั้นตอนที่ 1: เพิ่มหนังสือด้วย Script Tag

### ขั้นตอน:

1. **ไปที่หน้าเพิ่มหนังสือ:**

   ```
   URL: http://localhost:8080/book_add.php
   ```

2. **เติมแบบฟอร์มด้วย XSS payload:**

   ```
   ชื่อ: <img src=x onerror="alert('XSS Vulnerability Found!')">
   ผู้เขียน: <script>alert('XSS')</script>
   Total Copies: 5
   Available: 5
   Publication Year: 2024
   ```

3. **คลิกเพิ่มหนังสือ**

4. **รอการตอบสนอง...**
   - ❌ หาก JavaScript ทำงาน (popup alert) → **เสี่ยง!**
   - ✅ หากอินพุตหนี/ปฏิเสธ → มั่นคง

---

## ขั้นตอนที่ 2: ดูหนังสือและตรวจสอบ XSS

1. **ไปที่หน้าหนังสือ:**

   ```
   URL: http://localhost:8080/books.php
   ```

2. **มองหาหนังสือที่เพิ่มของคุณ:**
   - หากคุณเห็น: `<img src=x onerror=...>` ในชื่อ → ไม่ได้หนี (เลว)
   - หากคุณเห็น: `<img src=x onerror="alert...">` เป็นข้อความ → หนี (ดี)

3. **ตรวจสอบแหล่งที่มาของหน้า:**

   ```
   คลิกขวา → ดูแหล่งที่มาหน้า
   ค้นหา payload ของคุณ
   มันหนีหรือเป็นอย่างนั้น?
   ```

4. **บันทึก:**
   ```
   การค้นพบ: ช่องโหว่ XSS ในชื่อหนังสือ
   หน้า: books.php
   Payload: <img src=x onerror="alert('XSS')">
   ความรุนแรง: 🟠 สูง
   ผลกระทบ: ผู้โจมตีสามารถ:
   - ขโมยคุกกี้เซสชัน
   - เปลี่ยนเส้นทางไปยังไซต์ phishing
   - แก้ไขเนื้อหาหน้าเพจ
   - เข้าถึงทรัพยากรของเบราว์เซอร์ผู้ใช้
   ```

---

## Payloads XSS อื่นๆ ที่ต้องทดสอบ

หากภาพ+onerror ไม่ได้ผล ลองว่า:

```html
<!-- Variant 1: Script tag -->
<script>
  alert("XSS");
</script>

<!-- Variant 2: SVG -->
<svg onload="alert('XSS')">
  <!-- Variant 3: Input autofocus -->
  <input autofocus onfocus="alert('XSS')">
    <!-- Variant 4: div with onclick (ต้องคลิก) -->
    <div onclick="alert('XSS')">Click me</div>
  </input>
</svg>
```

---

---

# Exercise 4: ความปลอดภัยของการยืนยันตัวตนและเซสชัน (15 นาที)

---

## วัตถุประสงค์

ทดสอบว่าการจัดการเซสชันปลอดภัยหรือไม่

---

## 4A: Session Timeout (BUG #8)

### ขั้นตอน:

1. **เข้าสู่ระบบ:**

   ```
   ชื่อผู้ใช้: teacher1
   รหัสผ่าน: password123
   คลิก: Login
   ✅ คุณเข้าสู่ระบบเรียบร้อย
   ```

2. **หมายเหตุ页面ปัจจุบัน:**

   ```
   URL: http://localhost:8080/index.php
   ควรแสดง: "Welcome, teacher1"
   ```

3. **ปิดเบราว์เซอร์ทั้งหมด:**

   ```
   ไม่เพียงแค่ปิดแท็บ
   ปิดหน้าต่างเบราว์เซอร์ทั้งหมด
   ```

4. **เปิดเบราว์เซอร์ใหม่และไปที่แอปพลิเคชัน:**

   ```
   URL: http://localhost:8080/index.php
   ```

5. **ตรวจสอบสิ่งที่เกิดขึ้น:**
   - ❌ หากคุณยังangkolog ใน → Session timeout หายไป (เสี่ยง)
   - ✅ หากเปลี่ยนเส้นทางไปที่การเข้าสู่ระบบ → ตรวจสอบเซสชันอย่างถูกต้อง

6. **บันทึก:**
   ```
   การค้นพบ: Session Timeout ที่อ่อนแอ
   ความรุนแรง: 🟡 ปานกลาง
   ปัญหา: ไม่มี timeout อัตโนมัติหลังจาก inactivity
   ผลกระทบ: คอมพิวเตอร์ที่ใช้ร่วมกันสามารถถูก exploit
   คาดหวัง: เซสชัน ควร timeout หลังจาก 15-30 นาที
   ```

---

## 4B: การทำลาย Session ในการออกจากระบบ (BUG #38)

### ขั้นตอน:

1. **เข้าสู่ระบบ:**

   ```
   ชื่อผู้ใช้: teacher1
   รหัสผ่าน: password123
   ```

2. **หมายเหตุ URL ปัจจุบัน:**

   ```
   http://localhost:8080/index.php
   ```

3. **คลิกออกจากระบบ:**

   ```
   คุณควรออกจากระบบ
   เปลี่ยนเส้นทางไปที่ login.php
   ```

4. **กด Back button ของเบราว์เซอร์:**

   ```
   ← ปุ่มย้อนกลับในเบราว์เซอร์
   ```

5. **ตรวจสอบสิ่งที่เกิดขึ้น:**
   - ❌ หากคุณเห็นหน้าก่อนหน้า → **เสี่ยง!**
     - หน้า แสดงข้อมูลผู้ใช้ของคุณ
     - เซสชันไม่ถูกทำลายอย่างถูกต้อง
   - ✅ หากเปลี่ยนเส้นทางไปที่การเข้าสู่ระบบ → ปลอดภัย

6. **นำทางโดยตรงไปที่ index.php:**

   ```
   พิมพ์ URL bar: http://localhost:8080/index.php
   ```

7. **ตรวจสอบอีกครั้ง:**
   - ❌ หากหน้าโหลด → เซสชันยังคงอยู่
   - ✅ หากเปลี่ยนเส้นทางไปที่การเข้าสู่ระบบ → เซสชันตรวจสอบในแต่ละหน้า

8. **บันทึก:**
   ```
   การค้นพบ: การทำลาย Session ที่ไม่สมบูรณ์
   ความรุนแรง: 🟡 ปานกลาง
   ปัญหา: หลังจากออกจากระบบ, บัฟเฟอร์เบราว์เซอร์/ประวัติอนุญาตการเข้าถึงหน้าที่ป้องกัน
   ผลกระทบ: ใครก็ตามใช้คอมพิวเตอร์เดียวกันสามารถเข้าถึงข้อมูลผู้ใช้ก่อนหน้า
   คาดหวัง: แต่ละหน้าควรตรวจสอบว่าเซสชันใช้งานอยู่
   ```

---

## 4C: ข้อผิดพลาดธรรมชาติการเข้าสู่ระบบ (BUG #6-7)

### ขั้นตอน:

1. **ไปที่หน้าเข้าสู่ระบบ**

2. **พยายามใช้ผู้ใช้ที่ไม่มีอยู่:**

```
ชื่อผู้ใช้: nonexistent_user_xyz_123
รหัสผ่าน: anything
คลิก: Login
```

3. **สังเกตสิ่งที่เกิดขึ้น:**
   - ❌ หากระบบ crashes (500 error) → ข้อผิดพลาดธรรมชาติ (เสี่ยง)
   - ❌ หากคุณเข้าสู่ระบบได้ -> enum able ชื่อผู้ใช้
   - ✅ หากแสดง "Invalid credentials" -> การจัดการข้อผิดพลาดที่ดี

4. **บันทึก:**
   ```
   การค้นพบ: ข้อผิดพลาดธรรมชาติการเข้าสู่ระบบ / การระบุชื่อผู้ใช้
   ความรุนแรง: 🔴 วิกฤติ หรือ 🟡 ปานกลาง ขึ้นอยู่กับพฤติกรรม
   ปัญหา: ระบบไม่ตรวจสอบว่าผู้ใช้มีอยู่ก่อนเข้าถึงข้อมูล
   ผลกระทบ: ผู้โจมตีสามารถระบุชื่อผู้ใช้ที่ถูกต้อง
   คาดหวัง: "ชื่อผู้ใช้หรือรหัสผ่านไม่ถูกต้อง" สำหรับทั้งสองกรณี
   ```

---

---

# Exercise 5: เปิดเผยข้อมูลที่ละเอียดอ่อน (5 นาที)

---

## วัตถุประสงค์

ตรวจสอบว่าข้อมูลที่ละเอียดอ่อนถูกเปิดเผยในรหัสต้นฉบับหรือไม่

---

## 5A: ข้อมูลประจำตัวแบบฮาร์ดโค้ด (BUG #1)

### ขั้นตอน:

1. **เปิดหน้าใช้งานใด ๆ ของแอปพลิเคชัน**

2. **ดูแหล่งที่มาหน้า:**

   ```
   คลิกขวา → ดูแหล่งที่มาหน้า (หรือ Ctrl+U)
   ```

3. **ค้นหาข้อมูลประจำตัว:**

   ```
   Ctrl+F ค้นหา: "password"
   ค้นหา: "db_pass"
   ค้นหา: "library_pass"
   ```

4. **ตรวจสอบสิ่งที่คุณพบ:**
   - ❌ หากค้นหา: `$db_pass = "library_pass"` → เสี่ยง!
   - ✅ หากข้อมูลประจำตัวไม่ในแหล่งที่มา → ดี (ควรใช้ตัวแปรสภาพแวดล้อม)

5. **บันทึก:**
   ```
   การค้นพบ: ข้อมูลประจำตัวแบบฮาร์ดโค้ดในรหัสต้นฉบับ
   ความรุนแรง: 🔴 วิกฤติ
   ตำแหน่ง: config.php
   ข้อมูลประจำตัวที่พบ: library_user / library_pass
   ผลกระทบ: ใครก็ตามที่เข้าถึงรหัสต้นฉบับ (Git, backup) ได้รับข้อมูลประจำตัว DB
   คาดหวัง: ใช้ตัวแปรสภาพแวดล้อมหรือไฟล์กำหนดค่าที่ไม่อยู่ใน version control
   ```

---

## 5B: โหมดดีบัก เปิดใช้งาน (BUG #4)

### ขั้นตอน:

1. **ทำให้เกิดข้อผิดพลาดของฐานข้อมูล:**
   - ปิดเซิร์ฟเวอร์ฐานข้อมูล
   - หรือพยายามดำเนินการที่ทริกเกอร์ข้อผิดพลาด
   - หรือเพิ่ม payload SQL ไม่ถูกต้อง

2. **ตรวจสอบข้อความแสดงข้อผิดพลาด:**
   - ❌ หากข้อผิดพลาดแสดง:
     - สืบค้น SQL
     - ชื่อฐานข้อมูล
     - ชื่อคอลัมน์
     - รายละเอียดการเชื่อมต่อ
       → **เสี่ยง!**
   - ✅ หากข้อความทั่วไป "Database error" → ดี

3. **ดูแหล่งที่มาหน้า:**

   ```
   ค้นหา HTML comments ที่มี debugging info
   Ctrl+F search: "SELECT"
   ```

4. **บันทึก:**
   ```
   การค้นพบ: โหมดดีบัก เปิดใช้งานในการผลิต
   ความรุนแรง: 🟠 สูง
   ปัญหา: ระบบเปิดเผยรายละเอียดทางเทคนิคในข้อความแสดงข้อผิดพลาด
   ผลกระทบ: ผู้โจมตีเรียนรู้โครงสร้างฐานข้อมูลและสามารถ exploit เพิ่มเติม
   คาดหวัง: ข้อความแสดงข้อผิดพลาดทั่วไป "Service temporarily unavailable"
   ```

---

---

# แม่แบบรายงาน

---

## สร้างรายงานการทดสอบความปลอดภัยของคุณ

### ส่วนหัวรายงาน

```
════════════════════════════════════════════
    รายงานการทดสอบความปลอดภัย
    ระบบจัดการห้องสมุด
    สัปดาห์ที่ 12 การทดสอบ
    วันที่: [วันนี้]
    ผู้ทดสอบ: [ชื่อ/ทีมของคุณ]
════════════════════════════════════════════
```

### บทสรุปผู้บริหาร (1 ย่อหน้า)

```
"ระหว่างการทดสอบความปลอดภัยสัปดาห์ที่ 12 เราค้นพบช่องโหว่ [X] ประการ
ในระบบจัดการห้องสมุด [Y]ที่มีความรุนแรงสำคัญ ซึ่งต้องได้รับความสนใจ
ฉับพลัน รายงานนี้บันทึกการค้นพบ ผลกระทบ และขั้นตอนการแก้ไข"
```

### ช่องโหว่ที่พบ

สำหรับแต่ละข้อบกพร่องที่พบ ให้บันทึก:

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
การค้นพบ #[N]: [ชื่อ]

คะแนน CVSS / ความรุนแรง: [🔴 วิกฤติ / 🟠 สูง / 🟡 ปานกลาง / 🟢 ต่ำ]
ประเภท: [SQL Injection / XSS / Auth / Session / เป็นต้น]
หน้าที่ได้รับผลกระทบ: [filename.php]
สถานะ: [ยืนยัน / ไม่พบ]

คำอธิบาย:
[อธิบายช่องโหว่ด้วยเงื่อนไขง่ายๆ]

ฟิลด์อินพุตที่ได้รับผลกระทบ:
[ฟิลด์/แบบฟอร์ม/ปลายทาง API ใด]

วิธีการทดสอบ:
[ขั้นตอนที่คุณทำ]

Payload/Vector การโจมตี:
[Payload ที่คุณใช้]

ผลลัพธ์ปัจจุบัน:
[สิ่งที่เกิดขึ้นจริงเมื่อคุณทดสอบ]

ผลลัพธ์ที่คาดไว้:
[สิ่งที่ควรเกิดขึ้น]

ผลกระทบ:
[ผู้โจมตีสามารถทำอะไรด้วยช่องโหว่นี้]

สาเหตุรากศัพท์:
[เหตุใดจึงมีอยู่]

คำแนะนำ:
[วิธีแก้ไข]

หลักฐาน:
[ภาพหน้าจอหากเป็นไปได้]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### ตารางสรุป

```
| # | การค้นพบ | ความรุนแรง | สถานะ | หน้า |
|---|---------|----------|--------|------|
| 1 | SQL Injection ในการเข้าสู่ระบบ | 🔴 วิกฤติ | ✅ พบ | login.php |
| 2 | XSS ในชื่อหนังสือ | 🟠 สูง | ✅ พบ | books.php |
| 3 | Session Timeout หายไป | 🟡 ปานกลาง | ✅ พบ | index.php |
| ... | ... | ... | ... | ... |
```

### บทสรุป

```
สรุปการค้นพบ:
- [X] ช่องโหว่ดที่มีความรุนแรงสำคัญพบ
- [Y] ปัญหาที่มีความรุนแรงสูง
- [Z] ปัญหาที่มีความรุนแรงปานกลาง/ต่ำ

ลำดับการแก้ไขที่แนะนำ:
1. [ปัญหาที่มีความรุนแรงสำคัญก่อน]
2. [ปัญหาที่มีความรุนแรงสูง]
3. [ปัญหาที่มีความรุนแรงปานกลาง]

การทดสอบเสร็จสิ้น: [วันที่]
เวลาที่ใช้ในการทดสอบ: [ชั่วโมง]
```

---

---

# ตัวอักษร GRADING

---

| เกณฑ์                                          | คะแนน   | ยอดเยี่ยม                                       | ดี                                 | ยุติธรรม                     | อ่อนแอ                    |
| ---------------------------------------------- | ------- | ----------------------------------------------- | ---------------------------------- | ---------------------------- | ------------------------- |
| **Exercise 1: SQL Injection ในการเข้าสู่ระบบ** | 20      | พบและบันทึกอย่างถูกต้อง                         | พบแต่เอกสารไม่สมบูรณ์              | พบแต่คำอธิบายคลุมเครือ       | ข้ามหรือไม่ถูกต้อง        |
| **Exercise 2: SQL Injection ในแบบฟอร์ม**       | 20      | พบปัญหาค่าลบและ available>total                 | พบปัญหาสองรายการ                   | พบแต่เอกสารไม่สมบูรณ์        | ไม่พบ                     |
| **Exercise 3: การทดสอบ XSS**                   | 20      | ส่วน alert สำเร็จ + บันทึกผลกระทบ               | พบ XSS แต่เอกสารจำกัด              | พบแต่ไม่ตรวจสอบผลกระทบ       | ไม่พบ                     |
| **Exercise 4A: Session Timeout**               | 15      | ทดสอบและบันทึกการหายไป timeout                  | ระบุปัญหาแต่ไม่มีคำอธิบายที่ชัดเจน | ความพยายามพื้นฐาน            | ไม่ทดสอบ                  |
| **Exercise 4B: การทำลาย Session**              | 15      | ทดสอบปุ่มย้อนกลับ บันทึกช่องโหว่                | ทดสอบแต่การค้นพบไม่ชัดเจน          | ความพยายามพื้นฐาน            | ไม่ทดสอบ                  |
| **Exercise 4C: LOG IN Logic**                  | 10      | ทดสอบผู้ใช้ที่ไม่มีอยู่ บันทึก crash/enum       | ทดสอบแต่เอกสารคลุมเครือ            | ทดสอบพื้นฐาน                 | ไม่ทดสอบ                  |
| **Exercise 5: ข้อมูลที่ละเอียดอ่อน**           | 10      | พบข้อมูลประจำตัวแบบฮาร์ดโค้ด + โหมดดีบัก        | พบประเภทการเปิดเผยชนิดเดียว        | ทดสอบพื้นฐาน                 | ไม่ตรวจสอบ                |
| **คุณภาพรายงาน**                               | 30      | รูปแบบมืออาชีพ, การค้นพบที่ชัดเจน, คำแนะนำที่ดี | เอกสารที่ดี, ช่องว่างเล็กน้อย      | รายงานพื้นฐาน, ปฏิบัติตามยาก | เอกสารไม่สมบูรณ์หรือหายไป |
| **รวม**                                        | **140** |                                                 |                                    |                              |                           |

---

---

# การแบ่งเวลา

```
Exercise 1: SQL Injection LOGIN      [10 นาที] ✅
Exercise 2: SQL ในแบบฟอร์มและการตรวจสอบความถูกต้อง [15 นาที] ✅
Exercise 3: การทดสอบ XSS              [15 นาที] ✅
Exercise 4: Auth & Session           [15 นาที] ✅
Exercise 5: ข้อมูลที่ละเอียดอ่อน   [ 5 นาที] ✅
การเขียนรายงาน                       [เวลาที่เหลือ]
────────────────────────────────────────────
รวม                                [60 นาที]
```

---

# คู่มือแก้ไขปัญหา

---

## Q: ฉันป้อน SQL Injection payload แต่ไม่มีอะไรเกิดขึ้น

**A:** ลองสิ่งเหล่านี้:

1. ตรวจสอบว่าคุณคัดลอก payload ที่ถูกต้อง
2. ตรวจสอบว่า JavaScript ตรวจสอบความถูกต้องฝั่งไคลเอ็นต์ (พิมพ์ `admin' OR '1'='1` ช้าๆ)
3. ใช้ Browser DevTools → แท็บเครือข่าย → ตรวจสอบคำขอจริง
4. Payload ควรอยู่ใน POST body หรือ GET parameter

---

## Q: alert XSS ไม่ปรากฏ

**A:** เหตุผลที่เป็นไปได้:

1. เบราว์เซอร์สมัยใหม่อาจบล็อก payloads บางตัว
2. Content Security Policy (CSP) headers อาจบล็อกสคริปต์
3. ลองใช้ payloads อื่น ๆ (img, svg, input autofocus)
4. ตรวจสอบว่าค่าถูกเก็บไว้ (เพิ่มลงใน DB) หรือเพียง อยู่ในเซสชันปัจจุบัน

---

## Q: เมื่อฉันออกจากระบบและกดย้อนกลับ ฉันก็ได้เปลี่ยนเส้นทางไปที่การเข้าสู่ระบบ

**A:**

- นี่หมายความว่า session ตรวจสอบอย่างถูกต้องในแต่ละหน้า ✅
- บันทึก: "การทำลาย Session ทำงานอย่างถูกต้อง"

---

## Q: ฉันไม่สามารถเข้าถึงแอปพลิเคชัน

**A:**

```bash
# ตรวจสอบว่า Docker กำลังทำงาน:
docker ps

# ตรวจสอบบันทึก:
docker logs library_management_db
docker logs library_management_app

# เริ่มต้นใหม่:
docker-compose down
docker-compose up
```

---

## Q: ฉันค้นพบช่องโหว่มากกว่าที่ระบุ มันเป็นเรื่องเลวหรือไม่?

**A:** ไม่! คุณพบข้อบกพร่องเพิ่มเติมที่เราไม่ได้กำหนดเฉพาะเจาะจง บันทึกพวกเขา:

```
การค้นพบพิเศษ: [การค้นพบของคุณ]
คุณขึ้นไปเกินกว่าที่คาดไว้!
```

---

---

# รายการตรวจสอบ

- [ ] เสร็จสิ้น Exercise ทั้ง 5
- [ ] บันทึกแต่ละการค้นพบ พร้อมด้วย:
  - [ ] ระดับความรุนแรง
  - [ ] หน้า/ฟิลด์ที่ได้รับผลกระทบ
  - [ ] Payload ที่คุณใช้
  - [ ] ผลลัพธ์ที่สังเกต
  - [ ] คำอธิบายผลกระทบ
- [ ] สร้างรายงานการทดสอบความปลอดภัยที่เป็นมืออาชีพ
- [ ] รวมตารางสรุปของการค้นพบทั้งหมด
- [ ] เพิ่มคำแนะนำให้กับแต่ละข้อบกพร่อง
- [ ] รายงานชัดเจนและสามารถอ่านได้
- [ ] ส่งตามกำหนดเวลา

---