Report lab cyber security PortSwigger

Kita akan mengulas dan merangkum poin-poin yang ada pada 10 lab di PortSwigger bertemakan:

• Access control vulnerability

• Authentication

• Path traversal

• Business logic vulnerability 

Access control vulnerability

1. User id controlled by request parameter: 

• Tujuan: Obtain API key for the user Carlos and submit it as solution

Parameter user_id dalam permintaan dapat dimanipulasi untuk mencoba mendapatkan data milik pengguna lain, seperti API key milik Carlos. Penyerang akan mengubah user_id dalam permintaan untuk mencoba ID lain hingga menemukan milik Carlos.

• Penjelasan: 

OWASP WSTG-ATHZ-01 adalah referensi dimana parameter user_id yang dikendalikan oleh permintaan salah satu bentuk kelemahan akses kontrol yang sering ditemukan dalam aplikasi web. Dalam kerentanan ini, sistem menggunakan parameter yang diterima dari klien untuk menentukan data yang akan diakses tanpa melakukan validasi yang memadai. Parameter tersebut biasanya ditemukan dalam URL, body request, atau query string. Sebagai contoh, jika pengguna "wiener" memiliki user_id= wiener, penyerang dapat mengganti nilai user_id dalam permintaan menjadi angka lain, seperti user_id= carlos , untuk mencoba mendapatkan informasi dari pengguna lain.

• Dokumentasi step by step

1. LOGIN

2. Melihat API key 

3. Validasi Api key (Burp Suite)

API Key Wiener: kRuczd8g14ylHg0kua9KH0rgTuJQX21y

4. Mencari API key Carlos (menggunakan user_id)

API Key Carlos: XHML9xPuIIwMYzb35uSNWyL2sgab4hyZ

Rekomendasi:

Untuk mengatasi masalah ini, pastikan server memvalidasi akses ke data berdasarkan identitas pengguna yang terautentikasi, sehingga pengguna hanya dapat mengakses data yang menjadi miliknya. Selain itu, gunakan token otorisasi berbasis sesi (seperti JWT) untuk memastikan parameter user_id tidak dapat dimanipulasi. Validasi parameter di sisi server harus diterapkan agar data yang diakses sesuai dengan hak akses pengguna.

2. User id controlled by request parameter, with unpredictable user IDs 

• Tujuan : Find the GUID for carlos and compromise his account 

Jika ID pengguna berbentuk GUID yang sulit ditebak, penyerang dapat mencari pola GUID di respon atau log sistem. Setelah GUID milik Carlos ditemukan, data sensitifnya dapat diakses.

• Penjelasan:

Referensi: WSTG-ATHZ-02: Testing for Predictable Object Identifiers

GUID (Globally Unique Identifier) adalah pengenal unik yang biasanya terdiri dari kombinasi angka dan huruf secara acak dengan format yang sangat sulit ditebak (contoh: de64401c-a90e-4287-8f6a-b488a06340f3). Dalam konteks keamanan, GUID sering digunakan sebagai pengganti ID numerik biasa untuk mencegah eksploitasi sederhana seperti brute force. Namun, jika GUID diterapkan tanpa mekanisme validasi yang baik, penyerang dapat mencari pola GUID yang mungkin secara tidak sengaja terekspos, misalnya melalui log, respon API, atau parameter lain di aplikasi. Dengan mempelajari GUID yang sudah diketahui, penyerang dapat mencoba enumerasi GUID lain dalam skenario tertentu. Meskipun GUID dirancang untuk sulit diprediksi, kesalahan implementasi, seperti penggunaan GUID secara berurutan atau kebocoran dalam sistem, dapat memberikan jalan bagi penyerang untuk menemukan GUID milik pengguna lain, seperti Carlos, sehingga memungkinkan eksploitasi lebih lanjut.

• Dokumentasi step by step

1. LOGIN

2. Melihat API key Wiener

3. Validasi Api key (Burp Suite)

User_ID: de64401c-a90e-4287-8f6a-b488a06340f3

API Key is: dlG0QbWOX2I5Yko9QkSYrLVpzSj2Z4vt

4. Mencari User_Id Carlos

5. Mencari User_id Carlos (Burp suite)

User_id Carlos : 7df862f3-4440-40dd-abdc-6e5b74d962d5

6. Mencari API Key dengan User_id carlos (burp suite)

API Key : FQFKOim02cICDDObUkZVXBIVM8Fg80yD

Rekomendasi:

Pastikan GUID dihasilkan menggunakan algoritma yang divalidasi untuk mencegah prediksi. Selain itu, tambahkan lapisan kontrol akses tambahan di sisi server untuk memastikan bahwa GUID saja tidak cukup untuk mendapatkan akses. Implementasikan pula mekanisme pembatasan laju (rate-limiting) untuk mencegah serangan brute force terhadap GUID.

3. User id controlled by request parameter with data leakage in redirect

• Tujuan : Obtain API key for the user Carlos through the body of redirect response

Data sensitif, seperti API key, bocor dalam isi body atau header redirect. Penyerang dapat mencegat redirect menggunakan alat seperti Burp Suite untuk mengekstrak informasi tersebut.

• Penjelasan : 

Referensi: WSTG-INFO-03: Testing for Sensitive Data Exposure

Kebocoran data di redirect terjadi ketika aplikasi secara tidak aman mengirimkan data sensitif seperti API key, token otentikasi, atau informasi pribadi dalam body, header, atau URL selama proses pengalihan (redirect). Saat pengguna mengakses endpoint tertentu, server mungkin merespons dengan kode status seperti 301, 302, atau 307, disertai dengan URL tujuan yang mengandung informasi sensitif dalam parameter query atau respons HTTP. Jika penyerang menggunakan alat seperti Burp Suite untuk mencegat dan memeriksa redirect tersebut, mereka dapat mengekstrak data sensitif yang terkandung di dalamnya.

• Dokumentasi step by step

1. LOGIN menggunakan kredensial yang disediakan

2. Kirimkan request nya ke repeater

3. ubah parameter ID nya ke Carlos lalu klik send, cari API carlos lalu copy

4. Kembali ke browser, submit API carlos untuk menyelesaikan lab

Rekomendasi:

Hindari menyertakan data sensitif dalam rerponse redirect, Pastikan server memvalidasi ulang semua redirect untuk memastikan data sensitif tidak bocor.

4. User id controlled by request parameter with password disclosure

• Tujuan : Retrieve the administrator’s password and delete the user carlos.

Sistem yang membocorkan kata sandi melalui parameter atau respon dapat dieksploitasi untuk mengambil password administrator, lalu digunakan untuk menghapus akun Carlos.

• Penjelasan :

Referensi: WSTG-INFO-02: Testing for Weak Authentication

Pengungkapan password dalam respons terjadi ketika aplikasi secara tidak sengaja menampilkan kata sandi dalam body respons, URL, atau header akibat kesalahan pengkodean. Penyerang dapat memanfaatkan celah ini dengan menganalisis permintaan menggunakan alat seperti Burp Suite dan mengganti parameter seperti user_id untuk mendapatkan kata sandi target. Hal ini memungkinkan login tidak sah atau manipulasi akun.

• Dokumentasi step by step

1. LOGIN menggunakan kredensial yang disediakan

2. Ganti parameter id=wiener di URL menjadi id=administrator

3. Lihat HTTP history, lalu cari input nya di kolom response

4. Copy passwordnya dan kembali ke browser lalu logout, LOGIN kembali dengan kredensial administrator dan password yang sudah di copy. Pergi ke admin panel lalu hapus user Carlos.

Rekomendasi:

Hindari menyertakan data sensitif dalam URL pengalihan (redirect). Sebagai gantinya, gunakan metode POST untuk mentransfer data sensitif. Pastikan server memvalidasi ulang semua redirect untuk memastikan data sensitif tidak bocor. Jika data sensitif tetap diperlukan, enkripsi data tersebut sebelum dikirim melalui redirect

5. Insecure direct object references

• Tujuan = Find the carlos user password and log into his account

Penyerang dapat mengganti ID objek (misalnya, user_id=123) dalam permintaan untuk mengakses data pengguna lain seperti kata sandi milik Carlos.

• Penjelasan:

Referensi: WSTG-ATHZ-01

Insecure Direct Object References adalah kerentanan keamanan yang terjadi ketika aplikasi web secara langsung menggunakan parameter yang dapat diprediksi, seperti ID atau identifier lain, untuk mengakses objek di server tanpa mekanisme validasi atau otorisasi yang memadai. Penyerang dapat memanipulasi parameter (misalnya, mengganti user_id=123 dengan user_id=456) untuk mengakses data milik pengguna lain. Ini terjadi karena kurangnya pemeriksaan hak akses di server.

• Dokumentasi step by step

1. LOGIN

2. lakukan Live chat

 

3. Lakukan view transcript

4. Ubah data transcript/2.txt ke transcript/1.txt

5. Dapat Password carlos

Carlos Password : 0zf888xykw5vbnhh7evs

6. Lakukan login menggunakan username dan password carlos

Rekomendasi:

Untuk mengatasi kerentanan IDOR, pastikan setiap permintaan yang melibatkan akses ke objek tertentu divalidasi oleh server untuk memverifikasi bahwa pengguna memiliki izin yang sesuai. Sebaiknya gunakan referensi unik atau terenkripsi, seperti token atau UUID, alih-alih ID langsung, untuk mencegah manipulasi parameter oleh klien. Validasi tambahan juga perlu diterapkan untuk memastikan objek yang diminta benar-benar milik pengguna. Selain itu, audit semua akses ke objek secara berkala untuk mengidentifikasi pola eksploitasi yang mencurigakan

Authentication

6. Username enumeration via different responses:

• Tujuan = Enumerate a valid username and brute force this user’s password

• Penjelasan = Sistem memiliki kerentanan berupa tidak adanya batas percobaan login. Memungkinkan username dan password yang valid dapat dicari, ditebak, dan dicoba berkali-kali dengan brute force attack tanpa adanya peringatan langsung dari sistem. Sehingga mudah bagi peretas untuk menemukan username dan password yang tepat

• Dokumentasi step by step

1. LOGIN dengan kredensial acak

2. Beralih ke Burp suite, cari history HTTP nya dan kirim ke intruder

3. Masuk ke pengaturan di intruder, lalu blok value parameter admin dan pilih add hingga terdapat simbol $

4. Selanjutnya masukkan list username yang disediakan di lab kedalam payload

5. Lalu masukkan output Invalid username (slide 1) ke dalam list grep match

6. Setelahnya kembali ke position lalu klik Start attack hingga muncul window seperti ini, jika output nya menunjukkan kosong dan bukan angka 1. Maka itulah username yang valid

7. Selanjutnya untuk mencari password yang valid, lakukan hal yang sama dengan list password yang disediakan di lab

8. Jangan lupa untuk mengganti parameter username yang benar dari admin menjadi agenda, lalu blok parameter password admin untuk di add

9. Klik start attack dan tunggu hingga berhasil ditemukan password yang valid, yaitu salah satu list yang menunjukkan status code berbeda dari yang lain. Disini contohnya adalah robert dengan status code 302

10. Dengan username dan password yang sudah ditemukan, kembali ke browser lalu LOGIN dengan kredensial tersebut untuk menyelesaikan lab

Rekomendasi:

Gunakan pesan kesalahan generik yang sama, seperti "Username atau password salah," tanpa memberikan petunjuk yang berbeda. Untuk mengurangi kemungkinan serangan berbasis waktu, terapkan penundaan waktu respons secara konsisten. Batasi jumlah percobaan login yang dapat dilakukan oleh satu IP atau pengguna dalam periode waktu tertentu menggunakan mekanisme rate-limiting.

7. 2FA simple bypass:

• Tujuan = access Carlos’s account page.

Akses akun Carlos dengan melewati autentikasi verifikasi 2 faktor

• Penjelasan = 2F4 merupakan autentikasi 2 langkah, dimana dalam sistem ini terdapat celah untuk melewati autentikasi. Setelah login dengan username dan password, sistem ini menggunakan kode verifikasi yang dikirim melalui email agar bisa login. Namun saat memasuki halaman verifikasi kode, peretas dapat menembusnya dengan mengganti URL di belakangnya dengan “/my-account” sehingga peretas dapat melewati verifikasi dan langsung masuk ke halaman dashboard akun. Menunjukkan tidak adanya adanya algoritma yang mendeteksi akses masuk melalui URL yang belum di verifikasi

• Dokumentasi step by step

1. LOGIN

2. cek email client untuk code security, lalu masukkan code security nya pada link

3. Validasi code (burp suite)

4. Login akun carlos

5. Intercept on

6. Drop Intercept

7. Ubah Link menjadi /my-account

Rekomendasi:

Terapkan sistem 2FA berbasis algoritma yang lebih kuat, seperti Time-based One-Time Password (TOTP), dan pastikan token 2FA diverifikasi secara ketat di sisi server, bukan hanya di klien. Selain itu, audit implementasi autentikasi ganda secara menyeluruh untuk mendeteksi celah logika yang mungkin dimanfaatkan penyerang.

8. Password reset broken logic:  

• Tujuan = reset Carlos’s password and access his “My account” page. Reset password Carlos dan akses halaman akun Carlos

• penjelasan = Sistem ini memiliki kerentanan pada algoritma penggantian atau reset password, dimana token untuk penggantian password tidak diperiksa kembali oleh sistem algoritma sehingga permintaan pergantian password dapat dimanipulasi untuk akun lain

• Dokumentasi step by step

1. Masuk ke halaman LOGIN lalu klik tombol Forgot password

2. Masukkan username kredensial Wiener

3. Klik email client dan klik link yang disediakan dalam email client tersebut, maka akan tampil halaman berikut

4. Update dengan password yang diinginkan, Lalu beralih ke history HTTP dan cari proxy yang memiliki method POST lalu kirim ke repeater

5. Di repeater, ubah value dari parameter temp-forgot-password-token yang ada di baris pertama dan terakhir dengan value yang sama. Misalnya disini adalah “x”, kemudian ganti username nya menjadi carlos dan klik send. Jika sudah, maka klik tombol Follow redirection yang ada di bagian atas kolom request

6. Kemudian kembali ke browser lalu LOGIN menggunakan username carlos dan password yang sudah kita update

Rekomendasi:

Setiap permintaan reset password harus menggunakan token unik yang dikirimkan melalui saluran aman seperti email atau SMS. Token tersebut harus divalidasi secara ketat di sisi server. Batasi jumlah percobaan reset password yang dapat dilakukan untuk satu akun dalam periode waktu tertentu untuk mencegah penyalahgunaan. Selain itu, lakukan audit proses reset password untuk memastikan tidak ada kelemahan logika yang dapat dieksploitasi

• Path Traversal

9. File path traversal, simple case: 

• Tujuan = Retrieve the content of the /etc/passwd file

Mencari jalur file pada sistem yang seharusnya tidak untuk sembarang user

• Penjelasan : Kerentanan pada input yang tidak divalidasi dengan baik membuat peretas memanipulasi jalur file yang digunakan dalam sistem. misal dengan memasukkan karakter seperti ../ dalam parameter input yang digunakan untuk menentukan lokasi file, peretas mengakses file sistem di luar direktori yang diizinkan seperti /etc/passwd pada sistem Unix-like dan meluncurkan serangan privilege escalation.

• Dokumentasi Step By Step

1. Halaman Utama

2. Cari history HTTP lalu kirim ke repeater

3. Dapat dilihat ini adalah filename yang salah, ubah filename nya dengan ../../../etc/passwd

4. Mengubah filename menjadi benar

5. Hasil tampilan akhir

Rekomendasi:

Untuk mencegah serangan path traversal, pastikan input pengguna divalidasi secara ketat untuk mendeteksi karakter traversal seperti ../. Gunakan whitelist file yang diperbolehkan untuk diakses oleh pengguna, dan gunakan jalur absolut di server. Selain itu, pastikan aplikasi berjalan dengan izin minimal untuk membatasi akses ke file sensitif.

• Business logic

10. Excessive trust in client-side controls: 

• Tujuan = Checkout item with customized price

Memanipulasi data harga barang pada sistem yang memiliki kerentanan logika di sisi klien

• Penjelasan : Kerentanan pada banyaknya kepercayaan terhadap kontrol yang dilakukan di sisi klien (client-side). Dalam transaksi online, beberapa aplikasi bergantung pada logika sisi klien untuk memanipulasi harga/ diskon. Jika aplikasi tidak memverifikasi ulang harga di sisi server/ tidak memvalidasi nilai yang dimodifikasi di sisi klien, peretas bisa memodifikasi harga produk sebelum checkout untuk mendapatkan barang dengan harga yang rendah atau bahkan gratis.

• Dokumentasi step by step

1. LOGIN

2. Kembali ke Home lalu pilih item yang diminta, lalu klik Add to cart

3. Validasi harga (Burp suite) lalu kirim ke repeater

4. Ubah harga ke angka bulat di bawah 100$ dan send

5. Harga setelah diubah di browser

6. Check out barang

Rekomendasi:

Untuk melindungi logika bisnis dari manipulasi harga atau data lain, server harus memvalidasi setiap data yang diterima dari klien untuk memastikan konsistensinya dengan aturan bisnis. Sebagai tambahan, tambahkan otorisasi pada setiap tindakan sensitif, seperti perubahan harga atau kuantitas produk. Audit logika bisnis secara berkala untuk mengidentifikasi kelemahan yang berpotensi dieksploitasi oleh penyerang.