2010-02-13 9 views
69

वर्तमान में Google आपको एक एपीआई कुंजी बनाने की आवश्यकता है जो उस डोमेन के लिए विशिष्ट है जहां से मानचित्र पर सेवा की जाएगी। Google इसे कैसे लागू करता है? मैं वही काम करना चाहता हूं।Google मानचित्र उनकी API कुंजी को सुरक्षित कैसे करता है? कुछ समान कैसे करें?

मैं अपनी सेवा के लिए एक एपीआई का पर्दाफाश करता हूं लेकिन क्लाइंट को जावास्क्रिप्ट के माध्यम से एपीआई में कॉल एम्बेड करने की अनुमति देना चाहता हूं न कि सर्वर से। मैं इसे केवल एक यादृच्छिक टोकन से सुरक्षित कर सकता हूं लेकिन निश्चित रूप से क्लाइंट मशीन पर कोड को देखकर इसे आसानी से खराब किया जा सकता है।

मैं हमेशा इस अवधारणा को समझने के लिए समझ नहीं पाया लेकिन किसी भी तरह से Google इसे लागू करने के लिए एक अच्छा काम करता है।

संपादित करें - ऐसा लगता है जैसे Google ने वास्तव में कुछ भी अद्भुत नहीं किया है। उनकी एपीआई केवल ट्रैकिंग के लिए सबसे अधिक संभावना है और वास्तव में गारंटी नहीं है कि उनकी एपीआई कुंजी के साथ व्यक्ति द्वारा उपयोग की जाती है।

+0

मेरा मानना ​​है कि मुझे जवाब मिला। –

उत्तर

27

मुझे पूरा यकीन है कि वे कहां से आ रहे हैं यह निर्धारित करने के लिए वे संदर्भ URL का उपयोग करते हैं। यदि डोमेन कुंजी से सौंपा गया मेल नहीं खाता है, तो यह एक अमान्य अनुरोध है।

एक व्यावहारिक उदाहरण के लिए, PHP का उपयोग करके आप रेफरर की जांच के लिए $_SERVER['HTTP_REFERER'] का उपयोग कर डोमेन की जांच कर सकते हैं। यदि डोमेन मेल खाता है, तो एक वैध प्रतिक्रिया दें। यदि ऐसा नहीं होता है, तो आप 401 अनधिकृत या अन्य प्रतिक्रिया वापस कर सकते हैं।

+0

तो यदि कोई क्लाइंट जावास्क्रिप्ट के माध्यम से हमारे एपीएक्स को एजेक्स कॉल करना चाहता था तो मैं रेफरर डोमेन पर सटीक और गैर-स्पूफबल होने पर निर्भर कर सकता हूं? – Vyrotek

+1

नहीं। यह धोखा देने योग्य है। मुझे लगता है कि Google अधिक संभावना आईपी पते पर निर्भर करता है (आसानी से खराब नहीं किया जा सकता है), और एक DNS लुकअप। –

+0

आह, इसलिए वे डोमेन यूआरएल लेते हैं और आईपी देखते हैं और यह सुनिश्चित करने के लिए DNS को देखते हैं। हालांकि, आप कहते हैं कि यह तकनीकी रूप से स्पूफबल भी है? – Vyrotek

-6

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

+2

हालांकि इसके आसपास के तरीके हैं (JSONP)। मुझे नहीं लगता कि आप कॉल नहीं कर सकते हैं, आप आमतौर पर वापसी की प्रक्रिया नहीं कर सकते हैं। –

+0

कुछ उदाहरणों और विशेष रूप से http://econym.org.uk/gmap/example_map12.htm (एक अच्छे ट्यूटोरियल के रूप में सूचीबद्ध) को देखते हुए ऐसा प्रतीत होता है कि विशिष्ट उपयोगकर्ता कुंजी का पर्दाफाश करते हैं जब वे स्क्रिप्ट src maps api। Sourced जेएस पृष्ठ overwrites (नक्शा img का एक सेट है)। मार्कर को GDownloadUrl() का उपयोग करके जेसन डेटा डाउनलोड करके रखा जाता है - यह सिर्फ एक XMLHttpRequest बनाता है और इसलिए उसके सर्वर पर वापस आ जाता है। JSONP को Google सर्वर से समर्थन की आवश्यकता है, है ना? – mar

+4

यदि यह सत्य था, तो उदाहरण के लिए सीडीएन होस्ट किया गया jQuery jQuery को सीडीएन की तुलना में किसी अन्य डोमेन पर अजाक्स कॉल नहीं कर सका। – Arjan

3

मेरी टिप्पणी के रूप में कहते हैं:

संदर्भित spoofable है, इसलिए यह शायद संभव नहीं दिखता कि Google सत्यापन करने का एक साधन के रूप में उपयोग होगा। देखें this wikipedia entry.

मेरा अनुमान है कि Google शायद कॉलर के आईपी पते को DNS लुकअप के साथ उपयोग करता है। DNS वास्तव में खराब नहीं है, क्योंकि आपकी DNS प्रविष्टियों को वेबसाइट के लिए भी सही होना चाहिए।

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

पूछे जाने वाले प्रश्न से

ध्यान दें कि http://www.mygooglemapssite.com/ के लिए एक महत्वपूर्ण है केवल जब साइट को इस पते का उपयोग कर पहुँचा जा सकता है स्वीकार किया जाएगा। यदि साइट आईपी पते (जैसे। http://10.1.2.3/) द्वारा या एक होस्ट नाम है कि एक DNS CNAME रिकॉर्ड का उपयोग कर www.mygooglemapssite.com को एलियास द्वारा पहुँचा है यह स्वीकार नहीं किया जाएगा।

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

मेरा अनुमान है ऊपर तथ्य यह है कि आईपी पते या अन्य नाम के लिए काम नहीं करता है, यह एक DNS जांच नहीं कर रहा है, जिसका मतलब है समर्थित है।

इस विधि को धोखा नहीं दिया जा सकता है, क्योंकि यह पृष्ठ तक पहुंचने के लिए सही शीर्षलेख होना चाहिए। हालांकि, इसका मतलब है कि डोमेन के लिए कोई उपनाम काम नहीं करेगा।

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

+0

पृष्ठ का अनुरोध करते समय 'होस्ट' हेडर में पता हो सकता है, लेकिन मैं कैसे गारंटी दूंगा कि उस पृष्ठ द्वारा किए गए नए AJAX अनुरोध को मेरे एपीआई में भी पास किया गया है? मैंने सोचा कि यह मूल रूप से 'रेफरर' है जिसमें हम जानते हैं कि धोखा दिया जा सकता है। – Vyrotek

+0

ठीक है, क्योंकि आप AJAX कॉल लिख रहे हैं (क्योंकि आपने जावास्क्रिप्ट लाइब्रेरी प्रदान की है), आप यह सुनिश्चित कर सकते हैं कि यह भेजा जाए। –

+0

कारण Google को एपीआई कुंजी की आवश्यकता हो सकती है क्योंकि वे जावास्क्रिप्ट लाइब्रेरी प्रदान करते हैं, और फिर पेज पर जावास्क्रिप्ट चला सकते हैं। –

62

एपीआई कुंजी शायद डोमेन का एक तरीका हैश कुंजी से जुड़ा हुआ है और एक रहस्य केवल Google API सर्वर के बारे में जानता है। इसमें कुछ अन्य टुकड़े प्रसिद्ध (Google के लिए) जानकारी हो सकते हैं। जब आप उस डोमेन से अनुरोध करते हैं, तो एपीआई सर्वर डोमेन लेता है, अनुरोध आता है और उसी तरह से हैश गणना करता है और दो मानों की तुलना करता है।

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

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

और निश्चित रूप से उनके एपीआई के माध्यम से संभावित एक्सएसएस हमलों की चिंता भी है। लेकिन मुझे विश्वास नहीं है कि उनकी एपीआई कुंजी उनके पास मौजूद किसी भी एंटी-एक्सएसएस कोड में बहुत अधिक जुड़ी हुई है।

+0

दुर्भाग्यवश यह सबसे उचित उत्तर की तरह लगता है। आपके सहयोग के लिए धन्यवाद। – Vyrotek

+2

"वे अनाम पहुंच प्रदान कर सकते थे" - ध्यान दें कि कुछ फ़ंक्शंस प्रति दिन अनुरोधों और एपीआई कुंजी (और जब यह पोस्ट किया गया था) द्वारा सीमित हैं, उदा। रिवर्स भौगोलिक स्थान। – Piskvor

+1

यह भी ध्यान दें कि HTTPS पर उपयोग निःशुल्क नहीं है। – Arjan

2

मैं फ्रांसी पेनोव सूचीबद्ध सभी बिंदुओं से सहमत हूं। मैं किसी और की एपीआई कुंजी का उपयोग करने पर थोड़ा सा विस्तार करना चाहता हूं। आइए मान लें कि आप http://mysite.com के साथ कुंजी 1 पंजीकृत करते हैं।

1) पहला प्रयास - अगर किसी अन्य साइट पर स्क्रिप्ट src = http://www.google.com/jsapi?key=key1 है, तो Google रेफरर (हैश योजना का उल्लेख किया गया) देख सकता है और इस मामले में एक मेल नहीं है। बुराई हमलावर इस पर कैसे उबरता है - बहुत से लोगों ने उल्लेख किया है कि रेफरर को धोखा दिया जा सकता है। यह वास्तव में यहां लागू नहीं होता है। निश्चित रूप से यदि आप अनुरोध करते हैं तो आप मनमाने ढंग से शीर्षलेख भेज सकते हैं लेकिन किसी अन्य साइट पर उपयोगकर्ताओं के लिए बुरा हैकर स्पूफ रेफरर कैसे करता है - यह सामान्य रूप से आसान नहीं है। आईई 6 पर फ्लैश के पुराने संस्करण रहे हैं जो क्रॉस डोमेन अनुरोध करते समय हमलावर को मनमाने ढंग से शीर्षलेख सेट करने की अनुमति देते हैं लेकिन सामान्य रूप से यह स्क्रिप्ट src के लिए काम करने योग्य नहीं है। मुझे यकीन नहीं है कि शामिल जेएस दस्तावेज का कोई सत्यापन करता है। इसे रोकने के लिए स्थान (संभवतः नहीं)।

2) दूसरा प्रयास - बुराई हमलावर mysite.com पृष्ठ स्रोत से एपीआई कुंजी के लिए Google जावास्क्रिप्ट कॉपी करता है और फिर किसी अन्य साइट पर संशोधित जावास्क्रिप्ट एम्बेड करता है। अब Google कुछ भी जांच नहीं सकता है (रिमोट आईपी उपयोगकर्ता का कंप्यूटर होगा और आप बहुत कुछ नहीं कर सकते हैं या Google कर सकते हैं)।

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

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