Tác nhân người dùng với thành phần được mã hóa base64?

(Câu hỏi về tiền thưởng ở phía dưới)

Tôi gặp sự cố với một khách hàng truy cập trang web của chúng tôi và nguyên nhân cốt lõi là WAF (Tường lửa ứng dụng web) không giống như chuỗi Tác nhân người dùng của họ:

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

Trong trường hợp này, chuỗi được mã hóa base64 đang kích hoạt dương tính giả trong WAF, người cho rằng Tác nhân người dùng là libwww-perl. Chuỗi base64 không giải mã thành bất kỳ văn bản nào có thể đọc được.

• Việc có một chuỗi mã hóa base64 bên trong Tác nhân người dùng là bình thường hay bất thường?
• Việc sử dụng các chuỗi base64 bên trong Tác nhân người dùng có được bao phủ bởi bất kỳ RFC hoặc thực tiễn nhà cung cấp chính nào không?

Tôi đang cố gắng hiểu những gì đang xảy ra ở đây; Tôi không cảm thấy chữ ký WAF hoàn toàn không phù hợp với đối tượng, vì vậy tôi không chỉ vô hiệu hóa nó, nhưng tôi chưa từng thấy loại chuỗi Tác nhân người dùng này trước đây vì vậy tôi hiểu rõ hơn mức độ phổ biến và / hoặc hợp pháp một trường hợp sử dụng này là.

Trang web được thiết kế để con người sử dụng với trình duyệt - nó không phải là API hay bất cứ thứ gì tương tự - và tôi đã được báo cáo rằng người dùng đã thử truy cập trang web bằng "FF / IE / Chrome" và không thành công. Tuy nhiên, tôi hiển thị các kết nối thành công từ cùng một IP máy khách với tác nhân người dùng Opera:

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

Có một điều kỳ lạ là người dùng báo cáo đã dùng thử IE nhưng tất cả các chuỗi User-Agent mà tôi thấy dường như là Linux. (Như thường lệ, liên hệ với người dùng cuối được trung gian thông qua một số bên vì vậy tôi không thể hoàn toàn tin tưởng bất cứ điều gì tôi nghe thấy). Cũng có khả năng IP là phía bên ngoài của proxy web cấp doanh nghiệp, điều này sẽ giải thích lý do tại sao tôi thấy một số Opera làm việc cho ai đó trong khi người khác báo cáo sự cố từ cùng một IP.

Cập nhật

Lấy cảm hứng từ ví dụ @PlanetScaleNetworks, tôi đã tìm ra chuỗi và từ đó kết thúc bằng UA Tracker để tìm kiếm chuỗi cơ sở64 (hoặc, tập hợp con của chúng được đệm - Tôi đã tìm kiếm "=)"). Nó trả về khoảng 20 Đại lý người dùng:

Tôi sẽ thêm một phần thưởng cho câu hỏi này và không gian câu trả lời mà tôi đang tìm kiếm là "loại phần mềm nào đang đưa các chuỗi Base64 vào Đại lý người dùng, và tại sao? Và có dấu hiệu hợp pháp nào cho thực tiễn này không? "

Điểm nhỏ:

Người dùng đã giải quyết vấn đề của chúng tôi bằng cách sử dụng plugin trình duyệt để sửa đổi Tác nhân người dùng của họ, vì vậy đây hiện là một vấn đề học thuật - nhưng tôi nghĩ đó là một vấn đề học thuật thú vị :)

Nếu tất cả lưu lượng truy cập khác từ địa chỉ IP này là hợp pháp, thì tôi sẽ không lo lắng về quy tắc WAF được kích hoạt. Nó không giải mã thành một chuỗi có thể đọc được. Vì vậy, nó có khả năng được chèn bởi một thiết bị proxy cho mục đích theo dõi.

Về thắc mắc của bạn về RFC, họ đang viết như một khuyến nghị về cách thức lĩnh vực này nên được sử dụng mặc dù có rất ít sự nhất quán giữa các nền tảng. Điều đó đang được nói, đó là một giá trị được xác định bởi khách hàng không thể tin cậy vì nó không đáng để sửa đổi. Vì vậy, tại sao các quy tắc WAF là cần thiết.

Có hai lĩnh vực mà tôi thấy các chuỗi User-Agent trở thành mối quan tâm:

1. Tràn bộ đệm - hoặc cố gắng tràn bộ đệm trên máy chủ hoặc trong trang web / ứng dụng. Điều này rõ ràng không xảy ra trong ví dụ được cung cấp.
2. Script / Code Injection - cung cấp kịch bản nội tuyến, tham chiếu đến các tệp từ xa, v.v ... Một lần nữa, rõ ràng không áp dụng cho tình huống của bạn.

Nếu bạn thực sự lo lắng / hoang tưởng, hãy thay đổi chuỗi Tác nhân người dùng của hệ thống của bạn thành trang này và duyệt cùng các trang trong khi sử dụng proxy như Fiddler, Burp, v.v. Làm thế nào để yêu cầu / phản hồi so với sử dụng bản gốc của bạn Chuỗi tác nhân người dùng?

Tôi không khuyên bạn nên chặn bất kỳ địa chỉ IP nào dựa trên ví dụ được cung cấp trừ khi tất cả lưu lượng truy cập từ IP này là độc hại. Ngay cả sau đó nó chỉ nên bị chặn trong một thời gian giới hạn. Tốt hơn hết, hãy tạo một "trang web bị chặn" với các chi tiết về cách bỏ chặn. Chuyển hướng lưu lượng truy cập ở đó cho đến khi liên lạc.

Việc có một chuỗi mã hóa base64 bên trong Tác nhân người dùng là bình thường hay bất thường?

Đào qua danh sách các tác nhân người dùng tại whichBrowser . Thật hợp lý khi kết luận rằng điều này rất hiếm, nhưng có thể là kết quả của việc nhiễm phần mềm độc hại.

Tuy nhiên, tôi cũng đã lạm dụng hành vi này để thêm một lớp bảo mật khác vào trang web của riêng tôi trước đây, nơi chỉ một số khách hàng có mã thông báo U64 cơ sở cụ thể thậm chí sẽ được hiển thị trang đăng nhập. Tương tự, dấu vân tay độc đáo này cũng có thể được sử dụng để phục vụ trang tấn công hoặc chuyển hướng ở nơi khác.

Việc sử dụng các chuỗi base64 bên trong Tác nhân người dùng có được bao phủ bởi bất kỳ RFC hoặc thực tiễn nhà cung cấp chính nào không?

Không cụ thể. Không có gì được ghi lại trong bất kỳ thông tin nhà cung cấp trình duyệt Gecko nào. Trong UA bạn cung cấp, cơ sở64 nó không phải là một phần của thông tin sản phẩm, mà là một nhận xét. Dường như không có hạn chế nào của trường nhận xét mặc dù không có cơ sở 64 trong thông tin sản phẩm RFC7231vì nó có thể được xem là thông tin không cần thiết được thêm vào chuỗi UA.

WAF của bạn có thể không thể xác định UA là bất cứ điều gì cụ thể và có thể trả về libwww-perlvì bộ lọc không đặc hiệu (dương tính giả) và quá hài lòng với bit Linux / X11 vì nó không thể hiểu ý kiến ​​của 64 cơ sở.

Thực hiện kiểm tra trực tuyến đã bắt gặp chuỗi tác nhân người dùng này trên trang web Closnoc.org . User agent này được xác định là một trong số đó đã được bắt nguồn từ một địa chỉ IP duy nhất 192.185.1.20mà đã được gắn cờ là một spammer bằng list.quorum.to, bl.csma.bizvà spamsources.fabel.dk.

Để chặn quyền truy cập vào IP này (và lần lượt đến Tác nhân người dùng đó) ...

Sử dụng tường lửa CISCO

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

Sử dụng Nginx

Chỉnh sửa nginx.conf và chèn bao gồm blockips.conf; nếu nó không tồn tại Chỉnh sửa blockips.conf và thêm vào như sau:

deny 192.185.1.20/32;

Sử dụng tường lửa IPTables Linux

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

Sử dụng máy chủ web Microsoft IIS

<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>

Sử dụng Apache .htaccess

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

Nguồn: Closnoc.org

Tôi cũng thấy các tác nhân người dùng được mã hóa simil-b64. Sau một số phân tích, hóa ra khách hàng đã cài đặt chương trình chống vi-rút của Kaspersky và tìm kiếm các bản cập nhật.