• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

[apache] Bei Zeichenkette "fetch " im Formular -> 403

jeko

Lounge-Member
Hallo zusammen,

Ich bin mal wieder verzweifelt, hilflos, deprimiert etc., und so weiter.

Ich habe ein simples Formular:
HTML:
<form action="bug_fetch.php" method="post">
        <p>Enter text: </p>
        <textarea name="text"></textarea>
        <p><input type="submit" value="Send" /></p>
</form>
Das funktioniert auch gut. Doch komischerweise bekomme ich beim Absenden einen 403 - Forbidden wenn der Text in der Textarea die Zeichenfolge "fetch " enthält! Kanns das sein?

Zusätzliche Angaben: Apache/1.3.36, PHP 4.3.1

Ein Beispielfile ist hier.

Vielen Dank im voraus,

jeko
 
Der Fehler tritt bei mir nicht auf.

EDIT
Ah, doch. Aber nur wenn nach "fetch" noch was kommt.
 
Zuletzt bearbeitet von einem Moderator:
... hier auch nicht bzw. wenn ich fetch ins Textarea schreibe dann wird mir das nach dem Submit in der Seite angezeigt (graue Zeile unter Submitted text:).

----

Edit zu slosd, stimmt bei mir auch so.
 
Zuletzt bearbeitet:
Eine lokale Kopie des Codes läuft wunderbar, folglich ist Dein Server eine Zicke.

Nein, es kommt kein Edit... ;)
 
Der Fehler tritt bei mir nicht auf.

EDIT
Ah, doch. Aber nur wenn nach "fetch" noch was kommt.

Deswegen hat die Zeichenkette in meinem Post auch noch ein Leerzeichen nach dem fetch -> "fetch " (6 Chars) :)

Dass mein Server eine Zicke ist weiss ich, bloss nicht wieso. Kann es mit installierten Modulen zu tun haben, ...?

Vielleicht würde mir schon eine Anleitung zur Analyse helfen, wo ich anfangen könnte nach dem Fehler zu suchen. Google sagt überhaupt nichts zu dem Thema; bzw. wie immer viel, aber nix gscheits.
 
Hm, irgendwie laufen Threads von mir immer nach dem gleichen Schema ab; Problembeschreibung, 3-4 Posts, Windstille und Problem immer noch da.
Mach ich was falsch...? :)

Habe jetzt mal den Hoster kontaktiert, mal schauen was rauskommt.
 
Ist ein sehr spezielles Problem was mir so auch noch nicht untergekommen ist. Sofern in deinem PHP-Code nichts spezielles zu "fetch" definiert ist würde ich stark an ein fehlerhaftes Apache- oder PHP-Modul glauben. Hoster kontaktieren ist ne gute Idee. Wenn Du Zugriff auf access und error.log hast lohnt evtl. auch ein Blick dort hinein.
Tritt das Problem denn auch auf wenn Du die Daten per GET sendest? Nicht dass das eine Lösung wäre...aber ist interessant. ;)
Und schreib mal wenn Du (oder Dein Provider) rausgefunden hast was es ist. Interessiert mich.
 
Lass dir weniger ausgefallene Probleme einfallen ;)
Hm, ist es gar unpassend wenn ich jetzt nicht in Schenkel-Klopfer-Lachen ausbreche :icon7:?

meto schrieb:
Sofern in deinem PHP-Code nichts spezielles zu "fetch" definiert ist
Zu diesem Zweck habe ich's mal als reines HTML-Dok getestet (kein PHP drin). Selbes Ergebnis (Pure HTML-File)...
meto schrieb:
würde ich stark an ein fehlerhaftes Apache-[modul]
Dito.
meto schrieb:
Wenn Du Zugriff auf access und error.log hast
Leider nein :icon6:
meto schrieb:
Tritt das Problem denn auch auf wenn Du die Daten per GET sendest?
Ja, siehe 1. Zitat von meto.

@meto/all: Ich halte euch gern auf dem Laufenden :icon7:

Danke für die Bemühungen trotzdem,

und natürlich einen schönen Samstagabend noch!

gruss jeko
 
Also, habe nun endlich Antwort erhalten. Ich habe meinem Hoster (hoststar.ch) mein Problem geschildert. Hier das entsprechende Rückmail:
hoststar.ch schrieb:
Sehr geehrter Herr Sandoz

Wir haben die erwähnte Problematik analisiert. Das Problem ist darauf zurückzuführen, dass der Wert "fetch " nicht gestattet ist und durch das Apache Modul "mod_security" bewusst blockiert wird.

Wir können diese Serverkonfiguration leider aus Sicherheitsgründen nicht anpassen.

Für Ihr Verständnis danken wir Ihnen im Voraus.


Mit freundlichen Grüssen

Hoststar* - Multimedia Networks AG [Switzerland]
[...]

Das "störende" Modul heisst hier also mod_security. Ein bisschen Googlen brachte mir die Erkenntnis, dass es sich hierbei um eine Application-Level-Firewall handelt. Dabei werden nicht nur die Herkünfte der Verbindungen analysiert, sondern auch der Paketinhalt. Und hier reagiert dieser anscheinend empfindlich auf die Zeichenkette "fetch ".

http://www.heise.de/security/artikel/69070 schrieb:
Die Apache-Firewall
Web-Server mit mod_security absichern

Eine Application-Level-Firewall wie mod_security für den weit verbreiteten Webserver Apache braucht sich nicht mit einzelnen TCP-Paketen herumzuplagen. Sie integriert sich vollständig in die zu schützende Applikation und versteht dadurch auch die Einzelheiten des verwendeten HTTP-Protokolls.

Die wesentliche Einschränkung von Paket-filternden Firewalls wie IPTables und der Windows-Firewall besteht darin, dass sie im Grunde nichts von den Nutzdaten in den Paketen verstehen, die sie verarbeiten. Für sie ist nur wichtig, welche Pakete zu welcher Netzwerkverbindung gehören, woher sie kommen und wohin sie gehen. Application-Level-Firewalls hingegen verstehen die verarbeiteten Protokolle und können so viel differenzierter beispielsweise auf den Inhalt von HTTP-Verbindungen reagieren als dies auf Paketebene möglich wäre.

Die Probleme von Paketfiltern beginnen schon dabei, beispielsweise TCP-Pakete mit bekannten Exploits oder Webseiten mit schädlichen Links zu sperren. Zu suchende Muster befinden sich durch Fragmentierung nicht immer innerhalb eines einzelnen TCP-Paketes und die verwendeten Übertragungsprotokolle repräsentieren Daten häufig auch nicht in einem einheitlichen Format. Browser und Server würden den Deteipfad /docs/2.0/configuring.html zum Beispiel auch in der teilweise hexadezimal kodierten Form /%64o%63s/2%2E0/con%66igu%72ing%2Ehtml korrekt verarbeiten, was für die Erstellung von treffenden Suchmustern eine enorme Herausforderung darstellt. Entsprechend noch komplizierter wird die Angelegenheit bei der Erkennung von problematischen Inhalten in Variablenparametern in URLs oder gar POST-Anweisungen.

Darüber hinaus lässt sich von einem reinen Paketfilter auch nicht zuverlässig bestimmen, ob es sich bei den vorbeikommenden Paketen tatsächlich um Daten einer HTTP-Verbindung handelt. Der Ansatz, eine solche Zuordnung nach Ports vorzunehmen, scheitert in der Regel schon an den vielen Ausnahmen. So werden zur Umgehung restriktiver Firewalls viele Dienste, wie Internet-Telefonie, Filesharing oder Instant-Messenger ebenfalls über den HTTP-Port 80 abgewickelt. Die immer weitere Verbreitung SSL-verschlüsselter Verbindungen tut ihr Übriges, Paketfilter vom Protokollverständnis auszuschließen.

An diesem Punkt setzen Application-Level-Firewalls an. Wie der Name schon sagt, arbeiten sie nicht mehr wie Paketfilter auf der Netzwerk- und Transportschicht des OSI-Modells, sondern auf der Applikationsebene, über die die jeweiligen Anwendungen (in obigem Beispiel Browser und WWW-Server) miteinander kommunizieren. Hieraus leitet sich für diese Technik auch die alternative Bezeichnung Level-7-Filterung ab.

Im Falle von HTTP lässt sich eine Filterung auf Protokollebene noch recht bequem als Proxy realisieren. Doch es liegt nahe, die notwendige Funktionalität direkt in die Applikationen selbst zu integrieren, um eine engere Verzahnung und größere Flexibilität zu erreichen.
Quelle: heise Security - Know-how - Die Apache-Firewall

Was es nicht alles gibt & grüsse,
jeko
 
Zurück
Oben