LWP::UserAgent - URL-Splitting löst Boterkennung aus? (gelöst) - #192509 (Netzwerkprogrammierung und Netzwerke mit Perl)

Gast whatever_u_want

2020-09-16 19:15

2020-09-16T15:54:46 GwenDragon
Ist es so, dass TOR Proxy socks nutzt?

Definitiv. In C habe ich bereits vor Jahren ein Modul geschrieben, welches einen Socket an einen Tor Connector anmeldet. Der Rest ist dann einfaches HTTP/nicht ganz so einfaches HTTPS.
Und LWP::Protocol::socks habe ich schon längst installiert. Verdammt, ich habe vergessen zu erwähnen, dass ich schon ein anderes Script auf dem 9050 laufen habe; ich habe also bereits funktionierenden Code, nur halt für eine andere Seite, die nicht von Cloudflare "geschützt" wird. Und dieses andere Script läuft schon seit Monaten ohne Probleme; ich gehe also erstmal davon aus, dass der Code so tut.

GwenDragon
Lass mal ausgeben was gesendet+empfangen wird.

Ah, jetzt wird's interessant. Was gesendet wird.

Nun, das habe ich gerade in mühevoller Debugging-Arbeit selbst rausgefunden. Spoiler alert:

Code (perl): (dl )

$ua->add_handler( "request_send",  sub { shift->dump; return } );

gibt definitiv nicht das aus, was du glaubst, dass es ausgibt - was es nämlich ausgibt, ist so eine Klimamodellversion. Wie sich jemand vorstellt, dass es gesendet wird, was aber nicht der Realität entspricht. In LWP::Protocol::http steht nämlich der Code, der die Statuszeile und die Header baut und das dann in das jeweilige Socket-Objekt syswrited:

Code (perl): (dl )

my $req_buf = $socket->format_request($method, $fullpath, @h);
print "------\n$req_buf\n------\n";
if (!$has_content || $write_wait || $has_content > 8*1024) {
WRITE:
{
    # Since this just writes out the header block it should almost
    # always succeed to send the whole buffer in a single write call.
    my $n = $socket->syswrite($req_buf, length($req_buf));

Code: (dl )

GET /example.png HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: keep-alive, TE, close
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Host: example.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
Upgrade-Insecure-Requests: 1

HTTP/1.1 403 Forbidden
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Wed, 16 Sep 2020 17:11:24 GMT
Server: cloudflare
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Expires: Thu, 01 Jan 1970 00:00:01 GMT
CF-Chl-Bypass: 1
CF-RAY: 5d3c34da4e5edfad-FRA
Cf-Request-Id: 05397f5c6f0000dfad78ada200000001
Client-Date: Wed, 16 Sep 2020 17:11:21 GMT
Client-Peer: 127.0.0.1:9150
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Cloudflare, Inc./CN=Cloudflare Inc ECC CA-3
Client-SSL-Cert-Subject: /C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=sni.cloudflaressl.com
Client-SSL-Cipher: TLS_AES_256_GCM_SHA384
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Warning: Peer certificate not verified
Client-Transfer-Encoding: chunked
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Set-Cookie: __cfduid=da0509213e9332061eeceee8eeaa086ef1600276284; expires=Fri, 16-Oct-20 17:11:24 GMT; path=/; domain=.example.org; HttpOnly; SameSite=Lax
X-Frame-Options: SAMEORIGIN

Und da haben wir auch wieder diesen verfluchten "TE"-Header, den ich bereits im OP erwähnt habe. Und den Connection-Header setzt ich auch auf "keep-alive" und nicht auf "keep-alive, TE, close". Toll, wie da Fremdcode einem die Requests kaputt macht. "as_string" ist sowas von nutzlos ...

Jetzt habe ich mal den TE-Müll entfernt und als HTTP-Version 2.0 eingetragen - und es tut's immer noch nicht. Diesmal aber mit einem neuen RC: 505 HTTP Version Not Supported. Habe auch nochmal im Browser nachgeschaut, und nicht nur ist es Version 2.0, die der Browser sendet, sondern der Server akzeptiert das auch ohne Probleme, ich vermute also mal stark, dass LWP::UserAgent mit HTTP/2.0 nicht klarkommt. Und damit meine ich nicht mal das Protokoll an sich, sondern bereits am String "HTTP/2.0". Und nach dem, was ich so lese, wird LWP::UserAgent auch keine 2.0-Unterstützung bekommen.

Ach ja, ohne TE-Header bekomme ich nur wieder 403 Forbidden. Wenn's also wirklich an der Protokollversion liegt, dann geht nur noch ohne Tor. Was'n Blödsinn.
Last edited: 2020-09-16 20:02:19 +0200 (CEST)