ABAKUS

das problem hatte ich hier auch vor einiger zeit mal angesprochen, allerdings keine hilfreiche antwort bekommen. suche mal nach inurl:evilaliv3.org , da siehst du noch andere seiten die betroffen sind (so ab seite 5, nach all den "was ist meine seite wert" dingern fuer evilaliv3).
auf der seite evilaliv3.org selbst findest du ein paar hintergrundinfos zu dem problem, ist wohl eine schwachstelle in verschiedenen webservern die sa ausgenutzt wird. in dem aktuellen apache installationen ist es aber inzwischen behoben.

nerd hat geschrieben:ist wohl eine schwachstelle in verschiedenen webservern die sa ausgenutzt wird. in dem aktuellen apache installationen ist es aber inzwischen behoben.

Könntest du das präzisieren? Wenn jemand ein PHP-Skript mit dem Parameter show=URL aufruft, hat das IMHO eindeutig nichts mit dem Webserver zu tun, sondern mit dem PHP-Skript, dass sich auf diese Weise dazu verleiten lässt, besagte URL anzuzeigen.

Sowas ist überaus praktisch, um vertrauenswürde URLs zu basteln, mit denen der unbedarfte Besucher auf irgendeiner Pöse-Puben-Seite landet, idealerweise zum Beispiel grossedeutschesparbank.de/index.php?bla=fasel;dings=bums;show=boeseseite.de

holgerbauer hat geschrieben:Ich finde im index hunderte solcher urls:
www.meinedomain.com/index.php?show=http ... ddomain.or
g.au/se.txt???
[…]
301-weiterleitung zur indexseite sollte das problem gelöst sein
[…]
oder sollte man da eine andere problemlösung umsetzten ???

Letzteres, und zwar unbedingt, aus eben genanntem Grund. Dabei geht es nicht darum, dass deine Seite wohl nicht anfällig ist, sondern schlicht ums Prinzip.

Handelt es sich nur um URLs mit /index.php oder sind da noch andere betroffen? Hast du die index.php selbst gezimmert? Falls ja und ja, wäre es naheliegend, die entsprechende Problemlösung in der index.php unterzubringen.

siehe hier: https://www.evilaliv3.org/advisories/nginx/0.7.64/ - es hat nichts mit den php scripten zu tun die darauf laufen.

nerd hat geschrieben:siehe hier: https://www.evilaliv3.org/advisories/nginx/0.7.64/ - es hat nichts mit den php-scripten zu tun, die darauf laufen.

Richtig, das hat nichts mit PHP-Skripten zu tun. Deshalb wundert es mich, dass du das hier anführst. Du hast dir das schon durchgelesen und nicht nur irgendwas von „Webserver“ gesehen und gedacht, das müsse passen? „Nginx, Varnish, Cherokee, thttpd, mini-httpd, WEBrick, Orion, AOLserver, Yaws and Boa log escape sequence injection“ heißt es da.

in dem aktuellen apache installationen ist es aber inzwischen behoben.

Von Apache ist nur in einer Randbemerkung bezüglich zweier Uraltversionen die Rede und vor allem sieht eine „escape sequence injection“, wie auf der Seite beschrieben, so /%1b%5d%32%3b%6f%77%6e%65%64%07%0a oder so /\x1b]2;owned?\x07\x0a\x0d\x0a\x0d aus, nicht wie in der Frage, so /index.php?show=https://www.fasel.bla.
Es geht um „escape sequences“, das sind Byteketten, beginnend mit dem Escape-Zeichen \x1b, die zur Terminalsteuerung dienen; einfache Dinge wie fette ode kursive Schrift, aber auch Cursorbewegungen und mehr – in den Beispielen verwenden die Scherzkekse zusätzlich am Ende \x07, das ist quasi die Druckerklingel (als Drucker noch Klingeln hatten). Diese Bytes landen bei den betroffenen Webservern ungefiltert im Zugriffsprotokoll (log escape sequence injection) und sorgten dann für lustige Effekte bei denjenigen, die sich ihr Protokoll am Terminal angeschaut haben.

Kurzum: Das hat nichts mit dem angefragten Problem zu tun.

ich bin jetzt so schlau wie vorher auch, jedoch das problem besteht immer noch, wie würde der code für eine passendene 301 weiterleitung für dieses problem aussehen ?

Eine Weiterleitungmag zwar helfen, denoch ist der alte Mist dann immer noch im Index. Zumindest erstmal. Das ist viel schlimmer.

holgerbauer hat geschrieben:ich bin jetzt so schlau wie vorher auch

Mork vom Ork hat geschrieben:Handelt es sich nur um URLs mit /index.php oder sind da noch andere betroffen? Hast du die index.php selbst gezimmert? Falls ja und ja, wäre es naheliegend, die entsprechende Problemlösung in der index.php unterzubringen.

Kann man für solche tollen "Links" nicht ne seite basteln mit noinde, nofollow und von da dann auf die Index (link, js oder oder).

Somit müsste der "alte" mist doch aus den Serps kommen

es handelt sich leider um ca. 500 solcher tollen links

Mork vom Ork hat geschrieben: Richtig, das hat nichts mit PHP-Skripten zu tun. Deshalb wundert es mich, dass du das hier anführst. Du hast dir das schon durchgelesen und nicht nur irgendwas von „Webserver“ gesehen und gedacht, das müsse passen? „Nginx, Varnish, Cherokee, thttpd, mini-httpd, WEBrick, Orion, AOLserver, Yaws and Boa log escape sequence injection“ heißt es da.
Kurzum: Das hat nichts mit dem angefragten Problem zu tun.

vielleicht passt der artikel nicht genau zu dem problem, wenn du dich auf der seite unter https://www.evilaliv3.org/advisories/ weiter umschaust findest du aber noch andere beschreibungen von schwachstellen in diversen webservern. als ich damals geschaut habe woher der parameter q=http://... an meiner index.php kommt, habe ich jedenfalls einige referenzen gefunden die das sagen das das problem auf evilaliv3 beschrieben ist.

nerd hat geschrieben:noch andere beschreibungen von schwachstellen in diversen webservern
[…]
als ich damals geschaut habe woher der parameter q=http://... an meiner index.php kommt, habe ich jedenfalls einige referenzen gefunden die das sagen das das problem auf evilaliv3 beschrieben ist.

Es mag sein, dass das Problem da irgendwo beschrieben ist, aber der Artikel, den du genannt hast, war's definitiv nicht und ich möchte dir auch garantieren, dass das weder eine Apache- (nicht einmal eine Webserver-), noch eine PHP-Schwachstelle ist, sondern sich alleine auf ein Skript oder, am wahrscheinlichsten, eine Programmiermethode bezieht – wenn's denn überhaupt eine Schwachstelle ist.
Am Ende könnte es auch ein Programmierfehler seitens Holger sein, denn dass die /index.php gleich mit 500 verschiedenen URLs als Parameter aufgerufen wird, kommt mir merkwürdig vor (ein einzelner Test reicht doch, um herauszufinden, ob er angreifbar ist), auch, dass diese falschen Seiten überhaupt in Googles Index sind, sie müssen also auf irgendeiner Webseite genannt sein (braucht kein Hacker). Und er verrät ja trotz zweimaliger Nachfrage nichts über den Inhalt seiner index.php.