flawopen.com/SSRF/Metadata cloud dan SSRF

Bagaimana SSRF dapat menjangkau metadata cloud, dan kapan kredensial berisiko?

Halaman referensi

Penjelasan sederhana

Bayangkan layanan metadata sebagai loket layanan internal yang terkunci di dalam mesin cloud. SSRF dapat menjadikan aplikasi Anda kurir ke loket itu, tetapi data yang dapat diambil bergantung pada aturan permintaan penyedia, konfigurasi instans, dan jalur jaringan aplikasi. Endpoint yang dapat dijangkau tidak otomatis berarti kredensial terekspos.

Mengapa endpoint metadata dapat berbahaya

AWS EC2, Azure, dan Google Compute Engine mendokumentasikan layanan metadata instans yang dapat diakses dari lingkungan VM yang didukung. 169.254.169.254 adalah alamat link-local yang umum, tetapi format permintaan dan kontrolnya berbeda. Metadata dapat memuat detail instans yang sensitif; AWS dapat mengembalikan kredensial peran sementara jika profil instans dan jalur permintaan mengizinkannya. SSRF menjadi risiko jika penyerang dapat memengaruhi permintaan server yang mencapai layanan ini. Keterjangkauan saja tidak membuktikan kredensial dapat diambil: header atau token wajib, metode HTTP, proxy, posisi jaringan, dan konfigurasi instans memengaruhi hasil.

Bagaimana rantai dampak terbentuk

Dampak memerlukan beberapa kondisi berurutan: input memengaruhi permintaan server; permintaan mencapai layanan metadata; layanan menerimanya sesuai kontrol penyedia; dan data yang dikembalikan memberi akses yang berguna. Cakupan akhirnya bergantung pada izin identitas beban kerja. Putus rantai ini dengan tujuan tetap, kontrol egress ketat, perlindungan metadata penyedia, dan identitas berhak minimum.

Pertanyaan umum

Apakah semua penyedia cloud memakai alamat atau kontrol akses yang sama?

Tidak. Alamat, header, metode, persyaratan token, dan data yang tersedia berbeda. AWS IMDSv2 memerlukan token sesi untuk mengambil metadata saat HttpTokens disetel ke required; Azure mewajibkan header Metadata: true; Google mendokumentasikan header Metadata-Flavor: Google. Kontrol ini dapat mengurangi sebagian jalur SSRF, tetapi tidak menggantikan pencegahan tujuan yang dikendalikan pengguna atau pemblokiran egress yang tidak diperlukan. Periksa dokumentasi penyedia untuk konfigurasi VM dan kontainer yang tepat.

Sumber dan analisis terkait

Lihat juga Pemalsuan request sisi server (SSRF, CWE-918): cara kerja dan cara mencegahnya di setiap bahasa — flawopen.com Bot PR AI: Cegah SSRF — flawopen.com SSRF Node.js fetch(): Ambil URL dengan Aman