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

[thread]21014[/thread]

LWP::UserAgent - URL-Splitting löst Boterkennung aus? [gelöst]

Tags: perl5 LWP Ähnliche Threads

Leser: 13

Articles: hide open all | hide show old branches

+13 replies
Gast whatever_u_want

2020-09-16 14:04
Ich crawle eine Seite über LWP::UserAgent. Problem ist, dass die Seite von Cloudflare "beschützt" wird, und dass ich die Verbindung bei Vorhandensein eines Tor Connectors auf Port 9050 gerne über diesen Connector (SOCKS-Proxy) laufen lassen will, denn dann bekomme ich als Antwort vom Server nur einen 403 Forbidden. Ohne SOCKS-Proxyverbindung bekomme ich normale 200 OK.

Der interessante Teil - wo auch der Bezug zu Perl deutlich wird - ist wenn ich den Port statt auf 9050 auf 9150 setze. Auf dem Port hört nämlich der dem Tor Browser Bundle zugehörige Tor Connector, weil Port 9050 bereits von einem eigenen Dienst belegt wird - warum der Browser nicht einfach 9050 nimmt, anstatt eine Instanz seiner eigenen Software auf Port 9150 zu starten, braucht man mich nicht fragen. Jedenfalls senden jetzt mein Script und mein Browser ihre Anfragen beide über den 9150-Connector, verwenden also nach meinem Verständnis den gleichen Exitnode - und im Browser klappts reproduzierbar. Sogar mit abgeschaltetem Javascript. Das Script klappt nicht.

Also habe ich mir mal den Request im Browser und im Script genauer angeschaut und habe dabei Unterschiede in der Statuszeile festgestellt:
1. Der Browser sendet als HTTP-Version 2.0 mit, das Script sendet keinerlei Protokollversion mit.
2. Der Browser teilt die angefragte URL in Domain und Resource, packt die Domain in einen eigenen Host-Header, und die Resource in die Statuszeile. Das Script packt einfach die URL - samt Protokollkürzel - in die Statuszeile.

Wenn ich also nach https://example.org/example.png suche, sendet das Script:
Code: (dl )

GET https://example.org/example.png
, und der Browser sendet:
Code: (dl )

1 2

GET /example.png HTTP/2.0 Host: example.org
Dies - und die Reihenfolge, in die die Header gesendet werden - sind die einzgen Unterschiede, die ich in den Requests festmachen kann. Ansonsten sende ich die gleichen Browser-ähnlichen Header wie auch im Browser, und erhalte trotz gleichem Tor-Connector einen 403 statt einen 200.

Jetzt bin ich mir relativ sicher, dass dieses Verhalten neu ist; ich habe vor Jahren (2013 ~ 2014) bereits mit LWP::UserAgent gearbeitet und bin mir ziemlich sicher, dass das Paket sich bezüglich der Statuszeile verhalten hat wie der Browser (wobei LWP::UserAgent dabei noch einen bescheuerten TE-Header oder so mitgesendet hat, den man explizit in der PM-Datei auskommentieren musste, denn ich habe Seiten gesehen, die darauf geprüft haben und den UserAgent als Bot erkannt hatten). Ich bin mir deswegen so sicher, weil ich über diese Ausgaben HTTP gelernt habe. Ich bin mir ebenfalls relativ sicher, dass ich vor Monaten bereits eines anderen Scriptes wegen laut fluchend den Code debuggt habe, weil mir andere, von Cloudflare "geschützte" Seiten immer wieder 403 zurückgegeben haben und ich irgendwann noch lauter fluchend darauf gekommen bin, das Script in solchen Fällen in 10-sekündigen Schlaf zu senden und in der Zwischenzeit den Tor-Connector neuzustarten.

Funktioniert hier aber auch nicht, und durch den LWP-Code wühle ich mich erst, wenn klar geworden ist, dass LWP::UserAgent absichtlich mit älteren Versionen bricht und die auch keinen "Kompatibilitätsmodus" oder so haben, mit dem man das alte Splitting wieder herstellen kann. Dann werde ich halt bis nach Geilenkirchen hörbar fluchend das alte Verhalten für meine lokale Kopie wiederherstellen.

Ach ja, nur der Vollständigkeit halber: ja, ich setze auch den HTTP-UserAgent auf den gleichen String wie in meinem Browser, und wenn ich Proxies zwingend deaktiviere, bekomme ich auch wieder 200, und ich sehe nicht, wie das ein Tor-Problem sein könnte, wenn's im Tor Browser tut. Und auf Tor würde ich ungerne verzichten, weil das Script nicht schnell arbeiten braucht und es die NSA ärgert.
Last edited: 2020-09-16 14:18:58 +0200 (CEST)
- +11 replies
- GwenDragon
  
  2020-09-16 17:54
  User since
  2005-01-17
  14533 Artikel
  Admin1
  Lass mal ausgeben was gesendet+empfangen wird.
  
  Ein anschauliches Beispiel:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
  
  use strict; use warnings; use 5.010; use LWP::UserAgent; my $request_uri = ''; my $ua = LWP::UserAgent->new; $ua->protocols_allowed( [ 'http', 'https' ] ); $ua->ssl_opts( verify_hostnames => 1 ); $ua->add_handler( "request_send", sub { shift->dump; return } ); $ua->add_handler( "response_done", sub { shift->dump; return } ); $ua->agent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.106 Safari/537.36"); $ua->proxy(['http', 'https'], 'http://localhost:8001/'); $request_uri = 'https://example.org/'; my $response = $ua->get($request_uri); print $response->decoded_content;
  
  Ist es so, dass TOR Proxy socks nutzt?
  Dann brauchste noch LWP::Protocol::socks.
  Und wohl eher:
  $ua->proxy([qw(http https)] => 'socks://localhost:9150');
  Last edited: 2020-09-16 18:08:42 +0200 (CEST)
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +9 replies
  - 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 )
    
    1 2 3 4 5 6 7 8
    
    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 )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
    
    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)
    - +7 replies
    - Gast whatever_u_want
      
      2020-09-16 23:24
      
      Ich habe jetzt noch mal eine Weile dran ohne Erfolg rumdebuggt. Wer's selbst ausprobieren möchte, der kann das hier gepostete Script verwenden; www.cloudflare.com scheint genau das von mir beobachtete Verhalten zu reproduzieren. Um den Proxy nutzen zu können, started man am Besten den Tor Browser und setzt den Port im Script entweder auf 9050 oder 9150 (je nachdem, wo der Service seinen Port öffnet). Mit der Proxy-Zeile bekommt man 403 Forbidden, ohne sie normale 200. Wenn man aber www.cloudflare.com im geöffneten Tor Browser öffnet, erscheint die Seite ohne Fehlermeldung.
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
      
      #!/usr/bin/perl use strict; use warnings; use LWP::UserAgent; use LWP::Protocol::socks; my $line = '='x80 . "\n"; my $ua = LWP::UserAgent->new(ssl_opts => {verify_hostname => 1}); $ua->timeout(60); $ua->proxy(['http','https'],'socks://127.0.0.1:9150/'); $ua->default_header('User-Agent' => 'Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0'); $ua->default_header('Accept' => 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'); $ua->default_header('Accept-Encoding' => 'gzip, deflate'); $ua->default_header('Accept-Language' => 'en-US,en;q=0.5'); $ua->default_header('Connection' => 'keep-alive'); $ua->default_header('Upgrade-Insecure-Requests' => '1'); $ua->default_header('Cache-Control' => 'no-cache'); $ua->default_header('Pragma' => 'no-cache'); $ua->add_handler( "request_send", sub {print $line;shift->dump; return } ); $ua->add_handler( "response_done", sub {print $line;shift->dump; return } ); my $response = $ua->get('https://www.cloudflare.com'); $response->{_content} = $response->decoded_content; print $line; print $response->{_request}->as_string,"\n\n"; print $line; print $response->as_string,"\n\n";
      
      Last edited: 2020-09-17 07:23:05 +0200 (CEST)
      - +5 replies
      - Gast whatever_u_want
        
        2020-09-18 04:08
        
        Ich habe eine gute und eine schlechte Nachricht. Die gute Nachricht ist, dass ich herausgefunden habe, was das Problem ist; die schlechte Nachricht ist, dass ich nicht öffentlich darüber reden kann als Teil eines Gentlemen-Agreements. Nur so viel:
        
        - es liegt NICHT an der HTTP-Version
        - es liegt NICHT an den Headern bis möglicherweise dem User-Agent, das habe ich nicht getestet
        - das Problem, und damit auch die Lösung, setzen bereits früher an
        
        Natürlich ist das nur der Ist-Zustand, den ich beschreiben kann, aber wenn sich nichts ändern und in der Zukunft auch andere Leute über das Problem stolpern sollten - es liegt nicht an HTTP.
        Last edited: 2020-09-18 07:40:20 +0200 (CEST)
        
        GwenDragon
        
        2020-09-18 11:08
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Guest whatever_u_want
        (…) die schlechte Nachricht ist, dass ich nicht öffentlich darüber reden kann als Teil eines Gentlemen-Agreements.
        Hört sich nach einer entdeckten Lücke/Bug an, die du nicht preisgeben darfst. OK, verständlich.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +2 replies
        
        GwenDragon
        
        2020-09-18 11:09
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Soll ich den Thread nun als gelöst markieren?
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        Gast whatever_u_want
        
        2020-09-18 14:12
        
        Ja, Thread kann geschlossen werden. Tut mir Leid für die Nachwelt, aber es ist besser so für menschliche Nutzer.
        Last edited: 2020-09-18 14:17:32 +0200 (CEST)
        
        gelöscht 2020-11-11 14:16
      - gelöscht 2020-11-11 14:16
    - gelöscht 2020-11-11 14:16
  - gelöscht 2020-11-11 14:16
- gelöscht 2020-11-11 14:16

View all threads created 2020-09-16 14:04.