Closed ghost closed 13 years ago
ghost
commented
13 years ago Ok - ich habs gefunden: man kann den Token auch wahlweise in den Sicherheitseinstellungen deaktivieren.
Aber die Referer Prüfung wird dann nicht mehr aktiviert?
--- Originally created by Georg on June 4th, 2011, at 10:17am
fbender
commented
13 years ago Das ist in der Tat ein Problem. Man könnte zumindest statt eines Fatal Errors einfach die Seite mit ausgefülltem Formular nochmal anzeigen, mit der Bitte um erneutes absenden (diesmal mit dem richtigen Token). Allerdings würde das immer zu einer nervigen "Mehrarbeit" für den Besucher führen.
Das Abschalten des Caches oder massives reduzieren sollte auch nicht die Lösung des Problems sein.
Reicht es nicht das Token in der Session zu lagern?
--- Originally created on June 4th, 2011, at 02:06pm
aschempp
commented
13 years ago Dazu kann ich nur sagen, dass Seiten mit Formularen nach meinem Wissen nie gecacht werden sollten... Vielleicht ist mein Wissen hier aber auch veraltet (Leo?)
--- Originally created on June 5th, 2011, at 10:45am
fbender
commented
13 years ago Jap, die Info ist veraltet. Hat sich mit 2.6 glaub erledigt, da POST-Requests (korrekterweise) nicht mehr cached werden.
--- Originally created on June 5th, 2011, at 11:45am
ghost
commented
13 years ago Ich möchte noch mal verdeutlichen, was mich eigentlich zu meinem Kommentar bewegt hat. Nicht nur ich habe am 11.09. erlebt wie die Nachrichten Portale zusammenbrachen, weil die Server die dynamisch erzeugten Seiten nicht mehr zusammengebaut bekommen haben. Mittags sind dann die ersten Redakteure darauf gekommen, dass Sie doch einfach nur aus Ihrer Textverarbeitung regelmäßig einen HTML Export erstellen und auf den Web-Server stellen mussten, und trotz unveränderter Hardware konnte ganz Deutschland wieder mit aktuellen Nachrichten versorgt werden.
Wer sich die Referenz Portale (Fallbeispiele) auf der Contao Seite anschaut, wird mir hoffentlich zustimmen, dass die wichtigen Hauptseiten der Portale weder ein Session Handling, noch Cookies oder Tokens benötigen. Sie sind bestens geeignet um als fertige html Seiten vom Web Server aus einem wie auch immer gearteten Cache System direkt ausgeliefert zu werden.
Bitte nicht falsch verstehen: Auch ich benötige einen Nutzer individuellen Members Bereich usw. und liebe in dem Bereich die Möglichkeiten und Performance von Contao.
Aber ich glaube, dass man mit wenig Aufwand in der Konzeption auch auf kleiner Hardware keinen Horror vor der Fernsehsendung haben muss, in der die eigene Portaladresse plötzlich veröffentlicht wird.
Zum Beispiel könnte man vor dem endgültigen Versand des Formulars eine Seite mit der Zusammenfassung anzeigen. Erst in dieser Zusammenfassung wäre das Token und das Captcha enthalten. Die leere Formular Seite wäre also statisch und gut zu cachen. Als URL mit den Post Daten könnte man dann bei Bedarf sogar auf eine SSL verschlüsselte Seite wechseln und bekäme erst dort die dynamisch, nutzerindividuel erzeugte Zusammenfassung inkl. Token und zufällig erzeugtem Captcha angeboten.
--- Originally created by Georg on June 5th, 2011, at 02:16pm
aschempp
commented
13 years ago Das mit der Zusammenfassung würde nicht funktionieren, denn Contao akzeptiert keine POST-Daten ohne passendes Request Token. Damit würden auch keine Daten an eine Bestätigungsseite gesendet.
--- Originally created on June 5th, 2011, at 02:23pm
ghost
commented
13 years ago Wenn man das will schon. (Muss ja nur den Haken im BE setzen...)
Im Ernst: Der erste Post Data Aufruf benötigt weder ein Referer- noch ein Token Check. Bis hier ist ja noch kein Missbrauch möglich: Der kritische Versand der Email mit den Formular Daten (oder der Datenbankeintrag) soll ja erst nach Bestätigung der Zusammenfassung erfolgen.
--- Originally created by Georg on June 5th, 2011, at 02:39pm
aschempp
commented
13 years ago Ich denke du solltest dich mal in die Problematik einlesen, z.B. hier: http://phpsec.org/projects/guide/2.html
--- Originally created on June 5th, 2011, at 02:54pm
fbender
commented
13 years ago Eine "Bestätigungsseite" würde das Problem, das Andreas anspricht, ebenso lösen.
Nochmal meine Frage, ob man das Token nicht einfach in der Session speichern kann, dann hat man auch kein (zumindest weniger großes) Problem mit Caching mehr (jedoch müsste man sicherstellen, dass das Token in der Session angelegt wird).
Zwei Lösungvorschläge noch:
Das nicht-erlauben von Caching auf Formularseiten kann und darf nicht die Lösung sein.
--- Originally created on June 5th, 2011, at 03:06pm
ghost
commented
13 years ago `Andreas: Danke für den Link. Aber ich kann nicht erkennen, welche Lücke mit einer "Bestätigungsseite" bleiben sollte.
`quantumedia: Ein Angriffsszenario ist ein automatisierter Versand von post requests. Unter anderem das Captcha soll das ja unterbinden. Wenn die leere Formularseite jedoch schon das Captcha enthält und diese Seite gecached werden darf, dann wird das Captcha sinnlos, weil das Captcha immer gleich bleibt.
Daher mein Vorschlag mit der Trennung von statischer Formular Seite und der dynamischen Bestätigungsseite mit Captcha und Token.
--- Originally created by Georg on June 5th, 2011, at 03:35pm
aschempp
commented
13 years ago Dein Vorschlag mit der Bestätigungsseite geht nicht, weil die Daten gar nicht erst an Contao gesendet werden dürfen. Das wäre mit der Bestätigungsseite schon umgangen. Es geht nicht (nur) um eine Prüfung der Daten, sondern auch sicherzustellen dass diese von einem Contao-Formular kommen.
--- Originally created on June 6th, 2011, at 12:10pm
ghost
commented
13 years ago @Andreas: Auch gem. den Informationen in Deinem Link spielen hier zwei Szenarien eine Rolle:
Ein Token ist doch nur eine kleine Hürde: Dich als PHP Spezialisten kostet es keine 5 Minuten um mit einem Skript per Http Request das Formular mit dem Token anzufordern, dann das Token aus dem html Code zu fischen und zusammen mit einem beliebig manipuliertem Paket von Post Data wieder an den Server zu senden. Hier helfen dem Server nur gute Filter und Validierung der Eingangs Daten.
Und weil die Leute, die Internet Portale einem Abnahmetest unterziehen, ja auch nicht gerne zig Testfälle manuell durch Internetformulare klickern wollen, gibt es auch schon wieder Tools, die genau das machen: Token auslesen und dann je nach Testfall verschiedene Post Data Pakete zusammen mit dem Token an den Server senden.
Oder liegt Dein Bauchschmerz in einem ganz anderen Angriffsszenario?
--- Originally created by Georg on June 6th, 2011, at 11:38pm
ghost
commented
13 years ago Bevor Missverständnisse auftreten: Ich rede hier nicht von einem Bereich, indem der Nutzer sich durch Anmeldung autentifiziert hat und daher in einer Session behandelt wird. Hier ist das Token die beste Lösung, die sich aktuell anbietet. Ich möchte z.B. ja auch nicht jede Änderung im BE von Contao durch eine Captcha Abfrage noch mal autentifzieren.
Mein Hinweis bezog sich auf den öffentlichen Teil eines Portals, also die Visitenkarte des Internetauftritts. Den Teil, den die meisten Nutzer abfragen und gleichzeitig auch genau der Teil des Portals, der von Google in seinem Antwortverhalten bewertet wird.
Hier finde ich es einfach suboptimal Server Resourcen für dynamisch erzeugten HTML Code zu verschwenden, der doch eigentlich statisch und damit cacheable ist.
--- Originally created by Georg on June 7th, 2011, at 08:14am
fbender
commented
13 years ago `Andreas: Das stimmt, mit der aktuellen Implementierung würde der Vorschlag mit der Bestätigungsseite gar nicht funktionieren. Natürlich muss dafür manches umgebaut werden. Da ich auch nicht unbedingt Fan von zu viel Klickerei bin, wäre das IMO sowieso die weniger optimale Lösung.
Nochmal: Mit der Session müsste es doch funktionieren (`Georg: Sessions werden eh aufgebaut, dafür braucht es keine spezifische Authentifizierung). Dazu die Formular-ID und Generierungszeit bzw. expiry date speichern, das ganze nach dem Absenden validieren (beim Referercheck dabei Prüfen, ob im POST die richtige Formular-ID steht). Expiry date würde ich im Formularcode überprüfen und ggf. eine Fehlermeldung senden ("Sie haben für die Eingabe zu lange (/zu wenig Zeit) gebraucht, bitte (warten Sie kurz und) senden Sie das Formular erneut ab."), dass die Formulardaten erhalten bleiben und der Besucher nichts erneut eintippen muss.
--- Originally created on June 7th, 2011, at 03:48pm
ghost
commented
13 years ago `quantumedia: Manchmal habe ich Langeweile und lege die statischen Seiten eines Portals als html File direkt im Root der Domaine ab (Natürlich zusätzlich auch als .html.gz Version) und lasse Apache über .htaccess diesen File Cache abfragen. Nur die nicht als File vorhandenen URL mit dynamischen Inhalt werden dann von Contao bedient. Daher auch keine PHP Session und kein Cookie Overload für die statischen html Files. Aber das lenkt vom Thema ab:
`Leo, @Andreas: Ihr habt viel Schweiß und Gehirnschmalz in den von Contao gesteuerten, sehr performanten File Cache des Contao Core gesteckt.
Wenn man sich jedoch die Music Academy als Beispiel anschaut, ist jetzt mit Einführung des Tokens nicht eine einzige Seite dieser Demo mehr Cacheable, weil auf jeder Seite das Login Formular vorhanden ist.
Und ein Login Modul in der Navigationsleiste ist ja leider ein weitverbreiteter Regelfall.
Mit dem Referer Check hat das Cachen bisher (eher ungewollt) noch funktioniert. Mit dem Token ist das jetzt vorbei.
Obwohl 99% der Nutzer sich nicht einloggen, eine Seite mit Kontaktformular gar nicht absenden und auch keine Emailadresse in den Newsletter Verteiler eintragen, usw. können diese eigentlich statischen Seite jetzt nicht mehr gecached werden.
(Böse Zungen behaupten ja, dass das Portal mit dem Online Formular zur Abwrackprämie zusammengebrochen ist, weil die meisten Nutzer sich das vom Server dynamisch erzeugte Formular eigentlich nur mal anschauen wollten....)
Bitte erhaltet den Performance Boost durch des Contao Cachesystem. Und ich glaube, dass das bei Eingabe Feldern im öffentlichen Bereich eines Portals nur über einen Bestätigungsdialog funktioniert.
--- Originally created by Georg on June 8th, 2011, at 12:21am
leofeyer
commented
13 years ago Ich kann das Problem nicht reproduzieren. Ich habe es mit der Music Academy und einer Cachezeit von 60 Sekunden versucht und konnte das Anmeldeformular auf jeder Unterseite problemlos absenden. Es erscheint mir auch nicht logisch, da das Token nicht mit gecached wird und auch auf gecachten Seiten neu generiert wird. Vermutlich rührt das Problem eher von einer Tab-Nutzung her, die in 2137acd81be24779507fac062c223b06 nun auch unterstützt wird.
--- Originally created on June 8th, 2011, at 02:33pm
ghost
commented
13 years ago 2.10 Beta1, MusicAcademy frisch importiert, Token nicht deaktiviert, Den Command Scheduler deaktivieren, Server und Browser Cache aktivieren, Cache Zeit im Startpunkt der Webseite auf 60 Sekunden setzen, Systemwartung und persönliche Daten: alle Dateien bereinigen, Aus BackEnd abmelden.
=> Fehlermeldung: "Invalid Request Token
![]("
--- Originally created by Georg on June 8th, 2011, at 11:07pm
leofeyer
commented
13 years ago Wie gesagt kann ich den Fehler nicht reproduzieren. Ich habe mich exakt an Deine Anleitung gehalten und kann das Anmeldeformular trotzdem ohne Probleme abschicken.
--- Originally created on June 9th, 2011, at 08:51am
ghost
commented
13 years ago Dann mit der aktuellen Contao Online Demo:
Backend:
![]()
![](!
==>> Solange die URL in der form action für post data die gleiche ist wie die URL im normalen Get, bekomme ich mit einigem Aufwand in der Cacheverwaltung des Servers das obige Fehlerbild vielleicht noch beseitigt.
Nach Aktivierung des Browser Cache in Contao habe ich jedoch keine Chance mehr das Durcheinander von Seiten ohne Fehlermeldung und den gleichen Seiten mit Fehlermeldungen unter der gleichen URL in den Griff zu bekommen.
Diese Effekte führen dann bei einem Wechsel zu einem Contao mit dem Token System zu einer Verwendung einer Seite aus dem Browser Cache mit nicht mehr gültigem Token.
--- Originally created by Georg on June 9th, 2011, at 03:21pm
ghost
commented
13 years ago Kann bitte mal Jemand in der aktuellen Contao Online Demo mein zuletzt beschriebenes Fehlerbild bestätigen? Mein Nachname lautet nicht "Fletcher".... ;-)
Wichtig: nach den Einstellung im BE sich vor den Tests explizit wieder aus dem BE ausloggen, sonst wird der Server Cache nicht genutzt.
Fehlerbild: In Schritt 4 werden die fehlerhaften Post Data nicht angemeckert. Und in Schritt 5 werden fehlerhafte Post Data angemeckert, obwohl nur ein einfaches Get ohne Post Data an den Server gesendet wurde.
--- Originally created by Georg on June 11th, 2011, at 11:03am
Aybee
commented
13 years ago Ja, kann ich bestätigen.
Ich weiß nicht, ob das damit zusammenhängt, aber mit der 2.10.RC1 muss ich in den Einstellungen die Anfrage-Tokens deaktivieren, sonst ist mir ein flüssiges Arbeiten nicht mehr möglich. Bekomme sonst immer wieder in diversen unterschiedlichen Situationen den gelben Kasten mit der Fehlermeldung auf einen ungültigen Token.
--- Originally created on June 11th, 2011, at 04:23pm
ghost
commented
13 years ago Wie entwirren wir denn dieses Tickets jetzt wieder:
1.) Dieser letzte Effekt deutet ja nur auf ein Problemchen im Zusammenhang mit dem Server Cache (egal ob Contao 2.9x oder 2.10b1)
Das wird man ohne große Probleme abstellen können.
2.) Der eigentliche Knackpunkt entsteht jedoch erst bei Aktivierung des Contao Modus "Server UND Browser Cache" UND der Einführung des Tokens. Wenn ich z.B. "Home", "The Academy" und "Courses" im Browser einfach durchgeklickert habe, habe ich jede dieser Seiten im Browser Cache. Jede Seite hat aber auch ein anderes Token im Browser Cache. Wenn ich jetzt ein PostData durch Login absende, wird das Token nur akzeptiert, wenn es zufällig auch das zuletzt vom Server ausgelieferte Token ist - oder?
Kann aber sein, das der zuletzt aufgerufene Menuepunkt sich schon vorher im Browser Cache befand. Beim Login von dieser Seite aus gibt es dann den Token Fehler.
--- Originally created by Georg on June 11th, 2011, at 05:26pm
ghost
commented
13 years ago 1.) Fehler im Zusammenhang mit dem Contao Server Cache: Soll ich dazu ein eigenes Ticket aufmachen? 3132#note-19
2.) Probleme mit Token im Zusammenhang mit Browser Cache: Der Browser Cache kann ja nur zugelassen werden, solange der Nutzer sich nicht im Front End oder Back End angemeldet hat.
Ein nicht angemeldeter Nutzer hat aber keine Rechte, die über Cross-Site Request Forgeries missbraucht werden können. Und das ist nach meinem Verständnis der wesentliche Nutzen eines Token.
Also könnte man die Token Prüfung für nicht angemeldete Nutzer doch deaktivieren - oder?
--- Originally created by Georg on June 12th, 2011, at 12:29pm
ghost
commented
13 years ago Sorry für die Irrungen und Wirrungen in diesem Ticket. Habe jetzt versucht noch mal des Pudels Kern zu treffen:
Meine bisherige Anleitung zur Reproduzierung des Token Fehlers basierten auf einer "kontaminierten" 2.10beta Umgebung auf meinem Server: ich hatte schon eine Erweiterung installiert .... Das zu dem Thema, dass 2.10 nur ein "Minor" Releasewechsel wird ;-))
Habe jetzt 2.10Beta Rev852 noch mal ganz sauber und ohne Erweiterungen installiert.
Backend:
=>> Fehlermeldung "Invalid Request Token"
Logisch, weil alle 25 zulässige Token an die Browser Session gebunden sind. The Academy und alle Portale mit Login/Formularfeldern werden mit einer 24h Browser Cache Einstellungen nach einem Neustart des Browsers zunächst nur noch ungültige Token aus Ihrem Browser Cache absenden und entsprechende Fehlermeldungen erhalten.
Daher noch mal meine Frage: Benötigen wir das Token im öffentlichen Bereich eines Portals?
Das Token dient der Verhinderung von Cross-Site Request Forgeries, also einem Angriff zum Missbrauch von Nutzerrechten. z.B. Leo ist als Admin im Contao Entwicklersystem angemeldet und ich locke Ihn unter Vorwand auf eine von mir präperierte Seite. Mein Link erzeugt jedoch ein Post Request an Leos Entwicklersystem und in dem Post Data steht sinngemäß: mach Georg zum Superadmin.
Das funktioniert nur wenn der Angegriffene Rechte besitzt, die der Angreifer nicht hat. Solange aber kein Nutzer angemeldet ist, können auch keine Nutzerrechte missbraucht werden.
=> Token nur für Nutzer, die im System angemeldet sind.
P.S.: Auch Proxy Caching macht mit Token keinen Spass...
--- Originally created by Georg on June 20th, 2011, at 11:44pm
leofeyer
commented
13 years ago --- Originally closed on June 8th, 2011, at 02:33pm
Ich schätze an Contao unter anderem die gut funktionierenden Cache Mechanismen vom Server bis zum Browser Cache. Und wenn ich mir die Referenzseiten von Contao anschaue, habe offenbar nicht nur ich selten die Amazon Rechenpower hinter meinen Portalen um jedem Nutzer seine völlig individuelle, vollaktive Portal Seite mit Realtime Feedback anzubieten.
Für mich zählt das die Hauptseiten eines Portals auch bei einem preiswertem Hosting möglichst zügig dargestellt werden. Und jeder Nutzer der beim Durchklicken durch das Portal sich aus seinem lokalen Browser Cache selbst bedienen kann, läßt dem Server alle Resourcen um stattdessen für einen neuen Nutzer mit seiner gesamten Power bereit zu stehen.
Ich habe z.B. eine Kontakt Seite, ähnlich wie im folgenden Contao Referenz Portal: http://www.forstbetrieb-albrecht.de/kontakt.html
D.h. Kontaktinformationen und das Kontaktformular befinden sich auf der gleichen Seite, die beim Durchklicken durch das Portal auch oft aufgerufen wird. Bisher konnte ich für diese Seite den Browser Cache auf 24h eingestellt lassen.
Mit dem Token darf die Seite jetzt jedoch nicht mehr gecached werden. Sonst gibt es beim Absenden die neue Fehlermeldung: "Invalid request token
![]("
Zusätzlich taucht jetzt auch noch ein Problem mit den bösartigen Nutzern auf, die über die Browser Funktion eine Seite zurück gehen. Diese Seite wird dann auf jeden Fall aus dem Browser Cache geholt und führt danach mit dem Token zur obigen Fehlermeldung.
Ich habe leider beim Suchen nicht die Ursache zur Einführung des Tokens in 2.10 gefunden. Aber mein Feature Request lautet: Seiten mit jungfräulichen Formularfeldern sollen im Browser bitte problemlos gecached werden können. So wie bisher)
(Die Performance Verbesserungen durch CSS Zusammenführung usw. sind übrigens wirklich Klasse!!)
--- Originally created by Georg on June 3rd, 2011, at 11:02pm (ID 3132)