W WebKit pojawia się następujący błąd w moim JavaScript:
Odmówił wykonania skryptu JavaScript. Kod źródłowy skryptu znaleziony w żądaniu.
Kod jest przeznaczony dla spinner JavaScript, patrz ASCII Art .
Kod działał poprawnie i nadal działa poprawnie w Camino i Firefox. Wydaje się, że błąd pojawia się tylko wtedy, gdy strona jest zapisywana za pomocą POST, a następnie pobierana za pomocą GET. Dzieje się tak zarówno w Chrome / Mac, jak i Safari / Mac.
Czy ktoś wie, co to oznacza i jak to naprawić?
Odpowiedzi:
Jest to środek bezpieczeństwa mający na celu zapobieganie atakom XSS (cross-site scripting) .
Dzieje się tak, gdy jakiś kod JavaScript jest wysyłany do serwera za pośrednictwem żądania HTTP POST i ten sam kod wraca za pośrednictwem odpowiedzi HTTP. Jeśli Chrome wykryje tę sytuację, skrypt nie zostanie uruchomiony i pojawi się komunikat o błędzie Refused to execute a JavaScript script. Source code of script found within request.
Zobacz także ten post na blogu o szczegółach bezpieczeństwa: nowe funkcje zabezpieczeń .
Tę „funkcję” można wyłączyć, wysyłając niestandardowy nagłówek HTTP X-XSS-Protectionna stronie, której dotyczy problem.
X-XSS-Protection: 0
Krótka odpowiedź : odśwież stronę po przesłaniu kodu javascript lub kliknij adres URL, który wyświetli stronę, którą edytujesz.
Długa odpowiedź : ponieważ tekst, który wypełniłeś w formularzu, zawiera javascript, a przeglądarka niekoniecznie wie, że jesteś źródłem javascript, bezpieczniej jest, aby przeglądarka założyła, że nie jesteś źródłem tego JS oraz nie uruchamiaj go.
Przykład : załóżmy, że podałem ci link do twojego e-maila lub facebooka z jakimś javascriptem. I wyobraź sobie, że javascript przesłałby wszystkim twoim znajomym mój fajny link. Tak więc gra polegająca na uzyskaniu tego linku do wywołania staje się po prostu znalezieniem miejsca do wysłania kodu javascript w taki sposób, aby znalazł się na stronie.
Chrome i inne przeglądarki WebKit próbują zminimalizować to ryzyko, nie wykonując żadnego kodu JavaScript znajdującego się w odpowiedzi, jeśli był obecny w żądaniu. Mój nikczemny atak zostałby udaremniony, ponieważ Twoja przeglądarka nigdy nie uruchomiłaby tego JS.
W twoim przypadku przesyłasz go do pola formularza. Opublikowanie pola formularza spowoduje renderowanie strony, na której zostanie wyświetlony kod JavaScript, powodując zaniepokojenie przeglądarki. Jeśli jednak Twój skrypt javascript jest naprawdę zapisany, kliknięcie tej samej strony bez przesłania formularza pozwoli na jego wykonanie.
Jak powiedzieli inni, dzieje się tak, gdy odpowiedź HTTP zawiera ciąg JavaScript i / lub HTML, który również był w żądaniu. Zwykle jest to spowodowane wprowadzeniem kodu JS lub HTML do pola formularza, ale może również zostać wywołane innymi sposobami, na przykład ręcznym dostosowaniem parametrów adresu URL.
Problem polega na tym, że ktoś ze złymi intencjami może umieścić dowolny kod JS jako wartość, połączyć się z tym adresem URL ze złośliwą wartością JS i sprawić użytkownikom kłopoty.
W prawie każdym przypadku można to naprawić, kodując odpowiedź w formacie HTML , chociaż są wyjątki. Na przykład nie będzie to bezpieczne dla treści wewnątrz <script>tagu. Inne konkretne przypadki można traktować inaczej - na przykład wprowadzenie danych wejściowych do adresu URL jest lepiej obsługiwane przez kodowanie adresu URL.
Jak wspomniał Kendall Hopkins, może być kilka przypadków, w których faktycznie chcesz, aby JavaScript z danych wejściowych formularza był wykonywany, na przykład tworzenie aplikacji takiej jak JSFiddle . W takich przypadkach radzę przynajmniej przejrzeć dane wejściowe w kodzie zaplecza przed ślepym zapisaniem go z powrotem. Następnie możesz użyć wspomnianej przez niego metody, aby zapobiec blokowaniu XSS (przynajmniej w Chrome), ale pamiętaj, że otwiera cię to na atakujących.
Użyłem tej hakerskiej sztuczki PHP tuż po zatwierdzeniu do bazy danych, ale przed renderowaniem skryptu z mojego _GETżądania .:
if(!empty($_POST['contains_script'])) {
echo "<script>document.location='template.php';</script>";
}
To było dla mnie najtańsze rozwiązanie.