Hallo Mathias,

Anscheinend interessieren wir uns momentan für die gleichen Threads quer durchs inzwischen ganz schön lange Forum !?

CK sei dank... Das neue Forum ist einfach genial, wenn man den Überblick behalten will.

Schönen Sonntag noch!

Ebenso. :)

Grüße,

Christian

Die Leute hier sind da, um dir zu helfen wenn du ein
Problem hast, nicht, daß du ihre Programmierarbeit
schlechtmachst. Und dann schreiben wieder andere was
über "gereizte Stimmung im Forum"!

Hallo Henner,

Welche Spezifikation soll denn das sein?

Ich dachte, das wäre die HTTP-Spezifikation (RFC 2616), aber da steht das tatsächlich nicht drinnen, unter Punkt 13.13 steht nur etwas, das dieses Verhalten durchaus zulässt, jedoch nicht impliziert.

Tja, dann habe ich mich wohl nicht geirrt.

Grüße,

Christian

Hallo Rolf,

auf der Indexseite meines Script-Bereiches habe ich einen Hinweis, dass die 'html-lib.pl' in fast allen meiner Scripts verwendet wird, die 'html-lib.pl' selbst ist auch im Index:

Ok, da steht es in der Tat.

Noch eine Frage: ist der Script sicher von Missbrauch? D.H. kann dieser Script dazu missbraucht werden, spam mails zu versenden?

Das von mir geschriebene Script *404.cgi* hat die folgende Aufgabe:

1. Einen Request auf eine nicht vorhandene Seite umleiten auf eine eigens definierte *Sorry-Seite*,

Verstehe ich nicht. Die .htaccess im document-root macht ja das selbe. ErrorDocument 404 http://i-netlab.de/404.html wozu ein umleitung über ein Script auf die 404 Datei?

2. Einen Request nach *regulären Ausdrücken* zu handlen,

Wie meinst du das?

3. Einen Request auf *bekannte CGI Scripts welche Sicherheitslücken haben* zu handlen...

Ok, ich habe jetzt bei dir nach http://i-netlab.de/cgi-bin/adsflkaksdhfljfdsfgg.cgi gesucht und die Warnung gesehen.
Aber was bringt mir dieses Feature? Ich kann im cgi-bin selbst ein .htaccess Datei anlegen und dort bestimmen woher Zugriffe erfolgen können und wenn jemand nach einem nichtexistenten script sucht, gilt eh 404 im root.
Außerdem wie soll dieser Script eventuelle Sicherheitslücken in anderen Scripten verhindern?

Die Definition der entsprechenden Kontrollstruktur steht jedem Nutzer frei der dieses Script einsetzt.

Rolf

=Beispiel 404.cgi Kontrollstruktur

das ist aber nicht das was du vorher verlink hast:
http://i-netlab.de/cgi-bin/split.cgi?404
und mir sagt das sowieso so gut wie nichts.

Grüße
Thomas

Moin!

Hmm, das ist wirklich mal was mit dem ich was anfangen kann. Denn: Ich hab nunmal das Problem dass einige meiner Seiten wech sind und Suchmaschinen diese Teile immer noch indizieren. Meine Frage vor einiger Zeit dazu *wie gebe ich einen 404 zurück und zeige meinem Besucher _gleichzeitig_ eine nette Seite ggf. mit Alternativen* ist hier in diesem Forum ohne Antwort geblieben...

Muss ich wohl übersehen haben.

Allerdings verweise ich in diesem Zusammenhang mal auf die Möglichkeiten der .htaccess-Datei und deren Möglichkeiten.

Mit der Direktive "Redirect" bzw. "RedirectMatch" hast du die Möglichkeit, Zugriffe auf gewisse URLs umzuleiten. RedirectMatch ist dabei recht mächtig, weil es mit regulären Ausdrücken arbeitet.

Ansonsten hast du natürlich auch immer die Möglichkeit, mit URL-Rewriting zu arbeiten.

Das W3C sagt übrigens dazu: "Cool URIs don't change". Soll heißen: Überlege dir ein _vernünftiges_ [1] URL-Schema, welches auch in 2, 20 oder 200 Jahren noch sinnvollen Zugriff auf alle deine Informationen bietet. Wie du dahinter deine Informationen organisierst, ist für den Benutzer vollkommen uninteressant. Das W3C hat sich in dieser Hinsicht eigentlich eine sehr vernünftiges Schema ausgedacht: www.w3.org/thema/unterthema/jahreszahl/dateiname. Gute Beispiele sind in [1] erwähnt.

Beachte auch, dass in einer guten URI _keine_ Hinweise auf die verwendeten Techniken vorkommen. ".html" ist fehl am Platze (was ist, wenn du auf XHTML wechselst? Alles umbenennen?). "cgi-bin" ist fehl am Platze (die CGI-Schnittstelle kann ja irgendwann mal durch etwas viel besseres ersetzt werden).

[1] http://www.w3.org/Provider/Style/URI.html

Wie auch immer, für meine Begriffe ist's ersteinmal wichtig dem Besucher einen entsprechenden Hinweis zu geben!

Diesem grundlegenen Gedanken dient letztendlich auch das Script
404.cgi, try this: http://i-netlab.de/scr or this:
http://i-netlab.de/down - stets landet der Besucher im meinem Downlaodbereich.

Naja, das ist nichts, was nicht per Redirect auch ginge. Warum du allerdings deine URLs geändert hast, ist die größere und interessantere Frage. Ohne Änderung würde die Notwendigkeit des CGI-Skriptes entfallen. Und außerdem mußt du natürlich dafür sorgen, die richtigen Status-Codes auszugeben. Wenn du Zugriffe auf /down umlenken willst, mußt du ein Redirect ausgeben (301 bzw. 302 - je nachdem. Ein permanenter Redirect ist sinnvoll - dann stellen auch Suchmaschinen ihren Index mal um). Wenn du hingegen nichts passendes findest, mußt du Status 404 ausgeben. Das gilt auch für deine Angriffsseite.

Wehe dem jedoch der
http://i-netlab.de/cgi-bin/formmail.pl versucht! Das ist ein Request auf ein Script was *offiziell* dafür bekannt ist dass Sicherheitslücken aufweist (siehe xwolf - Liste) und einem solchen Request begegnet das Script 404.cgi entsprechend (Hinweis auf rechtliche Schritte, Mail an Webmaster...).

Naja, da schießt du doch etwas mit Kanonen auf Spatzen. Nicht jeder, der /cgi-bin/formmail.pl auf deinem Server erreichen will, ist dafür auch selbst verantwortlich, und nicht jedes Programm, was formmail.pl heißt, muß von Matt Wright kommen und Sicherheitslücken aufweisen. Ein schlichter 404-Status "Nicht gefunden" und ein aufmerksames Lesen der Logfiles sollten doch ausreichen. Wenn nämlich kein formmail.pl existiert, dann kann man es nicht hacken. Wo ist das Problem? Auch ein Portscan ist kein Angriff. Ich würde es mit "Angucken eines Hauses, ob es Türen oder Fenster hat" vergleichen. Wenn du nicht willst, dass dein Haus gesehen wird, sorge für dauerhafte Dunkelheit, oder tarne Türen und Fenster als Mauer.

Gerne stellte ich diesen Artikel auch SELF*:TIPPS&TRICKS zur Verfügung. Aber nicht unter den Bedingungen die ich bisher vorfand.

Nimm eine der bestehenden Tipps&Tricks-Seiten, lösche den alten Inhalt, füge den neuen Inhalt ein, und maile diese Seite an Mathias Bigge (der hat die zentrale Verwaltung für T&T-Artikel). Das ist das, was mir als Lösungsmöglichkeit dazu einfällt.

In der Hoffnung dass sich das ändert ;-)

Wenn wir dir Opera zwangsinstalliert hätten, würdest du doch sicherlich auch meckern, oder? :)

- Sven Rautenberg

Moin!

Hallo Sven,

Vom IE und Mozilla/Netscape (egal welche Version) kann man
das leider nicht sagen - die rufen beim "Zurück" in der
Regel die Seite neu vom Server ab, und in dieser Seite
fehlen natürlich deine Eingaben.

Das ist inkorrekt. Mozilla nimmt, wenn ein Cache-Header
geschickt wurde, die Seiten solange aus dem Cache, wie er
darf. Wurde keiner geschickt, schickt er ein conditional get.

Ja, aber das ist das Problem: Er nimmt sie aus dem _Cache_, wenn er darf, ansonsten fordert er sie neu an. So schlau ist der IE sicher auch. Der History-Mechanismus erlaubt aber keinen Zugriff auf den Cache oder Neuanforderung, sofern der User das nicht konfiguriert hat:

"User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents."
(Quelle: RFC 1945, Abschnitt 10.7 "Expires")

Das bedeutet ganz schlicht und einfach, dass der User-Agent beim Navigieren mit Back- und Forward-Funktionen die Seite nicht neu zu laden hat - egal ob sie mittlerweile ungültig geworden ist oder nicht.

"An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for explanation of the difference between caches and history mechanisms."
(Quelle: RFC 2068, Abschnitt 13.2.1. "Server-Specified Expiration")
sowie
"History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."
(Quelle: RFC 2068, Abschnitt 13.13. "History Lists")
sind in dieser Hinsicht absolut unmißverständlich.

Wo der Browser den mit History-Funktion angeforderten letztgesehenen Zustand wieder herholt, ist den Browserprogrammierern überlassen - das darf auch der Cache sein, wenn sichergestellt ist, dass die History-Funktion ordnungsgemäß funktioniert. Denn ein mögliches Szenario wäre ja, dass in einem Browserfenster eine alte Version der Ressource mittels History angesteuert wird, während in einem anderen Fenster zuvor die aktuelle Version der Ressource vom Server geladen wurde. Und da sich Ressourcen durchaus bei zwei Requests unterschiedlich darstellen können (auch hier im Forum ist das so: Wenn z.B. ein Beitrag archiviert ist, kriegt man eine Fehlermeldung - mit History muß man ihn aber immer noch erreichen können, wenn man ihn in dieser Browsersession schon mal gesehen hat und er mit "Back" und/oder "Forward" noch erreichbar ist), kann man den Cache eigentlich nicht als Datenquelle für die History verwenden.

- Sven Rautenberg