2009-05-13 13 views
29

मेरे पास एक वेब एप्लिकेशन है जो मेरे नव निर्मित जेएसओएन एपीआई से डेटा खींचता है।मैं JSON पहुंच को कैसे प्रतिबंधित करूं?

मेरे स्थिर HTML पृष्ठ गतिशील रूप से स्थिर HTML पृष्ठ से जावास्क्रिप्ट के माध्यम से JSON API को कॉल करते हैं।

मैं अपने JSON एपीआई तक पहुंच कैसे प्रतिबंधित करूं ताकि केवल मैं (मेरी वेबसाइट) इसे कॉल कर सकूं?

यदि यह मदद करता है, तो मेरा एपीआई कुछ ऐसा है: http://example.com/json/?var1=x&var2=y&var3=z ... जो क्वेरी के आधार पर उचित JSON उत्पन्न करता है।

मैं अपने JSON परिणामों को उत्पन्न करने के लिए PHP का उपयोग कर रहा हूं ... JSON एपीआई तक पहुंच प्रतिबंधित करना $_SERVER['HTTP_REFERER'] की जांच के रूप में सरल हो सकता है यह सुनिश्चित करने के लिए कि एपीआई केवल मेरे डोमेन से ही कहा जा रहा है और रिमोट उपयोगकर्ता नहीं है?

+0

बस स्पष्टीकरण के लिए, क्या आप इसे बनाने की कोशिश कर रहे हैं, इसलिए आपका सर्वर एपीआई का उपयोग कर सकता है, या केवल आपके सर्वर से वेबसाइट देखने वाले लोग? –

+1

मेरा JSON एपीआई यहां है: http: //example.com/json? ... और मैं केवल अपनी वेबसाइट http://example.com चाहता हूं कि मैं अपने JSON एपीआई से परिणाम पुनर्प्राप्त कर सकूं। –

+0

जिज्ञासा से बाहर, आप ऐसा करने की कोशिश क्यों कर रहे हैं? यह थोड़े वेब के अनाज के खिलाफ चला जाता है इसलिए आवश्यकता के पीछे तर्क जानने के लिए अच्छा होगा। – Sam

उत्तर

4

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

आप अपने एपीआई के पीछे ऐप को http रेफरर की जांच कर सकते हैं, लेकिन अगर कोई चाहता है तो नकली करना आसान है।

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

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

+0

यह शायद सबसे खूबसूरत काम है, लेकिन मैं मानता हूं कि यह केवल एक काम है और वास्तविक समाधान नहीं है (कोई भी नहीं है)। –

+0

तो आप जो कह रहे हैं वह है कि ... यदि मैंने 'HTTP_REFERER' की जांच की - तो कम से कम *** कुछ *** सीमित आश्वासन प्रदान करता है कि केवल मेरी वेबसाइट मेरे JSON api का उपयोग कर रही है। लेकिन फिर, 'HTTP_REFERER' आसानी से फिक्र किया जा सकता है। –

+0

जेम्सज़ - सही। –

4

संक्षिप्त उत्तर यह है: कोई भी जो आपकी वेबसाइट के पृष्ठों तक पहुंच सकता है, वह भी आपके एपीआई तक पहुंच पाएगा।

आप अपने एपीआई को विभिन्न तरीकों से एन्क्रिप्ट करके अधिक कठिन बनाने का प्रयास कर सकते हैं, लेकिन चूंकि आपको अपने एपीआई के आउटपुट को डिक्रिप्ट करने के लिए जावास्क्रिप्ट कोड शामिल करना होगा, तो आप बस अपने आप को स्थापित करने जा रहे हैं किसी भी व्यक्ति के साथ एक हथियार दौड़ जो निर्णय लेती है कि वे अन्य तरीकों से आपके एपीआई का उपयोग करना चाहते हैं। यहां तक ​​कि यदि आप अल्पकालिक कुंजी का उपयोग करते हैं, तो एपीआई का उपयोग करने से पहले एक निर्धारित "हमलावर" हमेशा आपके एचटीएमएल (वर्तमान कुंजी के साथ) को स्क्रैप कर सकता है।

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

+1

मैं इसे एन्क्रिप्ट नहीं करना चाहता, मैं बस "कौन" मेरे JSON एपीआई को कॉल कर सकता हूं प्रतिबंधित करना चाहता हूं। एकमात्र व्यक्ति जिसे मैं एपीआई कॉल करने में सक्षम होना चाहता हूं वह मेरा स्वयं का वेब सर्वर है और कोई दूरस्थ उपयोगकर्ता नहीं है। –

+0

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

18

आपके डोमेन तक पहुंच प्रतिबंधित करने की सामान्य विधि सामग्री को असीमित रूप से चलाने वाली चीज़ के साथ प्रीपेड कर रही है।

उदाहरण के लिए:

while(1);{"json": "here"} // google uses this method 
for (;;);{"json": "here"} // facebook uses this method 

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

<script src="http://some.server/secret_api?..."></script> 

यह विफल हो जाएगा क्योंकि स्क्रिप्ट पहले कथन से कभी नहीं मिलेगी।

+1

क्या कहें? एक अनंत लूप बनाने के लिए आपकी सिफारिश है?या तो मैं यहाँ कुछ पूरी तरह याद कर रहा हूं या आप मेरा पैर खींच रहे हैं। –

+16

किसी को भी बिना किसी परेशानी के सर्वर-साइड कोड से कॉल कर सकते हैं और बस लूप को बाहर निकालें। –

+4

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

17

मुझे लगता है कि आप उस हिस्से को गलत समझ सकते हैं जहां JSON अनुरोध उपयोगकर्ता के ब्राउज़र से आपके अपने सर्वर से बजाए गए हैं। स्थिर HTML पृष्ठ उपयोगकर्ता के ब्राउज़र पर वितरित किया जाता है, फिर यह पृष्ठ पर जावास्क्रिप्ट कोड को बदल देता है और निष्पादित करता है। JSON डेटा प्राप्त करने के लिए यह कोड आपके सर्वर पर एक नया कनेक्शन खोलता है। आपकी PHP स्क्रिप्ट के दृष्टिकोण से, JSON अनुरोध बाहरी दुनिया में कहीं से आता है।

उपर्युक्त तंत्र को देखते हुए, आप अपने HTML पृष्ठ के संदर्भ में JSON API को कॉल करने से रोकने के लिए बहुत कुछ नहीं कर सकते हैं।

+0

यदि ऐसा है, तो लोग अपने "रीस्टफुल" एपीआई कैसे पेश कर रहे हैं? या ये एपीआई सभी सार्वजनिक हैं? –

+1

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

+0

तो लोग उपयोगकर्ताओं को एक आरईएसटी क्वेरी सबमिट करने से कैसे रोकते हैं जो वेब अनुप्रयोग डेटाबेस से सभी डेटा को डंप करता है। –

5

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

तो, क्या हम कर सकते हैं?

यहाँ कमजोरी की पहचान:

http://www.example.com/json/getUserInfo.php?id=443

हमलावर अब आसानी से एक पाश में 1.000.000 1 से सभी उपयोगकर्ता जानकारी का अनुरोध कर सकते हैं। auto_increment आईडी का कमजोर बिंदु उनकी रैखिकता है और वे अनुमान लगाना आसान है।

समाधान: आपके डेटा के लिए गैर-संख्यात्मक अद्वितीय पहचानकर्ताओं का उपयोग करें।

http://www.example.com/json/getUserInfo.php?userid=XijjP4ow

आप उन से अधिक पाश नहीं कर सकते। सच है, आप अभी भी सभी प्रकार की चाबियों के लिए HTML पृष्ठों को पार्स कर सकते हैं, लेकिन इस प्रकार का हमला अलग है (और अधिक आसानी से टालने योग्य) समस्या है।

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

0

क्षमा करें, शायद मैं गलत हूं लेकिन ... क्या इसे HTTPS का उपयोग करके किया जा सकता है?

आप कर सकते हैं http रों के माध्यम से अपने एपीआई सुलभ है (?): //example.com/json/ var1 = एक्स & var2 = y, इस प्रकार केवल प्रमाणीकृत उपभोक्ता अपने डेटा प्राप्त कर सकते हैं ...

+5

एसएसएल पहचान की गारंटी नहीं देता है, यह केवल तृतीय पक्षों को आपके डेटा को देखने से रोकता है जबकि यह ब्राउज़र और सर्वर के बीच पारगमन में होता है। – RQDQ

0

क्या आप हैं, या आप कुकी आधारित प्रमाणीकरण का उपयोग कर सकते हैं? मेरा अनुभव एएसपी.नेट फॉर्म प्रमाणीकरण पर आधारित है, लेकिन एक ही दृष्टिकोण PHP के साथ थोड़ा कोड के साथ व्यवहार्य होना चाहिए।

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

इस दृष्टिकोण को स्पष्ट रूप से कुकीज़ के उपयोग की आवश्यकता है, ताकि आपके लिए कोई समस्या हो या न हो।

0

क्षमा करें, :-)

वेब पर कोई DRM से आप एक विश्वसनीय ग्राहक के रूप में एचटीएमएल इलाज नहीं कर सकता है। यह एक सादा पाठ स्क्रिप्ट है जो अन्य लोगों के कंप्यूटरों पर व्याख्या के रूप में व्याख्या की जाती है। जो कुछ भी आप अपने "खुद" जावास्क्रिप्ट कोड की अनुमति देते हैं, क्या आप किसी को भी अनुमति देते हैं। जंगली में आप Greasemonkey और Firebug के साथ "आपका" कितना समय निर्धारित कर सकते हैं।

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

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

+0

ओह, और जब लोग आपकी सेवा का उपयोग शुरू करते हैं तो आपके एचटीएमएल की अनुमति नहीं है? मुफ्त व्यापार विकास सलाह लें और इसके साथ रोल करें! – Szocske

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