Cheatsheet UTS (PSP)

• Buka terminal di Kali Linux. Lakukan update sistem: apt update && apt upgrade
• Instal dependensi Node.js dan Git: apt install nodejs npm -y && apt install git-all
• Kloning repositori Juice Shop: git clone https://github.com/juice-shop/juice-shop.git --depth 1
• Masuk ke direktori dan jalankan: cd juice-shop lalu npm install lalu npm start
• Buka browser dan akses aplikasi untuk mulai simulasi pentest di URL: http://localhost:3000

• Tujuan Juice Shop: Menjadi "kelinci percobaan" (guinea pig) yang aman untuk alat-alat keamanan (security tools). Meskipun dibuat modern, aplikasi ini sengaja ditanamkan arsitektur yang lemah di berbagai fiturnya agar pengguna bisa berlatih eksploitasi dari seluruh kategori OWASP Top 10 di lingkungan yang legal.

1. Menonaktifkan Directory Listing (.htaccess)

Options -Indexes

2. Memblokir File Eksekusi di Folder Upload (.htaccess)

<Directory /var/www/html/uploads>
    Require all denied
    <FilesMatch "\.(php|cgi|pl|py|sh|exe)$">
        Require all denied
    </FilesMatch>
</Directory>

3. Konfigurasi Security Headers (PHP)

header("X-Frame-Options: DENY"); // Cegah Clickjacking
header("X-Content-Type-Options: nosniff"); // Blokir MIME sniffing
header("X-XSS-Protection: 1; mode=block"); // Mitigasi XSS
header("Strict-Transport-Security: max-age=31536000; includeSubDomains"); // Paksa HTTPS
header("Content-Security-Policy: default-src 'self';"); // Batasi load resource

• Direct Browser: Buka direktori seperti /uploads atau /admin di URL tanpa menyertakan nama file spesifik. Jika layar memunculkan daftar file/folder (Index of /uploads), berarti sistem rentan.
• Burp Suite (Cek Header & CORS): Lakukan intercept, kirim ke Repeater (Ctrl+R), dan amati Response Headers. Jika menemukan Access-Control-Allow-Origin: * atau tidak ada header X-Frame-Options, konfigurasi keamanannya sangat lemah.

• Google Dorking (Exposure KTP/KK): Melalui pencarian spesifik di Search Engine (Google Dork), penyerang bisa menemukan Security Misconfiguration yang mengekspos direktori situs web. Hal ini terjadi karena developer lupa memasukkan opsi Options -Indexes pada file .htaccess, yang berakibat fatal karena dokumen sensitif pengguna seperti KTP dan KK terpublikasi bebas secara terbuka (terlihat pada halaman Index of /uploads/dokumen).
• Directory Listing pada Assets Image: Menguji kerentanan dengan memanipulasi path gambar (contoh: dari URL asli https://.../pentest/assets/img/cat.jpg dihapus ujungnya menjadi https://.../pentest/assets/img/). Jika layar menampilkan kumpulan folder (Index of /pentest/assets/img/), berarti konfigurasi keamanan folder tersebut lemah dan terekspos ke publik.

• Dampak Utama Misconfiguration: Eksposur data sensitif dan pengambilalihan akun (System Takeover).
• Contoh Bahaya: Menggunakan kredensial bawaan (admin/admin), membiarkan mode APP_DEBUG=true di lingkungan produksi, dan tidak memisahkan lingkungan Development, Testing, dan Production.
• Cara Ekstra Mencegahnya: Lakukan audit rutin, terapkan Least Privilege (berikan izin seminimal mungkin yang diperlukan), gunakan Automated Tools untuk memindai konfigurasi, dan selalu lakukan Patch Management agar perangkat lunak selalu terbarui.

session_start();

// Cek otoritas sebelum memberi akses ke halaman/fungsi admin
if (!isset($_SESSION['role']) || $_SESSION['role'] !== 'admin') {
    http_response_code(403);
    die("Access Denied");
}

echo "Welcome to Admin Panel";

• Privilege Escalation / IDOR via Parameter Tampering: Saat memberikan ulasan (review) pada produk, aktifkan Intercept di Burp Suite. Tangkap request tersebut dan kirim ke Repeater. Pada Request Body (format JSON/Form), cari parameter pembuat ulasan. Ubah data email dari milik Anda (mitsuha@gmail.com) menjadi milik pengguna lain (yotsuha@gmail.com). Klik Send. Jika ulasan berhasil diposting atas nama pengguna lain, aplikasi rentan.
• Forceful Browsing & IDOR Keranjang: Tangkap request saat membuka keranjang belanja Anda (contoh: GET /rest/basket/7 HTTP/1.1). Kirim ke Repeater, lalu ganti ID keranjang di URL tersebut dari 7 menjadi 1. Jika respons server (200 OK) mengembalikan JSON berisi isi keranjang orang lain (misal: "name":"Apple Juice", "quantity":2), kontrol akses gagal diterapkan.

• Parameter Tampering / Privilege Escalation via Repeater: Tangkap intersep request login milik akun admin menggunakan Burp Suite, lalu Send to Repeater. Ubah parameter username=kasir1, pass=kasir1, serta ubah hidden value loginas dari admin menjadi kasir (misal loginas=2). Kirim (Send). Jika aplikasi merespons berhasil dan memberikan akses halaman kasir menggunakan kerangka request admin tadi, maka terdapat kerentanan Privilege Escalation.

• Apa itu Access Control? Keamanan yang menjamin user hanya mengakses apa yang menjadi haknya. (Misal: User biasa tidak boleh punya akses ubah data, hanya Admin).
• Teknik Penyerangan Spesifik:
  • Privilege Escalation: Contohnya mengganti parameter user_id atau parameter role di URL/Body secara paksa untuk menaikkan hak akses.
  • Forceful Browsing: Menebak atau memanipulasi URL secara langsung untuk mengakses halaman tersembunyi tanpa melalui navigasi wajar (bypassing navigasi).

// Menyimpan hash yang aman (Gunakan Bcrypt/Argon2, hindari MD5)
$hash = password_hash($password, PASSWORD_BCRYPT);

// Memverifikasi saat user login
if (password_verify($password, $storedHash)) {
    echo "Login successful!";
} else {
    echo "Invalid username or password!";
}

Gunakan Nmap Scripting Engine (NSE) untuk mencari kelemahan SSL/TLS di server target:

• Mengecek cipher suite server yang lemah: nmap --script ssl-enum-ciphers -p 443 <target>
• Mengecek kerentanan protokol SSLv3 (POODLE): nmap --script ssl-poodle -p 443 <target>
• Mengecek kerentanan protokol SSLv2 (DROWN): nmap --script ssl-drown -p 443 <target>
• Mengecek kerentanan Export-Grade RSA (FREAK): nmap --script ssl-freak -p 443 <target>

Catatan: <target> adalah IP Address ATAU Domain Name (Link), tapi TANPA awalan http:// atau https://.

• Kategori Kelemahan (CWE): CWE-259 (Hard-coded Password yang disimpan langsung di file source), CWE-327 (Algoritma Kripto Rusak), dan CWE-331 (Insufficient Entropy / keacakan lemah).
• Anatomi Serangan Kriptografi: Penyerang menggunakan kelemahan aplikasi untuk mengambil isi Password DB. Karena sandi tidak di-hash dengan benar, mereka memakai Rainbow Table untuk membuka sandi dan mencoba kredensialnya di website lain.
• Langkah Pencegahan Esensial: Enkripsi semua data saat dipindahkan (in transit) menggunakan protokol TLS terbaru, matikan caching untuk response data sensitif, dan jangan gunakan protokol legacy seperti FTP tanpa pengaman. Selalu gunakan nilai IV (Initialization Vector) yang digenerate acak secara aman (CSPRNG).

// Pencegahan SQLi: WAJIB gunakan Prepared Statements / Parameterized Queries
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);

// Pencegahan XSS: Lakukan HTML Encoding saat menampilkan data dari database
echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

// Pencegahan LDAP Injection: Parameterized/escaping input
// Hindari menyambung string langsung seperti "(&(uid=" . $_GET['username'] . "))"

• Classic SQLi: Pada form login admin, masukkan payload username: admin' OR '1'='1 --
• Time-Based SQLi: Pada kolom search atau username, masukkan payload penunda waktu: admin' AND IF(1=1, SLEEP(5), 0) -- (Jika loading web tiba-tiba melambat 5 detik, injeksi berhasil).
• LDAP Injection: Masukkan payload untuk menembus filter, misal username diubah menjadi: admin)(&) untuk mengubah logika (&(uid=admin)(&)(password=any))
• Stored XSS: Pada kolom input komentar produk, masukkan payload JavaScript: alert('Hacked!'). Jika setiap kali halaman produk tersebut dibuka muncul pop-up di layar pengguna (bahkan pengguna lain), artinya XSS tersimpan permanen di database.

• SQL Injection via Repeater: Tangkap HTTP Request form login menggunakan Burp Suite, dan teruskan ke Repeater. Ganti parameter username dan password masing-masing dengan payload SQL Injection ' OR 1=1 - -. Jika dieksekusi (Send) dan HTTP Response menunjukkan "200 OK" serta sistem menampilkan pesan login berhasil, berarti website rentan terhadap Classic SQL Injection.
• XSS pada Search Bar / Kolom Cari Barang: Buka halaman pencarian data di aplikasi. Masukkan baris script XSS berbahaya seperti <script>alert(document.cookie)</script> lalu tekan tombol Search. Apabila halaman segera mengeksekusinya dan memberikan peringatan pop-up bertuliskan elemen Cookie milik browser Anda, maka dapat dipastikan bahwa kolom input website tersebut sangat rentan terhadap serangan XSS.

• Varian SQL Injection Lain:
  • Blind SQLi: Penyerang tidak menerima error DB langsung, melainkan mengekstrak data perlahan berdasarkan perubahan perilaku aplikasi (misal: payload admin' AND 1=1 -- berhasil login, tapi 1=2 gagal).
  • Out-of-Band SQLi: Menjalankan payload yang menyuruh database mengirimkan data lewat DNS atau HTTP ke server penyerang (contoh fungsi: LOAD_FILE() ke \\attacker.com\data).
• Cross-Site Scripting (XSS): Reflected XSS mengeksekusi script langsung via URL tanpa disimpan (misal: ?q=alert(1)), sedangkan Stored XSS menanamkan kodenya di database sehingga dieksekusi secara masif oleh siapapun yang memuat halaman tersebut. XSS bisa digunakan untuk pencurian Cookie/Session, Defacement, atau mengarahkan ke situs Phishing.
• Solusi Basis Data: Hindari akses root untuk web app, gunakan Object-Relational Mapping (ORM) seperti Eloquent/Hibernate, dan matikan fitur bahaya SQL seperti fungsi SLEEP() di permission MySQL.

1. Mengamankan dari Brute Force (Account Lockout)

session_start();
$maxAttempts = 5; 
$lockoutTime = 15 * 60; // 15 menit

if ($_SESSION['failed_attempts'] >= $maxAttempts) {
    if ((time() - $_SESSION['last_attempt_time']) < $lockoutTime) {
        die("Account locked. Try again later.");
    } else { 
        $_SESSION['failed_attempts'] = 0; 
    }
}

2. Mengamankan dari Cross-Site Request Forgery (CSRF)

// Saat merender Form, buat Token CSRF
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// Saat memproses Form tersubmit, pastikan token cocok
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF token mismatch!");
}

• Mendeteksi Plaintext Credential: Hidupkan Intercept, lalu ketik email dan password di halaman login target, klik Sign In. Pada Burp Suite, periksa bagian bawah Request Headers. Jika terlihat jelas txtuserid=s160422001&txtpassword=kunci_rahasia_anda, berarti data dikirim polos. Desain yang baik seharusnya mengandalkan koneksi Transport Layer aman (HTTPS pada port 443 yang diamankan SSL/TLS) serta menghindari metode GET agar data rahasia tidak terekam di riwayat (history) URL browser.
• Mendeteksi Tidak Ada Rate Limit (Brute Force): Tangkap request login dengan Burp Suite, klik kanan dan Send to Intruder. Pada menu Positions, tandai parameter password. Pada tab Payloads, muat daftar ratusan password acak (Wordlist). Jalankan serangan. Amati tab Results; jika server terus-menerus merespons dengan HTTP status "200 OK" atau "302 Found" pada semua percobaan tanpa memblokir IP atau mengeluarkan pesan akun terkunci (misalnya "429 Too Many Requests"), berarti desain aplikasi sangat lemah terhadap serangan kamus (Dictionary / Brute Force Attack).
• Verifikasi Keamanan Frame & Log: Lakukan inspect response header untuk memastikan ada X-Frame-Options: SAMEORIGIN untuk mencegah situs disematkan dalam iFrame (Clickjacking) dan memastikan form menggunakan metode "POST" untuk melindungi kebocoran parameter.

• Manipulasi Logika Harga / Modus Negatif: Pada form pendaftaran input "Data Barang", masukkan bilangan bernilai minus/negatif pada field 'Harga Jual', 'Harga Beli', maupun 'Modal'. Jika setelah disubmit sistem memberikan notifikasi penyimpanan sukses dan besaran harga di database benar-benar berubah menjadi negatif, ini merupakan cacat fatal dari Insecure Design (Validasi Logika Bisnis gagal). Solusi teraman adalah dengan memanfaatkan instruksi try-catch block atau Exception Handling sebelum data dikirimkan, guna menolak masukan yang angkanya di bawah nilai kewajaran / nol.

• Beda Insecure Design vs Bug Biasa: Insecure Design terjadi karena ketiadaan Threat Modeling (perencanaan keamanan) dari awal. Walaupun kodenya sudah dibuat sempurna (tanpa bug injeksi), aplikasinya tetap bisa diretas karena alur kerjanya memang tidak aman.
• Kasus Insecure Design Lainnya di PPT:
  • Session ID in URL: Menyisipkan session_id di URL sangat berbahaya karena bisa disalin dan dikirim tidak sengaja ke orang lain (Session Hijacking). Seharusnya gunakan Secure Cookies (httponly dan secure).
  • Insecure API (No Authentication): Membuat titik masuk (Endpoint/API) tanpa sistem autentikasi, sehingga siapa pun bisa mengakses URL JSON. Pencegahan terbaik: Harus menggunakan verifikasi Token (misal JWT / JSON Web Token) agar akses ditolak jika token tidak dilampirkan dalam headers.