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. Guna mengetahui pendekatan tambahan yang didokumentasikan untuk Apigee, lihat 10 opsi mitigasi teratas 2021 OWASP 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 mengetahui tantangan ini dan mengatasinya saat membuat dan menggunakan API.

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

Dengan Apigee, lapisan proxy API dapat mendeteksi, memblokir, dan melaporkan permintaan API dengan format yang salah dari klien sebelum permintaan diproses di sistem backend, sehingga mengurangi risiko dan melindungi layanan Anda. Permintaan yang salah format dapat menyertakan 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 dikenal 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 dasar yang dapat memitigasi risiko, seperti penyamaran data, logging, administrasi, dan sebagainya.

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

Solusi Apigee untuk 10 Teratas OWASP 2017

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

A1:2017 - Injeksi

Untuk melindungi dari injeksi data tidak tepercaya seperti SQL, NoSQL, LDAP, dan JavaScript, yang dapat mengakibatkan eksekusi perintah yang tidak diinginkan atau akses data 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 yang masuk, memeriksa untuk memastikan bahwa 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 yang berisiko dan menggantinya dengan nilai yang aman.

Ada beberapa pendekatan untuk memvalidasi input dengan platform Apigee:

Validasi jenis konten:

A2:2017 - Autentikasi Rusak dan Pengelolaan Sesi

Penyerang dapat mengakses sandi, token sesi, dan kunci untuk meniru identitas pengguna lain dengan memanfaatkan kelemahan implementasi dalam aplikasi. Hal ini lebih merupakan masalah implementasi dan bukan masalah produk. Apigee menyediakan kebijakan VerifyApiKey, OAuth, dan JSON Web Token (JWT), yang membantu memberikan perlindungan 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, kemudian Apigee Edge, melalui kebijakan yang terpasang pada proxy API, akan memeriksa apakah kunci API dalam status disetujui untuk resource yang diminta.

Apigee menyediakan dukungan untuk pembuatan dan validasi Kunci API. Apigee menghasilkan kunci dan rahasia 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 menghasilkan client ID dan rahasia klien. Beberapa menyebut ID dan rahasia ini sebagai kunci API. Beberapa hanya merujuk 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 akan diverifikasi. Developer menerima kunci konsumen saat 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 sudah ada dari sumber eksternal.

Untuk jenis pemberian OAuth, client ID dan rahasia klien 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 agar dapat diautentikasi, yang akan memberi mereka token akses buram. Token ini dapat digunakan untuk mengontrol akses ke API.

JWT

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

  • Menghasilkan token JWT (mendukung tanda tangan HS256 dan RS256)
  • Validasi token JWT
  • Mendekode tokenJWT tanpa memvalidasi

A3:2017 - Eksposur Data Sensitif

Penyerang menarget data sensitif seperti detail kartu kredit, nomor jaminan sosial, kredensial login, informasi identitas pribadi (PII), dan nomor pajak untuk melakukan pencurian identitas, pencurian uang, penipuan, dan kejahatan lainnya. Aplikasi web perlu mengimplementasikan enkripsi, baik dalam penyimpanan maupun saat transit, 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 arah utara (klien yang terhubung ke API yang bertindak sebagai server) didukung melalui penggunaan konfigurasi Host Virtual. 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 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 diaktivasi ke Apigee. OWASP juga menyediakan praktik terbaik TLS.

Pada Apigee Hybrid, TLS tersedia saat traffic masuk 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 dijaga di tingkat protokol.
  • Gunakan kebijakan seperti kebijakanAssignMessage 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 guna meningkatkan level autentikasi untuk setiap permintaan.
  • Gunakan setelan data masking untuk menyamarkan data sensitif di alat Edge Trace.
  • Berhati-hatilah saat menyimpan data sensitif apa pun dalam cache (atau enkripsi data sensitif yang disimpan dalam 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 entitas eksternal" dalam XML—merujuk ke file atau data yang diganti dengan data aktual selama pemrosesan XML. Jika aplikasi atau prosesor XML sudah lama atau tidak diimplementasikan 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 bagian pesan mana pun, termasuk header, jalur URI, payload JSON/XML, parameter formulir, dan parameter kueri. Kebijakan ini bekerja 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 Rusak

Setelah pengguna login dan mendapatkan akses ke sistem, kontrol otorisasi yang tepat harus diterapkan sehingga pengguna dapat melihat dan melakukan hanya apa 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 tidak bertanggung jawab melakukan 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.
  • Konfigurasikan kontrol akses berbasis peran (RBAC) agar hanya mengizinkan pengguna mengakses fungsi dan konfigurasi yang mereka perlukan di portal developer berbasis Drupal.
  • Konfigurasi portal developer untuk menampilkan produk API tertentu sesuai dengan peran pengguna.
  • Konfigurasikan 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 API pengelolaan, atau melalui portal developer. Ketika aplikasi developer diberi akses ke produk API, aplikasi tersebut akan menerima client ID dan rahasia yang digunakan dalam proses autentikasi.
  • Apigee dapat berintegrasi dengan penyedia identitas mana pun untuk menjalankan OAuth.
  • Apigee bisa menghasilkan 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:Kesalahan Konfigurasi Keamanan 2017

Kesalahan konfigurasi keamanan mudah diabaikan, sering kali karena administrator dan developer salah memercayai bahwa sistem yang mereka gunakan sangat aman. Kesalahan konfigurasi keamanan dapat terjadi dalam berbagai cara, seperti memercayai konfigurasi default atau membuat konfigurasi parsial yang mungkin tidak aman, membiarkan 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 agar Anda dapat 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 mengambil 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 selangkah lebih jauh dan menempatkan alur bersama di hook alur untuk secara 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 ditemukan kerentanan baru. Cloud publik Edge di-patch otomatis. Pelanggan Edge untuk Private Cloud (lokal) harus menerapkan patch produk sendiri.

A7:Pembuatan Skrip Lintas Situs (XSS) 2017

Dengan pembuatan skrip lintas situs (XSS), penyerang dapat mengeksekusi skrip di browser web pengguna untuk mengontrol sesi pengguna, memanipulasi situs web, atau memengaruhi pengguna 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. Dengan menggunakan ekspresi reguler, baik dengan kebijakan RegularExpressionProtection maupun kebijakan JavaScript, periksa payload dan parameter value untuk JavaScript dan serangan jenis injeksi lainnya.

CORS, salah satu solusi yang umumnya diimplementasikan untuk kebijakan origin yang sama yang diterapkan oleh semua browser, dapat diimplementasikan menggunakan kebijakanAssignMessage.

A8:2017 - Deserialisasi Tidak Aman

Penyerang dapat menggunakan kekurangan 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 yang berbahaya. Kebijakan JavaScript juga dapat digunakan untuk memindai payload untuk konten berbahaya. Cache dan kebijakan lainnya dapat digunakan untuk melindungi dari serangan replay. Pada tingkat infrastruktur, platform Apigee juga memiliki pagar pembatas bawaan untuk melindungi proses yang sedang berjalan.

A9:2017 - Menggunakan Komponen yang 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 jika kerentanan tertentu ditemukan. Cloud publik Apigee di-patch secara otomatis, dan Apigee memberi tahu Edge untuk pelanggan Private Cloud saat patch lokal tersedia untuk diinstal.

A10:2017 - Logging & Pemantauan Tidak Memadai

Jika Anda tidak secara memadai melakukan logging, pemantauan, dan manajemen insiden dalam sistem Anda, penyerang dapat melakukan serangan yang lebih dalam dan berkepanjangan pada data serta 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 API analisis 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.

Monitoring

  • Gunakan UI atau API API Monitoring untuk memantau API dan backend secara rutin serta memicu alet.
  • Gunakan pemantauan kondisi 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 kesalahan yang kuat dan serbaguna untuk proxy API. Mirip dengan cara program Java menangkap pengecualian, proxy API dapat menangkap kesalahan dan menentukan cara menampilkan respons yang sesuai ke klien. Penanganan kesalahan kustom Apigee memungkinkan Anda menambahkan fungsionalitas 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 dihilangkan. Mereka masih dianggap sebagai 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 menipu aplikasi web sehingga meyakini bahwa permintaan tersebut adalah permintaan yang sah dari pengguna.

Pedoman:

  • Ini lebih ke 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 pemalsuan dan replay.

A10:2013 - Pengalihan dan Penerusan yang Tidak Divalidasi

Jika aplikasi web melakukan pengalihan, tetapi tidak memvalidasi bahwa pengalihan mengirimkan pengguna ke situs web yang diinginkan dan tepercaya, 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.