Requests: HTTPoxy-Migration

Erstellt am 18. Juli 2016  ·  4Kommentare  ·  Quelle: psf/requests

https://httpoxy.org/

Es ist möglich, HTTP_PROXY in CGI-Skripten zu setzen, indem der Header Proxy übergeben wird. Wenn das Skript Anfragen zum Herunterladen von Dateien verwendet, verwenden Anfragen gerne den vom Angreifer bereitgestellten Proxy, um Anfragen zu stellen.

Dies sollte wie in Perl (seit 2001), Ruby und Bibliotheken wie curl gemildert werden.

Ich habe bestätigt, dass HTTP_PROXY (in Großbuchstaben) ebenso akzeptiert wird wie die konventionellen Kleinbuchstaben http_proxy (Anfragen 2.7.0)

Hilfreichster Kommentar

Wir haben das ausführlich im IRC diskutiert. Wir haben hier eine komplexe Reihe von Meinungen, aber hier sind sie:

  1. Wenn Sie Ihr Requests-Skript an einem Ort ausführen, an dem Ihre Anwendung Schreibzugriffe auf die Umgebung zulässt, sollten Sie im Allgemeinen die Suche der Umgebung durch Requests deaktivieren. Dafür haben wir ein Flag: Session.trust_env . Wenn Sie es vollständig auf False setzen, wird dieses Risiko vollständig gemindert.
  2. CGI ist ein _extrem_ ungewöhnlicher Modus zum Ausführen von Python-Code. Es ist erstaunlich ineffizient, und soweit ich weiß, werden im Wesentlichen keine Python-Anwendungen damit entwickelt.
  3. Unsere Suche nach Proxys wird tatsächlich von der Python-Standardbibliothek durchgeführt. Dies bedeutet, dass sich die effizientere Lösung in der Python-Standardbibliothek selbst befindet, wodurch das Problem nicht nur für Anfragen, sondern für alle anderen Clients in der Python-Standardbibliothek gemildert werden kann.

Ich bin bereit, die Möglichkeit in Betracht zu ziehen, Warnungen auszulösen, wenn Anfragen innerhalb eines CGI-Prozesses mit trust_env=True ausgeführt werden, und ich bin sogar bereit, die Möglichkeit in Betracht zu ziehen, trust_env in False zu zwingen in einer solchen Situation, aber realistischerweise für Python-Code ist die richtige Lösung dafür einfach, _Ihre Anwendungen nicht innerhalb von CGI auszuführen_.

Alle 4 Kommentare

Wir haben das ausführlich im IRC diskutiert. Wir haben hier eine komplexe Reihe von Meinungen, aber hier sind sie:

  1. Wenn Sie Ihr Requests-Skript an einem Ort ausführen, an dem Ihre Anwendung Schreibzugriffe auf die Umgebung zulässt, sollten Sie im Allgemeinen die Suche der Umgebung durch Requests deaktivieren. Dafür haben wir ein Flag: Session.trust_env . Wenn Sie es vollständig auf False setzen, wird dieses Risiko vollständig gemindert.
  2. CGI ist ein _extrem_ ungewöhnlicher Modus zum Ausführen von Python-Code. Es ist erstaunlich ineffizient, und soweit ich weiß, werden im Wesentlichen keine Python-Anwendungen damit entwickelt.
  3. Unsere Suche nach Proxys wird tatsächlich von der Python-Standardbibliothek durchgeführt. Dies bedeutet, dass sich die effizientere Lösung in der Python-Standardbibliothek selbst befindet, wodurch das Problem nicht nur für Anfragen, sondern für alle anderen Clients in der Python-Standardbibliothek gemildert werden kann.

Ich bin bereit, die Möglichkeit in Betracht zu ziehen, Warnungen auszulösen, wenn Anfragen innerhalb eines CGI-Prozesses mit trust_env=True ausgeführt werden, und ich bin sogar bereit, die Möglichkeit in Betracht zu ziehen, trust_env in False zu zwingen in einer solchen Situation, aber realistischerweise für Python-Code ist die richtige Lösung dafür einfach, _Ihre Anwendungen nicht innerhalb von CGI auszuführen_.

Für mich ergibt das Sinn. Das Vermeiden von HTTP_PROXY (Großbuchstaben) in einem CGI-Kontext wäre wahrscheinlich ein guter Schachzug, aber wenn Anfragen dies nicht direkt tun, macht es wahrscheinlich keinen Sinn, aktive Maßnahmen zu ergreifen. Ich selbst benutze immer nur wsgi. Ich werde weitermachen und das hier schließen.

@remram44 Für das, was es wert ist, würde ich _herzlich_ einen Patch für die getproxies -Methode des urllib.request -Moduls der stdlib unterstützen, um diese Art der Überprüfung zu implementieren. Das scheint ein viel produktiverer Ort zu sein, um den Patch zu platzieren. =) Wenn Sie dafür einen Fehlerbericht eröffnen möchten, melde ich mich gerne: Ich melde mich sogar freiwillig, um den Patch selbst zu schreiben!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen