Layanan Web Aman: REST lebih dari HTTPS vs SOAP + WS-Security. Mana yang lebih baik? [Tutup]

Saya bukan ahli keamanan, tetapi saya lebih suka menciptakan layanan web bergaya REST.

Dalam menciptakan layanan baru yang perlu memiliki data yang ditransmisikan aman. Kami telah memasuki perdebatan tentang pendekatan mana yang lebih aman - BERTAHAN dengan HTTPS atau SOAP WS dengan WS-Security.

Saya mendapat kesan kita bisa menggunakan HTTPS untuk semua panggilan layanan web dan pendekatan ini akan aman. Cara saya melihatnya adalah, "jika HTTPS cukup baik untuk situs web bank dan keuangan, itu cukup baik untuk saya". Sekali lagi, saya bukan ahli dalam bidang ini, tetapi saya pikir orang-orang ini telah berpikir keras tentang masalah ini dan nyaman dengan HTTPS.

Seorang rekan kerja tidak setuju dan mengatakan SOAP dan WS-Security adalah satu-satunya cara untuk pergi.

Tampaknya web di seluruh papan tentang ini.

Mungkin komunitas di sini bisa mempertimbangkan pro dan kontra dari masing-masing? Terima kasih!

HTTPS mengamankan transmisi pesan melalui jaringan dan memberikan jaminan kepada klien tentang identitas server. Inilah yang penting bagi bank atau pialang saham daring Anda. Minat mereka dalam mengautentikasi klien bukan pada identitas komputer, tetapi pada identitas Anda. Jadi nomor kartu, nama pengguna, kata sandi dll digunakan untuk mengotentikasi Anda. Beberapa tindakan pencegahan kemudian biasanya diambil untuk memastikan bahwa pengiriman belum dirusak, tetapi secara keseluruhan apa pun yang terjadi selama sesi dianggap telah diprakarsai oleh Anda.

WS-Security menawarkan perlindungan kerahasiaan dan integritas dari penciptaan pesan untuk konsumsi itu. Jadi, alih-alih memastikan bahwa konten komunikasi hanya dapat dibaca oleh server yang tepat, tetapi memastikan bahwa itu hanya dapat dibaca oleh proses yang tepat di server. Alih-alih mengasumsikan bahwa semua komunikasi dalam sesi yang dimulai dengan aman berasal dari pengguna yang diautentikasi, masing-masing harus ditandatangani.

Ada penjelasan lucu yang melibatkan pengendara sepeda motor telanjang di sini:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Jadi WS-Security menawarkan lebih banyak perlindungan daripada HTTPS, dan SOAP menawarkan API yang lebih kaya daripada REST. Pendapat saya adalah bahwa kecuali Anda benar-benar membutuhkan fitur atau perlindungan tambahan, Anda harus melewati overhead SOAP dan WS-Security. Saya tahu ini agak sulit tetapi keputusan tentang seberapa banyak perlindungan yang benar-benar dapat dibenarkan (bukan hanya apa yang akan dibuat keren) perlu dibuat oleh mereka yang mengetahui masalah itu secara intim.

Keamanan REST bergantung pada transportasi sedangkan keamanan SOAP tidak.

REST mewarisi langkah-langkah keamanan dari transportasi yang mendasarinya sementara SOAP mendefinisikan sendiri melalui WS-Security.

Ketika kita berbicara tentang REST, melalui HTTP - semua tindakan keamanan yang diterapkan HTTP diwariskan dan ini dikenal sebagai keamanan tingkat transportasi.

Keamanan tingkat transportasi, amankan pesan Anda hanya saat ada di kabel - segera setelah meninggalkan kabel, pesan tidak lagi diamankan.

Tetapi, dengan WS-Security, tingkat keamanan pesannya - meskipun pesan meninggalkan saluran transportasi, pesan tersebut tetap dilindungi. Juga - dengan keamanan tingkat pesan Anda dapat mengenkripsi sebagian pesan [bukan seluruh pesan, tetapi hanya bagian yang Anda inginkan] - tetapi dengan keamanan tingkat transportasi Anda tidak dapat melakukannya.

WS-Security memiliki langkah-langkah untuk otentikasi, integritas, kerahasiaan dan non-repudiation sementara SSL tidak mendukung non repudiation [dengan 2-legged OAuth itu].

Dalam performa, SSL jauh lebih cepat daripada WS-Security.

Terima kasih...

Secara teknis, cara Anda mengucapkannya, tidak ada yang benar, karena komunikasi metode SOAP tidak aman, dan metode REST tidak mengatakan apa-apa tentang otentikasi pengguna yang sah.

HTTPS mencegah penyerang menguping komunikasi antara dua sistem. Ini juga memverifikasi bahwa sistem host (server) sebenarnya adalah sistem host yang ingin diakses pengguna.

WS-Security mencegah aplikasi yang tidak sah (pengguna) mengakses sistem.

Jika sistem RESTful memiliki cara untuk mengautentikasi pengguna dan aplikasi SOAP dengan WS-Security menggunakan HTTPS, maka keduanya benar-benar aman. Itu hanya cara berbeda dalam mempresentasikan dan mengakses data.

Lihat artikel wiki :

Dalam situasi point-to-point kerahasiaan dan integritas data juga dapat ditegakkan pada layanan Web melalui penggunaan Transport Layer Security (TLS), misalnya, dengan mengirim pesan melalui https.

Namun WS-Security menangani masalah yang lebih luas yaitu menjaga integritas dan kerahasiaan pesan sampai setelah pesan dikirim dari node asal, memberikan apa yang disebut keamanan ujung ke ujung.

Itu adalah:

• HTTPS adalah mekanisme keamanan lapisan transport (point-to-point)
• WS-Security adalah mekanisme keamanan lapisan aplikasi (ujung-ke-ujung).

Seperti yang Anda katakan, REST cukup baik untuk bank sehingga harus cukup baik untuk Anda.

Ada dua aspek utama keamanan: 1) enkripsi dan 2) identitas.

Transmisi dalam SSL / HTTPS menyediakan enkripsi melalui kabel. Tetapi Anda juga harus memastikan bahwa kedua server dapat mengonfirmasi bahwa mereka tahu kepada siapa mereka berbicara. Ini bisa melalui sertifikat klien SSL, rahasia berbagi, dll.

Saya yakin orang dapat mengatakan bahwa SOAP "lebih aman" tetapi mungkin tidak secara signifikan. Analogi pengendara motor telanjang itu lucu tetapi jika akurat akan menyiratkan bahwa seluruh internet tidak aman.

Saya belum memiliki perwakilan yang diperlukan untuk menambahkan komentar atau saya hanya akan menambahkan ini ke jawaban Bell. Saya pikir Bell melakukan pekerjaan yang sangat baik untuk merangkum pro dan kontra tingkat atas dari dua pendekatan. Hanya beberapa faktor lain yang mungkin ingin Anda pertimbangkan:

1) Apakah permintaan antara klien Anda dan layanan Anda harus melalui perantara yang memerlukan akses ke payload? Jika demikian maka WS-Security mungkin lebih cocok.

2) Sebenarnya dimungkinkan untuk menggunakan SSL untuk memberikan jaminan kepada server mengenai identitas klien menggunakan fitur yang disebut otentikasi bersama. Namun, ini tidak banyak digunakan di luar beberapa skenario yang sangat khusus karena kompleksitas mengonfigurasinya. Jadi Bell benar bahwa WS-Sec jauh lebih cocok di sini.

3) SSL secara umum dapat sedikit kesulitan untuk mengatur dan memelihara (bahkan dalam konfigurasi yang lebih sederhana) karena sebagian besar masalah manajemen sertifikat. Memiliki seseorang yang tahu bagaimana melakukan ini untuk platform Anda akan menjadi nilai tambah yang besar.

4) Jika Anda mungkin perlu melakukan beberapa bentuk pemetaan kredensial atau federasi identitas maka WS-Sec mungkin sepadan dengan biaya overhead. Bukannya Anda tidak dapat melakukan ini dengan REST, Anda hanya memiliki sedikit struktur untuk membantu Anda.

5) Mendapatkan semua WS-Security goop ke tempat yang tepat di sisi klien hal bisa lebih menyebalkan daripada yang Anda pikirkan seharusnya.

Pada akhirnya itu benar-benar tergantung pada banyak hal yang sepertinya tidak akan kita ketahui. Untuk sebagian besar situasi, saya akan mengatakan bahwa pendekatan mana pun akan "cukup aman" dan sehingga seharusnya tidak menjadi faktor penentu utama.

Brace yourself, here there's another coming :-)

Hari ini saya harus menjelaskan kepada pacar saya perbedaan antara kekuatan ekspresif WS-Security sebagai lawan HTTPS. Dia seorang ilmuwan komputer, jadi bahkan jika dia tidak tahu semua XML omong kosong dia mengerti (mungkin lebih baik dari saya) apa arti enkripsi atau tanda tangan. Namun saya menginginkan citra yang kuat, yang dapat membuatnya benar-benar memahami hal-hal apa yang berguna, daripada bagaimana mereka diterapkan (yang datang sedikit kemudian, dia tidak menghindarinya :-)).

Begitulah yang terjadi. Misalkan Anda telanjang, dan Anda harus mengendarai sepeda motor Anda ke tujuan tertentu. Dalam kasus (A) Anda melewati terowongan transparan: satu-satunya harapan Anda untuk tidak ditangkap karena perilaku cabul adalah tidak ada yang melihat. Itu bukan strategi paling aman yang bisa kamu lakukan ... (perhatikan keringat keluar dari dahi pria :-)). Itu setara dengan POST yang jelas, dan ketika saya mengatakan "setara", saya bersungguh-sungguh. Dalam kasus (B), Anda berada dalam situasi yang lebih baik. Terowongan itu buram, jadi selama Anda bepergian ke dalamnya, catatan publik Anda aman. Namun, ini masih bukan situasi terbaik. Anda masih harus meninggalkan rumah dan mencapai pintu masuk terowongan, dan sekali di luar terowongan mungkin Anda harus turun dan berjalan di suatu tempat ... dan itu berlaku untuk HTTPS. Benar, pesan Anda aman saat melintasi jurang terbesar: tetapi begitu Anda mengirimnya di sisi lain, Anda tidak benar-benar tahu berapa banyak tahapan yang harus dilalui sebelum mencapai titik nyata di mana data akan diproses. Dan tentu saja semua tahapan tersebut dapat menggunakan sesuatu yang berbeda dari HTTP: MSMQ klasik yang mendukung permintaan yang tidak dapat dilayani segera, misalnya. Apa yang terjadi jika seseorang mengintai data Anda saat mereka berada dalam limbo praproses? Hm (bacalah "hm" ini seperti yang diucapkan oleh Morpheus di akhir kalimat "apakah menurut Anda udara yang Anda hirup?"). Solusi lengkap (c) dalam metafora ini sangat sepele: dapatkan beberapa pakaian sialan untuk diri sendiri, dan terutama helm saat berada di sepeda motor !!! Jadi Anda bisa berkeliling dengan aman tanpa harus bergantung pada kekaburan lingkungan. Metafornya mudah-mudahan jelas: pakaian itu datang bersamamu terlepas dari sarana atau infrastruktur di sekitarnya, seperti halnya keamanan tingkat pesan. Selain itu, Anda dapat memutuskan untuk menutupi satu bagian tetapi mengungkapkan yang lain (dan Anda dapat melakukannya secara pribadi: keamanan bandara dapat melepaskan jaket dan sepatu Anda, sementara dokter Anda mungkin memiliki tingkat akses yang lebih tinggi), tetapi ingat bahwa kemeja lengan pendek praktik buruk bahkan jika Anda bangga dengan bisep Anda :-) (lebih baik polo, atau t-shirt).

Saya senang mengatakan bahwa dia mengerti maksudnya! Saya harus mengatakan bahwa metafora pakaian sangat kuat: Saya tergoda untuk menggunakannya untuk memperkenalkan konsep kebijakan (klub disko tidak akan membiarkan Anda memakai sepatu olahraga; Anda tidak dapat pergi untuk menarik uang di bank dengan pakaian dalam Anda , sementara ini terlihat sangat bisa diterima sambil menyeimbangkan diri Anda pada ombak; dan sebagainya) tapi saya pikir untuk satu sore itu sudah cukup ;-)

Arsitektur - WS, Gagasan Liar

Courtesy: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Saya bekerja di ruang ini setiap hari jadi saya ingin meringkas komentar baik tentang ini dalam upaya untuk menutup ini:

SSL (HTTP / s) hanya satu lapisan yang memastikan:

1. Server sedang terhubung untuk menyajikan sertifikat yang membuktikan identitasnya (meskipun ini dapat dipalsukan melalui keracunan DNS).
2. Lapisan komunikasi dienkripsi (tidak ada penyadapan).

WS-Security dan standar / implementasi terkait menggunakan PKI yang:

1. Buktikan identitas klien.
2. Buktikan pesan itu tidak dimodifikasi dalam perjalanan (MITM).
3. Mengizinkan server untuk mengautentikasi / mengotorisasi klien.

Poin terakhir penting untuk permintaan layanan ketika identitas klien (penelepon) sangat penting untuk mengetahui JIKA mereka harus diotorisasi untuk menerima data tersebut dari layanan. SSL standar adalah otentikasi satu arah (server) dan tidak melakukan apa pun untuk mengidentifikasi klien.

Jawabannya sebenarnya tergantung pada kebutuhan spesifik Anda.

Misalnya, apakah Anda perlu melindungi pesan web atau kerahasiaan tidak diperlukan dan yang Anda perlukan hanyalah mengotentikasi pihak akhir dan memastikan integritas pesan? Jika ini masalahnya - dan seringkali dengan layanan web - HTTPS mungkin adalah palu yang salah.

Namun - dari pengalaman saya - jangan mengabaikan kompleksitas sistem yang Anda bangun. Tidak hanya HTTPS lebih mudah untuk digunakan dengan benar, tetapi aplikasi yang bergantung pada keamanan lapisan transport lebih mudah untuk di-debug (melalui HTTP biasa).

Semoga berhasil.

REST Over HTTPS Harus menjadi metode yang aman selama penyedia API mengimplementasikan otorisasi server end. Dalam hal aplikasi web dan juga apa yang kita lakukan adalah mengakses aplikasi web melalui HTTPS dan beberapa otentikasi / otorisasi, aplikasi web tradisional tidak memiliki masalah keamanan maka Restful API juga akan mengatasi masalah keamanan tanpa masalah!

Jika panggilan RESTFul Anda mengirim XML Pesan bolak-balik tertanam di Badan Html permintaan HTTP, Anda harus dapat memiliki semua manfaat WS-Security seperti enkripsi XML, Sertifikat, dll dalam pesan XML Anda saat menggunakan fitur keamanan apa pun tersedia dari http seperti enkripsi SSL / TLS.