Belajar SOAP - Secure Coding & API Security Testing

#Pendahuluan

Setelah di episode 16 kita mengamankan autentikasi dan otorisasi, sekarang kita menghadapi sisi gelap XML: serangan yang lahir dari struktur XML itu sendiri. SOAP menerima dokumen XML yang sepenuhnya ditentukan oleh pengirim — dan pengirim bisa jadi penyerang.

Mengapa penting? Karena banyak kerentanan keamanan paling mematikan di API bukan serangan ala film — melainkan eksploitasi atas perilaku parser: XML yang dikirim untuk membaca file server, membanjiri memory, atau melewati validasi keamanan. Service SOAP yang tidak mengamankan parsing XML adalah pintu terbuka, meskipun autentikasi dan TLS-nya sempurna.

#Serangan-Serangan Utama pada SOAP

#XXE (XML External Entity)

Serangan paling klasik dan paling berbahaya. Dengan mendeklarasikan entity eksternal, penyerang bisa membaca file server atau meminta server mengakses URL internal:

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <bank:getBalance xmlns:bank="urn:example:bank">
      <bank:accountNo>&xxe;</bank:accountNo>
    </bank:getBalance>
  </soap:Body>
</soap:Envelope>

Jika parser tidak mengamankan DOCTYPE, nilai &xxe; diganti isi /etc/passwd dan bisa bocor di response. Mitigasi: nonaktifkan semua DTD di parser XML. Beberapa framework menonaktifkannya secara default, banyak yang tidak.

#Billion Laughs (Entity Expansion)

Perkembangan XXE yang membanjiri memory tanpa membaca file — entity yang merujuk entity lain secara eksponensial:

<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
  ...
]>

Serangan ini meledakkan ukuran dokumen menjadi gigabyte di memory. Mitigasi yang sama: nonaktifkan DTD dan batasi ukuran dokumen.

#XML Signature Wrapping

Serangan paling licik: penyerang mengambil pesan yang ditandatangani sah, lalu membungkusnya dalam envelope baru dan mengubah logika yang "dianggap" body oleh aplikasi:

<soap:Body>
  <spoofed>... operasi jahat ...</spoofed>
  <realSignedOperation wsu:Id="valid-op">
    ... operasi yang sah dan ditandatangani ...
  </realSignedOperation>
</soap:Body>

Jika aplikasi memvalidasi signature pada valid-op (yang memang sah), tetapi kemudian mengeksekusi spoofed (yang tidak ditandatangani), penyerang sukses. Mitigasi: validasi dan eksekusi harus pada elemen yang sama dan identik — jangan validasi satu elemen lalu proses elemen lain.

#Replay Attack

Dari episode 14: mengirim ulang request sah yang sudah lewat. Mitigasi: timestamp + nonce yang diverifikasi, dan pencatatan MessageID yang sudah diproses dalam jangka waktu tertentu.

#Schema Bypass / Over-permissive Parsing

Server yang "memperbaiki" request alih-alih memvalidasinya. Contoh: client mengirim field tak dikenal — parser yang toleran menambahkannya ke object, lalu code menggunakan field itu. Mitigasi: validasi ketat terhadap XSD, tolak yang tidak dikenal, dan jangan pernah "membersihkan" input secara diam-diam.

#Pengujian Keamanan dengan SoapUI Security

SoapUI menyediakan security scans pada test suite:

TestSuite > Security Tests > Add Security Scan
  ├── XPath Injection
  ├── XML Bomb
  ├── Malformed XML
  ├── Fuzzing (random/edge inputs)
  └── Cross Site Scripting

Jalankan scans ini pada setiap operasi, terutama terhadap input yang menuju parser XML (di SoapUI 5.x, integrasi dengan OWASP ZAP tersedia via plugin). Tujuannya: membuktikan server menolak malformed XML, entity expansion, dan input berbahaya tanpa crash atau bocor data.

#Pengujian dengan Burp/ZAP

Burp Suite dan OWASP ZAP adalah proxy interceptor standar industri. Alur untuk SOAP:

1. Arahkan client SOAP ke proxy (mis. ZAP di localhost:8080... konfigurasi HTTP proxy).
2. Tangkap request SOAP — kalian melihat pesan mentah sebelum dikirim.
3. Modifikasi (tamper) request: ganti body, tambah DTD, ubah header Security.
4. Kirim ulang (repeater) dan periksa bagaimana server merespons.
5. Gunakan scanner otomatis untuk fuzz semua parameter dan header.

Client SOAP -> Proxy (ZAP/Burp) -> Service
    ^               |
    |___tamper______|

#Checklist Produksi

Sebelum service SOAP diluncurkan, pastikan semua poin ini:

• Parser XML aman: DTD dan external entity dinonaktifkan di semua parser (JAXP, DOM, SAX, StAX).
• Batasi ukuran payload: ukuran request maksimal di connector dan di interceptor aplikasi.
• Batasi kedalaman/kompleksitas XML: tolak dokumen dengan nesting ekstrem (beyond billion laughs).
• Validasi ketat terhadap XSD: tolak elemen tak dikenal; jangan "memperbaiki" request.
• Message expiry: timestamp + nonce diverifikasi; MessageID diproses-satu-kali untuk periode tertentu.
• Signature wrapping diuji: validasi dan eksekusi memakai elemen yang identik.
• Least privilege: RBAC di level operasi, credential terpisah per mitra.
• Log keamanan: autentikasi gagal, request mencurigakan, dan pelanggaran kebijakan tercatat.

#Penutup

Inti yang harus dibawa pulang:

• XXE dan entity expansion diblokir dengan menonaktifkan DTD dan membatasi ukuran/kedalaman dokumen.
• Signature wrapping dicegah dengan memastikan elemen yang divalidasi sama persis dengan yang dieksekusi.
• Replay dicegah dengan timestamp + nonce + pencatatan pesan yang sudah diproses.
• Uji keamanan dengan SoapUI security scans dan proxy Burp/ZAP, termasuk tamper pada request bertanda tangan.
• Checklist produksi: validasi XSD ketat, size limit, expiry, least privilege, dan log keamanan.

Di episode 18 selanjutnya kita akan membahas interoperabilitas & WS-I Basic Profile — standar yang menjamin Java, .NET, dan PHP berbicara lancar, tool verifikasi WS-I, serta cara menyelesaikan incompatibility lintas stack yang umum. Sampai jumpa di episode 18!