search

contao / core

Contao 3 → see contao/contao for Contao 4
GNU Lesser General Public License v3.0
490 stars 213 forks source link

manuelle Links im Tiny produzieren Fehler in Chrome u. Safari #5716

Closed kgansberger closed 11 years ago

kgansberger commented 11 years ago

Links ( zB "/") generiert mit TinyMCE produzieren beim Speichern seltsames Problem, dass das CSS beim "Speichern und schliessen" nicht geladen wird.

Neuladen mit cmd+r zeigt die Seite wieder richtig an. Auch in Onlinedemo.

3.0.6, Macosx 10.8 Chrome u. Safari, Firefox bringt den Fehler nicht.

leofeyer commented 11 years ago

Wie genau lässt sich das in der Onlinedemo reproduzieren?

kgansberger commented 11 years ago

http://cloud.webplus.at/0t300K0S3703

adressler commented 11 years ago

Den Fehler kann ich auch für Contao 3.1.RC1 bestätigen. Aus irgendeinem Grund ist im Safari (bzw. Webkit) im DOM-Baum der base-Tag im Header leer, so dass der Pfad für alle Asset-Anfragen (js, css, Bilder) falsch ist. Im HTML-Source ist der Pfad aber richtig gesetzt.

adressler commented 11 years ago

Hier gibt es Bugreports für Chromium zu dem Thema: http://code.google.com/p/chromium/issues/detail?id=120408 http://code.google.com/p/chromium/issues/detail?id=104924

leofeyer commented 11 years ago

Die Frage ist, ob wir das abfangen können/sollen oder ob wir das als Webkit-Bug behandeln, der (hoffentlich) irgendwann seitens des Herstellers behoben wird.

@contao/workgroup-core

kgansberger commented 11 years ago 
header( "X-XSS-Protection: 0" );

Soll das base Problem in Webkit beheben.. Weiss nicht ob das sicherheitstechnisch gut ist .. ?!?

aschempp commented 11 years ago

Es bezieht sich ja lediglich auf Backend mit angemeldetem Benutzer? Wäre der Header da wirklich ein Problem?

uschindler commented 11 years ago

Lässt sich im Backend temporär fixen mit folgendem in der Apache-Config, so das der Header nur dann gesendet wird, wenn man im Backend ist - Contao selbst braucht man nicht wirklich zu hacken, es reicht die htaccess o.ä.:

<Location "/contao">
  Header set X-XSS-Protection 0
</Location>
leofeyer commented 11 years ago

@contao/workgroup-core Sollen wir die .htaccess-Anpassung in den Core übernehmen?

uschindler commented 11 years ago

Warum sendet ihr das nicht einfach via PHP über das backend-master-Skript? Ich wollte bei mir nur den source code nicht anpassen - daher der htaccess-Trick, aber korrekter wäre wohl ein header( "X-XSS-Protection: 0" ); im backend.

aschempp commented 11 years ago

Wenn dann würde ich das in eine .htaccess im /contao Ordner machen. Aber bitte nicht in einem Maintenance-Release, es gibt sicher Leute die den /contao Ordner per htaccess bereits geschützt haben...

leofeyer commented 11 years ago

Warum sendet ihr das nicht einfach via PHP über das backend-master-Skript?

Weil das Backend nicht nur aus einer Datei besteht.

Wenn dann würde ich das in eine .htaccess im /contao Ordner machen.

Davon würde ich abraten. Wir wollen irgendwann mal ganz ohne .htaccess auskommen (Stichwort "Nginx"), daher macht es schon Sinn, alles in einer zentralen .htaccess-Datei zu haben.

leofeyer commented 11 years ago

Wir haben ausführliche Tests mit der @contao/workgroup-core gemacht, aber es ist und bleibt ein Problem, das vom Browser-Hersteller behoben werden muss. Es gibt keinen sinnvollen Workaround, der nicht gleichzeitig ein Sicherheitsrisiko wäre.

aschempp commented 10 years ago

@DanielRuf Das Problem liegt woanders. Sobald ein POST-Request ausgeführt wird, und in den POST-Daten irgendwo ein href="..." vorkommt, wobei der Inhalt von href dem Meta-Tag <base href="…"> entspricht, ignoriert Chrome den Meta <base> Tag. Damit werden potentiell alle relativen Links ungültig.

DanielRuf commented 10 years ago

@adressler Ich sehe nur einen Zusammenhang mit dem XSS Auditor von Google Chrome, der das wohl verursacht. Diese absoluten Links, die auf Seiten der selben Domain zeigen, verursachen den Fehler. Es ist definitiv der XSS Auditor, der das Problem ist. Die Lösung dafür habe ich bereits genannt. Siehe #6556

Du kannst es gerne testen und mich auch vom Gegenteil überzeugen. Ich bin der festen Meinung, dass es genau das Problem ist.

Es ist im Grunde kein Bug von Chromium sondern eher ein Feature, das es schon seit sehr langem gibt - seit Chrome 4. http://www.gjdb.nl/?p=254 http://blog.k3170makan.com/2012/07/webkit-xssauditor-xss-catalyst.html https://github.com/WebKit/webkit/commits/master/Source/WebCore/html/parser/XSSAuditor.cpp?page=3 http://news.softpedia.com/news/Chrome-Gets-XSS-Filter-and-Starts-Disabling-Outdated-Plug-Ins-159498.shtml

Die Bugreports die @adressler erwähnt hat, dürften nichts damit zu tun haben. Die Lösung über den PHP Header wäre für alle Plattformen am einfachsten. Das entsprechend in den richtigen Dateien hinzuzufügen macht meiner Meinung vollkommen Sinn.

@leofeyer alle Workarounds sind Exploits und Sicherheitsprobleme, die aber generell schnell behoben werden und somit nicht mehr anwendbar wären. http://packetstormsecurity.com/files/123373/Google-Chrome-31.0-Webkit-Auditor-Bypass.html

Es ist also kein Problem, das vom Browserhersteller behoben werden muss. Der XSS Auditor ist in Webkit bzw Chromium/Blink und betrifft somit generell sehr viele Personen bzw Webentwickler und Webseitenbetreiber, die Contao nutzen.

http://stackoverflow.com/questions/1547884/refused-to-execute-a-javascript-script-source-code-of-script-found-within-reque

Nachdem ein Frontendmodul gespeichert ist, wirft der XSS Auditor eine Warnung in der Browserkonsole und die Inhalte werden nicht geladen (CSS, JS)

Die Domain ist localhost.de (Beispiel) und der Adminbereich ist unter localhost.de/contao, es ist also die selbe Domain

{{link_url::x}} funktioniert http://localhost.de/unterseite.html löst jedoch den XSS Auditor aus.

besteht das Problem Immer noch?

The XSS Auditor refused to execute a script in 'http://localhost.de/contao/main.php?do=themes&table=tl_module&act=edit&id=4' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

Man müsste also in Contao entsprechend eine Lösung finden. http://stackoverflow.com/questions/17016960/google-chromes-xss-auditor-causing-issues

Oder generell solche absoluten Links, die auf interne Seiten zeigen, automatisch in Shorttags umwandeln. Kann das Problem in aktuellen Versionen bestätigt werden? Ich denke schon.

aschempp commented 10 years ago

Und jetzt erkläre mir mal warum man keinen Link auf die aktuelle Seite haben darf?

DanielRuf commented 10 years ago

@aschempp keine Ahnung, ist so wohl seit langem bei dem XSS Auditor.

Darf schon, jedoch wird das anscheinend geblockt vom XSS Auditor von Google Chrome, da ein absoluter Link mit der selben Domain in den Formularfeldern an den Server übermittelt wird, und genau das auch wieder zurückkommt, was wohl für den XSS Auditor ein Hinweis auf (Reflected) XSS ist.

Wird wohl als Reflected XSS erkannt und deswegen blockiert.

aschempp commented 10 years ago

Siehe https://github.com/contao/core/issues/5716#issuecomment-17381299, es bezieht sich wirklich auf den Base-Tag. Und das ist wirklich ein Chrome Bug.

Das Prinzip jedes Eingabefeldes im Backend ist es, dass du nach dem POST dieselben Inhalte wieder zurück bekommst, da sie ja wieder angezeigt werden. Das wird ja (korrekt) nicht als XSS erkannt. Lediglich wenn der href-Tag mit dem kolidiert passiert was.

DanielRuf commented 10 years ago

@aschempp hat trotzdem mit dem XSS Auditor zu tun. Klar, der entfernt dann auch den base-Tag bzw entfernt bestimmte Teile des Inhalts bzw filtert die, die er als Teil des Reflected XSS sieht.

Bei mir sieht das genauso aus wie im Video. Und da habe ich nur einen Link mit href="http://localhost.de/unterseite.html"

Das Video von @kgansberger setzt doch auch das href Attribut bzw. ist ein Link. @adressler hat entweder ein anderes Problem entdeckt (anderes Issue wäre dann sinnvoll) oder es ist genau das selbe Problem.

Dann ist es imer noch kein Bug von Chrome sondern ein Feature von dem XSS Auditor. https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/parser/XSSAuditor.cpp#L363 https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/parser/XSSAuditor.h#L91

http://architects.dzone.com/articles/xss-auditor-refused-execute https://code.google.com/p/chromium/issues/detail?id=33115

Die Bugreports beschreiben genau das Verhalten von dem XSS Auditor. Deswegen sind die auch unbeantwortet seit 2-3 Jahren, es wird nicht gefixt werden. Andernfalls würde sofort jemand vom Blink Team sich der Sache annehmen. Werden die jedoch nicht. In den meisten Fällen wird das dann als wontfix geschlossen, besonders hier.

Ich habe mal beim Blink Team nachgefragt und die Bugreports nach oben geholt. Mal sehen, was das Blink Team dazu sagt.