10 ancaman Aplikasi Web teratas OWASP

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X.
info

Dokumen ini menjelaskan berbagai pendekatan yang dapat Anda gunakan dalam Apigee untuk mengatasi kerentanan keamanan yang diidentifikasi oleh OWASP. Untuk pendekatan tambahan yang didokumentasikan untuk Apigee, lihat 10 opsi mitigasi teratas OWASP 2021 di Google Cloud.

Ringkasan

Ekosistem API mengalami berbagai serangan dari klien eksternal dan internal. Menawarkan dan menggunakan API menciptakan peluang besar bagi penyedia layanan, tetapi juga menimbulkan beberapa risiko keamanan. Developer harus mengetahui tantangan ini dan mengatasinya saat mereka membuat dan menggunakan API.

OWASP adalah komunitas terbuka yang didedikasikan untuk membantu organisasi mengembangkan, membeli, dan mengelola aplikasi dan API tepercaya. Melalui project OWASP API Security, OWASP memublikasikan risiko keamanan yang paling penting untuk aplikasi web dan REST API serta memberikan rekomendasi untuk mengatasi risiko tersebut.

Dengan Apigee, lapisan proxy API dapat mendeteksi, memblokir, dan melaporkan permintaan API yang salah format dari klien sebelum permintaan diproses di sistem backend, sehingga mengurangi risiko dan melindungi layanan Anda. Permintaan yang salah format dapat mencakup komponen apa pun yang membentuk protokol tingkat aplikasi HTTP:

  • URL
  • Header
  • Jalur
  • Payload

Permintaan API yang salah format dapat berasal dari klien yang diketahui atau tidak diketahui yang dikembangkan oleh developer eksternal, developer internal, atau bot berbahaya.  Jenis permintaan ini membentuk sebagian besar ancaman OWASP, tetapi ada komponen tambahan dari lapisan proxy API yang mendasarinya yang dapat memitigasi risiko, seperti penyamaran data, logging, administrasi, dan sebagainya.

Platform pengelolaan API cerdas Apigee memungkinkan Anda mengatasi kerentanan keamanan API OWASP teratas dengan lancar saat Anda menggunakan pendekatan yang berfokus pada konsumsi untuk mendesain API dan menghubungkannya dengan sistem backend. Berikut adalah daftar kebijakan/konfigurasi yang direkomendasikan Apigee untuk ancaman OWASP REST teratas.

Solusi Apigee untuk 10 Teratas OWASP 2017

Ada banyak masalah keamanan terkait pembuatan dan pengamanan aplikasi web. OWASP merilis daftar 10 Ancaman Keamanan OWASP Teratas 2017 untuk aplikasi web.  Meskipun ada banyak bagian dalam aplikasi web, sebagian besar aplikasi web modern sangat mengandalkan REST API.  Apigee tidak dimaksudkan untuk menangani semua kebutuhan keamanan aplikasi web, tetapi dapat memainkan peran penting dalam mengamankan REST API. Berikut adalah ancaman keamanan OWASP teratas dengan deskripsi cara menggunakan Apigee untuk membantu mengatasi ancaman tersebut.

A1:2017 - Injeksi

Untuk melindungi dari injeksi data yang tidak tepercaya seperti SQL, NoSQL, LDAP, dan JavaScript, yang dapat mengakibatkan eksekusi perintah yang tidak diinginkan atau akses data yang tidak sah, Apigee menyediakan beberapa kebijakan validasi input untuk memverifikasi bahwa nilai yang diberikan oleh klien sesuai dengan ekspektasi sebelum mengizinkan pemrosesan lebih lanjut. Apigee Edge, yang bertindak sebagai server untuk permintaan API masuk, memeriksa untuk memastikan struktur payload berada dalam rentang yang dapat diterima, yang juga dikenal sebagai pemeriksaan batas. Anda dapat mengonfigurasi proxy API agar rutinitas validasi input mengubah input untuk menghapus urutan karakter berisiko dan menggantinya dengan nilai yang aman.

Ada beberapa pendekatan untuk memvalidasi input dengan platform Apigee:

Validasi jenis konten:

A2:2017 - Pengelolaan Autentikasi dan Sesi yang Rusak

Penyerang dapat mengakses sandi, token sesi, dan kunci untuk meniru identitas pengguna lain dengan memanfaatkan kelemahan implementasi dalam aplikasi. Hal ini lebih merupakan masalah penerapan, bukan masalah produk.  Apigee menyediakan kebijakan VerifyApiKey, OAuth, dan Token Web JSON (JWT), yang membantu melindungi dari kerentanan ini.

Validasi kunci API

Validasi kunci API adalah bentuk keamanan berbasis aplikasi paling sederhana yang dapat dikonfigurasi untuk API. Aplikasi klien hanya menampilkan kunci API dengan permintaannya, lalu Apigee Edge, melalui kebijakan yang terpasang ke proxy API, memeriksa untuk melihat apakah kunci API berada dalam status yang disetujui untuk resource yang diminta.

Apigee menyediakan dukungan untuk pembuatan dan validasi Kunci API. Apigee membuat kunci dan secret API saat aplikasi developer dibuat dan disetujui yang ditautkan ke satu atau beberapa produk API.

Istilah “kunci API” terkadang memiliki arti yang berbeda. Di Apigee, saat hubungan aplikasi dan produk terbentuk, Apigee akan membuat client ID dan rahasia klien.  Beberapa orang menyebut ID dan secret sebagai kunci API. Beberapa hanya menyebut client ID sebagai kunci API. Di UI Edge, Anda akan melihat "kunci konsumen" dan "rahasia konsumen".

Dalam kebijakan VerifyAPIKey, hanya client ID, atau "kunci konsumen", yang diverifikasi. Developer menerima kunci konsumen saat mereka mendaftarkan aplikasi ke Apigee dan mengaitkan aplikasi dengan produk API. Developer menyertakan kunci konsumen dalam panggilan yang dilakukan aplikasi ke proxy API yang dipaketkan dalam produk API.

Apigee juga mendukung kemampuan untuk mengimpor kunci API yang ada dari sumber eksternal.

Untuk jenis pemberian OAuth, client ID dan secret digunakan.

OAuth 2.0

Framework otorisasi OAuth 2.0 memungkinkan aplikasi pihak ketiga mendapatkan akses terbatas ke layanan HTTP, baik atas nama pemilik resource dengan mengatur interaksi persetujuan antara pemilik resource dan layanan HTTP, atau dengan mengizinkan aplikasi pihak ketiga untuk mendapatkan akses atas namanya sendiri.

Kebijakan OAuth 2.0 Apigee memungkinkan Anda menerapkan dan menyesuaikan empat jenis pemberian OAuth 2.0. Penerapan token akses OAuth dapat dilakukan menggunakan kebijakan OAuthv2. Konsumen harus terdaftar dan memiliki aplikasi yang disetujui yang telah memberi mereka akses ke API. Sebagai gantinya, mereka akan menerima client ID dan rahasia klien API. Konsumen harus melalui salah satu pemberian OAuth untuk diautentikasi, yang memberi mereka token akses buram. Token ini dapat digunakan untuk mengontrol akses ke API.

JWT

Token Web JSON, atau JWT, biasanya digunakan untuk membagikan klaim atau pernyataan antara aplikasi yang terhubung. Apigee menyediakan dukungan JWT menggunakan tiga kebijakan.

  • Token GenerateJWT (mendukung tanda tangan HS256 dan RS256)
  • Token ValidateJWT
  • Mendekode token JWT tanpa memvalidasi

A3:2017 - Eksposur Data Sensitif

Penyerang menargetkan data sensitif seperti detail kartu kredit, nomor jaminan sosial, kredensial login, informasi identitas pribadi (PII), dan ID pajak untuk melakukan pencurian identitas, pencurian uang, penipuan, dan kejahatan lainnya. Aplikasi web perlu menerapkan enkripsi, baik saat dalam penyimpanan maupun dalam pengiriman, dan strategi lainnya untuk memastikan perlindungan data sensitif.

TLS (Transport Layer Security, yang pendahulunya adalah SSL) adalah teknologi keamanan standar untuk membuat link terenkripsi antara server web dan klien web, seperti browser atau aplikasi. Apigee mendukung TLS satu arah dan dua arah.

TLS northbound (klien yang terhubung ke API yang bertindak sebagai server) didukung melalui penggunaan konfigurasi Virtual Host. Host virtual dapat dikonfigurasi untuk TLS satu arah atau dua arah.

TLS Southbound (apigee sebagai klien yang terhubung ke layanan backend) didukung melalui penggunaan konfigurasi Target Server.  Server Target dapat dikonfigurasi untuk TLS satu arah atau dua arah.

Apigee mendukung banyak opsi konfigurasi TLS.

Penerapan TLS 2 arah memastikan bahwa klien menggunakan sertifikat yang telah diaktifkan di Apigee. OWASP juga menyediakan praktik terbaik TLS.

Di Apigee hybrid, TLS tersedia di ingress melalui alias host, yang merupakan konsep yang mirip dengan host virtual.

Berikut adalah panduan untuk mengamankan data sensitif:

  • Gunakan platform yang mendukung TLS satu arah dan dua arah, yang akan melindungi di tingkat protokol.
  • Gunakan kebijakan seperti kebijakan AssignMessage dan kebijakan JavaScript untuk menghapus data sensitif sebelum ditampilkan ke klien.
  • Gunakan teknik OAuth standar dan pertimbangkan untuk menambahkan HMAC, hash, status, nonce, PKCE, atau teknik lainnya untuk meningkatkan level autentikasi untuk setiap permintaan.
  • Gunakan setelan penyamarkan data untuk menyamarkan data sensitif di alat Edge Trace.
  • Berhati-hatilah saat menyimpan data sensitif apa pun di cache (atau mengenkripsi data sensitif yang disimpan di cache). Di Edge, Anda dapat mengenkripsi data sensitif dalam penyimpanan di peta nilai kunci.

A4:2017 - Entitas Eksternal XML

Sistem atau aplikasi yang memproses XML harus menangani "referensi entity eksternal" dalam XML—referensi ke file atau data yang diganti dengan data sebenarnya selama pemrosesan XML. Jika aplikasi atau pemroses XML sudah lama atau tidak diterapkan dengan baik, penyerang dapat meretas data dan menggunakannya untuk mencuri informasi atau meluncurkan berbagai jenis serangan pada sistem, seperti denial of service.

Kebijakan ExtractVariables Apigee memungkinkan Anda mengekstrak konten dari permintaan atau respons, dan menetapkan konten tersebut ke variabel. Anda dapat mengekstrak setiap bagian pesan, termasuk header, jalur URI, payload JSON/XML, parameter formulir, dan parameter kueri. Kebijakan ini berfungsi dengan menerapkan pola teks ke konten pesan dan, setelah menemukan kecocokan, menetapkan variabel dengan konten pesan yang ditentukan.

Apigee memiliki parser XML bawaan sebagai bagian dari platform yang menggunakan XPath untuk mengekstrak data. Aplikasi ini juga memiliki kebijakan XMLThreatProtection untuk melindungi dari payload XML berbahaya.

A5:2017 - Kontrol Akses yang Rusak

Setelah pengguna login dan mendapatkan akses ke sistem, kontrol otorisasi yang tepat harus diterapkan agar pengguna hanya dapat melihat dan melakukan hal-hal yang diizinkan. Tanpa kontrol akses yang kuat, penyerang dapat melihat data yang tidak sah dan sering kali sensitif atau memanipulasi data dan perilaku sistem dengan niat jahat.

Apigee mendukung pendekatan berlapis untuk menerapkan kontrol akses guna mencegah pihak yang tidak bertanggung jawab membuat perubahan yang tidak sah atau mengakses sistem.

Kontrol akses untuk UI Edge

Kontrol akses untuk Portal Developer Apigee

  • Konfigurasikan single sign-on dengan penyedia identitas perusahaan Anda.
  • Konfigurasikan kontrol akses berbasis peran (RBAC) agar hanya mengizinkan pengguna mengakses fungsi dan konfigurasi yang mereka butuhkan di portal developer berbasis Drupal.
  • Konfigurasi portal developer untuk menampilkan produk API tertentu sesuai dengan peran pengguna.
  • Konfigurasi portal untuk menampilkan atau menyembunyikan konten berdasarkan peran pengguna.

Kontrol akses untuk akses API runtime Apigee

  • Akses ke API dapat diterapkan melalui kunci API, token OAuth, cakupan OAuth, sertifikat, dan teknik lainnya.
  • Penyedia API mengonfigurasi resource yang tersedia dengan menentukan produk API. Akses diberikan secara manual di UI, melalui API pengelolaan, atau melalui portal developer. Saat aplikasi developer diberi akses ke produk API, mereka akan menerima client ID dan secret yang digunakan dalam proses autentikasi.
  • Apigee dapat berintegrasi dengan penyedia identitas apa pun untuk melakukan OAuth.
  • Apigee dapat membuat token JWT atau teknik lain untuk mengirim identitas pengguna ke layanan target. Layanan target dapat menggunakan identitas tersebut untuk membatasi akses ke layanan dan data sesuai kebutuhan.

A6:2017-Kesalahan Konfigurasi Keamanan

Konfigurasi keamanan yang salah mudah diabaikan, sering kali karena administrator dan developer keliru memercayai bahwa sistem yang mereka gunakan secara inheren aman. Kesalahan konfigurasi keamanan dapat terjadi dalam berbagai cara, seperti memercayai konfigurasi default atau membuat konfigurasi parsial yang mungkin tidak aman, mengizinkan pesan error berisi detail sensitif, menyimpan data di cloud tanpa kontrol keamanan yang tepat, salah mengonfigurasi header HTTP, dan sebagainya. Platform Apigee menyediakan sejumlah mekanisme untuk memungkinkan Anda mengontrol, mengelola, dan memantau konfigurasi keamanan, termasuk alur bersama yang dapat digunakan kembali.

Alur bersama memungkinkan developer API menggabungkan kebijakan dan resource ke dalam grup yang dapat digunakan kembali. Dengan menangkap fungsi yang dapat digunakan kembali di satu tempat, alur bersama membantu Anda memastikan konsistensi, mempersingkat waktu pengembangan, dan mengelola kode dengan lebih mudah. Anda dapat menyertakan alur bersama di dalam setiap proxy API, atau Anda dapat melakukan langkah lebih lanjut dan menempatkan alur bersama di hook alur untuk otomatis menjalankan logika alur bersama untuk setiap proxy API yang di-deploy di lingkungan yang sama dengan alur bersama.

Rilis produk Apigee memastikan perlindungan terhadap library yang memiliki kerentanan. Apigee dapat merilis patch atau update tambahan jika ditemukan kerentanan baru. Cloud publik Edge di-patch secara otomatis. Pelanggan Edge untuk Private Cloud (di lokal) harus menerapkan patch produk sendiri.

A7:2017-Pembuatan Skrip Lintas Situs (XSS)

Pembuatan skrip lintas situs (XSS) memungkinkan penyerang mengeksekusi skrip di browser web pengguna untuk mengontrol sesi pengguna, memanipulasi situs web, atau memengaruhi pengguna secara berbahaya dengan cara lain. Masalah XSS tidak selalu terkait dengan API, tetapi Apigee menyediakan kebijakan perlindungan terhadap ancaman yang dapat dimanfaatkan untuk mencegah XSS di API.  Menggunakan ekspresi reguler, baik dengan kebijakan RegularExpressionProtection atau kebijakan JavaScript, periksa payload dan parameter value untuk JavaScript dan serangan jenis injeksi lainnya.

CORS, salah satu solusi yang umum diterapkan untuk kebijakan asal yang sama yang diterapkan oleh semua browser, dapat diterapkan menggunakan kebijakan AssignMessage.

A8:2017 - Deserialisasi Tidak Aman

Penyerang dapat menggunakan kelemahan dalam deserialisasi untuk berbagai jenis serangan, seperti replay, eskalasi akses, dan injeksi. Deserialisasi yang tidak aman juga dapat mengaktifkan eksekusi kode jarak jauh.

Apigee tidak merekomendasikan deserialisasi. Namun, kebijakan JSONThreatProtection dan kebijakan RegularExpressionProtection dapat membantu melindungi dari payload JSON berbahaya. Kebijakan JavaScript juga dapat digunakan untuk memindai payload guna menemukan konten berbahaya. Cache dan kebijakan lainnya dapat digunakan untuk melindungi dari serangan replay. Di tingkat infrastruktur, platform Apigee juga memiliki pembatasan bawaan untuk melindungi proses yang berjalan.

A9:2017 - Menggunakan Komponen dengan Kerentanan yang Diketahui

Karena framework, library, dan modul berjalan dengan eksekusi penuh dan akses CRUD, penyerang dapat memanfaatkan kerentanan komponen untuk menyerang sistem.

Rilis produk reguler Apigee memastikan perlindungan terhadap kerentanan komponen, terutama saat kerentanan tertentu ditemukan. Cloud publik Apigee di-patch secara otomatis, dan Apigee akan memberi tahu pelanggan Edge for Private Cloud saat patch on-premise tersedia untuk diinstal.

A10:2017 - Logging & Pemantauan yang Tidak Memadai

Jika Anda tidak melakukan logging, pemantauan, dan pengelolaan insiden secara memadai di sistem, penyerang dapat melakukan serangan yang lebih dalam dan berkepanjangan pada data dan software.

Apigee memiliki beberapa cara untuk melakukan logging, pemantauan, penanganan error, dan logging audit.

Logging

  • Pesan log dapat dikirim ke Splunk atau endpoint syslog lainnya menggunakan kebijakan MessageLogging.
  • Data analisis API dapat diambil melalui analytics API dan diimpor atau diekspor ke sistem lain.
  • Di Edge untuk Private Cloud, Anda dapat menggunakan kebijakan MessageLogging untuk menulis ke file log lokal. File log dari setiap komponen yang berjalan juga tersedia.
  • Kebijakan JavaScript dapat digunakan untuk mengirim pesan log ke endpoint logging REST secara sinkron atau asinkron.

Pemantauan

  • Gunakan UI atau API API Monitoring untuk memantau API dan backend secara rutin serta memicu pemberitahuan.
  • Gunakan pemantauan kesehatan untuk memantau backend server target secara rutin.
  • Apigee memberikan rekomendasi untuk memantau Edge untuk Private Cloud.
  • Apigee juga memberikan praktik terbaik yang dapat dimanfaatkan tim Anda untuk memantau program API.

Penanganan Error

Apigee menawarkan mekanisme penanganan error yang andal dan serbaguna untuk proxy API. Mirip dengan cara program Java menangkap pengecualian, proxy API dapat menangkap kesalahan dan menentukan cara menampilkan respons yang sesuai kepada klien. Dengan penanganan error kustom Apigee, Anda dapat menambahkan fungsi seperti logging pesan setiap kali terjadi error.

Log Audit

Platform Apigee menyimpan log audit yang melacak perubahan pada proxy API, produk, dan histori organisasi.  Log ini tersedia melalui UI atau melalui Audits API.

Solusi Apigee untuk kerentanan OWASP 2013

Saat OWASP memperbarui daftarnya untuk tahun 2017, beberapa kerentanan dari daftar tahun 2013 dihapus. Kerentanan tersebut masih merupakan ancaman yang valid. Bagian berikut menjelaskan cara menangani ancaman ini dengan Apigee.

A8:2013 - Pemalsuan Permintaan Lintas Situs (CSRF)

Permintaan pemalsuan lintas situs memungkinkan penyerang meneruskan detail autentikasi pengguna, cookie sesi, dan data lainnya ke aplikasi web yang rentan melalui HTTP, sehingga mengelabui aplikasi web agar meyakini bahwa permintaan tersebut adalah permintaan yang sah dari pengguna.

Pedoman:

  • Hal ini lebih merupakan masalah browser, bukan masalah produk API. Anda dapat mengatasi kerentanan ini dengan OpenID Connect, OAuth, dan teknik lainnya.
  • Pertimbangkan untuk menggunakan teknik HMAC, status, hash, nonce, atau PKCE untuk mencegah serangan peniruan dan replay.

A10:2013 - Pengalihan dan Penerusan yang Tidak Divalidasi

Jika aplikasi web melakukan pengalihan, tetapi tidak memvalidasi bahwa pengalihan tersebut mengirim pengguna ke situs web tepercaya yang diinginkan, penyerang dapat mengirim pengguna ke tujuan berbahaya untuk melakukan phishing, eksekusi malware, dan serangan lainnya.

Pedoman:

  • Gunakan OAuth dan terapkan validasi pada setiap permintaan.
  • Cegah pengalihan 302 yang tidak terduga dengan memeriksa kode respons dalam logika proxy API dan menangani pengalihan dengan tepat.