SSRF di Serverless: Awas, Cloud-mu Bisa Jebol!

Pernah Ngerasa Serverless Itu 100% Aman? Pikir Lagi, Lur!

Lagi asik-asik ngoding AWS Lambda atau Google Cloud Functions, terus lo mikir, "Wah, kan gak ada server fisiknya, pasti aman banget nih dari serangan hacker jadul." Eits, jangan salah kaprah dulu! Meskipun namanya serverless, di balik layar tetep ada infrastruktur yang jalanin kode lo. Dan salah satu celah yang paling sering disepelein tapi efeknya bisa bikin nangis bombay adalah SSRF (Server-Side Request Forgery).

Bayangin lo punya fitur buat narik data dari URL luar, eh malah dimanfaatin hacker buat ngintip daleman cloud lo. Ngeri kan? Makanya, gaskeun kita bahas tuntas gimana SSRF ini bisa jadi mimpi buruk di dunia serverless yang katanya serba canggih ini.

Apa Sih SSRF Itu Sebenernya?

SSRF itu kondisi pas penyerang bisa maksa aplikasi server-side buat ngirim request ke lokasi yang gak seharusnya. Lokasi ini bisa berupa internal network, local host, atau metadata service milik cloud provider. Di dunia serverless, SSRF itu ibarat lo ngasih kunci cadangan apartemen lo ke orang asing cuma gara-gara dia nanya alamat lewat kurir. Hacker nggak perlu nembus firewall lo yang berlapis-lapis, dia cukup minjem tangan function lo buat ngelakuin hal-hal terlarang.

Kenapa Serverless Malah Jadi Sasaran Empuk?

Banyak developer yang agak mager buat mikirin security di level infrastruktur karena mikirnya itu tugas provider (AWS, GCP, Azure). Padahal, security itu shared responsibility, lur! Di arsitektur serverless, function lo seringkali punya akses ke Metadata Service (kayak IMDS di AWS). Metadata ini isinya info sensitif banget, mulai dari ID instance sampe temporary credentials (IAM Role) yang bisa dipake buat ngacak-ngacak resource cloud lo yang lain.

Skenario SSRF yang Sering Kejadian

Misalnya nih, lo bikin fitur simpel buat 'Screenshot Website' atau 'URL Preview'. User tinggal masukin URL, terus function lo bakal nge-fetch URL itu. Kalo lo gak validasi inputnya dengan bener, hacker bisa masukin alamat internal kayak http://169.254.169.254/latest/meta-data/. Kalo tembus, si hacker dapet token akses cloud lo. Kelar deh idup lo, wkwk.

Contoh Kode yang Bahaya (Vulnerable Code)

Coba cek potongan kode Node.js di bawah ini yang biasa dipake di AWS Lambda. Keliatannya normal, tapi ini sebenernya ngundang maling masuk rumah.

const axios = require('axios');

exports.handler = async (event) => {
    const targetUrl = event.queryStringParameters.url;
    
    // BAHAYA: Gak ada validasi sama sekali!
    const response = await axios.get(targetUrl);
    
    return {
        statusCode: 200,
        body: JSON.stringify({ data: response.data })
    };
};

Kalo ada user iseng manggil endpoint lo dengan parameter ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role, function lo bakal dengan senang hati ngasih tau secret key dan session token ke si hacker. Asli, ini mah namanya bunuh diri digital.

Cara Mencegah SSRF Biar Gak Kebobolan

Tenang, jangan panik dulu. Ada beberapa cara ampuh biar function serverless lo gak gampang kena retak. Gaskeun terapin langkah-langkah ini:

• Validasi Input Pake Allowlist: Jangan cuma nge-block URL tertentu (blocklist), tapi tentuin URL mana aja yang boleh diakses (allowlist). Kalo cuma butuh akses ke domain lo sendiri, ya kunci cuma ke situ aja.
• Gunakan Library yang Aman: Beberapa library HTTP client punya fitur buat nge-restrict akses ke IP private atau internal.
• Update ke IMDSv2: Kalo lo pake AWS, pastiin pake Instance Metadata Service Version 2 yang butuh token session, jadi gak segampang itu ditembus pake SSRF biasa.
• Prinsip Least Privilege: Kasih IAM Role ke function lo seminimal mungkin. Kalo cuma butuh nulis ke S3, jangan dikasih akses AdministratorAccess, kocak banget kalo sampe kejadian gitu.
• Network Isolation: Taruh function lo di dalam VPC (Virtual Private Cloud) dan atur Security Group-nya biar gak sembarangan bisa outbound request ke mana-mana.

Kesimpulan Singkat (Eh, Gak Boleh Pake Kata Ini Ya?)

Pokoknya, intinya adalah jangan pernah percaya sama input dari user, sekecil apapun itu. Dunia serverless emang bikin hidup kita lebih gampang karena gak perlu mikirin patching OS, tapi urusan logic security tetep ada di tangan kita sebagai developer. Jangan sampe gara-gara satu baris kode yang kurang validasi, tagihan cloud lo membengkak gara-gara dipake mining sama hacker, atau lebih parah lagi data user lo bocor semua.

Pernah gak sih lo nemu celah aneh pas lagi iseng-iseng testing function serverless buatan sendiri?

FAQ (Pertanyaan Umum)