Gunicorn: Kemampuan untuk menutupi atribut Server header respons http

Biasanya gunicorn ditempatkan di belakang server proxy terbalik seperti nginx di lingkungan produksi, dan nginx akan menampilkan tag Server nya sendiri.

lantai atas plus satu

dengan @benoitc kami dapat mengusulkan opsi pada baris perintah, bagaimana menurut Anda? jika tidak, kami akan menutup tiket ini seperti yang dijelaskan oleh @georgexsh , dalam mode produksi, Anda dapat menggunakan proxy terbalik (nginx, apache, ...).

Tidak bisakah seseorang memodifikasi lingkungan di post_request hook?

@tilgovi itu akan berhasil, saya kira ... tidak yakin apakah kita perlu membuat opsi lain ...

Tidak bekerja. Permintaan sudah dikirim pada saat itu.

@tilgovi middleware juga tidak akan berfungsi, karena Server ada di header default.

Bagaimana jika kita hanya menghapus header Server sama sekali?

+1

Jika kami mengizinkan Anda menyetel nilai header ke string acak, kami juga harus mengizinkan Anda menghapus header sepenuhnya.

+1

kok header nya mau di hapus?

Di masa lalu, saya telah menghapus tajuk dari penerapan untuk menyembunyikan perangkat lunak dan versi server sehingga tidak diambil oleh seseorang yang merayapi server dengan eksploitasi yang diketahui.

Ya. Keamanan menjadi salah satu alasannya. Tentu saja, Anda dapat mengubah nilai Server menjadi sesuatu yang acak, tetapi mengapa mengirim byte tambahan yang sebenarnya tidak diperlukan?

Saya memberanikan diri untuk membuat PR untuk fitur ini: #1384 . Itu sudah ada di daftar pencarian saya selama beberapa waktu.

Untuk menambah diskusi: Saya berpendapat bahwa sementara beberapa server proxy terbalik memodifikasi header Server , beberapa menambahkan header Via seperti yang dijelaskan di https://www.w3.org/Protocols/ rfc2616/rfc2616-sec14.html#sec14.38

Sayangnya, @mathiasverhoeven menutup PR-nya karena suatu hal dan akhir-akhir ini tidak ada aktivitas.

Apakah tidak mungkin untuk memiliki opsi yang lebih umum di sini, seperti pada --set-headers mana Anda dapat menentukan jumlah header berapa pun sebagai pasangan nilai kunci? Nilai kosong akan menghilangkan header sepenuhnya.

Saat ini, saya ingin menyesuaikan Server , tetapi saya juga ingin menambahkan satu header respons lagi, misalnya X-Product: MyProduct .

Saya bisa melempar sesuatu bersama berdasarkan PR @mathiasverhoeven . @benoitc dan @tilgovi bagaimana menurutmu?

Hanya akan meninggalkan ini di sini: https://www.fastly.com/blog/headers-we-dont-want. Seperti yang dapat Anda baca di artikel, header Server sangat umum DAN sama sekali tidak diperlukan.

Saya juga ingin dapat menghilangkan header Server. Saya menggunakan server web yang berfokus pada keamanan bernama Hiawatha untuk membalikkan proxy, disetel untuk tidak menambahkan header Server sendiri, jadi header Server gunicorn saat ini membuatnya untuk klien.

Ide @tuukkamustonen terdengar bagus bagi saya. :)

Sunting: baru saja dilihat https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string akan sangat bagus.

Ada yang menjalankan Flask? https://stackoverflow.com/a/46858238/452210 menyarankan untuk membungkus dan mengganti process_response , mengganti atau menghapus header.

Saya juga ingin dapat menghilangkan header Server. Saya menggunakan server web yang berfokus pada keamanan bernama Hiawatha untuk membalikkan proxy, disetel untuk tidak menambahkan header Server sendiri, jadi header Server gunicorn saat ini membuatnya untuk klien.

Saya perhatikan bahwa bahkan cloudflare menampilkan header Server, jadi saya tidak yakin hari ini bagaimana ini lebih tentang keamanan daripada ketenaran.

Saya pikir daripada menambahkan opsi lain ke baris perintah atau konfigurasi, saya hanya akan menghapus versi dari header sebagai permulaan. Kemudian tambahkan pengaturan file konfigurasi saja untuk menghapus server_token. Keuntungannya adalah server yang dengan anggun meningkatkan ke versi baru akan dapat menambahkan pengaturan itu tanpa menghentikan layanan. Pikiran?

Saya perhatikan bahwa bahkan cloudflare menampilkan header Server, jadi saya tidak yakin hari ini bagaimana ini lebih tentang keamanan daripada ketenaran.

Saya pikir layanan Cloudflare dan header server memiliki konteks yang berbeda dengan server situs individu. Ketika sebuah situs diproksi balik melalui Cloudflare, fakta bahwa Cloudflare yang melakukan proksi bukanlah hal yang tidak diketahui; itu terlihat melalui server nama dan/atau alamat IP, dll. Sebaliknya, saya menghosting situs di VPS tanpa proxy terbalik pihak ketiga berpotensi memberi saya harapan untuk menghindari setidaknya identifikasi langsung melalui header HTTP dari perangkat lunak server. (Tentu saja pemikirannya adalah bahwa jika gunicorn di masa depan ditemukan memiliki beberapa kerentanan, menemukan target akan lebih sulit daripada hanya mencari header servernya.)

Saya pikir daripada menambahkan opsi lain ke baris perintah atau konfigurasi, saya hanya akan menghapus versi dari header sebagai permulaan. Kemudian tambahkan pengaturan file konfigurasi saja untuk menghapus server_token. Keuntungannya adalah server yang dengan anggun meningkatkan ke versi baru akan dapat menambahkan pengaturan itu tanpa menghentikan layanan. Pikiran?

Itu bagus. :+1: :slightly_smiling_face:

Ya tolong setidaknya hapus versi. Versi tidak menambah ketenaran dan menghemat banyak waktu bagi penyerang.

Saya berpikir untuk menghapus versi saja. @tilgovi ada pemikiran tentang itu?

Baik untuk saya!

Ada kemajuan dalam hal ini? Ini sepertinya kemenangan cepat untuk keamanan.

yang akan menjadi bagian dari 20,1 berikutnya

Saya berpikir untuk menghapus versi saja.

Apakah pengaturan file-only konfigurasi untuk menghapus header Server sama sekali masih direncanakan?

@DavidOliver mengapa pertanyaannya?

@benoitc Komentar Anda yang saya kutip dapat diartikan bahwa itu "hanya"/hanya nomor versi yang akan dihapus, sedangkan sebelumnya dalam percakapan pengaturan untuk menghapus header Server sama sekali (yang ingin saya lakukan) adalah sedang dipertimbangkan.

Terima kasih.

Jika kita bisa menghapus header server sama sekali, kita harus melakukannya.

Saya masih harus yakin bahwa menghapusnya ada hubungannya dengan
keamanan. Itu tidak menjadi masalah dalam 10 tahun terakhir. Keamanan oleh
ketidakjelasan juga tidak membantu, saya lebih suka mengetahui bahwa kami memiliki masalah dan
memperbaikinya. Juga mengetahui server dapat membantu operasi

Saya cenderung untuk menghapus versi saat ini karena versi ini memberikan
terlalu banyak informasi tentang bagaimana server dipelihara. Kita harus melakukannya untuk
setiap cabang yang kami pertahankan.

Pikiran?

Benoît

Pada Minggu 29 Des 2019 pukul 04:23 Randall Leeds [email protected] menulis:

Jika kita bisa menghapus header server sama sekali, kita harus melakukannya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTLOW69
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

Dikirim dari Ponsel saya

Hai,

Saya menggunakan gunicorn untuk memberikan tanggapan melalui koneksi di mana data
mahal, apa pun yang bisa saya hapus adalah apa pun yang tidak perlu saya bayar.

Header Server kecil, tetapi hal-hal kecil bertambah, dan terkadang
hal-hal kecil berarti Anda dapat memasukkan semuanya dalam satu paket: the
header server dengan versi 24 byte, sekitar 1,7% dari payload
dengan MSS 1460 dan header TLS. Bahkan tanpa paket tambahan,
paket yang lebih besar kemungkinan besar perlu dikirim ulang sepenuhnya
saat koneksi buruk (seperti jaringan seluler di tempat terpencil).

Pada koneksi HTTPS baru, jabat tangan dan sertifikat
pertukaran membuat sebagian besar muatan dan hal-hal kecil dapat
diabaikan. Untuk permintaan berulang kecil menggunakan keep-alive, redundant
header menjadi bagian yang jauh lebih besar dari permintaan/tanggapan.

Ini mungkin juga penting bagi orang-orang yang lebih peduli dengan klien
kinerja (latensi lebih dari throughput) daripada biaya.

Untuk kasus penggunaan ini, opsi yang paling berguna adalah dapat
sepenuhnya hapus tajuk, bukan hanya menghapus nilainya
atau bagian versi.

Komentar ini sebagian besar terbatas pada penambahan referensi/spesifikasi/informasi RFC yang relevan, dan (semoga) sebagian besar interpretasi/komentar tanpa opini.

RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantik dan Konten https://tools.ietf.org/html/rfc7231#section -7.4.2

...Server asal MUNGKIN menghasilkan bidang Server dalam tanggapannya.

Server asal TIDAK HARUS menghasilkan bidang Server yang berisi detail halus yang tidak perlu dan HARUS membatasi penambahan subproduk oleh pihak ketiga. Nilai bidang Server yang terlalu panjang dan mendetail meningkatkan latensi respons dan berpotensi mengungkapkan detail implementasi internal yang mungkin membuat (sedikit) lebih mudah bagi penyerang untuk menemukan dan mengeksploitasi lubang keamanan yang diketahui.

https://tools.ietf.org/html/rfc7231#section -9.6

9.6. Keterbukaan Informasi Produk
Bidang header Agen-Pengguna (Bagian 5.5.3), Via (Bagian 5.7.1 dari [RFC7230]), dan Server (Bagian 7.4.2) sering kali mengungkapkan informasi tentang sistem perangkat lunak masing-masing pengirim. Secara teori, ini dapat memudahkan penyerang untuk mengeksploitasi lubang keamanan yang diketahui; dalam praktiknya, penyerang cenderung mencoba semua lubang potensial terlepas dari versi perangkat lunak yang digunakan. Proxy yang berfungsi sebagai portal melalui firewall jaringan harus mengambil tindakan pencegahan khusus mengenai transfer informasi header yang mungkin mengidentifikasi host di belakang firewall. Bidang header Via memungkinkan perantara untuk mengganti nama mesin yang sensitif dengan nama samaran.

Dari (usang) RFC2616:

15.1.2 Transfer Informasi Sensitif
Seperti protokol transfer data umum lainnya, HTTP tidak dapat mengatur konten data yang ditransfer, juga tidak ada metode apriori untuk menentukan sensitivitas bagian informasi tertentu dalam konteks permintaan yang diberikan. Oleh karena itu, aplikasi HARUS memberikan kendali sebanyak mungkin atas informasi ini kepada penyedia informasi tersebut. Empat bidang header perlu disebutkan secara khusus dalam konteks ini: Server, Via, Referer, dan From.
Mengungkap versi perangkat lunak tertentu dari server mungkin memungkinkan mesin server menjadi lebih rentan terhadap serangan terhadap perangkat lunak yang diketahui mengandung lubang keamanan. Pelaksana HARUS menjadikan bidang header Server sebagai opsi yang dapat dikonfigurasi.

PEP3333 Antarmuka Gateway Server Web Python v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

Secara umum, server atau gateway bertanggung jawab untuk memastikan bahwa header yang benar dikirim ke klien: jika aplikasi menghilangkan header yang diperlukan oleh HTTP (atau spesifikasi relevan lainnya yang berlaku), server atau gateway harus menambahkannya. Misalnya, HTTP Date: dan Server: header biasanya disediakan oleh server atau gateway.

• Header respons Server bersifat opsional menurut HTTP 1.1
• RFC menyadari bahwa bidang Server yang terlalu detail dapat mempermudah pemindaian situs untuk server yang rentan. Jelas ini adalah ketentuan yang membuat-satu-langkah-lebih sulit, ketidakjelasan, dan seberapa banyak-detail terlalu banyak bersifat tidak langsung.
• HTTP 1.1 RFC2616 yang sudah usang sedikit lebih berani dalam nilai menyembunyikan header Server.
• PEP3333 tampaknya sedikit melampaui batas ketika menyebutkan header Server dalam konteks header yang diperlukan atau normal.

Banyak pendapat tentang ini, seperti di Apache HTTPD ServerTokens : https://httpd.Apache.org/docs/2.4/mod/core.html#servertokens

Menyetel ServerTokens ke kurang dari minimal tidak disarankan karena membuat lebih sulit untuk men-debug masalah interoperasional. Perhatikan juga bahwa menonaktifkan Server: header tidak melakukan apa pun untuk membuat server Anda lebih aman. Gagasan "keamanan melalui ketidakjelasan" adalah mitos dan mengarah pada rasa aman yang salah.

Mengubah header server menjadi hanya mengatakan gunicorn adalah solusi praktis dan saya pikir kita harus melakukannya, tanpa konfigurasi.

Orang-orang seperti @kmichel-sereema, yang ingin mengoptimalkan ukuran setiap transfer, saya pikir ini bukan tempat untuk melakukan optimasi mikro seperti itu. Jika header HTTP terlalu berlebihan, HTTP 1.x bukanlah protokol yang ideal untuk digunakan, dan menurut saya kita tidak perlu menambahkan konfigurasi tambahan untuk memungkinkan perubahan atau penonaktifan header server.

Saran dari @tilgovi sepertinya merupakan kompromi yang baik bagi saya.

Di banyak lingkungan ini bahkan mungkin diperdebatkan. Dokumen penyebaran gunicorn merekomendasikan untuk memiliki server proxy seperti nginx di depan gunicorn. nginx secara otomatis menghapus header

mengikuti saran dan komentar saya dari @tilgovi & @jamadden Saya menutup masalah ini dengan bantuan #2233. Terima kasih semua untuk kode dan komentarnya!