User-Agent mit Base64-codierter Komponente?

(Kopfgeldfrage unten)

Ich habe ein Problem mit einem Client, der auf unsere Website zugreift, und die Hauptursache ist, dass die WAF (Web Application Firewall) ihre User-Agent-Zeichenfolge nicht mag:

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

In diesem Fall löst die base64-codierte Zeichenfolge in der WAF ein falsches Positiv aus, das den User-Agent für libwww-perl hält. Die base64-Zeichenfolge wird nicht in lesbaren Text dekodiert.

• Ist eine normale 64-codierte Zeichenfolge in einem User-Agent normal oder ungewöhnlich?
• Wird die Verwendung von base64-Zeichenfolgen in einem User-Agent durch RFCs oder wichtige Herstellerpraktiken abgedeckt?

Ich versuche zu verstehen, was hier passiert. Ich habe nicht das Gefühl, dass die WAF-Signatur für das Objekt völlig unpassend ist, daher möchte ich sie lieber nicht nur deaktivieren, sondern diese Art von User-Agent-Zeichenfolge noch nie gesehen haben, um besser zu verstehen, wie häufig und / oder ein legitimer Anwendungsfall ist dies.

Die Site wurde für die Verwendung durch Benutzer mit Browsern entwickelt - es handelt sich nicht um eine API oder ähnliches - und es wurde mir berichtet, dass der Benutzer versucht hat, mit "FF / IE / Chrome" auf die Site zuzugreifen, und dies fehlgeschlagen ist. Ich zeige jedoch erfolgreiche Verbindungen von derselben Client-IP mit einem Opera-Benutzeragenten:

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

Es ist etwas seltsam, dass der Benutzer angibt, den IE ausprobiert zu haben, aber alle User-Agent-Zeichenfolgen, die ich sehe, scheinen Linux zu sein. (Wie üblich wird der Kontakt mit dem Endbenutzer über mehrere Parteien vermittelt, sodass ich nichts, was ich höre, voll vertrauen kann.) Es ist auch wahrscheinlich, dass die IP die ausgehende Seite eines Business-Class-Webproxys ist, was erklären würde, warum ich sehe, dass Opera für jemanden arbeitet, während jemand anderes Probleme von derselben IP meldet.

Aktualisieren

Inspiriert vom Beispiel von @PlanetScaleNetworks habe ich die Zeichenfolge gegoogelt und von dort aus UA Tracker verwendet, um nach base64-Zeichenfolgen zu suchen (oder nach der Teilmenge von ihnen, die aufgefüllt wurden - ich habe nach "=)" gesucht). Es wurden ungefähr 20 User-Agents zurückgegeben:

Ich werde dieser Frage ein Kopfgeld hinzufügen, und der gesuchte Antwortbereich lautet: "Welche Art von Software fügt Base64-Zeichenfolgen in User-Agents ein und warum? Und gibt es einen Stempel der Legitimität für diese Praxis? ""

Kleiner Punkt:

Der Benutzer hat unser Problem umgangen, indem er ein Browser-Plugin verwendet hat, um seinen User-Agent zu ändern. Dies ist also jetzt ein akademisches Problem - aber ich denke, es ist ein interessantes akademisches Problem :)

Wenn der gesamte andere Datenverkehr von dieser IP-Adresse legitim ist, würde ich mir keine Sorgen machen, dass die WAF-Regel ausgelöst wird. Es wird nicht in eine von Menschen lesbare Zeichenfolge dekodiert. Daher wurde es wahrscheinlich von einem Proxy-Gerät zu Verfolgungszwecken eingefügt.

In Bezug auf Ihre Besorgnis über die RFC, sind sie als Empfehlung geschrieben für , wie das Feld sollte verwendet werden , obwohl es wenig Übereinstimmung zwischen den Plattformen gibt. Davon abgesehen ist es ein vom Client definierter Wert, dem nicht vertraut werden kann, da es trivial ist, ihn zu ändern. Deshalb werden WAF-Regeln benötigt.

Es gibt zwei Bereiche, in denen User-Agent-Zeichenfolgen zu einem Problem werden:

1. Pufferüberlauf - versucht entweder, den Puffer auf dem Server oder innerhalb der Website / Anwendung zu überlaufen. Dies ist im angegebenen Beispiel eindeutig nicht der Fall.
2. Skript- / Code-Injektion - Bereitstellung von Inline-Skripten, Verweisen auf entfernte Dateien usw. Auch dies gilt eindeutig nicht für Ihre Situation.

Wenn Sie wirklich besorgt / paranoid sind, ändern Sie die User-Agent-Zeichenfolge Ihres eigenen Systems in diese und durchsuchen Sie dieselben Seiten, während Sie einen Proxy wie Fiddler, Burp usw. verwenden. Wie vergleichen sich die Anforderungen / Antworten mit der Verwendung Ihres Originals? User-Agent-String?

Ich würde nicht empfehlen, IP-Adressen basierend auf dem angegebenen Beispiel zu blockieren, es sei denn, der gesamte Datenverkehr von dieser IP ist böswillig. Auch dann sollte es nur für eine begrenzte Zeit gesperrt werden. Besser noch, erstellen Sie eine "blockierte Webseite" mit Details zum Entsperren. Leiten Sie den Verkehr dort um, bis Sie kontaktiert werden.

Ist eine normale 64-codierte Zeichenfolge in einem User-Agent normal oder ungewöhnlich?

Durchsuchen der Liste der Benutzeragenten bei WhichBrowser . Es ist vernünftig zu schließen, dass dies selten ist, aber möglicherweise das Ergebnis einer Malware-Infektion.

Ich habe dieses Verhalten jedoch in der Vergangenheit auch missbraucht, um meiner eigenen Site eine weitere Sicherheitsschicht hinzuzufügen, auf der nur wenige Clients mit einem bestimmten base64 UA-Token sogar auf der Anmeldeseite angezeigt wurden. In ähnlicher Weise könnte dieser einzigartige Fingerabdruck auch verwendet werden, um eine Angriffsseite bereitzustellen oder an eine andere Stelle umzuleiten.

Wird die Verwendung von base64-Zeichenfolgen in einem User-Agent durch RFCs oder wichtige Herstellerpraktiken abgedeckt?

Nicht speziell. In den Herstellerinformationen des Gecko-Browsers ist nichts dokumentiert. In der von Ihnen angegebenen UA ist die base64 nicht Teil der Produktinformationen, sondern ein Kommentar. Es gibt anscheinend keine Einschränkungen für das Kommentarfeld, obwohl base64 in den Produktinformationen nicht zulässig RFC7231ist, da dies als unnötige Informationen angesehen werden kann, die an die UA-Zeichenfolge angehängt werden.

Ihre WAF kann die UA wahrscheinlich nicht als spezifisch identifizieren und kehrt möglicherweise zurück, libwww-perlda der Filter unspezifisch (falsch positiv) ist und mit dem Linux / X11-Bit zu zufrieden ist, da er für den base64-Kommentar keinen Sinn ergibt.

Bei einer Online-Überprüfung ist diese Benutzeragentenzeichenfolge auf der Websiteschranknoc.org aufgetreten . Dieser User - Agent wurde als eine von vielen identifiziert , die auf eine einzelne IP - Adresse zurückverfolgt worden , 192.185.1.20die als Spammer markiert wurde durch list.quorum.to, bl.csma.bizund spamsources.fabel.dk.

So blockieren Sie den Zugriff auf diese IP (und damit auf diesen User-Agent) ...

Verwenden der CISCO-Firewall

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

Verwenden von Nginx

Bearbeiten Sie die Datei nginx.conf und fügen Sie include blockips.conf ein. wenn es nicht existiert. Bearbeiten Sie die blockips.conf und fügen Sie Folgendes hinzu:

deny 192.185.1.20/32;

Verwenden der Linux IPTables-Firewall

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

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

Verwenden von Apache .htaccess

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

Quelle : schranknoc.org

Ich sehe auch simil-b64-codierte Benutzeragenten. Nach einigen Analysen stellt sich heraus, dass es sich um Clients handelt, auf denen Kaspersky Antivirus installiert ist und die nach Updates suchen.