Wie Link auf ein Objekt setzen?

[supervisior]

Geh mal auf: https://csp-evaluator.withgoogle.com/

In das Textfeld gibst dann mal den Javascript Code, der da für den Zähler verwendet wird und lässt den Code prüfen:

Code: Alles auswählen

(function() {
    var req, y;

    function start() {
        req = false;
        if (typeof XMLHttpRequest != 'undefined') {
            req = new XMLHttpRequest();
        }
        if (!req) {
            try {
                req = new ActiveXObject('Msxml2.XMLHTTP');
            } catch (e) {
                try {
                    req = newActiveXObject('Microsoft.XMLHTTP');
                } catch (e) {
                    req = null;
                }
            }
        }
        datei = 'https://www.yogizaehler.de/Besucherzaehler/x_009.php?id=4757940626&auto&f3=green&f4=yellow&f2=$808080&f5=$aaa&schraeg&leg=92d3bea01d&' + Date.now();
        req.open('get', datei);
        req.onreadystatechange = hc;
        req.send(null);
    }

    function hc() {
        if (req.readyState === 4 && req.status === 200) {
            y = req.responseText;
            if (y.length > 0) document.getElementById('r1').innerHTML = y;
        }
    }
    window.setInterval(start, 60000);
}());

[Yogilein]

Also bevor ich auf das Eigentliche eingehe, fällt schon mal auf, dass das <object> ja gar nicht verlinkt ist. Da gibts zwar einen Link, aber der ist im Code oberhalb des <objects> und Du hast den Link nur über den Zähler gelegt.

Das Objekt ist schon verlinkt und zwar direkt aus dem Objekt heraus, was auch wunderbar funktioniert, bis auf den Umstand, dass Google diesen Link nicht erkennt, da es das Objekt nicht ausliest. Daher mein "Kunstgriff" mit der zusätzlichen Verlinkung oberhalb des Codes. Diesen Link erkennt nämlich Google. Und selbstverständlich ist es genau der gleiche Link, der auch aus dem Objekt kommt.

Ein Klick irgendwo auf das Objekt (also auf den Besucherzähler) ruft somit die Seite https://www.yogizaehler.de auf.

Ich hoffe, dass jetzt einiges klarer ist und daher nochmals meine Ausgansfrage: Wie kann ich auf das eingebundene Objekt einen Link setzen, den Google erkennt und der syntaxmäßig besser gelöst ist, als meine Krücke oben?

[supervisior]

Naja, ganz einfach einen stinknormalen Link auf ein Bild oder Text setzen. So wie man das halt macht, wenn man was verlinken will. Dass Dein Code in Sachen XSS und object nicht safe ist, ist Dir aber nicht zufällig aufgefallen.....?

[Hanzo2012]

Geh mal auf: https://csp-evaluator.withgoogle.com/

In das Textfeld gibst dann mal den Javascript Code, der da für den Zähler verwendet wird und lässt den Code prüfen:

Ich glaube, da hast du was falsch verstanden.
Das Tool kann kein Javascript prüfen, sondern es prüft die Content Security Policy-Header, die der Server ausliefert.

[supervisior]

Ich glaube, da hast du was falsch verstanden.
Das Textfeld ist nicht für Javascript-Code gedacht.

Deswegen ist es trotzdem möglich den Code zu validieren...., zumal daraus ersichtlich wird, dass trotz gegenteiliger Meinung des TE es damit möglich ist entsprechenden malignen Code über das <object> einzuschleusen, weil sowohl er als auch der Host von dem der Zähler kommt kein XSS Schutz besteht.

[Hanzo2012]

Das von dir verlinkte Tool kann kein Javascript validieren. Es guckt sich einfach nur die Content Security Policy-Header an, die der Server sendet, bzw. die man ins Textfeld reinkopiert.

[supervisior]

Das von dir verlinkte Tool kann kein Javascript validieren. Es guckt sich einfach nur die Content Security Policy-Header an, die der Server sendet, bzw. die man ins Textfeld reinkopiert.

Ja und? Wird die Sache deswegen harmlos?

Ich habe nichts gegen das object Tag, jedoch sehr wohl dann, wenn man Sourcen darüber von einem anderen Host nachläd, die dazu gegeignet sind Anwender zu schädigen und weder Ursprungs-Host noch Ziel Host einen XSS Schutz haben!

[Hanzo2012]

Hier ist so ein Zähler eingebunden (ganz nach unten scrollen):
https://www.yogifotos.de/

Der Zähler wird in einem iframe geladen.
Ein <object> sehe ich weder im Code der einbindenden Seite noch im Code des iframes ...

Der Javascript-Code des Zählers kann auf keinen Fall auf Informationen im Kontext der einbindenden Seite zugreifen, dafür braucht's keine CSP-Header.

[supervisior]

Du bist auf der falschen Seite: https://www.wanderfreunde-buerstadt.de/

[Hanzo2012]

Also zunächst mal: Die CSP-Header müsste die einbindende Seite mitliefern, nicht die eingebundene Seite. CSP-Headern einer fremden, nicht vertrauenswürdigen Seite könnte man ohnehin nicht trauen, da diese ja auch jederzeit wieder entfernt oder geändert werden könnten.

Dann ist noch die Frage: Wenn ich über ein <object> eine fremde Seite einbinde (verschiedene Domain), hat diese dann (über Javascript) überhaupt Zugriff auf den Kontext der einbindenden Seite, um z. B. Cookies zu klauen? Ich denke nicht. Das dürfte ähnlich geregelt sein wie bei iframes, eben um solche bösen Sachen von vornherein zu unterbinden.

[supervisior]

Also zunächst mal: Die CSP-Header müsste die einbindende Seite mitliefern, nicht die eingebundene Seite. CSP-Headern einer fremden, nicht vertrauenswürdigen Seite könnte man ohnehin nicht trauen, da diese ja auch jederzeit wieder entfernt oder geändert werden könnten.

Dann ist noch die Frage: Wenn ich über ein <object> eine fremde Seite einbinde (verschiedene Domain), hat diese dann (über Javascript) überhaupt Zugriff auf den Kontext der einbindenden Seite, um z. B. Cookies zu klauen? Ich denke nicht. Das dürfte ähnlich geregelt sein wie bei iframes, eben um solche bösen Sachen von vornherein zu unterbinden.

Ich will Dir nichts nichts unterstellen, aber Du relativierst gerade und das wirkt als würdest Du das Ganze verharmlosen wollen. Fakt ist, dass man mittels <object> etwas nachlädt, was schon unter PHP nur möglich wäre, wenn man die Sicherheit aufweicht. In HTML wird es deswegen weder besser noch wird das dadurch sicher(er). Fakt ist ebenso, dass eine Seite ohne entsprechende CSP Header aus dem Verkehr genommen werden müsste. Wenn man denn wirklich einen Zähler haben will, dann soll man das entsprechend richtig machen, also max. mit statischen Sourcen und eben keine PHP Seite.

[Hanzo2012]

Ich denke in der Tat, dass es harmlos ist, weil ich keine Möglichkeit für einen Angriff sehe. Javascript-Code, der im <object> von einer fremden Domain geladen wird, dürfte genau wie beim <iframe> keinerlei Zugriff auf die einbindende Seite haben.

Dein Vergleich zwischen PHP und HTML ist Quatsch - sorry. In HTML ist es völlig normal, Ressourcen von anderen Domains zu laden. Denk nur mal an CDNs, Google Analytics, Facebook-Plugins etc.

[supervisior]

Ich denke in der Tat, dass es harmlos ist, weil ich keine Möglichkeit für einen Angriff sehe. Javascript-Code, der im <object> von einer fremden Domain geladen wird, dürfte genau wie beim <iframe> keinerlei Zugriff auf die einbindende Seite haben.

Dein Vergleich zwischen PHP und HTML ist Quatsch - sorry. In HTML ist es völlig normal, Ressourcen von anderen Domains zu laden. Denk nur mal an CDNs, Google Analytics, Facebook-Plugins etc.

Liest Du was ich geschrieben habe? Ich stelle doch das generelle Laden von Sourcen von einem anderen Host nicht in Frage! Also bezeichne es bitte nicht als Quatsch. Nachdem Du es offenbar nicht gesichert weißt, ob sich das object Tag genauso verhält wie bei einem einem iframe, ist es fahrlässig es trotzdem so darzustellen, dass die ganze Aktion harmlos wäre. Auch wenn es object zulässt, dass man darüber eine PHP Seite aufrufen, bzw. einbinden kann, wird die Sache auch nicht besser, eben weil kein XSS Schutz besteht. Und schon das allein gehört sich verboten.

[Hanzo2012]

Ich stelle doch das generelle Laden von Sourcen von einem anderen Host nicht in Frage!

Doch, irgendwie schon, wenn du sagst, dass man das in PHP nicht machen kann und dass es in HTML deshalb erst recht schlecht ist.

Nachdem Du es offenbar nicht gesichert weißt, ob sich das object Tag genauso verhält wie bei einem einem iframe, ist es fahrlässig es trotzdem so darzustellen, dass die ganze Aktion harmlos wäre.

Ein kurzer Test bestätigt meine Annahme: https://jsfiddle.net/xczh6u7a/
Öffne die Konsole, da kommt eine Fehlermeldung, sobald ich versuche auf die Cookies der einbindenden Seite zuzugreifen.

Auch wenn es object zulässt, dass man darüber eine PHP Seite aufrufen, bzw. einbinden kann, wird die Sache auch nicht besser, eben weil kein XSS Schutz besteht. Und schon das allein gehört sich verboten.

Was hat jetzt PHP damit zu tun? Ist doch total egal, womit die Seite erzeugt wird.

Bezüglich XSS-Schutz: Nochmal: Die CSP-Header müssen von der einbindenden Seite kommen, um XSS zu verhindern. Nicht von der eingebundenen Seite. Das ist also kein Vorwurf, den du dem Thread-Ersteller machen kannst.

[supervisior]

Bezüglich XSS-Schutz: Nochmal: Die CSP-Header müssen von der einbindenden Seite kommen, um XSS zu verhindern. Nicht von der eingebundenen Seite. Das ist also kein Vorwurf, den du dem Thread-Ersteller machen kannst.

Die Ausgangslage war zu Beginn eine ganz andere. Es war immer von einem Link die Rede und das object war in den Link eingebunden, also wie ein verlinktes Bild oder Text. Dadurch, dass ich den TE drum gebeten hatte den tatsächlichen Code nochmal zu posten, ist es eben nicht so mit diesem Link. Dieser steht jetzt parallel zu dem object. Dadurch hat sich die Sache in gewisser Hinsicht relativiert. Nichtsdestotrotz mag ich solche Art von eingebundenen Inhalten von einem fremden Host nicht, was nichts mit dem ansonsten typischen Einbinden von statischen Sourcen von einem anderen Host zu tun hat. Nicht, dass Du mir da wieder was falsches in den Mund legst.

Du darfst immer versuchen mich eines Besseren zu belehren, aber nachdem Du keine Lust hast Deine Aussage durch entsprechende Quellen zu unterlegen, bleibt Deine Bewertung eine Spekulation. Wenn ich das Gegenteil behaupte, wärs zwar auch spekulativ, aber in Sachen Sicherheit gilt im Zweifelsfalle lieber den worst case zu unterstützen. Deswegen halte ich es auch für grob fahrlässig, was Du da äußerst.