जैसा कि बी-कॉन का उल्लेख है, हमलावर कंप्यूटर पर बैठा नहीं है, इसलिए वर्तमान उपयोगकर्ता के सत्र का शोषण करने के लिए आपकी साइट पर दुर्भावनापूर्ण कोड पास करने के साधन के रूप में eval() पहले से ही आपकी स्क्रिप्ट में उपयोग किया जा सकता है किसी भी तरह (उदाहरण के लिए एक दुर्भावनापूर्ण लिंक के बाद एक उपयोगकर्ता)।
eval() का खतरा यह है कि जब इसे अनुचित मूल्यों पर निष्पादित किया जाता है, और DOM Based XSS भेद्यता का कारण बन सकता है।
उदा। अपने HTML में निम्न कोड पर विचार (बल्कि काल्पनिक है, लेकिन यह मुद्दा मुझे आशा है कि यह दर्शाता है)
<script>
eval('alert("Your query string was ' + unescape(document.location.search) + '");');
</script>
अब अगर क्वेरी स्ट्रिंग ?foo है तो आप बस बताते हुए एक चेतावनी संवाद मिल निम्नलिखित: Your query string was ?foo
लेकिन क्या यह कोड उपयोगकर्ता को करने की अनुमति देगा उपयोगकर्ताओं को उनकी साइट से http://www.example.com/page.htm?hello%22);alert(document.cookie+%22 पर रीडायरेक्ट करेगा, जहां www.example.com आपकी वेबसाइट है।
इस कोड है कि
alert("Your query string was hello");
alert(document.cookie+"");
(न्यू लाइनों स्पष्टता के लिए मेरे द्वारा जोड़ा) को eval() द्वारा निष्पादित किया जाता है संशोधित करता है। अब यह वर्तमान कुकी मूल्य दिखाने से कुछ और दुर्भावनापूर्ण कर सकता है, क्योंकि आवश्यक कोड केवल एन्कोडेड फॉर्म में हमलावर के लिंक द्वारा क्वेरी स्ट्रिंग पर पारित किया जाता है। उदाहरण के लिए, यह संसाधन अनुरोध में हमलावर के डोमेन पर कुकी भेज रहा है, प्रमाणीकरण सत्र को अपहृत करने में सक्षम बनाता है।
यह उपयोगकर्ता/बाहरी इनपुट से किसी भी मूल्य पर लागू होता है जो eval() में सीधे अनियंत्रित और निष्पादित होता है, न केवल यहां क्वेरी स्ट्रिंग के रूप में।
यह * "आम सहमति" * नहीं है। कई अनुभवी डेवलपर्स एफयूडी द्वारा 'eval' के बारे में नाराज हैं। * "Eval बुरा है" * शायद अनुभवी कोडर द्वारा आज कभी नहीं कहा जाता है। यदि आप बेवकूफ हैं, तो यह खतरनाक हो सकता है। लेकिन आम तौर पर यह धीमा, बदसूरत और कोड विकसित करने के लिए कड़ी मेहनत कर रहा है। –
अब, मुझे नहीं पता कि यह प्रश्न कैसे एक अच्छा जवाब प्राप्त कर सकता है ... –