Update auf 2.9 - Zugriffsfehler auf main.php

[teoMa]

Hallo,

nach einem Update von 2.8.x auf 2.9 funktioniert die Seite und das Backend scheinbar problemlos.

Nun musste ich feststellen, dass ich beim speichern im Backend auf den Seiten "Einstellungen" und "Seitenlayout" folgende Fehlermeldung bekomme:

You don't have permission to access /contao/main.php on this server.

Die Zugriffsrechte für die main.php stehen auf 644, das Verzeichnis contao auf 755.
Die contao-check.php bringt keine Fehlermeldungen bzgl. Dateirechten.
Es werden aber die config.php und languages.php als corrupt gemeldet.

Ich stehe im Moment etwas auf der "Leitung" und komme nicht so richtig weiter.
Das Update habe ich mit easy_update ausgeführt und die entsprechenden Dateien unter system/config ausgeschlossen.

Besten Dank im vorraus.

Thomas

[xchs]

Es werden aber die config.php und languages.php als corrupt gemeldet.

Ich nehme jetzt mal an (bzw. hoffe es), dass Du die betreffenden beiden Dateien nicht selbst bearbeitet hast. Du müsstest daher auf jeden Fall diese beiden Dateien nochmals neu hochladen, wenn das Systemdiagnosetool diese als "Corrupt" reklamiert.

[teoMa]

Nein, ich habe die beiden Dateien nicht bearbeitet.
Habe die beiden Dateien neu hochgeladen und die contao-check.php meldet nun keine Fehler.

Das ursprüngliche Problem mit der Fehlermeldung bzgl. der main.php bleibt aber bestehen.

Thomas

[xchs]

Das ursprüngliche Problem mit der Fehlermeldung bzgl. der main.php bleibt aber bestehen.

Hmm, echt komisch. Und das Problem tritt nur auf, wenn Du die Seiten "Einstellungen" und "Seitenlayout" aufrufst (bzw. dort Einstellungen speicherst)? Gibt es im "/contao"-Verzeichnis u.U. eine ".htaccess", die den Zugriff blockiert?

[teoMa]

Ja, ist wirklich so - ich habe eben nochmal durchgetestet.
Ich kann in der Seitenstruktur arbeiten, kann Artikel und Inhaltselemente bearbeiten.
Nur bei den Seiten "Einstellungen" und "Seitenlayout" erfolgt beim speichern die genannte Fehlermeldung.

Im "Contao"-Verzeichnis gibt es keine ".htaccess".

Ich habe auch mal die verwendeten Erweiterungen deinstalliert - leider auch ohne Erfolg.

Hm - ratlos

Gruß
Thomas

[planepix]

Hallo Thomas,

im FTP-Programm auch unsichtbare Dateien auf anzeigen gestellt?

[teoMa]

Ich habe im Filezilla die Option "Server --> Auflistung versteckter Dateien erzwingen" aktiviert. Bringt aber keine neuen Dateien zu Ansicht.

Thomas

[planepix]

ok, dann wurde diese nicht übertragen bzw. beim Update nicht überspielt.

Dann kannst Du immer noch aus dem 2.9-Ziparchiv die .htaccess.default laden.

War vorher auch eine .htaccess-Datei im Einsatz?
URLs umschreiben z.B.?

[teoMa]

Hm, also im Projektverzeichnis ist die "._htaccess" als auch die ".htaccess.default" vorhanden, ist also übertragen worden.

Ich hatte vor dem Update keine .htaccess im Einsatz und URLs umschreiben nicht aktiv.

In Bezug auf die nicht vorhandene .htaccess meinte ich das Verzeichnis "Projektname/contao/". Ich hatte xchs auch dahingehend verstanden.

Thomas

[planepix]

Hallo Thomas,

ja im Rootverzeichnis der Contao-Installation.

Ansonsten müsste man sich das glaube ich live ansehen.

[xchs]

In Bezug auf die nicht vorhandene .htaccess meinte ich das Verzeichnis "Projektname/contao/". Ich hatte xchs auch dahingehend verstanden.

Ja richtig, mein Hinweis oben bezog sich auf das "[TL_ROOT]/contao/"-(Unter-)Verzeichnis. Aber wenn es dort auch keine Serverkonfigurationsdatei gibt, dann sollte das eigentlich soweit passen.

Du sagst weiters, dass Du bisher im Contao-Root-Verzeichnis keine ".htaccess" verwendet hast: Könnte es sein, dass in einem übergeordnetem Verzeichnis irgendwo eine ".htaccess" rumliegt, die hier eventuell einen Strich durch die Rechnung macht?

Laut Deinen Angaben gibt Dir der System-Check "contao-check.php" keinerlei Fehlermeldungen aus. Auch keinen Hinweis darauf, dass Du ev. doch den Safe Mode Hack (SMH) brauchst?

Könntest Du bitte auch mal die komplette URL (mit dem "main.php"-Fragment) hier posten, welche dann zu diesem Fehler führt (den Domain-Namen kannst Du meinetwegen auch weglassen, wenn Du den Link zur Seite hier nicht veröffentlichen möchtest)?

Und vielleicht zuletzt noch: Hast Du die Möglichkeit, die Installation auch auf einem anderen Server / einem anderen Hosting / ev. auch unter localhost (XAMPP) auszuprobieren?

[teoMa]

Du sagst weiters, dass Du bisher im Contao-Root-Verzeichnis keine ".htaccess" verwendet hast: Könnte es sein, dass in einem übergeordnetem Verzeichnis irgendwo eine ".htaccess" rumliegt, die hier eventuell einen Strich durch die Rechnung macht?

Kann ich erst heute Abend genau prüfen, ich gehe aber nicht davon aus.

Laut Deinen Angaben gibt Dir der System-Check "contao-check.php" keinerlei Fehlermeldungen aus. Auch keinen Hinweis darauf, dass Du ev. doch den Safe Mode Hack (SMH) brauchst?

Das glaube ich nicht, hatte auf dem Server bereits mehrere Installationen und nie Probleme gehabt. Installationen auf anderen Servern des Providers laufen auch ohne SMH.

Könntest Du bitte auch mal die komplette URL (mit dem "main.php"-Fragment) hier posten, welche dann zu diesem Fehler führt (den Domain-Namen kannst Du meinetwegen auch weglassen, wenn Du den Link zur Seite hier nicht veröffentlichen möchtest)?

für "Einstellungen" -

http://xxxxxx.de/contao/main.php?do=settings

für "Seitenlayout" -

http://xxxxxx.de/contao/main.php?do=themes&table=tl_layout&act=edit&id=1

Und vielleicht zuletzt noch: Hast Du die Möglichkeit, die Installation auch auf einem anderen Server / einem anderen Hosting / ev. auch unter localhost (XAMPP) auszuprobieren?

Kann ich erst in den nächsten Tagen probieren.

Gruß
Thomas

[mr_flory]

Hallo,

ich habe dasselbe Problem seit dem Update auf Contao 2.9 per Live Update. Vorher nie Probleme gehabt, habe auch bereits händisch alle Dateien aktualisiert. Ich verwende eine .htaccess im Root Verzeichnis, aber auch ohne und mit der default tritt der Fehler auf, aber auch nur in den oben genannten Modulen.
Der SMH ist nicht in Verwendung. Die contao-check.php wirft keine Fehler.

Kann ich noch irgendwie zur Lösungsfindung beitragen?

Gruß
Florian

[lindesbs]

Koennt ihr (wenn moeglich) mal nachschauen, ob in der Apache error.log irgendetwas steht ?

Das hoert sich irgendwie nach fehlenden Daten im POST Aufruf an.

Hatte sowas aehnliches schonmal bei einer Mdoulentwicklung.

Sucht mal nach dem Stichwort "suhosin"

Und wenn moeglich auch den Auszug ueber suhosin aus einer phpinfo

[mr_flory]

Error-Log:

[Thu Jul 08 00:53:11 2010] [error] [client 109.91.27.85] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(< ?(?:script|about|applet|activex|chrome).*(?:script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame|\\%env)" at ARGS:allowedTags. [file "/etc/apache2/modsec2/10_asl_rules.conf"] [line "688"] [id "340147"] [rev "54"] [msg "Atomicorp.com WAF Rules: Generic XSS filter"] [data ""] [severity "CRITICAL"] [hostname "www.DOMAIN.de"] [uri "/contao/main.php"] [unique_id "CLzKa06KWcYAACHeWWkAAADK"]

Suhosin Teil auf der phpinfo:

suhosinThis server is protected with the Suhosin Extension 0.9.29

Copyright (c) 2006-2007 Hardened-PHP Project
Copyright (c) 2007-2008 SektionEins GmbH 

Directive	Local Value	Master Value
suhosin.apc_bug_workaround	Off	Off
suhosin.cookie.checkraddr	0	0
suhosin.cookie.cryptdocroot	On	On
suhosin.cookie.cryptkey	[ protected ]	[ protected ]
suhosin.cookie.cryptlist	no value	no value
suhosin.cookie.cryptraddr	0	0
suhosin.cookie.cryptua	On	On
suhosin.cookie.disallow_nul	1	1
suhosin.cookie.disallow_ws	1	1
suhosin.cookie.encrypt	Off	Off
suhosin.cookie.max_array_depth	50	50
suhosin.cookie.max_array_index_length	64	64
suhosin.cookie.max_name_length	64	64
suhosin.cookie.max_totalname_length	256	256
suhosin.cookie.max_value_length	10000	10000
suhosin.cookie.max_vars	100	100
suhosin.cookie.plainlist	no value	no value
suhosin.coredump	Off	Off
suhosin.disable.display_errors	Off	Off
suhosin.executor.allow_symlink	Off	Off
suhosin.executor.disable_emodifier	Off	Off
suhosin.executor.disable_eval	Off	Off
suhosin.executor.eval.blacklist	no value	no value
suhosin.executor.eval.whitelist	no value	no value
suhosin.executor.func.blacklist	no value	no value
suhosin.executor.func.whitelist	no value	no value
suhosin.executor.include.allow_writable_files	On	On
suhosin.executor.include.blacklist	no value	no value
suhosin.executor.include.max_traversal	0	0
suhosin.executor.include.whitelist	no value	no value
suhosin.executor.max_depth	0	0
suhosin.filter.action	no value	no value
suhosin.get.disallow_nul	1	1
suhosin.get.disallow_ws	0	0
suhosin.get.max_array_depth	50	50
suhosin.get.max_array_index_length	64	64
suhosin.get.max_name_length	64	64
suhosin.get.max_totalname_length	256	256
suhosin.get.max_value_length	512	512
suhosin.get.max_vars	200	200
suhosin.mail.protect	1	1
suhosin.memory_limit	32M	32M
suhosin.mt_srand.ignore	On	On
suhosin.multiheader	Off	Off
suhosin.perdir	0	0
suhosin.post.disallow_nul	1	1
suhosin.post.disallow_ws	0	0
suhosin.post.max_array_depth	50	50
suhosin.post.max_array_index_length	64	64
suhosin.post.max_name_length	64	64
suhosin.post.max_totalname_length	256	256
suhosin.post.max_value_length	1000000	1000000
suhosin.post.max_vars	300	300
suhosin.protectkey	On	On
suhosin.request.disallow_nul	1	1
suhosin.request.disallow_ws	0	0
suhosin.request.max_array_depth	50	50
suhosin.request.max_array_index_length	64	64
suhosin.request.max_totalname_length	256	256
suhosin.request.max_value_length	1000000	1000000
suhosin.request.max_varname_length	64	64
suhosin.request.max_vars	400	400
suhosin.server.encode	On	On
suhosin.server.strip	On	On
suhosin.session.checkraddr	0	0
suhosin.session.cryptdocroot	On	On
suhosin.session.cryptkey	[ protected ]	[ protected ]
suhosin.session.cryptraddr	0	0
suhosin.session.cryptua	Off	Off
suhosin.session.encrypt	On	On
suhosin.session.max_id_length	128	128
suhosin.simulation	Off	Off
suhosin.sql.bailout_on_error	Off	Off
suhosin.sql.comment	0	0
suhosin.sql.multiselect	0	0
suhosin.sql.opencomment	0	0
suhosin.sql.union	0	0
suhosin.sql.user_postfix	no value	no value
suhosin.sql.user_prefix	no value	no value
suhosin.srand.ignore	On	On
suhosin.stealth	On	On
suhosin.upload.disallow_binary	0	0
suhosin.upload.disallow_elf	1	1
suhosin.upload.max_uploads	10	10
suhosin.upload.remove_binary	0	0
suhosin.upload.verification_script	no value	no value

[lindesbs]

@mr_flory . Schreib mal in deine htaccess dieses hier :
SecFilterEngine Off

Und berichte, ob sich danach etwas aendert.

[mr_flory]

Jup, kommt nen Internal Server Error. Das Überschreiben dieses Parameter scheint der Provider nicht zu erlauben.

[teoMa]

Problem wurde gelöst.

Ich habe mich mit meinem Provider (Sysprovide) in Verbindung gesetzt. Dort wurde sofort ein Problem mit der Webserverfirewall vermutet.

Nach Auswertung der error_log Einträge wurden die "WebServer Firewall Regel "340147"
bis "340149" auf "off" gesetzt.

Dies brachte den gewünschten Erfolg .

Gruß
Thomas

[mr_flory]

Hey,
was fürn Zufall, bin auch bei Sysprovide. Habe bei mir nun auch die entsprechenden Regeln ausgeschaltet und nun geht alles
Vielen Dank
Florian

[lindesbs]

Kannst Du kurz noch kommentieren, was die WebServer Firewall Regel "340147"
bis "340149" auf "off" genau bedeutet?Weil, selbst wenn eine FW genuztzt wird, dies eigentlich keinen Einfluss auf spezielle Seiten haben sollte.

[mr_flory]

Das weiß ich leider selber nicht. Ich kann einfach in meinem Confixx als httpd Einstellung diverse Firewallregeln ein- und ausschalten. Ich vermute es hat irgendwas mit Suhosin zu tun.

[teoMa]

Ich frage mal beim Provider nach.

Gruß
Thomas

[lindesbs]

Danke , das wuerd mich naemlich wirklich interessieren

[teoMa]

So, hier nun die Antwort von meinem Provider:

es sind die Regeln von atomicorp. Wenn jemand Interesse hat einfach dort die
"delayed" Regeln herunterladen und nachschauen (Regelnummern). Diese sind
kostenlos im Gegensatz zu den Echtzeitregeln.

http://downloads.prometheus-group.com/delayed/rules/

Gruß
Thomas

[BugBuster]

Ist in 10_asl_rules.conf drin und sind "Generic XSS filter" bzw. "XSS injection" Regeln.

[freaky]

Hab noch ein Update für diesen Thread. Ich hatte auch diese Fehlermeldung. Hosting ist ebenfalls Sysprovide und die besagten Regeln sind bereits ausgeschalten.

Mit dem Ausschalten der "Firewall Regel 300077" ist das Problem aber auch gelöst.

Hier könnt ihr nachlesen wie es dazu gekommen ist. Er meckerte beim div tag wenn ich HTML einfügen wollte.

Gruß
freaky