REST adalah arsitektur aplikasi web yang sangat populer. Untuk memanggil fungsi di server, permintaan HTTP biasa dengan parameter yang ditentukan digunakan (JSON atau XML biasanya digunakan untuk menyusun parameter), sementara tidak ada standar ketat untuk arsitektur REST, yang menambah fleksibilitas (dan, tentu saja, sedikit kekacauan).
REST memungkinkan Anda untuk secara fleksibel mendekati masalah keamanan atau, daripada banyak dosa, untuk tidak mendekati pertanyaan sama sekali. Berdasarkan
OWASP , kami telah menyiapkan daftar kiat untuk membantu Anda meningkatkan keamanan aplikasi REST Anda.
Sebagai titik awal dalam kasus-kasus langka ketika dibutuhkan di sini, kami menggunakan python dan Django.
Aturan 0
Https
Hanya mengaturnya. Tolong. Perlindungan data yang dikirim tidak membahayakan siapa pun. Bahkan jika Anda berpikir bahwa tidak ada yang perlu dilindungi saat ini, ini tidak akan selalu menjadi masalah dan Anda masih harus mengonfigurasi HTTPS. Jadi konfigurasikan dengan lebih baik segera, dan semua orang akan baik-baik saja.
Aturan 1
Otentikasi
Tampaknya nasihat yang jelas, yang, bagaimanapun, lebih suka diabaikan. Aplikasi harus selalu memiliki otentikasi, bahkan jika Anda sekarang berpikir bahwa Anda akan menggunakannya hanya di dalam perusahaan dan tidak ada perbedaan karyawan mana yang melakukannya. Dan jika Anda menambahkan lebih banyak dengan majalah, maka menyelidiki insiden dan menganalisis aktivitas akan menjadi jauh lebih mudah.
Sebagai token akses, saat ini dianggap praktik yang baik untuk menggunakan
JWT (JSON web token). Jangan gunakan token dengan nilai {"alg": "none"} untuk kontrol integritas, token harus selalu berisi tanda tangan atau MAC! Tanda tangan lebih disukai karena fakta bahwa kunci pembuatan dan verifikasi kecocokan MAC (atau dapat dengan mudah dihitung satu sama lain), yaitu, jika server dapat memeriksa nilai MAC, maka ia juga dapat menghasilkan nilainya. Tanda tangan juga menegaskan tidak hanya integritas pesan, tetapi juga identitas pengirim.
Aturan 2
Tolak metode HTTP yang tidak Anda gunakan
Konfigurasikan server untuk membuat daftar putih metode yang Anda gunakan (GET, POST, PUT, dll.) Dan tolak semua yang tidak sesuai dengan daftar ini. Server Anda mungkin tidak perlu memproses permintaan TRACE saat produksi (metode ini adalah bagian dari serangan XST (Cross-Site Tracing), yang terdiri dari serangan XSS dan metode TRACE atau TRACK. Serangan ini memungkinkan, misalnya, untuk mencuri cookie pengguna, bahkan jika mereka ditandai sebagai HttpOnly). Semakin sedikit informasi tentang infrastruktur Anda yang tersedia dari luar, semakin baik.
Aturan 3
Bedakan akses
Apakah semua pengguna Anda memerlukan semua metode, misalnya, HAPUS? Jika Anda tidak ingin beberapa pengguna dapat melakukan operasi tertentu - konfigurasikan kontrol akses di aplikasi Anda. Misalnya, pengguna biasa hanya dapat mengakses metode GET untuk beberapa fungsi, manajer dapat menggunakan GET dan POST, dll. Untuk ini, ada baiknya menetapkan peran dalam basis data yang dapat ditetapkan kepada pengguna untuk kontrol akses yang nyaman.
Akibatnya, setiap fungsi akan memiliki blok centang kira-kira jenis ini:
if request.POST and user.is_manager: do_stuff()
Aturan 4
Pikirkan tentang membatasi jumlah kueri
Jika Anda berpikir bahwa pengguna Anda tidak boleh mengirimi Anda seratus ribu permintaan per detik, maka Anda harus membatasi nomor ini. Gunakan kunci API atau mekanisme lain yang nyaman bagi Anda untuk melacak dan membatasi jumlah permintaan yang akan diproses dalam periode waktu tertentu dari satu pengguna. Untuk Django, misalnya, django-ratelimit menyediakan fungsionalitas ini, di mana Anda dapat mengatur berbagai parameter sebagai pengidentifikasi untuk pembatasan, tidak harus kunci API, tetapi alamat IP.
Aturan 5
Pastikan untuk memvalidasi / membersihkan input
Jangan pernah mempercayai parameter input yang dikirimkan, selalu lakukan validasi / sanitasi:
- Jika memungkinkan (dan jika memungkinkan), tetapkan batas pada panjang / jenis / format input dan permintaan itu sendiri. Tolak semua permintaan / data yang dikirim yang melebihi panjang yang ditentukan oleh Anda atau yang tidak cocok dengan jenis / format.
- Saat memproses string, selalu lepaskan semua karakter khusus.
- Jika Anda menggunakan kerangka kerja tersebut, kebanyakan dari mereka mengandung alat validasi dan sanitasi bawaan mereka sendiri (begitu saja dari yang populer - Django (python) dan Yii2 (php)), jadi penting untuk mempelajari kemampuan mereka dan jika beberapa aspek yang Anda butuhkan tidak tercakup - temukan perpustakaan yang menutup ini, atau tulis sendiri fungsi tersebut.
- Catat kesalahan validasi. Jika permintaan beberapa pengguna terus gagal validasi - pikirkan tentang pemblokiran otomatis pengguna tersebut.
- Pastikan parser input Anda (atau versinya saat ini) tidak rentan terhadap serangan apa pun dengan sendirinya.
Aturan 6
Jangan memberikan informasi lebih dari yang diperlukan
Jika ada permintaan yang menyebabkan kesalahan dalam aplikasi, atau hanya karena alasan tertentu, jangan berikan detail dalam respons, kembalikan pesan kesalahan yang paling abstrak. Beberapa server mengembalikan stacktrace setelah kesalahan secara default, jadi pastikan untuk mengkonfigurasi ulang logika ini.
Aturan 7
Selalu simpan log
Biarkan setiap peristiwa (otentikasi, kesalahan, permintaan, dll.) Dicatat sedetail mungkin. Log mereka secara logis untuk pencarian yang lebih mudah di dalamnya jika perlu. Untuk jaga-jaga, sebelum merekam dalam log, bersihkan data yang direkam.
Aturan 8
Tunjukkan Konten-Jenis dengan benar - ini penting!
Agar peramban (atau klien) membaca dengan benar data yang disediakan, Jenis-Konten yang ditentukan dengan benar yang sesuai dengan data yang disediakan adalah penting. Untuk peramban, Anda juga perlu mengatur tajuk ke X-Content-Type-Options: nosniff, untuk mencegah peramban mencoba mendeteksi Tipe-Konten lain selain yang sebenarnya dikirim (ukuran terhadap serangan XSS).
Aturan 9
Validasi Jenis-Konten
- Layak mengatur penolakan permintaan jika Jenis Konten mereka berbeda dari isinya. Ini akan mengurangi risiko pemrosesan data yang salah, yang dapat menyebabkan injeksi atau eksekusi kode di server / klien.
- Sebaiknya Anda juga menolak permintaan yang Jenis-Kontennya tidak Anda dukung, atau yang tidak ada tajuk ini. Hindari juga jawaban langsung tentang fungsi / tipe Konten mana yang menerima / masalah, jika ini tidak perlu (ini akan membantu untuk menghindari serangan XXE).
- Dalam layanan REST, merupakan hal biasa untuk mendukung beberapa jenis respons (misalnya, json dan xml), dan klien menunjukkan jenis respons yang disukai di header Terima saat meminta. Hindari menyalin isi tajuk Terima ke dalam Tipe Konten dari respons sebagai mekanisme untuk mengatur tajuk ini. Tolak permintaan yang tajuk Terima tidak secara langsung mengandung setidaknya satu dari jenis yang didukung.
Aturan 10
Jangan lupa menyiapkan Cross-Origin Resource Sharing (CORS)
CORS adalah standar yang menjelaskan bekerja dengan kueri lintas-domain. Jika aplikasi Anda tidak mendukung CORS, nonaktifkan pekerjaan dengan header jenis ini. Jika Anda perlu menggunakannya, kebijakan akses harus spesifik dan seketat mungkin.
Aturan 11
Jangan perluas parameter di URL
Semua data penting (kata sandi, kunci, token dan login, sebaiknya juga) harus ada di dalam tubuh permintaan atau di header, tetapi tidak akan muncul dalam URL. Jika Anda harus meneruskan data sensitif melalui metode GET, taruh di header.
Itu tidak mungkin:contoh .com / controller / 123 / action? apiKey = a53f435643de32
Anda bisa:contoh .com / controller / 123 / action
Tajuk:Host: example.com
Agen-Pengguna: Mozilla ...
X-APIkey: a53f435643de32
Aturan 12
Pikirkan tentang perlindungan terhadap serangan CSRF
Anda dapat membaca lebih lanjut tentang semua jenis perlindungan di
sini , dan karenanya, penggunaan token CSRF dianggap sebagai cara paling populer untuk mengurangi risiko serangan jenis ini.
Aturan 13
Jelajahi kerangka kerja Anda
Jika Anda menggunakan kerangka kerja apa pun untuk mengimplementasikan REST dalam aplikasi Anda, maka Anda harus mempelajarinya dan tidak menggunakannya secara membabi buta, seperti yang sering dilakukan. Baca dokumentasi dengan seksama, terutama bagian keamanan. Jangan biarkan itu bekerja pada pengaturan default! Setiap kerangka kerja memiliki nuansa tersendiri, terutama dalam hal keamanan, sehingga mengenalnya sangat penting.