Was bedeutet "HTTPRequestParser"? wie am Zugriff hindern?

[Juergen]

Ich sehe in meinen Logs vermehrt Zugriffe wie folgenden

"GET /\r HTTP/1.1"

Geht mit 200 OK durch, aufgrund der gelieferten Bytes wird die erste
(Haupt-) Seite geliefert.

Was bedeutet das aber? Was wird da probiert?

Bei Google hab ich nur 2 Treffer weltweit gefunden (code.google.com), wo
Code zu
TEST_SUITE(HTTPRequestParser)
veröffentlicht wird und darin sich auch voriger GET wiederfindet.

Von dem Code hab ich nix verstanden, möchte aber solche Zugriffe
blocken, bisherige Versuche via .htaccess haben nicht gewirkt, z.B.
versucht mit

RewriteCond %{THE_REQUEST} ^GET./\\

zeigt keine Wirkung, neuer Zugriff ging wieder mit 200 OK durch :-(
Vielleicht macht der Apache beim Zugriff aus "\r" einen "echten" Return,
dann kann ich solche Dinge ja überhaupt nicht verhindern, oder?

Wer hat ne Idee?
Ich weiss nicht mal, was der Apache bei meinem Provider bei einem
solchen Zugriff macht. Emails an meinen Provider (sogar an Abuse wegen
möglicher Sicherheitslöcher) wurden nicht beantwortet :-(

Ja, ich weiss. bei einmaleins bekomm ich das, was ich bezahle, aber
bislang bekomme ich die Logdateien zu sehen (ohne Errorlog), auch wenn
ich bislang nicht alle "komischen" Zugriffe nach meinen Wünschen
geblockt bekomme (das meiste klappt aber schon).

Jürgen

[Thomas Braun]

Juergen wrote:

> Ich sehe in meinen Logs vermehrt Zugriffe wie folgenden
>
> "GET /\r HTTP/1.1"

Das ist keine vollständige Logzeile, wie soll da irgendjemand was rauslesen
können?

> Was bedeutet das aber? Was wird da probiert?

Jemand/etwas schaut sich deine Webseite an - dafür hast du sie gemacht,
oder nicht?

> RewriteCond %{THE_REQUEST} ^GET./\\

Ohne eine darauf folgende RewriteRule passiert hier nix.

Meiner Ansicht nach siehst du Probleme wo keine sind.

[Holger Jeromin]

Thomas Braun schrieb am 06.03.2012 09:10:
> Juergen wrote:
>> Ich sehe in meinen Logs vermehrt Zugriffe wie folgenden
>> "GET /\r HTTP/1.1"
> Das ist keine vollständige Logzeile, wie soll da irgendjemand was rauslesen
> können?
>
>> Was bedeutet das aber? Was wird da probiert?
> Jemand/etwas schaut sich deine Webseite an - dafür hast du sie gemacht,
> oder nicht?

HTTP schreibt "GET / HTTP/1.1" fest, und nicht "GET /\r HTTP/1.1". Den
Unterschied hab ich auch erst spät gesehen.

--
Grüße
Holger Jeromin

[Juergen]

Am 06.03.2012 09:10, schrieb Thomas Braun:

> Juergen wrote:
>> "GET /\r HTTP/1.1"
>
> Das ist keine vollständige Logzeile, wie soll da irgendjemand was rauslesen
> können?

ok, hier die ganze Zeile aus dem Log, nur etwas anonymisiert

IP - - [Datum, Zeit] "GET /\r HTTP/1.1" 200 999 www.#meineseite#.de
"http://www.#refererseite#.si/" "#referer Network# (<a
rel=\"index,follow\" href=\"http://www.#refererseite#.si/\">Do
follow</a>)" "-"

anstelle
- IP stand da natürlich eine rückverfolgbare IP
- "999" = hier war Anzahl Bytes, die meiner Seite entsprechen
- #meineseite# = meine Domain (-teil)
- #refererseite# = reale Domain
- #referer Network# = dort war auch der Domainteil wie refererseite
alle anderen Zeichen identisch aus der Logdatei kopiert.

> Jemand/etwas schaut sich deine Webseite an - dafür hast du sie gemacht,
> oder nicht?

Hmm, ja, gegen das Anschauen habe ich nichts, nur vorstehende im Log
"dokumentierte" Zugriffsvariante ist nicht so ganz "normal", d.h. nicht
so ganz koscher. Wenn dieses "\r" in Wirklichkeit ein "Return" ist (was
es laut regexp sein dürfte), was macht der Apache damit, _bevor_ er
"HTTP/1.1" bekommt?
Ich hab leider keinen Apache und auch nicht das nötige Wissen dazu...
trotz bereits stundenlangem Lesen ;-/

Eine Zeile in der Logdatei spiegelt scheinbar nicht _genau_ die
HTTP-Zugriffe wider, die in Wirklichkeit zu einem Request beim Apache
(den einmaleins wohl verwendet) ankommen. Ein "Return" innerhalb eines
Requests dürfte in der Logdatei kaum anders darstellbar sein, so mein
Gedanke.

>> RewriteCond %{THE_REQUEST} ^GET./\\
>
> Ohne eine darauf folgende RewriteRule passiert hier nix.

Natürlich <gr> steht danach noch
RewriteRule ^.*$ - [F]

Ich habe inzwischen doch etwas gefunden, was dahinter stecken könnte...
http://www.apacheweek.com/issues/03-01-24
Cross-Site Tracing issues

nur... verstanden hab ich das Ganze nicht so richtig, ausser, dass man
mit dieser "Methode" eventuell Webseiten (bzw. aufrufende Browser)
missbrauchen kann.

Dort stand dann auch ein Hinweis, wie ich diese Requests "unterbinden" kann
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

Hab ich gemacht, zumindest wird das beim Hochladen meiner htaccess
akzeptiert und ergibt keinen 500 ;-) Ob der Eintrag erfolgreich ist,
muss sich zeigen.

Nochmal zu
"GET /\r HTTP/1.1"
Wie müsste die htaccess-Direktive aussehen, die das vergleichen kann
(bzw. was der Apache damit/daraus macht bzw. gemacht hat)?
Wenn ich in der htaccess eintrage
RewriteCond %{THE_REQUEST} ^GET./\r

weiss der Apache dann, was _ich_ möchte? Ich hab irgendwo auch was
aufgeschnappt, dass der erste "/" beim RewriteCond entfallen müsste.
Ich hatte auch etliche Zugriffe beginnend mit
GET //
Was muss ich dafür in der htaccess eintragen
a) RewriteCond %{THE_REQUEST} ^GET.//
oder
b) RewriteCond %{THE_REQUEST} ^GET./

und ein Eintrag laut a) hat nicht gegriffen :-(
(ich weiss, statt "." wäre "\." sicherer)

Jürgen

[Thomas Braun]

Juergen wrote:

> IP - - [Datum, Zeit] "GET /\r HTTP/1.1" 200 999 www.#meineseite#.de
> "http://www.#refererseite#.si/" "#referer Network# (<a
> rel=\"index,follow\" href=\"http://www.#refererseite#.si/\">Do
> follow</a>)" "-"
>

[...]

> Ich habe inzwischen doch etwas gefunden, was dahinter stecken könnte...
> http://www.apacheweek.com/issues/03-01-24
> Cross-Site Tracing issues

Öhhmmm... dein Request ist aber GET, nicht TRACE!

Dein Logeintrag von oben würde dann so aussehen:

IP - - [Datum, Zeit] "TRACE /\r HTTP/1.1" 200 999 www.#meineseite#.de

> Hab ich gemacht, zumindest wird das beim Hochladen meiner htaccess
> akzeptiert und ergibt keinen 500 ;-) Ob der Eintrag erfolgreich ist,
> muss sich zeigen.

Schadet zumindest nicht, nützt aber für diesen Fall auch nix. :-)

> Nochmal zu
> "GET /\r HTTP/1.1"
> Wie müsste die htaccess-Direktive aussehen, die das vergleichen kann

Gute Frage.

> (bzw. was der Apache damit/daraus macht bzw. gemacht hat)?
> Wenn ich in der htaccess eintrage
> RewriteCond %{THE_REQUEST} ^GET./\r

Das *müßte* meiner Ansicht nach gehen.

Thomas

[Juergen]

Am 08.03.2012 09:26, schrieb Thomas Braun:
> Juergen wrote:

danke für die Erläuterungen.

>> Ich habe inzwischen doch etwas gefunden, was dahinter stecken könnte...
>> http://www.apacheweek.com/issues/03-01-24
>> Cross-Site Tracing issues

> Öhhmmm... dein Request ist aber GET, nicht TRACE!

Ja, du hast recht, aber im Text bei apacheweek steht u.a.
| Cross-Site Tracing issues
| Earlier this week a paper was published, "Cross-Site Tracing"
| which gave details of how the TRACE HTTP request could be used
| in Cross-Site Scripting attacks. ...

Hört sich für mich alles noch etwas "nebulös" an, aber ich bin auch dem
Sinn und Zweck des speziellen GET noch nicht auf den Grund gekommen.

> Dein Logeintrag von oben würde dann so aussehen:
> IP - - [Datum, Zeit] "TRACE /\r HTTP/1.1" 200 999 www.#meineseite#.de

Wenn dem so wäre, würde _mich_ wieder "/\r" stören, weil ungewöhnlich.

Die angegebene Fundstelle bei Google
http://code.google.com/p/yield/source/browse/test/yield/http/http_request_parser_test.cpp?spec=svn66bb6f0274d8502ded0483da70864d88aef245bc&r=15495b7640fa4668996ee2b7bbb3e7b9f601a8bf

beschreibt u.a. einige Zeilen zu "TEST_SUITE(HTTPRequestParser);", was
ich aber nicht mal im Ansatz verstanden habe:

| TEST(HTTPRequestParser, MalformedHTTPVersionMissingHTTP)
| HTTPRequestParser http_request_parser("GET /\r\nHost: localhost\r
| \n\r\n");

| TEST(HTTPRequestParser, MalformedURIEmbeddedLF) {
| HTTPRequestParser http_request_parser("GET /\r HTTP/1.1\r\nHost:
| localhost\r\n\r\n");

genau da findet sich mein "GET /\r" wieder. Vermutlich ist das eine
offline-Suite, um HTTP-Requests zu testen (oder aber ein Hilfsmittel für
"richtige" Webserver-Verantwortliche).

Warum akzeptiert der Apache überhaupt einen Request "GET /\r HTTP/1.1"?

Gibts noch ne andere Gruppe, wo Apache ein Thema ist?

Werd auch prüfen, ob ich ein Apache-Forum finde, wo meine Frage ontopic
ist und schon "ähnliche" Fragen gestellt wurden. Ich hab da irgendein
komisches Gefühl in der Magengegend. Hast du einen Tipp für mich?

Inzwischen auch etwas gefunden, was nicht ganz mein Thema trifft:
> CVE-2006-2769
> Summary: The HTTP Inspect preprocessor (http_inspect) in Snort 2.4.0
> through 2.4.4 allows remote attackers to bypass
> "uricontent" rules via a carriage return (\r) after the URL and
> before the HTTP declaration.
> Published: 06/02/2006
> CVSS Severity: 5.0 (MEDIUM)

und noch was gefunden, ob noch aktuell, weiss ich nicht ;-)
http://www.faqs.org/rfcs/rfc2616.html (HTTP)
| 5.1 Request-Line
| The Request-Line begins with a method token, followed by the
| Request-URI and the protocol version, and ending with CRLF. The
| elements are separated by SP characters. No CR or LF is allowed
| except in the final CRLF sequence.
| Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Da ist keine Rede von CR nach Method.

Jürgen

[Juergen]

Am 08.03.2012 09:26, schrieb Thomas Braun:

> Juergen wrote:
>> > IP - - [Datum, Zeit] "GET /\r HTTP/1.1"

ich nochmal...

Gefunden bei
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
| Jim Manico 2008-06-11 17:36:39 UTC
| It is actually quite illegal to have \r (carriage return) \n (newline)
inside
| of a HTTP 1.1 Header Value. If any HTTP server allows CLRF inside of a
header
| value, it can and will lead to HTTP Response Splitting Attacks.
| http://en.wikipedia.org/wiki/HTTP_response_splitting

http://en.wikipedia.org/wiki/HTTP_response_splitting
Auszug daraus
| HTTP response splitting is a form of web application vulnerability,
| resulting from the failure of the application or its environment
| to properly sanitize input values. It can be used to perform
| cross-site scripting attacks, cross-user defacement,
| web cache poisoning, and similar exploits.

Mir ist vorhin wieder der Name eines 1&1-Mitarbeiters eingefallen, der
mir mal sehr gut beim Aufbau und Verständnis der htaccess vor Jahren (!)
geholfen hatte ;-)

Ich habe ihm mal eine Nachricht zukommen lassen, vielleicht liest er sie
und kann mit seinem Wissen etwas Licht in mein Dunkel bringen.

Jürgen

[Peter J. Holzer]

On 2012-03-08 17:11, Juergen <mac...@arcor.de> wrote:
> Hört sich für mich alles noch etwas "nebulös" an, aber ich bin auch dem
> Sinn und Zweck des speziellen GET noch nicht auf den Grund gekommen.

Es könnte sein, dass das \r den Zweck hat, einen Bug in bestimmten
Webservern zu triggern oder Intrusion Detection Systeme zu verwirren
oder ähnliches.

Es kann aber aber auch sein, dass das \r gar keinen Zweck hat, sondern
schlicht ein Fehler des Senders (triviales Beispiel, wie sowas passieren
kann: Liste von URLs ist in File mit CRLF-Zeilentrennern gespeichert,
das unter Unix gelesen wird).

> Warum akzeptiert der Apache überhaupt einen Request "GET /\r HTTP/1.1"?

"Be liberal in what you accept". Apache (2.2) akzeptiert statt der
einzelnen Spaces als Trennzeichen zwischen Methode, URI und Protokoll
beliebige Folgen von Whitespace. Du kannst also

GET <tab><tab> / <tab><cr> HTTP/1.1

als als Request-Line schicken und Apache wird das genau gleich wie

GET / HTTP/1.1

behandeln und die Resource / ausliefern.

IMHO wäre es sinnvoller, wenn Apache hier mit "400 Bad Request"
antworten würde, aber solche Fehlerkorrekturen sind nicht verboten und
habe eine lange Tradition in Internet-Protokollen.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Juergen]

Am 10.03.2012 20:40, schrieb Peter J. Holzer:

> Es kann aber aber auch sein, dass das \r gar keinen Zweck hat, sondern
> schlicht ein Fehler des Senders (triviales Beispiel, wie sowas passieren
> kann: Liste von URLs ist in File mit CRLF-Zeilentrennern gespeichert,
> das unter Unix gelesen wird).

danke, hast recht, daran hatte ich auch zunächst gedacht, nur... vom
gleichen .si-hoster kamen über verschiedene IPs gleiche Aufrufe, da denk
ich dann eher an Lückensucher.

>> Warum akzeptiert der Apache überhaupt einen Request "GET /\r HTTP/1.1"?
>
> "Be liberal in what you accept".

Ok, das ist eine Erklärung, wenngleich aus meiner Sicht etwas
"gefährlich", weil dadurch Otto-Normalo-Domainbesitzer wie ich nicht so
richtig weiss, was der Apache dem remoteHost liefert und ich im Log die
Aufrufe bestaune.

> GET<tab><tab> /<tab><cr> HTTP/1.1
> als Request-Line schicken und Apache wird das genau gleich wie
> GET / HTTP/1.1
> behandeln und die Resource / ausliefern.

weia. Wenn ich dann via htaccess einiges um-/weiterleiten würde (hab ich
nicht drin), könnte ich sicher unbewusst einige "Dummheiten" machen.

> IMHO wäre es sinnvoller, wenn Apache hier mit "400 Bad Request"

Ja, an sowas hab ich bislang auch gedacht, und zwar ohne dass ich
irgendwas in der htaccess _selber_ stricken muss.

danke nochmal
Jürgen

[Peter J. Holzer]

Ich glaube nicht, dass Du da im htaccess noch was stricken kannst. Der
Request wurde da bereits geparst, und Du hast nur mehr die Information,
dass der Client die Resource "/" möchte - dass in dem Request ein paar
überflüssige Whitespace-Zeichen enthalten waren, weißt Du nicht.

Wahrscheinlich könnte man ein Modul schreiben, das an passender Stelle
in den Parser eingreift. Aber ehrlich gesagt sehe ich den Sinn nicht so
ganz.

[Thomas Braun]

Juergen wrote:

> Ok, das ist eine Erklärung, wenngleich aus meiner Sicht etwas
> "gefährlich", weil dadurch Otto-Normalo-Domainbesitzer wie ich nicht so
> richtig weiss, was der Apache dem remoteHost liefert und ich im Log die
> Aufrufe bestaune.

Als "normaler" Benutzer mußt du erstmal davon ausgehen das die Entwickler
des Apachen wissen was sie tun - die Alternative dazu ist Programmieren zu
lernen um den Apache-Code zu verstehen und rauszufinden was in dem
konkreten Fall passiert.

Ehrlich, *ich* kenne keinen der das gemacht hat :-)

Thomas

[Juergen]

Am 12.03.2012 08:51, schrieb Thomas Braun:

> Als "normaler" Benutzer mußt du erstmal davon ausgehen das die Entwickler
> des Apachen wissen was sie tun

Nein ;-)
Ich war mal Entwickler auf Grossrechner und weiss daher, dass Entwickler
häufig _nicht_ wissen, was sie tun bzw. nicht zu Ende denken. Warum gibt
es immer wieder sog. "Löcher", die gestopft werden müssen? Sei es beim
Apache oder bei M$.

> - die Alternative dazu ist Programmieren zu
> lernen um den Apache-Code zu verstehen und rauszufinden was in dem
> konkreten Fall passiert.
>
> Ehrlich, *ich* kenne keinen der das gemacht hat :-)

Ich glaub schon, dass es ne Menge Leute gibt (sog. oder auch "Hacker"),
die genau das machen. _Ich_ werde das nicht tun, darum hab ich meine
Fragen gestellt, die ich nach stundenlangem Lesen von Apache- und
HTTP-Lektüre nicht beantwortet fand. Und laut RFC dürfen so manche Dinge
nicht sein, nur sorgt keine Software für deren Einhaltung.

Es wäre doch so einfach, wenn ein Webserver nur "zulässige" Aufrufe
akzeptieren würde (als _erste_ Software die mit HTTP aufgerufen wird),
dann bräuchte nicht _jeder_ Software-Entwickler, der auf dem Webserver
"aufsetzt", alle Zulässigkeitsprüfungen für HTTP machen.

Mittlerweile hab ich per Email sehr aufschlussreiche Hinweise erhalten,
u.a. auf eine bekannte Sicherheitsluecke in awstatstotals.php
(CVE-2008-3922), die vermutlich bei meinen "komischen" Aufrufen auch
"überprüft" wurde ;-)

siehe auch
http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-AWStats-Totals-200125.html

Wie Peter schrieb "Be liberal in what you accept" oder auch
Jon Postal "be conservative in what you do, be liberal in what you
accept from others" (RFC 761), wie mir geschrieben wurde.

Also bestehen für _mich_ (!) HTTP und Apache (bzw. Webserver allgemein?)
eigentlich nur aus mehr oder weniger grossen Löchern. Zu meiner
Entwicklerzeit hab ich es zwar auch wie Jon Postal gehalten, aber...
dennoch die Schotten dicht gemacht und kaputte Aufrufe nicht
weitergereicht an "andere" Software. Aber da das "Internet" aus dem
ARPAnet hervorgegangen ist, verstehe ich immer mehr, warum solche Löcher
drin sind und drin bleiben ;-) (oder auch neue eingebaut werden)

Jürgen

[Thomas Braun]

Juergen wrote:

> Am 12.03.2012 08:51, schrieb Thomas Braun:
>
>> Als "normaler" Benutzer mußt du erstmal davon ausgehen das die Entwickler
>> des Apachen wissen was sie tun
>
> Nein ;-)
> Ich war mal Entwickler auf Grossrechner

Dann fällst du aus der "Nomaler Benutzer"-Kategorie schon raus. :-)