जावास्क्रिप्ट (एक ब्राउज़र में) को हैक करना कितना आसान है?


37

मेरा सवाल जावास्क्रिप्ट सुरक्षा के साथ क्या करना है।

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

लेकिन क्या होगा अगर आपको सर्वर को शामिल किए बिना थोड़ी सुरक्षा की आवश्यकता है? क्या यह संभव है?

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

उपयोगकर्ता के लिए उस चर को संशोधित करना और पहुँच प्राप्त करना कितना आसान है?

मेरी सुरक्षा (और जावास्क्रिप्ट) ज्ञान महान नहीं है। लेकिन अगर एक वैरिएबल वैश्विक दायरे में नहीं है और एक मॉड्यूल पैटर्न के निजी भाग में है, जिसमें केवल गेटर्स हैं, लेकिन बसने वाले नहीं हैं, तो उस स्थिति में भी आप इस चीज को हैक कर सकते हैं?


29
इन सभी लंबे जवाब। संक्षेप में, आपको हेडर का जवाब देने के लिए, "बहुत हैक करने योग्य"। एक दूसरे के साथ आपके पहले 2 सवालों के जवाब देने के लिए, "बिना सर्वर, यू खोई सुरक्षा" और& "नहीं"। 3 जवाब देने के लिए, "बहुत आसान", और अंत में, "हां, आसानी के साथ"। तुम वहाँ जाओ। सभी सवालों के जवाब दिए। : पी
SpYk3HH

मुख्य उदाहरण, किसी भी वेब पेज पर jQuery जोड़ने के बारे में मेरी ब्लॉग पोस्ट देखें। spyk3lc.blogspot.com/2013/05/… अब, युवा पैडावन , आगे बढ़ो और इसे आज़माएं। बस यह देखें कि किसी भी साइट पर jQuery को जोड़ना कितना आसान है, जो पहले से ही नहीं है, फिर javascript की लंबी लाइनों के बिना दृष्टि के किसी भी हिस्से में हेरफेर करने के लिए jquery का उपयोग बहुत आसानी से करें। बूम!
SpYk3HH

7
एक बार, एक डोमेन नाम के लिए पंजीकरण करते समय, फ़ोन नंबर एक आवश्यक फ़ील्ड था, लेकिन वह केवल जावास्क्रिप्ट में लागू किया गया था - सर्वर साइड। इसलिए, मैंने इसे एक फंक्शन (फायरबग का उपयोग करके), और वॉइल को रिडिफाइन करके अक्षम कर दिया! उनके पास मेरा फोन नंबर नहीं है।
इज़्काता

8
manipulate any part of the sight without long lines साइट बनाम दृष्टि
mplungjan

8
पेशेवर वेब प्रोग्रामर को इस तरह की चीज को सही करने की आवश्यकता है। कृप्या। यह व्याकरण की नाज़ी चीज़ से अधिक शर्मिंदगी है :) plus.google.com/u/0/+MonaNomura/posts/h9ywDhfEYxT
mplungjan

जवाबों:


26

कृपया इसे पढ़ने से पहले जोकिम का उत्तर पढ़ें । वह क्लाइंट-साइड भेद्यता के पीछे सामान्य कारणों को शामिल करता है। अब, एक सुझाव के लिए कि आप इस समस्या के आसपास कैसे पहुँच सकते हैं ...

हर अनुरोध पर मैन्युअल रूप से सर्वर के साथ प्रमाणित किए बिना क्लाइंट-सर्वर संचार के लिए एक सुरक्षित योजना:

आप अभी भी सर्वर को अंतिम कहने दे रहे हैं, और सर्वर को अभी भी क्लाइंट के कहे अनुसार सब कुछ मान्य करना होगा, लेकिन यह पारदर्शी रूप से होता है।

मैन-इन-बीच हमलों (MITMA) को रोकने के लिए HTTPS प्रोटोकॉल मान लें ।

  • क्लाइंट पहली बार सर्वर के साथ हैंडशेक करता है, और सर्वर क्लाइंट के लिए एक सार्वजनिक कुंजी बनाता है और एक असममित एन्क्रिप्शन योजना का उपयोग करके एक निजी रखता है। क्लाइंट स्थानीय भंडारण में सर्वर की "सार्वजनिक" कुंजी संग्रहीत करता है, एक सुरक्षित पासवर्ड के साथ एन्क्रिप्टेड जिसे आप कहीं भी नहीं बचाते हैं।

  • ग्राहक अब ऑफ़लाइन है। ग्राहक विश्वसनीय कार्य करना चाहता है। क्लाइंट अपना पासवर्ड दर्ज करता है और सर्वर की सार्वजनिक कुंजी को पकड़ लेता है।

  • उस डेटा के अपने ज्ञान के आधार पर अब ग्राहक प्रदर्शन कार्यों, और ग्राहक हर क्रिया यह सर्वर की सार्वजनिक कुंजी के साथ प्रदर्शन को एन्क्रिप्ट है कि ग्राहक के लिए

  • जब क्लाइंट ऑनलाइन होता है, तो क्लाइंट अपनी क्लाइंट आईडी भेजता है और ग्राहक द्वारा की जाने वाली सभी क्रियाओं को सर्वर की सार्वजनिक कुंजी के साथ एन्क्रिप्ट किए गए सर्वर पर भेज दिया जाता है।

  • सर्वर क्रियाओं को डिक्रिप्ट करता है, और यदि वे सही प्रारूप में हैं तो यह विश्वास करता है कि वे क्लाइंट में उत्पन्न हुए हैं।

ध्यान दें:

  • आप क्लाइंट के पासवर्ड को कहीं भी स्टोर नहीं कर सकते हैं, अन्यथा एक हमलावर कुंजी प्राप्त करने और अपने स्वयं के रूप में कार्यों पर हस्ताक्षर करने में सक्षम होगा। इस योजना की सुरक्षा पूरी तरह से उस कुंजी पर निर्भर करती है, जो सर्वर क्लाइंट के लिए बनाता है। क्लाइंट को अभी भी उस कुंजी के लिए पूछने पर सर्वर के साथ प्रमाणित करने की आवश्यकता होगी।

  • आप वास्तव में सुरक्षा के लिए सर्वर पर भरोसा कर रहे हैं और ग्राहक नहीं । क्लाइंट द्वारा की जाने वाली हर क्रिया आपको सर्वर पर मान्य होनी चाहिए

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

  • यह आपकी मांग को पूरा करता है कि 'सर्वर से कोई पिंग नहीं' किया जाता है। यदि वे कुंजी को नहीं जानते हैं तो एक हमलावर जाली डेटा के साथ HTTP अनुरोध का अनुकरण नहीं कर सकता है।

  • जोआचिम का जवाब अभी भी सही है । आप वास्तव में, सर्वर पर सभी प्रमाणीकरण कर रहे हैं । केवल एक चीज जिसे आपने यहां सहेजा है, हर बार सर्वर के साथ पासवर्ड सत्यापन की आवश्यकता है। अब आपको केवल सर्वर को शामिल करने की आवश्यकता है, जब आप अपडेट किए गए डेटा को कमिट करना या खींचना चाहते हैं। हमने यहां जो भी किया वह क्लाइंट की विश्वसनीय कुंजी को सहेजना है और क्लाइंट को फिर से वैलिडेट करना है।

  • यह एकल पृष्ठ अनुप्रयोगों (उदाहरण के लिए, AngularJS के साथ) के लिए एक बहुत ही सामान्य योजना है।

  • मैं सर्वर की सार्वजनिक कुंजी को "सार्वजनिक" कहता हूं क्योंकि आरएसए जैसी योजनाओं में इसका क्या मतलब है , लेकिन यह वास्तव में योजना में संवेदनशील जानकारी है और इसे संरक्षित किया जाना चाहिए।

  • मैं पासवर्ड को कहीं भी मेमोरी में नहीं रखूंगा। हर बार जब वह ऑफ़लाइन कोड चलाना शुरू करता है, तो मैं उपयोगकर्ता को अपना 'ऑफ़लाइन' पासवर्ड सबमिट कर दूंगा।

  • अपनी स्वयं की क्रिप्टोग्राफ़ी को रोल न करें - प्रमाणीकरण के लिए स्टैनफोर्ड जैसी ज्ञात लाइब्रेरी का उपयोग करें।

  • यह सलाह इस प्रकार है । इससे पहले कि आप एक वास्तविक विश्व व्यापार-महत्वपूर्ण अनुप्रयोग में इस तरह के प्रमाणीकरण को रोल करें एक सुरक्षा विशेषज्ञ से परामर्श करें । यह एक गंभीर मुद्दा है जो गलत होने के लिए दर्दनाक और आसान दोनों है।

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

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

मैं फिर से जोड़ना चाहूंगा कि हमें अभी भी ग्राहक पर भरोसा नहीं है । आप अकेले ग्राहक पर भरोसा नहीं कर सकते , और मुझे लगता है कि जोआचिम के उत्तर में नाखून हैं। हमने केवल काम शुरू करने से पहले सर्वर को पिंग न करने की सुविधा प्राप्त की।

संबंधित सामग्री:


3
"अपने स्वयं के क्रिप्टो को रोल न करें" केवल प्रोटोकॉल पर उतना ही लागू होता है जितना कि यह आदिम करता है, यदि ऐसा भी नहीं है, क्योंकि जबकि लोग आमतौर पर अपनी स्वयं की आदिम बनाने के लिए पर्याप्त मूर्ख नहीं हैं, वे सोचते हैं कि वे एक प्रोटोकॉल बना सकते हैं जो ठीक है । मैं यह भी नहीं देखता कि यहाँ RSA क्यों आवश्यक है। जब से आप HTTPS का उपयोग कर रहे हैं, तो क्यों न सिर्फ एक 16-32 बाइट का साझा सीक्रेट जेनरेट किया जाए और जिसे भविष्य के अनुरोधों के साथ भेजा जाए? बेशक, यदि आप ऐसा करते हैं, तो स्ट्रिंग पर समय-अपरिवर्तनीय समानता की जाँच का उपयोग करना सुनिश्चित करें ...
रीड

2
+1 @ हाँ, मैंने अभी हाल ही में इस बारे में किसी विशेषज्ञ से चर्चा की है। मैंने एक प्राइमरी स्कीम के बारे में यहां एक प्रोटोकॉल पर आधारित था, जिसके बारे में मैंने (राबिन IIRC द्वारा) सीखा था, लेकिन कम से कम जब तक मैं बारीकियों को नहीं ढूँढ सकता (और उदाहरण के लिए यह बताता हूं कि इस मामले में असममित एन्क्रिप्शन की आवश्यकता क्यों है)। पहले किसी सुरक्षा विशेषज्ञ से सलाह के बिना इस उत्तर में सुझाई गई योजना का उपयोग न करें । मैंने कई जगहों पर इस दृष्टिकोण का उपयोग किया है, लेकिन व्यवहार में इसका मतलब बहुत कम है, अगर कुछ भी हो। मैंने उसे बढ़ाने के उत्तर को भी संपादित किया।
बेंजामिन ग्रुएनबाम

प्रॉम्प्ट का उपयोग करने से थोड़ी सुरक्षा बढ़ जाती है। एक हमलावर window.promptपास वाक्यांश को अवरोधन करने के लिए विधि को ओवरराइड कर सकता है , या अपना स्वयं का संकेत लॉन्च कर सकता है (संभवतः एक iframe के भीतर!)। पासवर्ड फ़ील्ड में एक अतिरिक्त लाभ है: वर्ण नहीं दिखाए गए हैं।
रोब डब्ल्यू

@RobW बेशक, यह पूरी योजना बेकार है अगर पेज से समझौता किया गया था। यदि हमलावर के पास उस पृष्ठ में जावास्क्रिप्ट चलाने के लिए पहुंच है, जिसे हमने खराब कर दिया है। शीघ्र के पीछे विचार यह था कि यह अवरुद्ध है, लेकिन आप सही हैं, जो भी सुरक्षा लाभ प्रदान करता है वह संदिग्ध है। सूची में अंतिम लिंक देखें।
बेंजामिन ग्रुएनबाम

1
सबसे पहले। बहुत बढ़िया जवाब, मुझे लगता है कि मैं कुछ और नहीं मांग सकता। दूसरी ओर, मैं मेरे लिए पालतू परियोजनाएं करना चाहता था (और निश्चित रूप से कौन इसका उपयोग करना चाहता है) और शायद यह ओवरकिल है (या शायद नहीं)। मेरा मतलब है, मैं कुछ भी गंभीर नहीं करना चाहता हूं और मुझे डर है कि मैं उस तरह के किसी भी रोल को नहीं कर सकता, जिसे आपने समझाया था, ज्ञान की कमी। मुझे लगता है कि मैं एक साधारण 401 चेक रोल करूंगा या अगर मेरे पास कोई अनुरोध नहीं है, तो मैं हर बार उस तरह के मार्गों तक पहुंचने पर सर्वर को पिंग करता हूं। प्रामाणिक टोकन एक विकल्प भी है (और शायद जो आपने यहां AFAIK को समझाया है, उससे संबंधित निकटतम चीज)। धन्यवाद :)
जीसस रॉड्रिग्ज

89

यह सरल है: कोई भी सुरक्षा तंत्र जो ग्राहक पर निर्भर करता है कि वह केवल वही करे जो आप उसे करने के लिए कहते हैं, उससे समझौता किया जा सकता है जब एक हमलावर का ग्राहक पर नियंत्रण होता है।

आपके पास क्लाइंट पर सुरक्षा जांच हो सकती है, लेकिन केवल "कैश" के रूप में प्रभावी रूप से कार्य करने के लिए (सर्वर को महंगी राउंड-ट्रिप करने से बचने के लिए यदि क्लाइंट को पहले से ही पता है कि उत्तर "नहीं" होगा)।

यदि आप उपयोगकर्ताओं के सेट से जानकारी रखना चाहते हैं, तो सुनिश्चित करें कि उन उपयोगकर्ताओं के ग्राहक को वह जानकारी कभी नहीं मिलती है। यदि आप उस "गुप्त डेटा" को निर्देशों के साथ एक साथ भेजते हैं, लेकिन कृपया इसे प्रदर्शित न करें, "यह उस कोड को अक्षम करने के लिए तुच्छ हो जाएगा जो उस अनुरोध को जांचता है।

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

एक बार जब आपका डेटा सर्वर से निकल जाता है, तो आपको यह मान लेना चाहिए कि किसी हमलावर के पास इसकी पूरी पहुंच है।


धन्यवाद। प्यारा होगा यदि आप इसे थोड़ा और समझा सकते हैं, तो मेरा सुरक्षा ज्ञान उतना अच्छा नहीं है और केवल एक ही हिस्सा मुझे समझ में आता है कि मैं गलत हूं: पी। जब आप कैशिंग के बारे में बात करते हैं, तो यह केवल कैश करने के लिए होता है जब सर्वर कहता है कि नहीं? मेरा मतलब है, अगर सर्वर ने एक बार हाँ कहा, तो आप उसे कैश नहीं कर सकते, है ना?
यीशु रोड्रिगेज

3
मैं जोड़ने के लिए कि यह सिर्फ चाहूँगा है ब्राउज़र में पहुँच बंद चर के लिए संभव (मॉड्यूल पैटर्न अपने उल्लेख की तरह), विशेष रूप से एक डिबगर के साथ :)
बेंजामिन Gruenbaum

2
@BenjaminGruenbaum: जेएस-साइड चीजों पर ध्यान केंद्रित करने वाले उत्तर में विस्तार करने के लिए स्वतंत्र महसूस करें। मैंने केवल यहां उच्च-स्तरीय, प्रौद्योगिकी-अज्ञेय अवलोकन दिया। जेएस पर ही ध्यान देने वाला उत्तर अच्छा होगा!
जोआचिम सॉउर

1
इसलिए संक्षेप में, यदि कुछ जानकारी / मार्ग / जो कुछ भी जावास्क्रिप्ट चर के आधार पर सुलभ है, तो यह किसी भी मामले में सुरक्षित नहीं होगा, क्योंकि आप आसानी से उस चर को यह कहने के लिए बदल सकते हैं कि आपको उस निजी सामान का उपयोग करने की आवश्यकता है।
यीशु रोड्रिगेज

4
@JoachimSauer मुझे लगता है कि इस सवाल के बिंदु को याद करेंगे जो आपने अच्छी तरह से पकड़ा था। इसके बावजूद कि ग्राहक क्या सुरक्षा उपाय करता है, संचार से समझौता करना संभव है । आप जावास्क्रिप्ट में बहुत सॉलिड ऑथेंटिकेशन सिस्टम बना सकते हैं, लेकिन यह सब कुछ भी लायक नहीं है जब आप सर्वर पर संचार सम्मिलित करते हैं जो अन्य क्लाइंट भी सत्य के स्रोत के रूप में मानते हैं। स्रोत कोड क्लाइंट पक्ष को भेजा जाता है, एक स्मार्ट हमलावर इसे पढ़ सकता है, और सर्वर पर एक HTTP अनुरोध की नकल कर सकता है। जब तक कि सर्वर पर वैरिफाइड नहीं किया जाता है, तब तक क्लाइंट से उत्पन्न होने वाली किसी भी चीज़ को अन-ट्रस्टेड मानना ​​चाहिए।
बेंजामिन ग्रुएनबाम

10

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


असेंबली एक
आक्षेप

@miniBill: जबकि एक मामूली अनुभवी हमलावर को इकट्ठे कोड से कोई परेशानी नहीं होगी, यह एक बहुत ही बुनियादी उच्च-पास फिल्टर प्रदान करेगा। (काश, यह अकादमिक है, क्योंकि स्क्रिप्ट
किडीज़ को

1

यह जावास्क्रिप्ट हैक करने का सवाल नहीं है। अगर मैं आपके ऐप पर हमला करना चाहता हूं, तो मैं एक निजी प्रॉक्सी का उपयोग करूंगा जो मुझे ट्रैफ़िक को कैप्चर करने, संशोधित करने और फिर से चलाने की अनुमति देगा। आपकी प्रस्तावित सुरक्षा योजना में उसके विरुद्ध कोई सुरक्षा नहीं दिखाई देती है।


0

विशेष रूप से कोणीय के बारे में बोलते हुए:

रूट क्लाइंट साइड की सुरक्षा करना मौजूद नहीं है। यहां तक ​​कि अगर आप उस मार्ग के एक बटन को 'छिपा'ते हैं, तो उपयोगकर्ता इसे हमेशा टाइप कर सकता है, कोणीय शिकायत करेगा, लेकिन ग्राहक उसके आसपास कोड कर सकता है।

किसी बिंदु पर आपके नियंत्रक को आपके सर्वर से दृश्य को प्रस्तुत करने के लिए आवश्यक डेटा के लिए पूछना होगा, यदि उपयोगकर्ता उस डेटा को एक्सेस करने के लिए अधिकृत नहीं है, तो वे इसे प्राप्त नहीं करेंगे क्योंकि आपने सर्वर पर इस डेटा को संरक्षित किया है। , और आपके कोणीय ऐप को 401 को उचित तरीके से संभालना चाहिए।

यदि आप कच्चे डेटा की सुरक्षा करने की कोशिश कर रहे हैं, तो आप ग्राहक की तरफदारी नहीं कर सकते हैं, यदि आप केवल एक विशेष उपयोगकर्ता को केवल सामान्य डेटा को एक निश्चित तरीके से देखने में सक्षम होना चाहते हैं, तो भेजने के बजाय सर्वर पर डेटा 'व्यू' बनाएं। ग्राहक के लिए कच्चा डेटा और इसे पुनर्गठित करना (आपको पहले से ही प्रदर्शन कारणों से ऐसा करना चाहिए)।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.