जावास्क्रिप्ट स्क्रिप्ट निष्पादित करने से इनकार कर दिया। अनुरोध के भीतर मिली स्क्रिप्ट का स्रोत कोड

Question

WebKit में मुझे अपने जावास्क्रिप्ट पर निम्नलिखित त्रुटि मिलती है:

जावास्क्रिप्ट स्क्रिप्ट निष्पादित करने से इनकार कर दिया। अनुरोध के भीतर मिली स्क्रिप्ट का स्रोत कोड।

कोड एक जावास्क्रिप्ट स्पिनर के लिए है, एएससीआईआई आर्ट देखें ।

कोड ठीक काम करता था और अभी भी कैमिनो और फ़ायरफ़ॉक्स में सही ढंग से काम कर रहा है। जब पृष्ठ POST के माध्यम से सहेजा जाता है और फिर GET के माध्यम से पुनर्प्राप्त किया जाता है, तो त्रुटि केवल फेंकी गई लगती है। यह क्रोम / मैक और सफारी / मैक दोनों में होता है।

किसी को पता है कि इसका क्या मतलब है, और इसे कैसे ठीक करें?

Comments

हम्म, शायद मेरे वेबकिट को अपडेट कर दिया गया है। पेज फिर से काम करता है। पृष्ठ के सभी पुराने संशोधन (पृष्ठ के तल पर पुराने संशोधन बटन देखें)।

— डॉकमैन

यह त्रुटि w3schools w3schools.com/js/tryit.asp?filename=tryjs_events के प्रयास संपादक में होती है, स्क्रिप्ट पहली बार निष्पादित की जाती है, लेकिन यह इस समय से अवरुद्ध है "संपादित करें और मुझे क्लिक करें" बटन पर क्लिक करें।

यदि आप "संपादित करें और मुझे क्लिक करें" बटन दबाते हैं, तो textarea की सामग्री (जावास्क्रिप्ट के साथ) एक POST के माध्यम से सर्वर को भेजी जाती है। Chrome पता लगाता है कि जावास्क्रिप्ट सर्वर पर पोस्ट किया गया है और यह दुर्भावनापूर्ण हो सकता है। ब्लॉकिंग XSS हमलों के खिलाफ उपाय है।

— डॉकमैन

यहाँ लिंक है जो दिखाता है कि हेडर X-

— XSS-

Answer 1

यह XSS (क्रॉस-साइट स्क्रिप्टिंग) हमलों को रोकने के लिए एक सुरक्षा उपाय है ।

यह तब होता है जब कुछ जावास्क्रिप्ट कोड को HTTP POST अनुरोध के माध्यम से सर्वर पर भेजा जाता है, और वही कोड HTTP प्रतिक्रिया के माध्यम से वापस आता है। यदि Chrome इस स्थिति का पता लगाता है, तो स्क्रिप्ट को चलाने से मना कर दिया जाता है, और आपको त्रुटि संदेश मिलता है Refused to execute a JavaScript script. Source code of script found within request।

गहराई में सुरक्षा के बारे में इस ब्लॉगपोस्ट को भी देखें : नई सुरक्षा सुविधाएँ ।

Comments

किसी तरह का संदर्भ देखना अच्छा होगा।

— kangax

लेकिन क्या यह कोई समस्या है? यदि हम इस संदेश को अनदेखा करते हैं तो यह ठीक है?

— 12

@Greg ब्राउज़र का उपयोग "स्थिति का पता लगाने" के लिए क्या किया जाता है? यह सिर्फ डेटा में स्ट्रिंग "<स्क्रिप्ट>" की तलाश नहीं कर सकता है?

— पचेरियर

मैं एक्स-एक्सएसएस-प्रोटेक्शन: 0 फिक्स का उपयोग करने के निहितार्थ के बारे में केंडल से नीचे दिए गए उत्तर के उत्तर के बीच कुछ चर्चा देखना चाहूंगा। क्या यह XSS हमलों तक की साइट खोलता है? यदि ऐसा है तो इस त्रुटि को हल करने का एक और तरीका है?

— डैंसलमो

संदर्भ है कि आगे यह बताते हैं, blog.chromium.org/2010/01/… चिंतनशील XSS संरक्षण अनुभाग देखें

— h - n

Answer 2

इस "सुविधा" X-XSS-Protectionको प्रभावित पृष्ठ पर गैर-मानक HTTP हेडर भेजकर अक्षम किया जा सकता है ।

X-XSS-Protection: 0

Comments

सुनिश्चित करें कि जो पेज इस त्रुटि को चालू कर रहा है, उसे इस हेडर के साथ भेजा गया है, न कि पेज सबमिट करने के लिए।

— केंडल हॉपकिंस

@KendallHopkins .... क्या आप मुझे बता सकते हैं कि मैं जावास्क्रिप्ट / जावा के माध्यम से इसका उपयोग कैसे कर सकता हूं?

— एसआरवाई

+1 यह प्रश्न को स्वीकृत उत्तर के विपरीत अच्छी तरह से उत्तर देता है, चेतावनी देता है लेकिन कोई समाधान नहीं देता है।

— जॉनीक्यू

-1 यह क्रोम में समस्या को "ठीक" कर सकता है, लेकिन यह वास्तविक समस्या को हल नहीं करता है - यदि आप ऐसा करते हैं तो आपकी साइट अभी भी क्रॉस-साइट स्क्रिप्टिंग हमलों (वास्तव में अधिक संवेदनशील) के लिए असुरक्षित है। वास्तविक समाधान, जैसा कि @Greg ने कहा, लेकिन स्पष्ट रूप से नहीं कहा, अनुरोध में सबमिट की गई प्रतिक्रिया में HTML / JS को वापस नहीं भेजना है। उनके द्वारा दिए गए लिंक को पढ़कर यह स्पष्ट हो जाना चाहिए।

— सिरफोटा कोटा

@sfarbota ऐसे कई मामले हैं जहां यह सुरक्षा खराब है। उदाहरण के लिए यह कई सीएमएस सिस्टम को तोड़ता है, जहां जेएस को वापस करने के लिए यह पूरी तरह से स्वीकार्य है कि आप संपादन कर रहे हैं। लेकिन आपकी बात के लिए, मैं किसी साइट पर हर पृष्ठ पर इसे जोड़ने के लिए कंबल की सलाह नहीं दूंगा और यह केवल उन मामलों में आवश्यक है जहां एक डेवलपर इस त्रुटि को मारता है।

— केंडल हॉपकिंस

Answer 3

संक्षिप्त उत्तर : जावास्क्रिप्ट के अपने प्रारंभिक प्रस्तुत करने के बाद पृष्ठ को ताज़ा करें, या उस URL को हिट करें जो आपके द्वारा संपादित किए जा रहे पृष्ठ को प्रदर्शित करेगा।

लंबा उत्तर : क्योंकि आपके द्वारा फ़ॉर्म में भरे गए पाठ में जावास्क्रिप्ट शामिल है, और ब्राउज़र को यह पता नहीं है कि आप जावास्क्रिप्ट के स्रोत हैं, यह ब्राउज़र के लिए यह मान लेना सुरक्षित है कि आप इस JS के स्रोत नहीं हैं, और इसे न चलाएं।

एक उदाहरण : मान लीजिए कि मैंने आपको अपना ईमेल या फेसबुक इसमें कुछ जावास्क्रिप्ट के साथ दिया। और कल्पना कीजिए कि जावास्क्रिप्ट आपके सभी दोस्तों को मेरे अच्छे लिंक का संदेश देगा। तो, उस लिंक को प्राप्त करने का खेल बस हो जाता है, जावास्क्रिप्ट भेजने के लिए एक जगह ढूंढें जैसे कि यह पृष्ठ में शामिल किया जाएगा।

Chrome और अन्य WebKit ब्राउज़र इस जोखिम को कम करने की कोशिश करते हैं, जो कि प्रतिक्रिया में मौजूद किसी भी जावास्क्रिप्ट को निष्पादित न करके, यदि यह अनुरोध में मौजूद था। मेरे नापाक हमले को नाकाम किया जाएगा क्योंकि आपका ब्राउज़र कभी भी जेएस नहीं चलाएगा।

आपके मामले में, आप इसे फ़ॉर्म फ़ील्ड में सबमिट कर रहे हैं। प्रपत्र फ़ील्ड का पोस्ट उस पृष्ठ के रेंडर का कारण होगा जो जावास्क्रिप्ट प्रदर्शित करेगा, जिससे ब्राउज़र को चिंता होगी। यदि आपकी जावास्क्रिप्ट वास्तव में बचाई गई है, हालांकि, फॉर्म सबमिट किए बिना उसी पेज को हिट करने से यह निष्पादित करने की अनुमति देगा।

Answer 4

जैसा कि दूसरों ने कहा है, यह तब होता है जब एक HTTP प्रतिक्रिया में एक जावास्क्रिप्ट और / या HTML स्ट्रिंग होता है जो अनुरोध में भी था। यह आमतौर पर जेएस या एचटीएमएल को एक फार्म क्षेत्र में प्रवेश करने के कारण होता है, लेकिन इसे अन्य तरीकों से भी ट्रिगर किया जा सकता है जैसे कि यूआरएल के मापदंडों को मैन्युअल रूप से जोड़ना।

इसके साथ समस्या यह है कि बुरे इरादों वाला कोई व्यक्ति जेएस को मूल्य के रूप में जो भी चाहे डाल सकता है, उस URL को दुर्भावनापूर्ण JS मान के साथ लिंक कर सकता है और आपके उपयोगकर्ताओं को परेशान कर सकता है।

में लगभग हर मामले, इस द्वारा निर्धारित किया जा सकता है प्रतिक्रिया एन्कोडिंग एचटीएमएल , हालांकि अपवाद हैं। उदाहरण के लिए, यह एक <script>टैग के अंदर सामग्री के लिए सुरक्षित नहीं होगा । अन्य विशिष्ट मामलों को अलग तरीके से संभाला जा सकता है - उदाहरण के लिए, URL में इनपुट को इंजेक्ट करना URL एन्कोडिंग द्वारा बेहतर तरीके से परोसा जाता है।

जैसा कि केंडल हॉपकिंस ने उल्लेख किया है, ऐसे कुछ मामले हो सकते हैं जब आप वास्तव में जावास्क्रिप्ट को फॉर्म इनपुट से निष्पादित करना चाहते हैं , जैसे कि JSFiddle जैसे एप्लिकेशन बनाना । उन मामलों में, मैं आपको सलाह दूंगा कि आप अपने बैकएंड कोड में इनपुट के माध्यम से कम से कम स्क्रब करें, इसे आँख बंद करके लिखने से पहले। उसके बाद, आप XSS रुकावट (कम से कम क्रोम में) को रोकने के लिए उनके द्वारा बताई गई विधि का उपयोग कर सकते हैं, लेकिन ध्यान रखें कि यह आपको हमलावरों के लिए खोल रहा है।

Answer 5

डेटाबेस के लिए प्रतिबद्ध होने के बाद मैंने इस हैक किए गए PHP ट्रिक का उपयोग किया, लेकिन स्क्रिप्ट मेरे _GETअनुरोध से प्रदान की गई है :

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

यह मेरे लिए सबसे सस्ता उपाय था।