2010-11-24 16 views
8

जहां तक ​​मुझे पता है कि इसे सुरक्षा के कारण जावास्क्रिप्ट में eval() JSON ऑब्जेक्ट्स के लिए खराब अभ्यास माना जाता है। यदि JSON किसी अन्य सर्वर से आता है तो मैं इस चिंता को समझ सकता हूं।क्यों eval() JSON?

लेकिन JSON मेरे अपने सर्वर द्वारा प्रदान की जाती है और का उपयोग कर बनाया गया है तो PHP के json_encode (आइए हम मान लेते यह गाड़ी नहीं है भी नहीं), यह वैध बस eval() का उपयोग जे एस में JSON को पढ़ने के लिए या वहाँ किसी भी सुरक्षा समस्या मैं कर रहे हैं करने के लिए है वर्तमान में नहीं सोच सकते हैं?

मैं वास्तव में एक JSON पार्सर को गतिशील रूप से लोड करने के साथ सौदा नहीं करना चाहता हूं और eval() का उपयोग करने में खुशी होगी।

पीएस: यदि यह उपलब्ध है तो मैं स्पष्ट रूप से मूल JSON ऑब्जेक्ट का उपयोग करूँगा, लेकिन आईई/ओपेरा के लिए eval() पर वापस आना चाहता हूं।

+2

जावास्क्रिप्ट का 'eval' * किसी भी * जावास्क्रिप्ट कोड का मूल्यांकन करेगा और न केवल छोटे सबसेट जो JSON के बराबर है। – Gumbo

+0

बेशक यह आपके डेटा को एन्कोड करना अच्छा है, लेकिन आप हमेशा के लिए एक ही कोडबेस बनाए रखने के लिए नहीं जा रहे हैं (उम्मीद है कि), अंततः किसी और को इसे बनाए रखने की आवश्यकता होगी, और यदि कोई बग फिक्स का एक नया हिस्सा है तो कोई फिक्स करता है यह और यह एन्कोडिंग विधि को कॉल नहीं करता है, या यह इसे कॉल करता है लेकिन गलत स्थान पर - और यह एक सुरक्षा भेद्यता खोलता है - दूसरी सुरक्षा नेट होने पर फॉलबैक के रूप में शर्मनाक पीआर घोषणा के बीच अंतर हो सकता है), महंगी मुकदमे और कानूनी परिणाम, मध्यम-स्तरीय सुरक्षा नेट को ठीक करने के लिए एक साधारण कोड पैच बनाम। – BrainSlugs83

+0

विचार करने की दूसरी बात भी रखरखाव है - अच्छी तरह से ज्ञात मानकों का पालन करना समय के आने पर कोड के स्वामित्व को किसी अन्य डेवलपर/टीम आदि में स्थानांतरित करना आसान बनाता है - जो कि अपने स्वयं के अधिकार में बहुत शक्तिशाली है, लेकिन सुरक्षा के संदर्भ में इसे रखने के लिए: डेवलपर्स जो जानते हैं कि उनका कोड क्या कर रहा है और यह कैसे काम करता है (क्योंकि यह आपके विशेष आला के लिए मानकीकृत सर्वोत्तम प्रथाओं का उपयोग करता है) उन चीज़ों को डालने की संभावना कम होने जा रहा है जो चीजों को डरते हैं और दुर्घटना, आदि द्वारा नई सुरक्षा त्रुटियों को जोड़ता है – BrainSlugs83

उत्तर

7

तरीके कि आपकी सुरक्षा के साथ समझौता किया जा सकता है की एक संख्या हैं।

  • मध्य हमलों में मैन सैद्धांतिक रूप से क्लाइंट को दिए जा रहे डेटा की सामग्री को बदल सकता है।
  • आपके सर्वर यातायात को कहीं और अवरुद्ध किया जा सकता है और विभिन्न सामग्री प्रदान की जा सकती है (एमआईएम हमले के समान नहीं)
  • आपके सर्वर से समझौता किया जा सकता है और डेटा स्रोत को छेड़छाड़ की जा सकती है।

और ये केवल साधारण उदाहरण हैं। एक्सएसएस बुरा है।

+1

यदि सर्वर से समझौता किया गया है, तो हमलावर मूल पृष्ठ को संशोधित कर सकता है। – SLaks

+1

हमेशा नहीं। (चार और वर्ण) – zzzzBov

+0

@zzzzBov: क्या आप विस्तृत कर सकते हैं? अगर किसी ने मेरे कनेक्शन पर नियंत्रण लिया है तो वह कुछ भी कुशलतापूर्वक उपयोग कर सकता है - और जेएसओएन की बजाय जेएस में हेरफेर करने के लिए यह और अधिक प्रभावी है। – NikiC

9

आपके परिदृश्य में, प्रश्न बन जाता है, PHP को जावास्क्रिप्ट को निष्पादित करने के लिए कहां मिल रहा है? क्या वह चैनल सुरक्षित है, और संभावित उपयोगकर्ता हेरफेर से मुक्त है? क्या होगा यदि आप उस चैनल को सीधे नियंत्रित नहीं करते हैं?

+0

मुझे नहीं पता कि उपयोगकर्ता यहां क्या उपयोग कर सकता है। मैं 'json_encode' के साथ आउटपुट का सही ढंग से निर्माण करता हूं। इस प्रकार उपयोगकर्ता केवल JSON की सामग्री में हेरफेर कर सकता है, न कि यह वाक्यविन्यास है। इस प्रकार मुझे कोई रास्ता नहीं दिख रहा है कि वह मनमाना जेएस इंजेक्ट कैसे कर सकता है। – NikiC

+2

@nikic: मैन-इन-द-बीच हमलों के बारे में सोचें। – Gumbo

+1

@ गम्बो: एक मैन-इन-द-बीच सीधे जावास्क्रिप्ट में हेरफेर कर सकता है। यदि आप जेएस को हैक कर सकते हैं तो JSON को हैकिंग क्यों परेशान करते हैं? – NikiC

3
स्पष्ट सुरक्षा के मुद्दों के अलावा

:

  1. मूल निवासी JSON तेजी से होता है
  2. आप को "लोड" एक JSON पार्सर की जरूरत नहीं है यह JavaScript इंजन के लिए सिर्फ एक और समारोह कॉल है
+1

ठीक है, * कुछ * लोग अभी भी आईई और ओपेरा के लिए समर्थन चाहते हैं - मैं उनमें से एक हूं। जाहिर है, अगर मूल JSON ऑब्जेक्ट उपलब्ध है, तो मैं इसे कॉल करूंगा। – NikiC

+1

ओपेरा? आप किस ओपेरा का संस्करण उपयोग कर रहे हैं? ओपेरा के पास लगभग एक साल के लिए जेएसओएन समर्थन है। साथ ही, आप अभी भी क्रॉकफोर्ड JSON पर फ़ॉलबैक कर सकते हैं जो * सामान को निकालने से पहले सत्यापन * करता है। –

+0

@ इवो: मैं वास्तव में वास्तव में ऐसा करता हूं। लेकिन मैं नहीं चाहता, अगर यह आवश्यक नहीं है;) – NikiC

0

युक्ति: जेएसओएन का उपयोग करते हुए एएसपीनेट में खराब है क्योंकि डेटटाइम का खराब becuase पार्सिंग सर्वर और क्लाइंट के बीच अलग है, इसलिए हम एक specia का उपयोग करते हैं l जावास्क्रिप्ट में तारीख deserialize करने के लिए समारोह। मुझे यकीन नहीं है कि क्या PHP में एक ही समस्या है लेकिन इसका उल्लेख उल्लेखनीय है। इस बाहर

-2

गंभीरता से "रोकथाम का एक औंस इलाज के एक पाउंड के लायक है"? यहां पर कुछ लोग पागल हैं। यदि आप JSON वितरित कर रहे हैं और आपको पता है कि यह सुरक्षित है, तो यह फ़ॉलबैक (*) से eval(); IE के लिए जेएस lib के बजाय ठीक है। आखिरकार, आईई उपयोगकर्ताओं के बारे में चिंता करने के लिए बहुत कुछ है।

और मैन-इन-द-मध्य तर्क बुलश * टी है।

(*) शब्द वापस आने और सुरक्षित बोल्ड में हैं क्योंकि यहाँ कुछ लोग उन्हें नहीं देखा।

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