8.5.3 Technical Report

Pendahuluan

Technical Report adalah dokumen inti yang berisi detail teknis setiap temuan penetration testing. Berbeda dengan Executive Summary yang ditujukan untuk manajemen, laporan teknis ditulis untuk tim pengembangan, DevOps, system administrator, dan security engineer yang akan melakukan remediasi. Setiap temuan harus dijelaskan dengan presisi sehingga pembaca dapat mereproduksi, memahami akar masalah, dan menerapkan perbaikan.

Laporan teknis yang baik memiliki tiga karakteristik: reproducible (pembaca bisa mengikuti langkah yang sama), actionable (rekomendasi langsung bisa diimplementasikan), dan verifiable (perbaikan bisa diuji).

1. Struktur Laporan Teknis Profesional

Laporan teknis yang lengkap memiliki struktur sebagai berikut:

1. Cover Page - judul, klien, tanggal, tim, klasifikasi
2. Table of Contents - daftar isi dengan nomor halaman
3. Document Control - versi dokumen, perubahan, reviewer
4. Pendahuluan - ruang lingkup, metodologi, batasan
5. Scope Details - daftar IP, domain, aplikasi yang diuji
6. Finding Summary - ringkasan temuan (table)
7. Detail Temuan - setiap temuan dengan format standar
8. Appendix - tool list, referensi, glossary, raw data

2. Cover Page & Document Control

2.1 Cover Page

┌──────────────────────────────────────────────────────────┐
│                                                          │
│           PENETRATION TESTING REPORT                     │
│                                                          │
│   Client:          PT Teknologi Maju                     │
│   Engagement ID:   PT-2026-001                           │
│   Report Date:     20 Januari 2026                       │
│   Classification:  RAHASIA - INTERNAL ONLY               │
│                                                          │
│   Prepared By:     Budi Santoso, CISSP, CEH              │
│                    Siti Aminah, OSCP                     │
│   Reviewed By:     Andi Pratama, CISSP                   │
│   Approved By:     Dr. Dian Kusuma, CISO                 │
│                                                          │
│   Version:         1.0                                   │
│   Status:          Final                                 │
│                                                          │
└──────────────────────────────────────────────────────────┘

2.2 Document Control Table

3. Finding Format Standar

Setiap temuan dalam laporan teknis harus mengikuti format yang konsisten. Format berikut adalah standar industri yang diadopsi dari OWASP dan PTES (Penetration Testing Execution Standard).

Template Finding:

┌─────────────────────────────────────────────────────────┐
│ FINDING #F-001                                          │
├─────────────────────────────────────────────────────────┤
│ Title:          SQL Injection pada Login Page            │
│ Severity:       Critical                                │
│ CVSS Score:     9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/  │
│                  A:H)                                    │
│ CVE/CWE:        CWE-89: SQL Injection                    │
│ Location:       https://app.teknologimaju.com/login      │
│ Parameter:      username (POST)                          │
│ Status:         Open - Unresolved                        │
│ Discovered:     2026-01-03 09:15 UTC+7                   │
└─────────────────────────────────────────────────────────┘

Komponen finding:

• Title - nama kerentanan yang jelas dan deskriptif
• Severity - Critical, High, Medium, Low, atau Informational
• CVSS Score - vektor CVSS lengkap dan skor numerik
• CVE/CWE - referensi ke Common Weakness Enumeration
• Location - URL, endpoint, host, port spesifik
• Parameter - parameter rentan (jika aplikasi web)
• Status - Open, Fixed, Verified, Accepted Risk, Out of Scope
• Discovered - timestamp penemuan

4. Detail Finding - Deskripsi, Dampak, Reproduksi

Setiap finding memiliki lima sub-bagian yang harus diisi secara lengkap.

4.1 Description

Jelaskan kerentanan dalam bahasa teknis yang jelas. Sertakan prinsip dasar mengapa kerentanan terjadi.

Contoh (SQL Injection):

Halaman login aplikasi tidak melakukan sanitasi atau parameterized query pada input field "username". Input langsung digabungkan ke query SQL tanpa escaping, memungkinkan attacker menyuntikkan perintah SQL arbitrer. Aplikasi menggunakan MySQL 8.0 dengan user database yang memiliki hak akses SELECT, INSERT, UPDATE, dan DELETE pada database teknologi_maju_db.

4.2 Impact

Jelaskan dampak teknis dan bisnis dari kerentanan.

Contoh:

Attacker dapat:

• Mengakses seluruh data pengguna (50.000+ records): username, email, password hash, alamat, nomor telepon
• Mengekstrak data dari tabel lain (transaksi, pembayaran, log aktivitas)
• Memodifikasi atau menghapus data dalam database
• Melakukan bypass autentikasi dan login sebagai admin

Dampak bisnis:

• Pelanggaran UU PDP Pasal 15 - potensi denda administratif
• Kebocoran data PII (Personally Identifiable Information)
• Akses tidak sah ke data finansial pengguna

4.3 Reproduction Steps

Langkah reproduksi harus step-by-step, reproducible, dan menggunakan tool yang umum. Setiap langkah harus bisa diikuti oleh developer yang mungkin tidak familiar dengan tool pentest.

Contoh reproduction steps:

Tool: curl, Burp Suite Community Edition

Langkah 1: Kirim request login normal untuk memahami parameter:

curl -X POST https://app.teknologimaju.com/login \
  -d "username=test&password=test123" \
  -v

Langkah 2: Uji injeksi dengan payload sederhana:

curl -X POST https://app.teknologimaju.com/login \
  -d "username=admin' OR '1'='1&password=test" \
  -v

Langkah 3: Observasi response. Jika login berhasil tanpa credentials valid, kerentanan terkonfirmasi.

Langkah 4: Ekstrak daftar database menggunakan UNION-based injection:

curl -X POST https://app.teknologimaju.com/login \
  -d "username=admin' UNION SELECT 1,database(),user(),4,5,6-- -&password=test" \
  -s | grep -oP '(?<=<td>)[^<]+'

Hasil yang diharapkan:

Response HTTP 200 OK dengan session cookie baru
Database: teknologi_maju_db
User: db_admin@localhost

4.4 Evidence

Sertakan bukti dalam format yang jelas:

• Screenshot - tangkapan layar yang menunjukkan payload dan hasil eksekusi
• Request/Response - HTTP request dan response lengkap (gunakan code block)
• PCAP excerpt - potongan network capture yang relevan
• Log excerpt - log system atau aplikasi yang mencatat aktivitas

Contoh evidence format:

HTTP Request:

POST /login HTTP/1.1
Host: app.teknologimaju.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 47

username=admin' OR '1'='1'-- -&password=irrelevant

HTTP Response:

HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: session=eyJ1c2VyIjoiYWRtaW4ifQ; HttpOnly; Path=/

Evidence screenshot:

[MEDIA: evidence/screenshots/SQL-001-login-bypass.png]
 - Menunjukkan login berhasil sebagai admin tanpa password valid

4.5 Recommendation

Rekomendasi harus langsung implementable oleh developer. Berikan kode contoh jika memungkinkan.

Contoh rekomendasi SQL Injection:

Rekomendasi 1: Gunakan Parameterized Query (Prepared Statement) Ganti query string concatenation dengan prepared statement:

Kode rentan (PHP):

$query = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "'";
$result = mysqli_query($conn, $query);

Kode aman (PHP dengan PDO):

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $_POST['username']]);
$result = $stmt->fetchAll();

Rekomendasi 2: Validasi Input Terapkan whitelist validation untuk field yang memiliki format tertentu:

if (!preg_match('/^[a-zA-Z0-9_]+$/', $_POST['username'])) {
    die('Invalid username format');
}

Rekomendasi 3: Principle of Least Privilege User database aplikasi hanya boleh memiliki hak SELECT pada tabel yang dibutuhkan. Jangan menggunakan user admin database untuk koneksi aplikasi.

5. Severity Classification

Gunakan klasifikasi severity yang konsisten di seluruh laporan.

6. Appendix

Appendix berisi informasi pendukung yang terlalu detail untuk body laporan.

6.1 Tool List

6.2 Glossary

6.3 Remediation Timeline Template

REMEDIATION TIMELINE
═══════════════════════════════════════════════════
Client: PT Teknologi Maju
Engagement ID: PT-2026-001

| Finding | Severity | Deadline | PIC | Status |
|---|---|---|---|---|
| F-001 SQLi Login | Critical | 27 Jan 2026 | Tim Dev | [ ] |
| F-002 RCE Upload | Critical | 27 Jan 2026 | Tim DevOps | [ ] |
| F-003 XSS Stored | High | 19 Feb 2026 | Tim Dev | [ ] |
| ... | ... | ... | ... | [ ] |

CATATAN:
- Critical: 7 hari kalender sejak laporan diterima
- High: 30 hari kalender
- Medium: 90 hari kalender
- Low: 180 hari kalender
═══════════════════════════════════════════════════

7. Retest Verification

Setelah klien menyelesaikan remediasi, tim pentest harus melakukan retest untuk memverifikasi perbaikan.

Prosedur Retest:

1. Klien mengirimkan daftar temuan yang sudah diperbaiki
2. Tim pentest mereproduksi langkah eksploitasi asli
3. Jika eksploitasi gagal → Fixed
4. Jika eksploitasi masih berhasil → Not Fixed
5. Jika muncul kerentanan baru akibat perubahan kode → Regression - Finding Baru

Format retest:

RETEST VERIFICATION REPORT
═══════════════════════════════════════════════════
Client: PT Teknologi Maju
Retest Date: 27 Januari 2026
Tester: Budi Santoso

| Finding | Original Status | Retest Date | Retest Result | Notes |
|---|---|---|---|---|
| F-001 SQLi | Fixed (claimed) | 2026-01-27 | Verified Fixed | Prepared statement sudah diimplementasi |
| F-002 RCE | Fixed (claimed) | 2026-01-27 | Not Fixed | Filter mime-type masih bisa bypass |
| F-003 XSS | Fixed (claimed) | 2026-01-27 | Verified Fixed | Output encoding sudah benar |
═══════════════════════════════════════════════════

8. Contoh Finding Lengkap

Berikut adalah contoh satu finding yang diisi lengkap:

┌─────────────────────────────────────────────────────────┐
│ FINDING #F-001                                          │
│ Title: SQL Injection pada Login Page                     │
│ Severity: Critical                                      │
│ CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)        │
│ CWE-89                                                  │
│ Location: POST /login - parameter: username              │
│ Status: Open                                            │
├─────────────────────────────────────────────────────────┤
│ DESCRIPTION                                             │
│ Input "username" tidak disanitasi sebelum dimasukkan    │
│ ke query SQL. Attacker dapat menyuntikkan perintah SQL  │
│ arbitrer. Database: MySQL 8.0.32 - user db_admin.       │
│                                                         │
│ IMPACT                                                  │
│ - Akses ke 50.000+ records pengguna                     │
│ - Bypass autentikasi sebagai admin                      │
│ - Ekstrak data finansial dari tabel transaksi           │
│                                                         │
│ REPRODUCTION STEPS                                      │
│ 1. Jalankan: curl -X POST https://target/login \        │
│    -d "username=admin' OR '1'='1'-- -&password=x"       │
│ 2. Observasi response 302 redirect ke /dashboard        │
│ 3. Konfirmasi bypass autentikasi                        │
│                                                         │
│ EVIDENCE                                                │
│ [Screenshot: evidence/screenshots/F-001-bypass.png]     │
│ Request:                                                │
│ POST /login HTTP/1.1                                    │
│ username=admin' OR '1'='1'-- -&password=x               │
│ Response:                                               │
│ HTTP/1.1 302 Found                                      │
│ Location: /dashboard                                    │
│                                                         │
│ RECOMMENDATION                                          │
│ Gunakan prepared statement (PDO) sebagai ganti query    │
│ concatenation. Terapkan whitelist validation pada input │
│ dan batasi hak akses user database.                     │
└─────────────────────────────────────────────────────────┘

9. Praktik Terbaik Penulisan Technical Report

1. Konsisten - gunakan format yang sama untuk setiap finding
2. Spesifik - sertakan endpoint, parameter, dan payload exact
3. Reproducible - langkah reproduksi harus bisa diikuti tanpa interpretasi
4. Evidence-rich - screenshot, request/response, log, pcap
5. Actionable - rekomendasi harus konkret dengan kode contoh
6. Objektif - jangan gunakan bahasa subjektif ("sangat mudah dieksploitasi" → "eksploitasi membutuhkan 1 request HTTP dengan tool curl standar")
7. No false positives - setiap finding harus diverifikasi minimal 2 kali
8. Version control - gunakan nomor versi dan changelog
9. Confidential - tandai setiap halaman dengan klasifikasi kerahasiaan
10. Peer review - minta rekan pentester mereview laporan sebelum dikirim

Kesimpulan

Technical Report adalah deliverable paling bernilai dari sebuah engagement penetration testing. Laporan yang ditulis dengan baik - reproducible, actionable, dan evidence-rich - memungkinkan tim teknis klien memperbaiki kerentanan secara efektif. Sebaliknya, laporan yang buruk (kurang detail, langkah tidak reproducible, rekomendasi terlalu umum) membuat remediasi menjadi sulit dan engagement kehilangan nilainya. Investasi waktu dalam penulisan laporan teknis yang berkualitas adalah investasi dalam efektivitas perbaikan keamanan klien.