Praktik Terbaik untuk mengamankan API REST / layanan web [ditutup]

Ketika merancang API atau layanan REST, adakah praktik terbaik yang ditetapkan untuk menangani keamanan (Otentikasi, Otorisasi, Manajemen Identitas)?

Saat membangun SOAP API Anda memiliki WS-Security sebagai panduan dan banyak literatur tentang topik tersebut. Saya telah menemukan sedikit informasi tentang mengamankan titik akhir REST.

Sementara saya mengerti REST sengaja tidak memiliki spesifikasi analog dengan WS- * Saya berharap praktik terbaik atau pola yang direkomendasikan telah muncul.

Setiap diskusi atau tautan ke dokumen yang relevan akan sangat dihargai. Jika itu penting, kami akan menggunakan WCF dengan pesan serial POX / JSON untuk REST API kami / Layanan yang dibangun menggunakan v3.5 dari .NET Framework.

Seperti yang dikatakan tweakt, Amazon S3 adalah model yang bagus untuk digunakan. Tanda tangan permintaan mereka memang memiliki beberapa fitur (seperti memasukkan stempel waktu) yang membantu melindungi terhadap permintaan ulangan yang tidak disengaja dan jahat.

Yang menyenangkan tentang HTTP Basic adalah bahwa hampir semua perpustakaan HTTP mendukungnya. Anda tentu saja perlu meminta SSL dalam hal ini karena mengirim kata sandi plaintext melalui internet hampir secara universal merupakan hal yang buruk. Basic lebih disukai daripada Digest ketika menggunakan SSL karena meskipun penelepon sudah tahu bahwa kredensial diperlukan, Digest memerlukan bolak-balik tambahan untuk menukar nilai nonce. Dengan Basic, penelepon hanya mengirim kredensial pertama kalinya.

Setelah identitas klien ditetapkan, otorisasi benar-benar hanya masalah implementasi. Namun, Anda dapat mendelegasikan otorisasi ke beberapa komponen lain dengan model otorisasi yang ada. Lagi-lagi hal yang menyenangkan tentang Basic di sini adalah server Anda berakhir dengan salinan plaintext dari kata sandi klien yang dapat Anda kirimkan ke komponen lain dalam infrastruktur Anda sesuai kebutuhan.

Tidak ada standar untuk REST selain HTTP. Ada layanan REST didirikan di luar sana. Saya sarankan Anda mengintip mereka dan merasakan bagaimana mereka bekerja.

Misalnya, kami meminjam banyak ide dari layanan S3 REST Amazon ketika mengembangkan ide kami sendiri. Tetapi kami memilih untuk tidak menggunakan model keamanan yang lebih maju berdasarkan tanda tangan permintaan. Pendekatan yang lebih sederhana adalah HTTP Basic auth over SSL. Anda harus memutuskan mana yang paling cocok untuk situasi Anda.

Juga, saya sangat merekomendasikan buku RESTful Web Services dari O'reilly. Ini menjelaskan konsep inti dan menyediakan beberapa praktik terbaik. Anda umumnya dapat mengambil model yang mereka berikan dan memetakannya ke aplikasi Anda sendiri.

Anda mungkin juga ingin melihat OAuth , protokol terbuka yang muncul untuk otorisasi berbasis token yang secara khusus menargetkan http http.

Ini sangat mirip dengan pendekatan yang diambil oleh flickr dan ingat susu "rest" apis (belum tentu contoh apis yang tenang, tetapi contoh yang baik dari pendekatan berbasis token).

Ada daftar periksa hebat yang ditemukan di Github :

Autentikasi

• Jangan menemukan kembali roda dalam Otentikasi, pembuatan token, penyimpanan kata sandi. Gunakan standar.

• Gunakan Max Retrydan fitur penjara di Login.

• Gunakan enkripsi pada semua data sensitif.

JWT (Token Web JSON)

• Gunakan kunci rumit yang acak (JWT Secret) untuk membuat brute memaksa token menjadi sangat keras.

• Jangan mengekstrak algoritme dari payload. Paksa algoritma di backend (HS256 atau RS256).

• Jadikan token kedaluwarsa ( TTL, RTTL) sesingkat mungkin.

• Jangan menyimpan data sensitif dalam JWTpayload, itu dapat diterjemahkan dengan mudah.

OAuth

• Selalu memvalidasi redirect_urisisi server untuk membolehkan hanya URL yang masuk daftar putih.

• Selalu mencoba menukar kode dan bukan token (jangan izinkan response_type=token).

• Gunakan parameter negara dengan hash acak untuk mencegah CSRFpada OAuthproses otentikasi.

• Tetapkan ruang lingkup default, dan validasikan parameter ruang lingkup untuk setiap aplikasi.

Mengakses

• Batasi permintaan (Throttling) untuk menghindari serangan DDoS / brute-force.

• Gunakan HTTPS di sisi server untuk menghindari MITM (Man In The Middle Attack)

• Gunakan HSTSheader dengan SSL untuk menghindari serangan Strip SSL.

Memasukkan

• Gunakan metode HTTP yang tepat sesuai dengan operasi: GET(baca), POST(buat), PUT/PATCH(ganti / perbarui), dan DELETE(untuk menghapus catatan), dan merespons dengan 405 Method Not Allowedjika metode yang diminta tidak sesuai untuk sumber daya yang diminta.

• Validasi tipe konten pada Accepttajuk permintaan (Negosiasi Konten) untuk memungkinkan hanya format yang didukung (mis application/xml. application/json, Dll) dan merespons dengan 406 Not Acceptablerespons jika tidak cocok.

• Validasi content-typedari diposting data saat Anda menerima (misalnya application/x-www-form-urlencoded, multipart/form-data, application/json, dll).

• Validasi input pengguna untuk menghindari kerentanan umum (misalnya XSS, SQL-Injection, Eksekusi Kode Jarak Jauh, dll).

• Jangan gunakan data sensitif (kredensial, Kata sandi, token keamanan, atau kunci API) di URL, tetapi gunakan Authorizationtajuk standar .

• Gunakan layanan API Gateway untuk mengaktifkan caching, Rate Limitkebijakan (mis. Kuota, Spike Arrest, Concurrent Rate Limit) dan menggunakan sumber daya API secara dinamis.

Pengolahan

• Periksa apakah semua titik akhir dilindungi di belakang otentikasi untuk menghindari proses otentikasi yang rusak.

• ID sumber daya milik pengguna harus dihindari. Gunakan / me / orders sebagai ganti / user / 654321 / orders.

• Jangan menambah ID secara otomatis. Gunakan UUID sebagai gantinya.

• Jika Anda mem-parsing file XML, pastikan parsing entitas tidak diaktifkan untuk menghindari XXE (serangan entitas eksternal XML).

• Jika Anda mem-parsing file XML, pastikan ekspansi entitas tidak diaktifkan untuk menghindari bom Billion Laughs / XML melalui serangan ekspansi entitas eksponensial.

• Gunakan CDN untuk mengunggah file.

• Jika Anda berurusan dengan data dalam jumlah besar, gunakan Pekerja dan Antrian untuk memproses sebanyak mungkin di latar belakang dan mengembalikan respons dengan cepat untuk menghindari Pemblokiran HTTP.

• Jangan lupa untuk mematikan mode DEBUG .

Keluaran

• Kirim X-Content-Type-Options: nosnifftajuk.

• Kirim X-Frame-Options: denytajuk.

• Kirim Content-Security-Policy: default-src 'none'tajuk.

• Hapus sidik jari header - X-Powered-By, Server, X-AspNet-Versiondll

• Paksa content-typerespons Anda, jika Anda kembali application/jsonmaka tipe konten respons Anda adalah application/json.

• Jangan kembalikan data sensitif seperti kredensial, Kata sandi, token keamanan.

• Kembalikan kode status yang tepat sesuai dengan operasi yang diselesaikan. (misalnya 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, dll).

Saya agak terkejut SSL dengan sertifikat klien belum disebutkan. Memang, pendekatan ini hanya sangat berguna jika Anda dapat mengandalkan komunitas pengguna yang diidentifikasi oleh sertifikat. Tetapi sejumlah pemerintah / perusahaan memang mengeluarkannya kepada penggunanya. Pengguna tidak perlu khawatir tentang membuat kombinasi nama pengguna / kata sandi lagi, dan identitas dibuat pada setiap koneksi sehingga komunikasi dengan server dapat sepenuhnya tanpa kewarganegaraan, tidak ada sesi pengguna yang diperlukan. (Tidak menyiratkan bahwa salah satu / semua solusi lain yang disebutkan membutuhkan sesi)

Setiap orang dalam jawaban ini telah mengabaikan kontrol / otorisasi akses yang sebenarnya.

Jika misalnya API REST / layanan web Anda tentang POST / MENDAPATKAN catatan medis, Anda mungkin ingin menetapkan kebijakan kontrol akses tentang siapa yang dapat mengakses data dan dalam keadaan apa. Contohnya:

• dokter dapat MENDAPATKAN catatan medis pasien yang memiliki hubungan asuhan dengan mereka
• tidak ada yang bisa POST data medis di luar jam praktik (misalnya 9 hingga 5)
• pengguna akhir dapat MENDAPATKAN rekam medis yang mereka miliki atau rekam medis pasien yang menjadi wali mereka
• perawat dapat MEMPERBARUI catatan medis pasien yang memiliki unit yang sama dengan perawat.

Untuk mendefinisikan dan mengimplementasikan otorisasi berbutir halus itu, Anda perlu menggunakan bahasa kontrol akses berbasis atribut yang disebut XACML, Bahasa Markup Kontrol Akses eXtensible.

Standar lain di sini adalah sebagai berikut:

• OAuth: id. federasi dan delegasi otorisasi misalnya membiarkan layanan bertindak atas nama saya di layanan lain (Facebook dapat memposting ke Twitter saya)
• SAML: federasi identitas / SSO web. SAML sangat banyak tentang siapa pengguna.
• Standar WS-Security / WS- *: ini fokus pada komunikasi antara layanan SOAP. Mereka khusus untuk format pesan tingkat aplikasi (SOAP) dan mereka berurusan dengan aspek olahpesan misalnya keandalan, keamanan, kerahasiaan, integritas, atomicity, peristiwa ... Tidak ada yang mencakup kontrol akses dan semua khusus untuk SOAP.

XACML adalah teknologi-agnostik. Ini dapat diterapkan ke aplikasi java, .NET, Python, Ruby ... layanan web, REST API, dan banyak lagi.

Berikut ini adalah sumber daya yang menarik:

• situs web OASIS XACML
• standar NIST ABAC

Saya telah menggunakan OAuth beberapa kali, dan juga menggunakan beberapa metode lain (BASIC / DIGEST). Saya sepenuh hati menyarankan OAuth. Tautan berikut adalah tutorial terbaik yang pernah saya lihat tentang penggunaan OAuth:

http://hueniverse.com/oauth/guide/

Salah satu pos terbaik yang pernah saya temui mengenai Keamanan yang berkaitan dengan REST adalah pada 1 RainDrop . API MySpace menggunakan OAuth juga untuk keamanan dan Anda memiliki akses penuh ke saluran kustom mereka dalam kode RestChess, yang saya lakukan dengan banyak eksplorasi. Ini demo'd di Mix dan Anda dapat menemukan posting di sini .

Terima kasih atas sarannya. Kami akhirnya menggunakan tajuk HTTP khusus untuk memberikan token identitas dari klien ke layanan, dalam persiapan untuk mengintegrasikan RESTful API kami dengan kerangka kerja Zermatt Identity yang akan datang dari Microsoft. Saya telah menjelaskan masalahnya di sini dan solusi kami di sini . Saya juga menerima saran tweakt dan membeli RESTful Web Services - buku yang sangat bagus jika Anda sedang membangun API RESTful dalam bentuk apa pun.

OWASP (Proyek Keamanan Aplikasi Web Terbuka) memiliki beberapa lembar contekan yang mencakup semua aspek pengembangan Aplikasi Web. Proyek ini adalah sumber informasi yang sangat berharga dan dapat diandalkan. Mengenai layanan REST Anda dapat memeriksa ini: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Saya akan merekomendasikan OAuth 2/3. Anda dapat menemukan informasi lebih lanjut di http://oauth.net/2/

Saya mencari banyak tentang keamanan yang tenang dan kami juga akhirnya menggunakan token via cookie dari klien ke server untuk mengotentikasi permintaan. Saya menggunakan keamanan pegas untuk otorisasi permintaan dalam layanan karena saya harus mengotentikasi dan mengesahkan setiap permintaan berdasarkan kebijakan keamanan tertentu yang telah ada dalam DB.

Fakta bahwa dunia SOAP cukup baik ditutupi dengan standar keamanan tidak berarti bahwa itu aman secara default. Pertama, standarnya sangat kompleks. Kompleksitas bukanlah teman keamanan yang sangat baik dan kerentanan implementasi seperti serangan pembungkus tanda tangan XML bersifat endemik di sini.

Adapun lingkungan NET saya tidak akan membantu banyak, tapi “layanan Building web dengan Java” (bata dengan ~ 10 penulis) memang membantu saya banyak dalam memahami WS- * arsitektur keamanan dan, terutama, kebiasaan.

REST sendiri tidak menawarkan standar keamanan, tetapi hal-hal seperti OAuth dan SAML dengan cepat menjadi standar dalam ruang ini. Namun, otentikasi dan otorisasi hanyalah sebagian kecil dari apa yang perlu Anda pertimbangkan. Banyak kerentanan diketahui terkait dengan aplikasi web berlaku sangat banyak untuk REST apis. Anda harus mempertimbangkan validasi input, cracking sesi, pesan kesalahan yang tidak pantas, kerentanan karyawan internal dan sebagainya. Itu adalah subjek besar.

Saya ingin menambahkan (sejalan dengan stinkeymatt), solusi paling sederhana adalah menambahkan sertifikat SSL ke situs Anda. Dengan kata lain, pastikan url Anda adalah HTTPS: //. Itu akan mencakup keamanan transportasi Anda (bang for the buck). Dengan RESTful url, idenya adalah untuk membuatnya tetap sederhana (tidak seperti WS * security / SAML), Anda dapat menggunakan oAuth2 / openID connect atau bahkan Basic Auth (dalam kasus sederhana). Tetapi Anda masih membutuhkan SSL / HTTPS. Silakan periksa keamanan ASP.NET Web API 2 di sini: http://www.asp.net/web-api/overview/security (Artikel dan Video)

Sebagai @Nathan berakhir dengan yang merupakan HTTP Header sederhana, dan beberapa mengatakan OAuth2 dan sertifikat SSL sisi klien. Intinya adalah ini ... API REST Anda tidak harus menangani keamanan karena itu harus benar-benar berada di luar cakupan API.

Sebaliknya lapisan keamanan harus diletakkan di atasnya, apakah itu HTTP Header di belakang proxy web (pendekatan umum seperti SiteMinder, Zermatt atau bahkan Apache HTTPd), atau serumit OAuth 2.

Kuncinya adalah permintaan harus berfungsi tanpa interaksi pengguna akhir. Yang diperlukan hanyalah memastikan bahwa koneksi ke REST API diautentikasi. Di Java EE kami memiliki gagasan tentang userPrincipalyang dapat diperoleh padaHttpServletRequest . Hal ini juga dikelola dalam deskriptor penyebaran bahwa pola URL dapat aman sehingga kode API REST tidak perlu memeriksa lagi.

Di dunia WCF, saya akan gunakan ServiceSecurityContext.Currentuntuk mendapatkan konteks keamanan saat ini. Anda perlu mengonfigurasi aplikasi Anda untuk meminta otentikasi.

Ada satu pengecualian untuk pernyataan yang saya miliki di atas dan itu adalah penggunaan nonce untuk mencegah replay (yang bisa berupa serangan atau seseorang hanya mengirimkan data yang sama dua kali). Bagian itu hanya dapat ditangani di lapisan aplikasi.

Untuk Keamanan Aplikasi Web, Anda harus melihat pada OWASP ( https://www.owasp.org/index.php/Main_Page ) yang menyediakan cheatsheet untuk berbagai serangan keamanan. Anda dapat memasukkan sebanyak mungkin tindakan untuk mengamankan Aplikasi Anda. Sehubungan dengan keamanan API (otorisasi, otentikasi, manajemen identitas), ada beberapa cara seperti yang telah disebutkan (Dasar, Intisari dan OAuth). Ada lubang lubang di OAuth1.0, sehingga Anda dapat menggunakan OAuth1.0a (OAuth2.0 tidak diadopsi secara luas karena masalah dengan spesifikasi)

Sudah lama tetapi pertanyaannya masih relevan, meskipun jawabannya mungkin telah sedikit berubah.

API Gateway akan menjadi solusi yang fleksibel dan sangat dapat dikonfigurasi. Saya menguji dan menggunakan KONG sedikit dan sangat menyukai apa yang saya lihat. KONG menyediakan admin REST API miliknya sendiri yang dapat Anda gunakan untuk mengelola pengguna.

Express-gateway.io lebih baru dan juga merupakan Gateway API.