Apakah boleh memiliki lapisan validasi sebelum lapisan kontrol akses


24

Saya membuat aplikasi web strcutured API dan dalam aplikasi ini kami memiliki berbagai lapisan yang melakukan pekerjaan mereka sendiri.

Lapisan pertama adalah lapisan Validasi yang memvalidasi input pengguna dan jika melewati validasi, kami memindahkannya ke lapisan kedua (yang merupakan lapisan Access Control ) jika tidak mengembalikan pesan kesalahan

Lapisan kedua adalah Kontrol Akses yang memeriksa apakah pengguna memiliki izin untuk melakukan tugas yang ingin dilakukan, Jika pengguna memiliki izin itu memindahkan permintaan ke lapisan berikutnya jika tidak mengembalikan pesan kesalahan

Lapisan Ketiga adalah Lapisan Pengendali di mana kita memiliki logika aplikasi

Pertanyaan saya adalah apakah boleh memiliki lapisan validasi sebelum kontrol akses? Bagaimana jika pengguna mencoba melakukan tugas yang tidak diizinkan oleh pengguna dan kami mengirim kembali pesan kesalahan validasi? Pengguna akan mengirim permintaan ke titik akhir dan berbicara dengan lapisan validasi dan setelah melewati validasi hanya kemudian ia akan melihat pesanYou can't access this!

Rasanya aneh bagi saya sehingga tidak masalah seperti ini atau apa yang bisa menjadi pilihan saya yang lain dalam infrastruktur ini?


10
Perlu juga disebutkan bahwa validasi sering kali harus menjangkau database untuk melakukan pekerjaan mereka, atau penyimpanan file. Jika Anda melakukan ini sebelum memeriksa pelanggaran kontrol akses, Anda pada dasarnya mengizinkan penyerang untuk melakukan DDoS pada basis data atau sistem file Anda dengan melemparkan lalu lintas dalam jumlah besar ke URL tersebut.
Greg Burghardt

Dalam kasus saya, hal yang sama berlaku untuk Access Control Middleware, ia memeriksa sumber daya dan melihat apakah jenis sumber daya dapat diakses oleh pengguna, jika itu diakses, saya mengizinkan akses sebaliknya
Muhammad

Itu benar. Selama DDoS lapisan itu masih akan mengenai penyimpanan data Anda. Dengan menjalankan lapisan itu terlebih dahulu, Anda tidak akan menekan penyimpanan data untuk validasi DAN kontrol akses - Anda tinggal menekannya untuk kontrol akses. Ini mengurangi ukuran tsunami, tetapi tidak mencegahnya mengenai pantai. Ini memberi Anda atau tim server Anda kesempatan untuk merespons serangan sebelum seluruh sistem macet.
Greg Burghardt

5
Dari sudut pandang praktis, toh kontrol akses harus dilakukan sebelum validasi - bagaimana Anda akan memvalidasi kebenaran permintaan pengguna jika mereka tidak dapat mengakses permintaan tersebut?
Zibbobz

Validasi @Zibbobz sederhana seperti memeriksa apakah pengguna mengirim skema yang benar, seperti parameter yang seharusnya integer adalah integer atau sesuatu yang lain
Muhammad

Jawaban:


57

Itu tergantung pada apakah mengetahui validitas beberapa input untuk tugas yang tidak diizinkan Anda lakukan adalah kebocoran keamanan. Jika ya, Anda harus melakukannya dengan cara sebaliknya.

Satu-satunya respons yang aman untuk pengguna yang tidak sah adalah "akses ditolak". Jika terkadang responsnya adalah "permintaan buruk" dan terkadang "akses ditolak", Anda mengirim informasi ke pengguna yang tidak sah.

Sebagai contoh, Anda dapat melakukan pemeriksaan validasi tugas "hapus dokumen" yang ada di dokumen yang disebutkan. Seseorang tanpa izin akan dapat melihat apakah ada sesuatu dengan mencoba menghapusnya, dan membandingkan kesalahan mana yang mereka terima kembali. Penyerang yang bertekad kuat dapat menyebutkan semua nama dokumen (di bawah panjang tertentu), untuk melihat yang ada.


7
+1, tentu saja. Jika data Anda dengan cara apa pun dapat diidentifikasi secara pribadi atau sensitif dengan cara lain, maka implikasi keamanan jauh, jauh lebih serius daripada implikasi kegunaan.
Kilian Foth

4
@ caleth sebenarnya tidak akan memberi tahu Anda jika dokumen tertentu ada di sistem atau tidak, jenis informasi ini hanya diberikan ketika Anda mencapai lapisan pengontrol. Validasi hanya memeriksa skema, itu tidak mengakses database - hanya kontrol akses & lapisan yang lebih dalam melakukan akses database. Selain itu, lapisan kontrol akses hanya menampilkan hal-hal yang sama saat sumber daya ada atau tidak. Satu-satunya hal yang berkompromi adalah skema yang saya pikirkan apakah boleh atau tidak
Muhammad

@Caleth Bisakah Anda menguraikan komentar terakhir Anda? Saya tidak melihat bagaimana itu yang diberikan komentar OP. Sepertinya, satu-satunya informasi yang dikirim kembali adalah informasi yang tidak memiliki hak jika skema tersebut didokumentasikan secara publik.
Rotem

11
@Rotem Pada dasarnya tidak mungkin untuk menentukan terlebih dahulu informasi apa yang dapat dimanfaatkan oleh penyerang. Hanya karena Anda belum menemukan cara untuk mempelajari sesuatu yang seharusnya tidak Anda lakukan, tidak berarti tidak ada cara seperti itu. Sebagai contoh ekstrim, mungkin tidak ada kerentanan setiap saat , tetapi dalam seseorang masa depan bisa menambahkan cek ke lapisan validasi yang tidak kebocoran informasi karena mereka tidak tahu itu tidak dilindungi.
Kamil Drakari

4
@ KamilDrakari itu bukan contoh ekstrem, itu contoh yang masuk akal. Dengan kata lain - jika Anda melakukan validasi sebelum kontrol akses, setiap kali pengembang ingin menambahkan langkah validasi, mereka harus membuat keputusan apakah validasi itu memperlihatkan sesuatu yang sensitif. Kesempatan setiap dev mendapatkan panggilan itu benar tampak kecil.
mfrankli

24

Ya, ada beberapa jenis validasi:

  1. Pengecekan kewarasan dasar murah, yang memverifikasi bahwa permintaan tidak jelas cacat.

    Ini biasanya setidaknya sisi klien diduplikasi sebagian, untuk menghindari pulang pergi yang sia-sia.

    Bagaimanapun, itu harus dilakukan sebelum akses-kontrol untuk membuat hal-hal lebih mudah dan lebih rentan kesalahan, karena tidak berisiko kebocoran informasi.

  2. Validasi lebih mahal yang masih tidak bergantung pada data-aplikasi yang dilindungi.

    Jika ada validasi ekstra seperti itu, mungkin setelah kontrol akses tidak untuk menghindari kebocoran data, tetapi untuk menghambat serangan DOS.
    Kadang-kadang hanya menjalankan permintaan melakukan beberapa validasi itu secara implisit dengan pengurangan atau tanpa biaya, sehingga mungkin ditinggalkan di sini.

    Jika semua validasi dari langkah pertama digandakan, mungkin masuk akal juga untuk menggandakan bagian sisi klien ini.

  3. Validasi tambahan tergantung pada data-aplikasi yang dilindungi.

    Melakukannya sebelum akses-kontrol jelas berisiko kebocoran informasi. Maka, pertama lakukan akses-kontrol.


3
Akan ideal untuk melakukan kontrol akses pada titik penegakan kebijakan di infrastruktur Anda bahkan sebelum mencapai API Anda. Satu set validasi statis dasar (Mis: OpenAPI) akan menjadi yang pertama, diikuti oleh validasi bisnis yang lebih dalam. Bahkan beberapa validasi statis berpotensi berdampak pada ketersediaan serangan ReDOS aplikasi Anda .
felickz

@felickz: Ya, serangan DOS adalah alasan yang sah untuk menunda validasi sampai setelah otorisasi. Ini adalah tindakan keseimbangan. Bagaimanapun, saya membagi poin pertama saya untuk memperhitungkannya dengan benar.
Deduplicator

Melakukan validasi yang mahal sebelum kontrol akses juga berisiko bocornya informasi karena serangan waktu. Jika sistem Anda memakan waktu lebih pendek atau lebih lama tergantung pada sumber daya, maka penyerang dapat menyimpulkan aspek sumber daya yang diminta.
Lie Ryan

@ LieRyan: Itulah alasan semua validasi yang berpotensi sebelum kontrol akses tidak bergantung pada data aplikasi yang dilindungi sama sekali.
Deduplicator

13

Harus ada beberapa validasi sebelum kontrol akses. Misalkan API SO memiliki titik akhir "edit jawaban", lalu apakah pengguna dapat mengedit jawaban tertentu dapat bergantung pada jawabannya (di bawah reputasi tertentu, pengguna hanya dapat mengedit jawaban sendiri). Jadi parameter "ID jawaban" yang dibentuk dengan baik harus diverifikasi sebelum lapisan kontrol akses berperan; mungkin juga jawabannya ada.

OTOH, seperti yang disebutkan Caleth dan Greg, menempatkan validasi yang lebih luas sebelum kontrol akses merupakan risiko keamanan potensial.

Jadi aturan sulitnya

  1. Anda tidak boleh mengungkapkan informasi apa pun melalui validasi yang seharusnya tidak dapat ditemukan oleh pengguna.
  2. Anda harus memvalidasi data sebelum kontrol akses dapat menggunakannya sejauh kontrol akses membutuhkannya.

Mengikuti kedua aturan ini dapat berarti bahwa Anda harus memiliki beberapa validasi sebelum dan beberapa setelah kontrol akses.


3
Ini jawaban realistisnya. Jika sederhana, validasi struktur data input lurus, maka tidak boleh ada keraguan meletakkannya terlebih dahulu. Bahkan melindungi lapisan kontrol akses dari input / paket yang dirancang khusus. Validasi yang benar-benar memerlukan kebocoran atau dugaan informasi yang aman, harus ditempatkan setelah pemeriksaan akses.
SD

Itu mengasumsikan jawaban bersifat publik. Saya berani mengatakan banyak API bahkan tidak akan menampilkan data tanpa otentikasi.
TomTom

6

Selain kemungkinan frustrasi menerima 'akses ditolak' setelah memvalidasi input; juga perlu diingat bahwa lapisan Validasi , kecuali yang sangat sederhana, selalu dapat membutuhkan informasi dari Controller . Dengan mengingat hal ini, saya yakin posisi Validasi di belakang Access Control , lebih dekat ke Controller lebih masuk akal.


2

Itu tergantung pada apa yang Anda maksud dengan lapisan validasi - jika maksudnya Anda hanya memeriksa sintaks dari permintaan, itu aman dan sesuatu yang harus Anda lakukan pula. Jika 'validasi' Anda menggunakan informasi apa pun yang tidak dapat diakses oleh pengguna yang tidak memiliki hak pribadi, itu tidak lagi aman.

Anda harus memiliki pemeriksa kewarasan sebelum mencoba kontrol akses, tetapi Anda harus berhati-hati untuk berkomunikasi dengan sangat jelas kepada semua pengelola (saat ini dan di masa depan) bahwa bagian ini tidak boleh menggunakan informasi istimewa; Setiap pemeriksaan semacam itu harus dilakukan dalam langkah validasi terpisah setelah otentikasi.

Sebagai pemeriksaan kewarasan untuk pemeriksa kewarasan, seharusnya tidak benar-benar memiliki dependensi kode pada bagian mana pun dari kode Anda turunkan pipa dan harus dipisahkan ke dalam paket sendiri yang harus dipublikasikan untuk umum tanpa masalah (selain masalah hukum yang mungkin terjadi) . Jika Anda tidak bisa melakukan itu, 'lapisan validasi' Anda melakukan terlalu banyak (atau basis kode Anda berantakan).


1

Tidak. Itu tidak baik.

Jika Anda memiliki bug di lapisan validasi Anda, itu mungkin memotong lapisan keamanan.

Merupakan kesalahan umum untuk mempertimbangkan keamanan sebagai bagian dari persyaratan bisnis. "hanya pengguna dengan peran penjualan, yang dapat melihat angka-angka kuartalan" seperti aturan bisnis.

Tetapi jika Anda ingin aman, Anda harus membaca aturan seperti "hanya pengguna dalam peran penjualan, harus dapat menjalankan kode pada titik akhir ini" Anda harus memastikan server Anda selalu mengembalikan "akses ditolak" sebelum sampai ke segala jenis kode yang Anda tulis atau file di server.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.