User-Agent dengan komponen yang dikodekan base64?

(Pertanyaan hadiah di bagian bawah)

Saya mengalami masalah dengan klien yang mengakses situs kami, dan penyebab utamanya adalah bahwa WAF (Web Application Firewall) tidak menyukai string Agen-Pengguna mereka:

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0

Dalam hal ini, string yang dikodekan base64 memicu false positive dalam WAF yang menganggap User-Agent adalah libwww-perl. String base64 tidak men-decode ke teks yang dapat dibaca.

• Apakah memiliki string yang dikodekan base64 di dalam User-Agent normal atau tidak biasa?
• Apakah penggunaan string base64 di dalam Agen-Pengguna dilindungi oleh RFC atau praktik vendor utama?

Saya mencoba memahami apa yang terjadi di sini; Saya tidak merasa tanda tangan WAF benar-benar keluar dari jalur ke objek, jadi saya lebih suka tidak hanya menonaktifkannya, tapi saya belum pernah melihat string User-Agent semacam ini sebelumnya, jadi saya lebih mengerti lebih baik bagaimana umum dan / atau kasus penggunaan yang sah ini.

Situs ini dirancang untuk digunakan oleh manusia dengan browser - ini bukan API atau semacamnya - dan telah dilaporkan kepada saya bahwa pengguna telah mencoba mengakses situs dengan "FF / IE / Chrome" dan gagal. Namun, saya menunjukkan koneksi yang berhasil dari IP klien yang sama dengan agen-pengguna Opera:

User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

Agak aneh bahwa pengguna melaporkan telah mencoba IE tetapi semua string User-Agent yang saya lihat tampaknya Linux. (Seperti biasa, kontak dengan pengguna akhir dimediasi melalui beberapa pihak sehingga saya tidak dapat sepenuhnya mempercayai apa pun yang saya dengar). Kemungkinan juga IP adalah sisi keluar dari proxy web kelas bisnis, yang akan menjelaskan mengapa saya melihat beberapa Opera bekerja untuk seseorang sementara orang lain melaporkan masalah dari IP yang sama.

Memperbarui

Terinspirasi oleh contoh @PlanetScaleNetworks, saya mencari-cari di Google string dan dari sana akhirnya menggunakan UA Tracker untuk mencari string base64 (atau, subset dari mereka yang berlapis - saya mencari "=)"). Ini mengembalikan sekitar 20 Agen-Pengguna:

Saya akan menambahkan hadiah untuk pertanyaan ini, dan ruang jawaban yang saya cari adalah "jenis perangkat lunak apa yang meletakkan string base64 ke dalam User-Agent, dan mengapa? Dan apakah ada cap legitimasi untuk praktik ini? "

Titik kecil:

Pengguna telah mengatasi masalah kami dengan menggunakan plugin browser untuk memodifikasi User-Agent mereka, jadi ini sekarang merupakan masalah akademis - tapi saya pikir ini adalah masalah akademis yang menarik :)

Jika semua lalu lintas lain dari alamat IP ini sah, maka saya tidak akan khawatir tentang aturan WAF yang dipicu. Itu tidak diterjemahkan menjadi string yang dapat dibaca manusia. Jadi itu kemungkinan dimasukkan oleh perangkat proxy untuk tujuan pelacakan.

Mengenai kekhawatiran Anda tentang RFC, itu ditulis sebagai rekomendasi untuk bagaimana bidang harus digunakan meskipun ada sedikit konsistensi antara platform. Yang sedang berkata, itu adalah nilai yang ditentukan oleh klien yang tidak dapat dipercaya karena itu sepele untuk dimodifikasi. Oleh karena itu diperlukan aturan WAF.

Ada dua area di mana saya melihat string User-Agent menjadi perhatian:

1. Buffer Overflow - mencoba meluap buffer di server atau di dalam situs web / aplikasi. Ini jelas tidak terjadi dalam contoh yang diberikan.
2. Script / Code Injection - menyediakan skrip sebaris, referensi ke file jarak jauh, dll. Sekali lagi, jelas tidak berlaku untuk situasi Anda.

Jika Anda benar-benar khawatir / paranoid, ubah string User-Agent dari sistem Anda sendiri ke yang ini dan jelajahi halaman yang sama saat menggunakan proxy seperti Fiddler, Burp, dll. Bagaimana permintaan / tanggapan dibandingkan dengan menggunakan dokumen asli Anda String Agen-Pengguna?

Saya tidak akan merekomendasikan memblokir alamat IP apa pun berdasarkan contoh yang diberikan kecuali semua lalu lintas dari IP ini berbahaya. Itupun seharusnya hanya diblokir untuk waktu yang terbatas. Lebih baik lagi, buat "halaman web yang diblokir" dengan perincian cara diblokir. Arahkan lalu lintas ke sana sampai dihubungi.

Apakah memiliki string yang dikodekan base64 di dalam User-Agent normal atau tidak biasa?

Menggali daftar agen Pengguna di WhichBrowser . Sangat masuk akal untuk menyimpulkan bahwa ini jarang terjadi, tetapi mungkin akibat infeksi malware.

Namun saya juga menyalahgunakan perilaku ini untuk menambahkan lapisan keamanan lain ke situs saya sendiri di masa lalu, di mana hanya beberapa klien dengan token base64 UA tertentu yang bahkan akan ditampilkan halaman login. Demikian pula sidik jari unik ini juga dapat digunakan untuk melayani halaman serangan atau mengalihkan di tempat lain.

Apakah penggunaan string base64 di dalam Agen-Pengguna dilindungi oleh RFC atau praktik vendor utama?

Tidak secara khusus. Tidak ada yang didokumentasikan dalam informasi vendor peramban Gecko. Dalam UA yang Anda berikan, base64 itu bukan bagian dari informasi produk, tetapi sebuah komentar. Tampaknya tidak ada batasan bidang komentar meskipun memiliki base64 dalam informasi produk tidak diperbolehkan RFC7231karena dapat dilihat sebagai informasi yang tidak perlu ditambahkan ke string UA.

WAF Anda mungkin tidak dapat mengidentifikasi UA sebagai sesuatu yang spesifik dan mungkin kembali libwww-perlkarena filternya tidak spesifik (false positive) dan terlalu senang dengan bit Linux / X11 karena tidak dapat memahami komentar base64.

Melakukan cek online telah menemukan string agen pengguna ini di situs closetnoc.org . Agen pengguna ini diidentifikasi sebagai salah satu dari sejumlah yang telah dilacak ke satu alamat IP 192.185.1.20yang telah ditandai sebagai spammer oleh list.quorum.to, bl.csma.biz, dan spamsources.fabel.dk.

Untuk memblokir akses ke IP ini (dan pada gilirannya ke Agen-Pengguna) ...

Menggunakan CISCO Firewall

access-list block-192-185-1-20-32 deny ip 192.185.1.20 0.0.0.0 any
permit any ip

Menggunakan Nginx

Edit nginx.conf dan masukkan include blockips.conf; jika tidak ada. Edit blockips.conf dan tambahkan berikut ini:

deny 192.185.1.20/32;

Menggunakan Linux IPTables Firewall

/sbin/iptables -A INPUT -s 192.185.1.20/32 -j DROP

Menggunakan Microsoft IIS Web Server

<rule name="abort ip address block 192.185.1.20/32" stopProcessing="true">           
    <match url=".*" />   
    <conditions>    
        <add input="{REMOTE_ADDR}" pattern="^192\.185\.1\.20$" />   
    </conditions>  
    <action type="AbortRequest" /> 
</rule>

Menggunakan Apache .htaccess

RewriteCond %{REMOTE_ADDR} ^192\.185\.1\.20$ [NC] 
RewriteRule .* - [F,L]

Sumber: closetnoc.org

Saya melihat agen pengguna yang dikodekan simil-b64 juga. Setelah beberapa analisis ternyata mereka adalah klien yang memasang antivirus Kaspersky dan mencari pembaruan.