मैं वेबपृष्ठ में उपयोगकर्ता कोड को सुरक्षित रूप से "eval" कैसे करूं?

मैं प्रोग्रामिंग अवधारणाओं को पढ़ाने के लिए वेबपैप पर काम कर रहा हूं। वेबपृष्ठों में प्रोग्रामिंग अवधारणा के बारे में कुछ पाठ है, फिर प्रोग्रामिंग समस्या का उत्तर देने के लिए उपयोगकर्ता को जावास्क्रिप्ट कोड को टेक्स्ट एडिटर विंडो में टाइप करने दें। जब उपयोगकर्ता "सबमिट" पर क्लिक करता है, तो मैं यह देखने के लिए टाइप किए गए पाठ का विश्लेषण करता हूं कि क्या उन्होंने समस्या हल की है या नहीं। उदाहरण के लिए, मैं उनसे पूछता हूं कि "f नामक एक फ़ंक्शन लिखें जो इसके तर्क में तीन जोड़ता है"। ब्राउज़र या कंसोल कार्यों संभालने बिनामैं वेबपृष्ठ में उपयोगकर्ता कोड को सुरक्षित रूप से "eval" कैसे करूं?

भागो JSLint सख्त सेटिंग्स के साथ पाठ पर, विशेष रूप से:

यहाँ है कि मैं क्या उपयोगकर्ता के टेक्स्ट का विश्लेषण करने कर रहा हूँ है।
यदि कोई त्रुटि है, तो त्रुटियां दिखाएं और रोकें।
eval(usertext);
असाइनमेंट पास करने के लिए शर्तों के माध्यम से लूप, eval(condition)। एक उदाहरण की स्थिति "f(1)===4" है। शर्तें विश्वसनीय स्रोत से आती हैं।
उत्तीर्ण/असफल स्थितियों को दिखाएं।

मेरे प्रश्न: क्या यह सुरक्षा समस्याओं को रोकने के लिए पर्याप्त है? पागल होने के लिए मैं और क्या कर सकता हूं? क्या मैं चाहता हूं कि ऐसा करने का कोई बेहतर तरीका है?

यदि यह प्रासंगिक है तो मेरा आवेदन पाइथन बैकएंड के साथ Google ऐप इंजन पर है, JQuery का उपयोग करता है, इसमें व्यक्तिगत उपयोगकर्ता खाते हैं।

स्रोत

2011-07-15 Nathan Whitehead

मुझे आश्चर्य है कि jsfiddle के पास कोई स्रोत/नोट उपलब्ध है ... मुझे यकीन है कि यह किसी बिंदु पर साइट पर आता है जो एक्सएसएस या इसी तरह के लिए कमजोर नहीं है।(एक्सएसएस * किसी और को * उस पृष्ठ पर evaled कोड को लिंक देने की इजाजत देता है जो तब उस उपयोगकर्ता को "चलाएगा" जो वास्तव में लिंक देखता है।) –

मुझे कहना है कि जब मैं जेएसलिंट का उपयोग अपने जेएस को स्कैन करने के लिए करता हूं संपीड़न से पहले मुद्दों मैं कोशिश करता हूं और हर सुविधा को अक्षम कर सकता हूं जो कि लेखक की वरीयता का प्रतिनिधित्व करता है और वास्तव में एक कोड मुद्दा नहीं है, तो मैं जो कहता हूं उसका 9 0% अवहेलना करता हूं और गायब अर्ध-कॉलन और इसी तरह की तलाश करता हूं। अगर मैं आप थे तो मैं सोचूंगा कि आपके उपयोगकर्ता 'त्रुटियों' जेएसलिंट को पढ़ने में कितना आनंद ले रहे हैं। – tomfumb

यह एक अच्छा मुद्दा है, मैं "स्टाइलिस्ट" चेक को बंद करने के लिए एक विकल्प जोड़ूंगा। लेकिन मैं डिफ़ॉल्ट रूप से सख्त होना चाहता हूं, परियोजना के बिंदु का हिस्सा साफ जावास्क्रिप्ट प्रोग्रामिंग सिखाना है। –

तो मैं क्या कह सकता हूं कि आप केवल उनके लिए उपयोगकर्ता के इनपुट को eval'ing कर रहे हैं, यह एक सुरक्षा समस्या नहीं है। केवल तभी जब उनके इनपुट को अन्य उपयोगकर्ताओं के लिए eval'd किया गया है, तो आपको कोई समस्या है।

किसी उपयोगकर्ता के इनपुट को इवल करना, स्रोत स्रोत देखने से कोई भी बुरा नहीं है, HTTP हेडर को देखकर, जावास्क्रिप्ट ऑब्जेक्ट्स का निरीक्षण करने के लिए फायरबग का उपयोग करके, आदि। उनके पास पहले से ही सबकुछ तक पहुंच है।

अगर आप अपने कोड को सुरक्षित गूगल काजा http://code.google.com/p/google-caja/

स्रोत

2011-07-15 23:12:58

यह एक अच्छा मुद्दा है। यदि आपके पास फायरबग है, तो आप जो कुछ भी चाहते हैं उसे निकाल सकते हैं। –

मैं यहां सहमत हूं। उपयोगकर्ता के लिए अपने ब्राउज़र में हेरफेर करने में सक्षम होने के लिए यह एक सुरक्षा समस्या नहीं है। पहले से ही ऐसा करने के कई तरीके हैं (फायरबग, ग्रीसमोन्की, प्रतिलिपि स्रोत और इसे संपादित करें, आदि ...)। यह केवल एक सुरक्षा समस्या बन जाता है यदि कोई अन्य उपयोगकर्ता कभी भी किसी ऐसे उपयोगकर्ता से अविश्वसनीय कोड निष्पादित करने में सक्षम होता है जो किसी भिन्न उपयोगकर्ता से संबंधित होता है, जो इसे बिना किसी काम के कर सकता है। – jfriend00

यह वास्तव में एक बहुत अच्छा मुद्दा है। +1 – AlienWebguy

यह एक चाल सवाल है। आपकी वेबसाइट पर eval() उपयोगकर्ता का कोड कोई सुरक्षित तरीका नहीं है।

स्रोत

2011-07-15 23:12:25 AlienWebguy

हां, लेकिन jsfiddle पर विचार करें - यह "स्वीकार्य उपायों के साथ" कैसे किया जा सकता है? –

यह नहीं किया जा सकता की जाँच करने की आवश्यकता है कहा जा रहा है। ब्राउज़र किसी भी संदर्भ में किसी भी प्रकार के कोड को निष्पादित करने के लिए प्रतिबंधित करने के लिए वेब पृष्ठों पर कोई एपीआई प्रदान नहीं करते हैं।

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

फिर भी, कोर प्रश्न का उत्तर यह है कि यह बहुत अधिक है कि यह नहीं किया जा सकता है, और उस उपयोगकर्ता इनपुट पर भरोसा नहीं किया जा सकता है। क्षमा करें:/

स्रोत

2011-07-15 23:14:14 Matchu

प्रमाणीकरण की एक अवधारणा है, Google उपयोगकर्ता खाते हैं। मुझे नहीं पता कि वे जीएई में कैसे कार्यान्वित किए जाते हैं, लेकिन मैं अनुमान लगा रहा हूं कि कुकीज एक सत्र साझा कुंजी या कुछ स्टोर करता है। क्या आप टाइप की गई स्क्रिप्ट के बीच अंतर करने और पोस्ट अनुरोध प्राप्त करने के बारे में कुछ और बता सकते हैं? मैं कैसे अंतर कर सकता हूँ? –

@ नाथन: यदि उपयोगकर्ता पृष्ठ पर लिपि में टाइप करता है, तो यह चलाने के लिए सुरक्षित है, क्योंकि हम इसे सबमिट करने के लिए उपयोगकर्ता को जानते हैं। हालांकि, यदि कोड GET या POST डेटा से आता है, तो एक दुर्भावनापूर्ण उपयोगकर्ता किसी अन्य उपयोगकर्ता को उस अनुरोध को भेजने और उस स्क्रिप्ट को चलाने में चाल कर सकता है। (प्राप्त करने के लिए, यह एक लिंक के साथ आसान है। पोस्ट के लिए, एक ऑटो-सबमिटिंग फॉर्म इतना कठिन नहीं है।) इसलिए, उन अनुरोधों को तब तक अनुमति नहीं दी जानी चाहिए जब तक आप सुनिश्चित न हों कि वे आपकी साइट से आए हैं, जिसका अर्थ है कि आपकी साइट के फॉर्म उस डेटा को शामिल करने की आवश्यकता है जिसमें एक दुर्भावनापूर्ण उपयोगकर्ता नहीं हो सकता है। क्रॉस-साइट अनुरोध जालसाज़ी देखें, और उपयोगकर्ताओं को एक गुप्त टोकन दें। – Matchu

मैं वेबपृष्ठ में उपयोगकर्ता कोड को सुरक्षित रूप से "eval" कैसे करूं?

उत्तर

संबंधित मुद्दे