Weigerte sich, ein JavaScript-Skript auszuführen. Quellcode des Skripts innerhalb der Anfrage gefunden

81

In WebKit wird in meinem JavaScript der folgende Fehler angezeigt:

Weigerte sich, ein JavaScript-Skript auszuführen. Der Quellcode des Skripts, der in der Anfrage gefunden wurde.

Der Code ist für einen JavaScript-Spinner, siehe ASCII Art .

Der Code funktionierte einwandfrei und funktioniert in Camino und Firefox immer noch ordnungsgemäß. Der Fehler scheint nur ausgelöst zu werden, wenn die Seite über einen POST gespeichert und dann über einen GET abgerufen wird. Dies geschieht sowohl in Chrome / Mac als auch in Safari / Mac.

Weiß jemand, was dies bedeutet und wie man das behebt?

javascript code-injection

— Doekman
quelle

Hmm, wahrscheinlich wurde mein WebKit aktualisiert. Die Seite funktioniert wieder. Auch alle alten Revisionen der Seite (siehe Schaltfläche Alte Revisionen unten auf der Seite).

— Doekman

Dieser Fehler tritt im tryit-Editor von w3schools w3schools.com/js/tryit.asp?filename=tryjs_events auf. Das Skript wird zum ersten Mal ausgeführt, aber ab dem Moment blockiert, in dem Sie auf die Schaltfläche "Bearbeiten und auf mich klicken" klicken.

1

Wenn Sie auf die Schaltfläche "Bearbeiten und auf mich klicken" klicken, wird der Inhalt des Textbereichs (mit dem Javascript) über einen POST an den Server gesendet. Chrome erkennt, dass Javascript auf dem Server veröffentlicht wird und möglicherweise schädlich ist. Die Blockierung ist die Maßnahme gegen XSS-Angriffe.

— Doekman

Hier ist ein Link, der zeigt, wie der Header X-XSS-Protection gesetzt wird: stackoverflow.com/questions/4635403/…

— hh_s

67

Dies ist eine Sicherheitsmaßnahme, um XSS- Angriffe (Cross-Site Scripting) zu verhindern .

Dies geschieht, wenn JavaScript-Code über eine HTTP-POST-Anforderung an den Server gesendet wird und derselbe Code über die HTTP-Antwort zurückgegeben wird. Wenn Chrome diese Situation erkennt, wird die Ausführung des Skripts verweigert und Sie erhalten die Fehlermeldung Refused to execute a JavaScript script. Source code of script found within request.

Lesen Sie auch diesen Blogpost über Sicherheit im Detail: Neue Sicherheitsfunktionen .

— Greg
quelle

5

Es wäre schön, eine Art Referenz zu sehen.

— Kangax

Aber ist das ein Problem? Bedeutet das, dass es in Ordnung ist, wenn wir diese Nachricht ignorieren?

— Samach

@ Greg Welcher Algorithmus wird von Browsern verwendet, um "die Situation zu erkennen"? Es kann nicht nur nach der Zeichenfolge "<script>" in den Daten suchen, oder?

— Pacerier

1

Ich würde gerne eine Diskussion zwischen dieser Antwort und der Antwort von Kendall unten bezüglich der Auswirkungen der Verwendung des X-XSS-Protection: 0-Fixes sehen. Öffnet es die Site für XSS-Angriffe? Wenn ja, gibt es eine andere Möglichkeit, diesen Fehler zu beheben?

— Dansalmo

Referenz, die dies weiter erklärt, blog.chromium.org/2010/01/… Siehe Abschnitt Reflective XSS Protection

— h - n

131

Diese "Funktion" kann deaktiviert werden, indem der nicht standardmäßige HTTP-Header X-XSS-Protectionauf der betroffenen Seite gesendet wird.

X-XSS-Protection: 0

— Kendall Hopkins
quelle

2

Stellen Sie sicher, dass die Seite, die diesen Fehler auslöst, mit diesem Header gesendet wird und keine Seite sendet.

— Kendall Hopkins

@KendallHopkins .... Kannst du mir bitte sagen, wie ich das über Javascript / Java verwenden kann?

— SRy

+1 Dies beantwortet die Frage gründlich im Gegensatz zur akzeptierten Antwort, warnt jedoch, gibt aber keine Lösung.

— JohnnyQ

2

-1 Dies kann das Problem in Chrome "beheben", löst jedoch nicht das eigentliche Problem. Ihre Website ist weiterhin anfällig für Cross-Site-Scripting-Angriffe (in der Tat anfälliger), wenn Sie dies tun. Die eigentliche Lösung besteht, wie @Greg anspielte, aber nicht explizit sagte, darin, HTML / JS in der Antwort, die in der Anfrage übermittelt wurde, nicht zurückzusenden. Das Lesen der von ihm bereitgestellten Links hätte dies deutlich machen müssen.

— Sfarbota

@sfarbota Es gibt viele Fälle, in denen dieser Schutz schlecht ist. Beispielsweise werden viele CMS-Systeme beschädigt, bei denen es durchaus akzeptabel ist, das von Ihnen bearbeitete JS zurückzugeben. Aber bis zu Ihrem Punkt würde ich nicht empfehlen, dies pauschal zu jeder Seite einer Site hinzuzufügen, und es wird wahrscheinlich nur in Fällen benötigt, in denen ein Entwickler auf diesen Fehler stößt.

— Kendall Hopkins

15

Kurze Antwort : Aktualisieren Sie die Seite, nachdem Sie das Javascript zum ersten Mal eingereicht haben, oder klicken Sie auf die URL, die die Seite anzeigt, die Sie bearbeiten.

Lange Antwort : Da der Text, den Sie in das Formular ausgefüllt haben, Javascript enthält und der Browser nicht unbedingt weiß, dass Sie die Quelle des Javascript sind, ist es für den Browser sicherer anzunehmen, dass Sie nicht die Quelle dieses JS sind, und nicht ausführen.

Ein Beispiel : Angenommen, ich habe Ihnen einen Link zu Ihrer E-Mail oder Ihrem Facebook mit etwas Javascript gegeben. Und stell dir vor, das Javascript würde all deinen Freunden meinen coolen Link schicken. Das Spiel, bei dem dieser Link aufgerufen wird, wird einfach. Suchen Sie sich einen Ort, an dem Sie das Javascript so senden können, dass es auf der Seite enthalten ist.

Chrome und andere WebKit-Browser versuchen, dieses Risiko zu verringern, indem sie kein Javascript ausführen, das in der Antwort enthalten ist, wenn es in der Anforderung vorhanden war. Mein schändlicher Angriff würde vereitelt, weil Ihr Browser diesen JS niemals ausführen würde.

In Ihrem Fall senden Sie es in ein Formularfeld. Das Feld "Beitrag des Formulars" bewirkt ein Rendern der Seite, auf der Javascript angezeigt wird, was den Browser beunruhigt. Wenn Ihr Javascript jedoch wirklich gespeichert ist, kann es ausgeführt werden, wenn Sie dieselbe Seite ohne Senden des Formulars aufrufen.

— Koos Kleven
quelle

1

Wie andere gesagt haben, geschieht dies, wenn eine HTTP-Antwort eine JavaScript- und / oder HTML-Zeichenfolge enthält, die ebenfalls in der Anforderung enthalten war. Dies wird normalerweise durch die Eingabe von JS oder HTML in ein Formularfeld verursacht, kann aber auch auf andere Weise ausgelöst werden, z. B. durch manuelles Anpassen der URL-Parameter.

Das Problem dabei ist, dass jemand mit schlechten Absichten das gewünschte JS als Wert festlegen, mit dem böswilligen JS-Wert auf diese URL verlinken und Ihren Benutzern Probleme bereiten kann.

In fast allen Fällen kann dies durch HTML-Codierung der Antwort behoben werden , obwohl es Ausnahmen gibt. Dies ist beispielsweise für Inhalte in einem <script>Tag nicht sicher . Andere spezielle Fälle können anders behandelt werden. Beispielsweise wird das Einfügen von Eingaben in eine URL besser durch die URL-Codierung unterstützt.

Wie Kendall Hopkins erwähnt, kann es einige Fälle geben , wenn Sie tatsächlich wollen JavaScript von Formulareingaben ausgeführt werden, wie zum Beispiel eine Anwendung wie die Schaffung JSFiddle . In diesen Fällen würde ich empfehlen, dass Sie zumindest die Eingabe in Ihrem Backend-Code durchgehen, bevor Sie ihn blind zurückschreiben. Danach können Sie die von ihm erwähnte Methode verwenden, um die XSS-Blockierung zu verhindern (zumindest in Chrome). Beachten Sie jedoch, dass Sie dadurch für Angreifer geöffnet werden.

— Sfarbota
quelle

0

Ich habe diesen hackigen PHP-Trick verwendet, kurz nachdem ich mich für die Datenbank entschieden habe, aber bevor das Skript aus meiner _GETAnfrage gerendert wird :

if(!empty($_POST['contains_script'])) { 
    echo "<script>document.location='template.php';</script>";
}

Dies war die billigste Lösung für mich.

— gabrielcrowe
quelle