AWS S3 Multi-Bucket Compromise via GraphQL Federation SSRF

Pendahuluan

Dalam dunia bug bounty dan penetration testing, ada vulnerability yang terlihat kecil di awal, tetapi dampaknya sangat besar ketika dieksploitasi.

Artikel ini membahas sebuah pola vulnerability pada arsitektur GraphQL Federation yang berujung pada:

• SSRF (Server-Side Request Forgery)
• Arbitrary File Read
• Kebocoran kredensial AWS
• Kompromi beberapa bucket S3 sekaligus
• Akses ke data sensitif internal

Semua itu bermula dari satu parameter GraphQL bernama:

includeAnalytics

Sekilas parameter ini terlihat normal. Namun di balik itu, terdapat kesalahan validasi yang membuka jalur eksploitasi ke berbagai service internal.

Apa Itu GraphQL Federation?

GraphQL Federation adalah pola arsitektur yang menggabungkan beberapa GraphQL service menjadi satu endpoint terpusat.

Ilustrasinya seperti ini:

Gateway bertugas menerima request dari client, lalu meneruskannya ke microservice yang sesuai.

Kenapa SSRF Sering Muncul di GraphQL Gateway?

Ada beberapa alasan utama:

1. Gateway Melakukan HTTP Request Internal

Gateway sering membentuk URL internal secara dinamis.

Jika input user ikut digunakan dalam pembentukan URL, maka SSRF dapat terjadi.

2. GraphQL Type-Safe ≠ Aman

Banyak developer menganggap:

includeAnalytics: String

sudah cukup aman. Padahal String hanya memastikan input berupa string.GraphQL tidak memvalidasi apakah isi string tersebut aman atau tidak. Payload seperti berikut tetap dianggap valid:

file:///etc/passwd
http://127.0.0.1/
http://attacker.com

3. Service Internal Terlalu Percaya pada Gateway

Banyak microservice internal menganggap semua request dari gateway adalah trusted.

Akibatnya, ketika attacker berhasil memanfaatkan gateway sebagai SSRF proxy, service internal ikut terekspos.

Bagian 3 — Root Cause Vulnerability

Query Parser

Potongan kode berikut melakukan parsing query GraphQL:

async function parseGraphQLQuery(query) {
  const userMatch = query.match(
    /user\s*\(\s*id:\s*"([^"]+)"(?:,\s*includeAnalytics:\s*"([^"]*)")?\s*\)/
  );

if (!userMatch) return null;

const userId = userMatch[1];
  const analyticsParam = userMatch[2];

if (analyticsParam) {
    const internalResponse = await makeInternalServiceCall(userId, analyticsParam);
  }
}

Masalah utamanya: includeAnalytics dianggap aman hanya karena lolos regex. Padahal regex tersebut menerima string apa pun selama tidak mengandung karakter kutip.

Request normal yang dikirim frontend:

POST /graphql HTTP/1.1
Content-Type: application/json

{
  "query":"{ user(id: \"1\", includeAnalytics: \"purchases\") { id } }"
}

Menguji Parameter

Payload:

{
  "query":"{ user(id: \"1\", includeAnalytics: \"CANARY1337\") { id } }"
}

Result

Bagian 4 — Mitigasi

Mitigasi untuk vulnerability seperti ini tidak bisa hanya mengandalkan satu lapisan keamanan. Pendekatan terbaik adalah menerapkan defense in depth, yaitu kombinasi beberapa mekanisme proteksi sekaligus. Pada level aplikasi, developer sebaiknya menggunakan allowlist dan enum GraphQL agar input user tidak bisa digunakan secara bebas untuk membentuk URL atau path internal. Input juga harus divalidasi ulang sebelum digunakan pada konteks berbeda seperti HTTP request atau file access.Di sisi infrastruktur, service GraphQL gateway sebaiknya dibatasi akses jaringan keluar (egress restriction) agar hanya dapat berkomunikasi dengan service internal tertentu. Dengan cara ini, meskipun SSRF berhasil ditemukan, attacker tetap tidak bisa mengakses metadata cloud, localhost, ataupun internet secara bebas.

Pada level cloud security, prinsip IAM least privilege wajib diterapkan. Hindari penggunaan policy seperti AmazonS3FullAccess untuk aplikasi yang sebenarnya hanya membutuhkan akses terbatas. Setiap bucket idealnya menggunakan credential dan permission terpisah agar kompromi pada satu service tidak langsung berdampak ke seluruh environment.

Selain itu, production environment sebaiknya tidak menyimpan static credential sensitif di file .env. Gunakan solusi seperti AWS Secrets Manager, Parameter Store, atau IAM Role agar secret dapat dikelola secara lebih aman dan ter-rotasi otomatis.