2013-05-26 11 views
9

में कोड को सुरक्षित करें, मैं एक Google क्रोम एक्सटेंशन लिखना चाहता हूं, जो मुझे अपनी वेबसाइट को भेजने और कुछ डेटा प्राप्त करने का अनुरोध करना चाहिए, इसलिए वास्तव में मुझे एजेक्स अनुरोध करना चाहिए जैसे कि यह यहां लिखा गया है https://developer.chrome.com/extensions/xhr.htmlGoogle क्रोम एक्सटेंशन

var xhr = new XMLHttpRequest(); 
xhr.open("GET", "http://api.example.com/data.json", true); 

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

संपादित करें:

मैं, प्रमाणीकरण के कुछ प्रकार बनाने के लिए कैसे मैं ajax कॉल करने से पहले उपयोगकर्ता को प्रमाणित कर सकते हैं की तुलना में की जरूरत है? प्रमाणीकरण के लिए मुझे अपने सर्वर से एक अनुरोध भेजने की आवश्यकता होगी, लेकिन इसके लिए मुझे भेजना चाहिए, उदा। उपयोगकर्ता नाम और पासवर्ड, जिसे एक्सटेंशन की फ़ाइलों में कहीं सेव किया जाना चाहिए, वास्तव में, उपयोगकर्ताओं द्वारा एक्सटेंशन को इंस्टॉल करते समय देखा जा सकता है।

धन्यवाद

+0

आप क्रोम एक्सटेंशन में एक सार्वजनिक एपीआई का पर्दाफाश करते हैं - और आप एक्सटेंशन के अन्य उपयोगकर्ताओं को इसका उपयोग नहीं करना चाहते हैं? तब एपीआई का क्या अर्थ है? – madflow

+1

आप Google क्रोम प्रमाणीकरण एपीआई का उपयोग करके अपने उपयोगकर्ता की पहचान कर सकते हैं और उपयोगकर्ता को अधिकार सुनिश्चित करने के लिए अपनी तरफ से कुछ सामान स्टोर कर सकते हैं। यह गूगल दस्तावेज़ देखें; http://developer.chrome.com/apps/app_identity.html – happy

+1

@madflow, अगर मैं केवल अधिकृत लोगों द्वारा उपयोग किए जाने के लिए अपना एपीआई चाहता हूं, तो इसमें कोई अर्थ नहीं है? – dav

उत्तर

3

ब्राउज़र पर भरोसा न करें, उपयोगकर्ता को प्रमाणित करने के लिए चरण उठाएं। इसलिए, इस मामले में, आपको आवश्यकता हो सकती है कि आप उस पासवर्ड में प्रवेश करें जिसका उपयोग आपके सर्वर से संवाद करने के लिए किया जाता है।

आपके Google एक्सटेंशन को आपके सर्वर के साथ संवाद करने के लिए AJAX का उपयोग करने से पहले पासवर्ड में प्रवेश करने की आवश्यकता होगी।

ध्यान रखें कि आपको अपने आप को क्रूर-बल हमलों से बचाने के साधनों का निर्माण करना चाहिए। तो, अगर कुछ छोटी संख्या में गलत पासवर्ड हैं, तो कुछ भी लॉक करें जैसे

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

संपादित ताकि केवल एक ही आवेदन यह सिर्फ व्यावहारिक नहीं है और न ही तकनीकी रूप से संभव है का उपयोग कर सकते एक API को लॉक करने के लिए कोशिश कर रहा है, तो आप ऐसा करने का ही उम्मीद एपीआई का उपयोग कर उपयोगकर्ता को प्रमाणित करने, परवाह किए बिना कर रहे हैं वह उपयोग करने वाले सॉफ्टवेयर का उपयोग कर रहा है। आप उपयोगकर्ता को एक समझौते पर हस्ताक्षर कर सकते हैं जो कानूनी रूप से उन्हें केवल आपके एक्सटेंशन तक ही सीमित कर देता है, लेकिन मुझे संदेह है कि यह काफी हद तक लागू नहीं होगा और आपके समय को दुरुपयोग करने वालों को ट्रैक करेगा।

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

इस आउट ऑफ़ बैंड प्रक्रिया के दौरान, आप उपयोगकर्ता को एक अद्वितीय यूआरआई (एपीआई एक्सेस पॉइंट) भी प्रदान कर सकते हैं जो प्रति प्रमाणीकृत सत्र (उदाहरण के लिए https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/) मान्य है। अन्य यूआरआई पर आपके सर्वर के लिए कोई भी अनुरोध बस काम नहीं करेगा। हालांकि, यह एक ही एपीआई एक्सेस पॉइंट का उपयोग करने और एक अच्छा पासवर्ड रखने से सैद्धांतिक रूप से बहुत अलग नहीं है। यह सिर्फ आपके आर्किटेक्चर में स्थानों की संख्या को बदलता है जो प्रमाणीकरण और/या प्राधिकरण जांच कर रहे होंगे।

<aside> मेरा वोट प्राधिकरण/प्रमाणीकरण बिंदुओं की संख्या को जितना संभव हो सके कम करने के लिए होगा ताकि आप एक स्थान को कई जगहों और संभवतः एकाधिक तर्क त्रुटियों या अन्य चीजों के बजाय सही जगह पर प्राप्त करने में अधिक समय व्यतीत कर सकें। कमजोरियों का कारण बन सकता है। </aside>

आप सार्वजनिक कुंजी इंफ्रास्ट्रक्चर और/या एक बार की पासवर्ड योजनाओं या डिवाइस-आधारित टोकन जेनरेटर आदि का उपयोग करके भी पता लगा सकते हैं, लेकिन अंत में, आप प्रमाणीकृत और अधिकृत उपयोगकर्ताओं को अपने एपीआई का उपयोग करने की अनुमति देंगे। और, इंटरनेट के लिए धन्यवाद, यह लंबे समय तक एक अज्ञात यूआरआई नहीं रहेगा।

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

मुझे पता है कि आप यहां चांदी की बुलेट की तलाश में थे, लेकिन यह अस्तित्व में नहीं है।

+0

लेकिन AJAX कॉल करने से पहले मैं उपयोगकर्ता को प्रमाणीकृत कैसे कर सकता हूं? प्रमाणीकरण के लिए मुझे अपने सर्वर पर एक अनुरोध भेजने की आवश्यकता होगी, है ना? लेकिन इसके लिए मुझे भेजना चाहिए, उदा। उपयोगकर्ता नाम और पासवर्ड, जिसे एक्सटेंशन की फ़ाइलों में कहीं सेव किया जाना चाहिए, वास्तव में, उपयोगकर्ताओं द्वारा देखा जा सकता है, जब वे एक्सटेंशन इंस्टॉल करते हैं, है ना? – dav

+0

उस प्रश्न को संबोधित करने के लिए उत्तर अद्यतन करें। – mkoistinen

+0

धन्यवाद @mkoistinen, और आप सही हैं, मैं एक चांदी की बुलेट की तलाश में था, धन्यवाद! – dav

2

मुझे लगता है कि आप गलत कर रहे हैं। आपको इंटरनेट उपयोगकर्ताओं पीसी पर क्या चल रहा है पर भरोसा नहीं करना चाहिए। कभी नहीँ!

ट्रस्ट की एक पंक्ति को आगे बढ़ाएं, अपना एपीआई सार्वजनिक बनाएं और फिर उस सुरक्षा को डिज़ाइन करें जहां आपके पास सही नियंत्रण है - सर्वर पक्ष।

+0

लेकिन अगर एपीआई सार्वजनिक है तो कोई भी डेटा भेज और प्राप्त कर सकता है, मैं इसे सर्वर की तरफ कैसे सुरक्षित करूं? मैं यह सुनिश्चित करना चाहता हूं कि केवल वे लोग एपीआई का उपयोग कर सकें, कहें, एक कुंजी है, लेकिन अगर मैं विस्तार में एक कुंजी डालता हूं, तो यह दृश्यमान और सुरक्षित नहीं है, धन्यवाद! – dav

1

मैं आपके उपयोग के मामले की सही पहलू नहीं मिल सका

कुछ अंक:

  • आपका एक्सटेंशन कोड always मिल (किसी भी एक है जो विस्तार स्थापित किया है कोड देख सकते हैं)
  • है
  • यदि आप complicated or obfuscated coding patterns के माध्यम से सुरक्षा की तलाश में हैं तो आप पूरी तरह समझने की प्रक्रिया को धीमा नहीं कर देते हैं।
  • यदि आपका लक्ष्य यह सुनिश्चित करना है कि आपके एक्सटेंशन को इंस्टॉल करने वाले उपयोगकर्ताओं को अन्य सभी उपयोगकर्ताओं को एक्सेस करने और निष्क्रिय करने में सक्षम होना चाहिए (जिन्होंने अवैध पहुंच या डाउनलोड और संपादित कोड प्राप्त किया है) सत्र प्रति साझा साझा किया गया है।

कृपया आगे का उपयोग केस समझाएं ताकि मैं आपकी मदद कर सकूं।

+0

मेरा लक्ष्य यह सुनिश्चित करना है कि एक्सटेंशन बनाने के बाद कोई भी मेरे कोड को एक्सटेंशन में नहीं देख सकता है, किसी भी तरह से किसी अन्य वेबसाइट से मेरी वेबसाइट पर अनुरोध करने में सक्षम हो सकता है, या इस तरह का अन्य एक्सटेंशन बना सकता है और इसका उपयोग करता है कि मेरा अनुरोध वेबसाइट, क्या मेरी टिप्पणी समझ में आता है?धन्यवाद – dav

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