Pertanyaan Praktik Terbaik untuk mengamankan API REST / layanan web [tutup]


Saat merancang REST API atau layanan apakah ada praktik terbaik yang telah ditetapkan untuk menangani keamanan (Otentikasi, Otorisasi, Manajemen Identitas)?

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

Meskipun saya memahami REST sengaja tidak memiliki spesifikasi yang analog dengan WS- * Saya berharap praktik terbaik atau pola yang disarankan telah muncul.

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


747
2017-08-11 05:44


asal


Jawaban:


Seperti kata tweakt, Amazon S3 adalah model yang baik untuk digunakan. Tanda tangan permintaan mereka memang memiliki beberapa fitur (seperti memasukkan stempel waktu) yang membantu mencegah terjadinya replaying yang tidak disengaja dan berbahaya.

Yang menyenangkan tentang HTTP Basic adalah bahwa hampir semua pustaka HTTP mendukungnya. Anda akan, tentu saja, perlu membutuhkan SSL dalam kasus ini karena mengirim kata sandi plaintext melalui internet hampir secara universal merupakan hal yang buruk. Dasar lebih disukai untuk Digest ketika menggunakan SSL karena bahkan jika pemanggil sudah tahu bahwa kredensial diperlukan, Intisari memerlukan perjalanan ulang tambahan untuk bertukar nilai nonce. Dengan Dasar, para penelepon cukup mengirim kredensial pertama kali.

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 Dasar di sini adalah server Anda berakhir dengan salinan plaintext dari kata sandi klien yang dapat dengan mudah diteruskan ke komponen lain dalam infrastruktur Anda sesuai kebutuhan.


280
2017-08-11 08:45



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

Misalnya, kami meminjam banyak ide dari layanan REST S3 Amazon ketika mengembangkannya sendiri. Namun kami memilih untuk tidak menggunakan model keamanan yang lebih canggih berdasarkan permintaan tanda tangan. Pendekatan yang lebih sederhana adalah autentikasi HTTP Basic melalui SSL. Anda harus memutuskan apa yang terbaik dalam situasi Anda.

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


108
2017-08-11 06:07



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

Ini sangat mirip dengan pendekatan yang diambil flickr dan ingat susunya "istirahat" apis (tidak selalu merupakan contoh yang baik dari apis yang tenang, tetapi contoh yang baik dari pendekatan berbasis token).


68
2017-09-18 02:55



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


40
2017-09-25 19:39



Semua orang dalam jawaban ini telah mengabaikan kontrol / otorisasi akses yang sesungguhnya.

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

  • dokter dapat MENDAPAT rekam medis pasien yang memiliki hubungan asmara dengan mereka
  • tidak ada yang dapat mengirim data medis di luar jam latihan (misalnya 9 hingga 5)
  • pengguna akhir dapat MENDAPAT rekam medis yang mereka miliki atau rekam medis pasien untuk siapa mereka menjadi wali
  • perawat dapat MEMPERBARUI catatan medis pasien yang dimiliki oleh unit yang sama dengan perawat.

Untuk mendefinisikan dan mengimplementasikan otorisasi yang berbutir halus tersebut, Anda harus 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 mis. membiarkan tindakan layanan atas nama saya di layanan lain (Facebook dapat memposting ke Twitter saya)
  • SAML: identitas federasi / SSO web. SAML sangat banyak tentang siapa pengguna itu.
  • WS-Security / WS- * standards: ini fokus pada komunikasi antara layanan SOAP. Mereka spesifik untuk format perpesanan tingkat aplikasi (SOAP) dan mereka menangani aspek olahpesan, misalnya keandalan, keamanan, kerahasiaan, integritas, atomicity, eventing ... Tidak ada kontrol akses penutup dan semuanya khusus untuk SOAP.

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

Berikut ini adalah sumber daya yang menarik:


34
2017-09-24 22:22



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

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


25
2018-01-09 21:25



Ada daftar periksa hebat yang ditemukan Github:

Otentikasi

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

  • Menggunakan Max Retry dan fitur jail di Login.

  • Gunakan enkripsi pada semua data sensitif.

JWT (JSON Web Token)

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

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

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

  • Jangan simpan data sensitif di JWT muatan, itu dapat diterjemahkan dengan mudah.

OAuth

  • Selalu validasi redirect_uri sisi server untuk mengizinkan hanya URL yang masuk daftar putih.

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

  • Gunakan parameter status dengan hash acak untuk mencegah CSRF pada OAuth proses otentikasi.

  • Tentukan ruang lingkup default, dan validasi parameter 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)

  • Menggunakan HSTS tajuk dengan SSL untuk menghindari serangan SSL Strip.

Memasukkan 

  • Gunakan metode HTTP yang tepat sesuai dengan operasi: GET (Baca baca), POST (membuat), PUT/PATCH (ganti / perbarui), dan DELETE (untuk menghapus rekaman), dan merespons dengan 405 Method Not Allowed jika metode yang diminta tidak sesuai untuk sumber yang diminta.

  • Validasi tipe konten berdasarkan permintaan Accept tajuk (Negosiasi Konten) untuk hanya mengizinkan format yang didukung (mis. application/xml, application/json, dll.) dan merespons dengan 406 Not Acceptable respons jika tidak cocok.

  • Mengesahkan content-type data yang diposting saat Anda menerima (mis. application/x-www-form-urlencoded, multipart/form-data, application/json, dll).

  • Validasi masukan 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 standar Authorization tajuk.

  • Gunakan layanan API Gateway untuk mengaktifkan caching, Rate Limit kebijakan (misalnya, Kuota, Penangkapan Spike, Batas Kecepatan Serentak), dan gunakan sumber daya API secara dinamis.

Pengolahan

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

  • ID sumber daya sendiri milik pengguna harus dihindari. Gunakan / saya / pesanan bukannya / pengguna / 654321 / pesanan.

  • Jangan ID kenaikan otomatis. Gunakan UUID sebagai gantinya.

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

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

  • Gunakan CDN untuk mengunggah file.

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

  • Jangan lupa untuk memutar DEBUG mode MATI.

Keluaran

  • Kirim X-Content-Type-Options: nosniff tajuk.

  • Kirim X-Frame-Options: deny tajuk.

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

  • Hapus header sidik jari - X-Powered-By, Server, X-AspNet-Version dll.

  • Memaksa content-type untuk tanggapan Anda, jika Anda kembali application/json maka jenis konten tanggapan Anda adalah application/json.

  • Jangan mengembalikan data sensitif seperti kredensial, Sandi, token keamanan.

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


22
2017-11-08 20:29



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


17
2017-09-18 20:53