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 yang luar biasa bagi penyedia layanan, tetapi juga menimbulkan beberapa risiko keamanan. Developer harus menyadari tantangan ini dan mengatasinya saat mereka membuat dan menggunakan API.

OWASP adalah komunitas terbuka yang berdedikasi untuk membantu organisasi mengembangkan, membeli, dan memelihara aplikasi dan API tepercaya. Melalui project OWASP API Security, OWASP memublikasikan risiko keamanan 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 dikenal atau tidak dikenal yang dikembangkan oleh developer eksternal, developer internal, atau bot berbahaya.  Jenis permintaan ini merupakan 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 mengambil pendekatan yang berfokus pada penggunaan untuk mendesain API dan menghubungkannya dengan sistem backend Anda. Berikut adalah daftar kebijakan/konfigurasi yang direkomendasikan Apigee untuk ancaman OWASP REST teratas.

Solusi Apigee untuk 10 Teratas OWASP 2017

Ada banyak masalah keamanan saat membangun dan mengamankan aplikasi web. OWASP merilis daftar 10 Ancaman Keamanan Teratas OWASP 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 tentang cara Anda dapat 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 berperan 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 menghilangkan urutan karakter berisiko dan menggantinya dengan nilai yang aman.

Ada beberapa pendekatan untuk memvalidasi input dengan platform Apigee:

Validasi jenis konten:

A2:2017 - Autentikasi dan Pengelolaan Sesi yang Rusak

Penyerang dapat mengakses sandi, token sesi, dan kunci untuk meniru identitas pengguna lain dengan memanfaatkan kelemahan implementasi dalam aplikasi. Ini lebih merupakan masalah penerapan dan bukan masalah produk.  Apigee menyediakan kebijakan VerifyApiKey, OAuth, dan JSON Web Token (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 cukup menyajikan kunci API bersama 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 API dan secret saat aplikasi developer yang ditautkan ke satu atau beberapa produk API dibuat dan disetujui.

Istilah “kunci API” terkadang dapat 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 orang hanya menyebut ID klien sebagai kunci API. Di Edge UI, Anda akan melihat "kunci konsumen" dan "secret konsumen".

Dalam kebijakan VerifyAPIKey, hanya ID klien, atau "kunci konsumen", yang diverifikasi. Developer menerima kunci konsumen saat mereka mendaftarkan aplikasi mereka ke Apigee dan mengaitkan aplikasi tersebut 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 izin 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 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 memberinya token akses buram. Token ini dapat digunakan untuk mengontrol akses ke API.

JWT

JSON Web Token, atau JWT, umum digunakan untuk membagikan klaim atau pernyataan antaraplikasi 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 - Paparan 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 ke utara (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 ke selatan (Apigee sebagai klien yang terhubung ke layanan backend) didukung melalui penggunaan konfigurasi Server Target.  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 serupa 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 AssignMessage policy dan JavaScript policy untuk menghapus data sensitif sebelum ditampilkan ke klien.
  • Gunakan teknik OAuth standar dan pertimbangkan untuk menambahkan HMAC, hash, state, nonce, PKCE, atau teknik lainnya guna meningkatkan level autentikasi untuk setiap permintaan.
  • Gunakan setelan penyamaran 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 - XML External Entities

Sistem atau aplikasi yang memproses XML perlu menangani "referensi entitas eksternal" dalam XML—referensi ke file atau data yang diganti dengan data sebenarnya selama pemrosesan XML. Jika aplikasi atau pemroses XML sudah lama atau diimplementasikan dengan buruk, 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 - Broken Access Control

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 secara berbahaya.

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 Apigee Developer Portal

  • Konfigurasi single sign-on dengan penyedia identitas perusahaan Anda.
  • Konfigurasi role-based access control (RBAC) agar hanya mengizinkan pengguna mengakses fungsionalitas 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 mana yang tersedia dengan menentukan produk API. Akses diberikan secara manual di UI, melalui Management API, 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 terintegrasi dengan penyedia identitas mana pun untuk melakukan OAuth.
  • Apigee dapat membuat token JWT atau teknik lain untuk mengirimkan 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

Kesalahan konfigurasi keamanan mudah terlewatkan, sering kali karena administrator dan developer keliru menganggap bahwa sistem yang mereka gunakan pada dasarnya aman. Kesalahan konfigurasi keamanan dapat terjadi dalam banyak 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 flow 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 proxy API individual, atau Anda dapat melakukan langkah lebih lanjut dan menempatkan alur bersama di flow hook untuk otomatis menjalankan logika alur bersama bagi 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 kerentanan baru ditemukan. Edge cloud publik di-patch secara otomatis. Pelanggan Edge untuk Private Cloud (di tempat) harus menerapkan patch produk sendiri.

A7:2017-Cross-Site Scripting (XSS)

Pembuatan skrip lintas situs (XSS) memungkinkan penyerang menjalankan 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 memberikan perlindungan dari XSS di API.  Menggunakan ekspresi reguler, baik dengan kebijakan RegularExpressionProtection atau kebijakan JavaScript, periksa payload dan nilai parameter 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 diimplementasikan 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 mendeteksi konten berbahaya. Cache dan kebijakan lainnya dapat digunakan untuk melindungi dari serangan replay. Di tingkat infrastruktur, platform Apigee juga memiliki batas yang dibuat untuk melindungi proses yang sedang berjalan.

A9:2017 - Menggunakan Komponen dengan Kerentanan yang Diketahui

Karena framework, library, dan modul berjalan dengan akses CRUD dan eksekusi penuh, 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 untuk Private Cloud saat patch lokal tersedia untuk diinstal.

A10:2017 - Logging & Pemantauan yang Tidak Memadai

Jika Anda tidak melakukan pencatatan log, pemantauan, dan pengelolaan insiden secara memadai di sistem Anda, 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 masing-masing 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 menyediakan 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 kesalahan 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 tidak disertakan. 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 menganggap permintaan tersebut sebagai permintaan yang sah dari pengguna.

Pedoman:

  • 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, state, hash, nonce, atau PKCE untuk mencegah pemalsuan dan serangan replay.

A10:2013 - Pengalihan dan Penerusan yang Tidak Divalidasi

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

Pedoman:

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