Pertanyaan 403 Forbidden vs 401 Respons HTTP tidak sah


Untuk halaman web yang ada, tetapi untuk pengguna yang tidak memiliki hak istimewa yang cukup, (mereka tidak masuk atau bukan milik kelompok pengguna yang tepat), apa tanggapan HTTP yang tepat untuk melayani? 401? 403? Sesuatu yang lain? Apa yang saya baca pada masing-masing sejauh ini tidak begitu jelas tentang perbedaan antara keduanya. Kasus penggunaan apa yang sesuai untuk setiap tanggapan?


1896
2017-07-21 07:21


asal


Jawaban:


Penjelasan yang jelas dari Daniel Irvine:

Ada masalah dengan 401 Tidak Sah, kode status HTTP untuk kesalahan otentikasi. Dan itu hanya itu: itu untuk otentikasi, bukan otorisasi.   Menerima tanggapan 401 adalah server yang memberi tahu Anda, “Anda tidak   diautentikasi - baik tidak diautentikasi sama sekali atau diautentikasi   salah - tetapi mohon untuk mengautentikasi ulang dan coba lagi. ”Untuk membantu Anda,   itu akan selalu termasuk a WWW-Otentikasi tajuk yang menjelaskan bagaimana   untuk mengotentikasi.

Ini adalah respons yang umumnya dikembalikan oleh server web Anda, bukan web Anda   aplikasi.

Itu juga sesuatu yang sangat sementara; server meminta Anda untuk mencoba   lagi.

Jadi, untuk otorisasi saya gunakan 403 Forbidden tanggapan. Nya   permanen, itu terkait dengan logika aplikasi saya, dan itu lebih konkret   tanggapan dari 401.

Menerima tanggapan 403 adalah server yang memberi tahu Anda, “Saya minta maaf. aku tahu   siapa Anda — saya percaya siapa yang Anda katakan, tetapi Anda tidak memilikinya   izin untuk mengakses sumber daya ini. Mungkin jika Anda bertanya pada sistem   administrator dengan baik, Anda akan mendapatkan izin. Tapi tolong jangan repot-repot   saya lagi sampai kesulitan Anda berubah. "

Singkatnya, a 401 Tidak Sah Tanggapan harus digunakan untuk hilang   atau otentikasi yang buruk, dan a 403 Forbidden respons harus digunakan   setelah itu, ketika pengguna diautentikasi tetapi tidak berwenang   melakukan operasi yang diminta pada sumber daya yang diberikan.

Lain format bergambar yang bagus tentang bagaimana kode status http harus digunakan.


2828
2017-08-04 06:24



Lihat RFC2616:

401 Tidak Sah:

Jika permintaan sudah menyertakan kredensial Otorisasi, maka tanggapan 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut.

403 Forbidden:

Server memahami permintaan tersebut, tetapi menolak untuk memenuhinya.

Memperbarui

Dari kasus penggunaan Anda, tampaknya pengguna tidak diautentikasi. Saya akan mengembalikan 401.


Edit: RFC2616 sudah usang, lihat RFC7231 dan RFC7235.


336
2017-07-21 07:28



Sesuatu jawaban lain yang hilang adalah bahwa harus dipahami bahwa Otentikasi dan Otorisasi dalam konteks RFC 2616 hanya mengacu pada protokol Otentikasi HTTP dari RFC 2617. Otentikasi oleh skema di luar RFC2617 tidak didukung dalam kode status HTTP dan tidak dianggap ketika memutuskan apakah akan menggunakan 401 atau 403 ..

Singkat dan Terse

Tidak sah menunjukkan bahwa klien tidak dikonfirmasi oleh RFC2617 dan server memulai proses otentikasi. Dilarang menunjukkan bahwa klien diautentikasi oleh RFC2617 dan tidak memiliki otorisasi atau bahwa server tidak mendukung RFC2617 untuk sumber daya yang diminta.

Berarti jika Anda memiliki proses login roll-your-own Anda sendiri dan tidak pernah menggunakan HTTP Authentication, 403 selalu merupakan respon yang tepat dan 401 seharusnya tidak pernah digunakan.

Detil dan Mendalam

Dari RFC2616

10.4.2 401 Tidak Sah

Permintaan tersebut memerlukan otentikasi pengguna. Tanggapan HARUS menyertakan bidang header WWW-Otentikasi (bagian 14.47) berisi tantangan yang berlaku untuk sumber daya yang diminta. Klien MUNGKIN mengulangi permintaan dengan bidang header Otorisasi yang sesuai (bagian 14.8).

dan

10.4.4 403 Forbidden   Server memahami permintaan tersebut, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK BOLEH diulang.

Hal pertama yang perlu diingat adalah bahwa "Otentikasi" dan "Otorisasi" dalam konteks dokumen ini merujuk secara khusus ke protokol Otentikasi HTTP dari RFC 2617. Mereka tidak mengacu pada protokol otentikasi roll-your-own Anda mungkin telah Anda buat menggunakan halaman login, dll. Saya akan menggunakan "login" untuk merujuk ke otentikasi dan otorisasi dengan metode selain RFC2617

Jadi perbedaan sebenarnya bukanlah masalahnya atau bahkan jika ada solusi. Perbedaannya adalah apa yang diharapkan klien untuk dilakukan selanjutnya.

401 menunjukkan bahwa sumber daya tidak dapat diberikan, tetapi server MEMINTA bahwa klien masuk melalui Otentikasi HTTP dan telah mengirim tajuk balasan untuk memulai proses. Mungkin ada otorisasi yang akan mengizinkan akses ke sumber daya, mungkin tidak ada, tetapi mari kita coba dan lihat apa yang terjadi.

403 menunjukkan bahwa sumber daya tidak dapat disediakan dan ada, untuk pengguna saat ini, tidak ada cara untuk menyelesaikan ini melalui RFC2617 dan tidak ada gunanya mencoba. Ini mungkin karena diketahui bahwa tidak ada tingkat otentikasi yang cukup (misalnya karena daftar hitam IP), tetapi mungkin karena pengguna sudah diautentikasi dan tidak memiliki otoritas. Model RFC2617 adalah satu-pengguna, satu-kredensial sehingga kasus di mana pengguna mungkin memiliki kumpulan kredensial kedua yang dapat diotorisasi dapat diabaikan. Ini tidak menunjukkan atau menyiratkan bahwa semacam halaman login atau protokol otentikasi non-RFC2617 lain mungkin atau mungkin tidak membantu - yang berada di luar standar dan definisi RFC2616.


Edit: RFC2616 sudah usang, lihat RFC7231 dan RFC7235.


254
2018-02-05 17:14



Menurut RFC 2616 (HTTP / 1.1) 403 dikirim ketika:

Server memahami permintaan tersebut, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK BOLEH diulang. Jika metode permintaan tidak HEAD dan server ingin mengumumkan mengapa permintaan tersebut belum dipenuhi, HARUS menjelaskan alasan penolakan dalam entitas. Jika server tidak ingin membuat informasi ini tersedia bagi klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya

Dengan kata lain, jika klien DAPAT mendapatkan akses ke sumber daya dengan mengautentikasi, 401 harus dikirim.


94
2017-07-21 07:26



Versi TL; DR

    DAPATKAN sumber daya, ada?
    | |
    | |
    v v
TIDAK: 404 YA: Apakah dikonfirmasi?
             | |
             | |
             v v
           TIDAK: 401 YA: Dapatkah mengakses sumber daya?
           (atau: 404) | |
           atau 301 | |
           mengalihkan v v
           untuk masuk NO: 403 OK 200, 301, ...

Cek biasanya dilakukan dalam urutan ini:

  • 401 jika tidak masuk atau sesi berakhir
  • 403 jika pengguna tidak memiliki izin untuk mengakses sumber daya
  • 404 jika sumber daya tidak ada

UNAUTHORIZED: Kode status (401) menunjukkan bahwa permintaan membutuhkan otentikasi. Pengguna / agen tidak dikenal oleh server. Dapat mengulang dengan kredensial lainnya. CATATAN: Ini membingungkan karena ini seharusnya diberi nama 'tidak diautentikasi' dan bukan 'tidak sah'.

TERLARANG: Kode status (403) menunjukkan server memahami permintaan tetapi menolak memenuhinya. Pengguna / agen yang dikenal oleh server tetapi memiliki kredensial tidak memadai. Permintaan berulang tidak akan berfungsi.

TIDAK DITEMUKAN: Kode status (404) menunjukkan bahwa sumber daya yang diminta tidak tersedia. Pengguna / agen dikenal tetapi server tidak akan mengungkapkan apa pun tentang sumber daya, apakah seolah-olah tidak ada. Mengulang tidak akan berfungsi. Ini adalah penggunaan khusus 404 (github melakukannya misalnya).


46
2018-02-23 11:00



Jika mengotentikasi sebagai pengguna lain akan memberikan akses ke sumber daya yang diminta, maka 401 Tidak Sah harus dikembalikan. 403 Terlarang sebagian besar digunakan ketika akses ke sumber daya dilarang untuk semua orang atau dibatasi untuk jaringan tertentu atau diizinkan hanya melalui SSL, apa pun asalkan tidak terkait dengan otentikasi.

Dari RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Otentikasi):

3.1. 401 Tidak Sah

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan itu   belum diterapkan karena tidak memiliki kredensial autentikasi yang valid   untuk sumber target. Server asal HARUS mengirim a   WWW-Otentikasi bidang header (Bagian 4.4) mengandung setidaknya satu   tantangan berlaku untuk sumber target. Jika permintaan   termasuk kredensial otentikasi, maka respon 401   menunjukkan bahwa otorisasi telah ditolak untuk mereka   kredensial. Klien MUNGKIN mengulangi permintaan dengan yang baru atau   diganti bidang header Otorisasi (Bagian 4.1). Jika 401   respons berisi tantangan yang sama dengan respons sebelumnya, dan   agen pengguna telah mencoba otentikasi setidaknya sekali, lalu   agen pengguna HARUS menampilkan representasi terlampir ke   pengguna, karena biasanya berisi informasi diagnostik yang relevan.

Dan ini dari RFC 2616:

10.4.4 403 Forbidden

Server memahami permintaan tersebut, tetapi menolak untuk memenuhinya.
Otorisasi tidak akan membantu dan permintaan TIDAK BOLEH diulang.
  Jika metode permintaan tidak HEAD dan server ingin membuatnya
  publik mengapa permintaan belum dipenuhi, itu HARUS menggambarkan   alasan untuk penolakan dalam entitas. Jika server tidak mau   buat informasi ini tersedia bagi klien, kode status 404
  (Tidak Ditemukan) dapat digunakan sebagai gantinya.

Edit: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): Semantik dan Konten) mengubah arti dari 403:

6.5.3. 403 Forbidden

Kode status 403 (Terlarang) menunjukkan bahwa server   mengerti permintaan tetapi menolak untuk mengotorisasi. Sebuah server itu   ingin mengumumkan mengapa permintaan itu dilarang   jelaskan alasan itu dalam muatan tanggapan (jika ada).

Jika kredensial otentikasi disediakan dalam permintaan, maka
  server menganggap mereka tidak cukup untuk memberikan akses. Klien
  TIDAK HARUS secara otomatis mengulangi permintaan dengan yang sama
  kredensial. Klien MUNGKIN mengulangi permintaan dengan yang baru atau berbeda   kredensial. Namun, permintaan mungkin dilarang karena alasan
  tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini
  sumber daya target terlarang MUNGKIN malah merespons dengan kode status
  404 tidak ditemukan).

Jadi, 403 mungkin berarti tentang apa pun. Memberikan kredensial baru mungkin membantu ... atau mungkin tidak.


37
2018-02-27 09:44



Ini adalah pertanyaan yang lebih tua, tetapi satu opsi yang tidak pernah benar-benar diajukan adalah mengembalikan 404. Dari perspektif keamanan, jawaban tertinggi yang dipilih menderita potensi kerentanan kebocoran informasi. Katakanlah, misalnya, bahwa halaman web aman yang dimaksud adalah halaman admin sistem, atau mungkin lebih umum, adalah catatan dalam sistem yang tidak dapat diakses oleh pengguna. Idealnya Anda tidak ingin pengguna yang jahat bahkan tahu bahwa ada halaman / catatan di sana, apalagi mereka tidak memiliki akses. Saat saya membuat sesuatu seperti ini, saya akan mencoba mencatat permintaan yang tidak autentik / tidak sah dalam log internal, tetapi mengembalikan 404.

OWASP memiliki beberapa informasi lebih lanjut tentang bagaimana penyerang dapat menggunakan jenis informasi ini sebagai bagian dari serangan.


20
2017-12-25 09:09