एपीआई के अनधिकृत उपयोग से कैसे बचें?

Question

मुझे एक "विजेट" डिजाइन करना होगा, एक स्क्रिप्ट जो कुछ यूआई प्रदर्शित करने और हमारे एपीआई पर कॉल करने के लिए साझेदार अपनी वेबसाइटों में एम्बेड करेगी।

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

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

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

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

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

आप इस समाधान के बारे में क्या सोचते हैं, और आप इन बाधाओं के साथ क्या करेंगे?

Comments

क्या आप कुंजी को गतिशील बना सकते हैं? साझेदार के पहचानकर्ता के MD5 हैश के साथ UTC का समय निकटतम 10 मिनट तक हो गया है?

— डैन पिचेलमैन

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

— एंटोनी

मैं सोच रहा था कि यह सर्वर की ओर से साथी की गणना करे। यदि यह विकल्प नहीं है, तो मुझे संदेह है कि आपकी एकमात्र वास्तविक पसंद आपके द्वारा उल्लेखित थ्रॉटलिंग करना है (सीमित जीवनकाल, अनुरोधों / दिन की सीमा)। यह न भूलें कि जो IP आप देख रहे हैं वह जरूरी नहीं कि किसी एक कंप्यूटर पर मैप हो।

— दान पिचेलमैन

मुझे व्यवसाय की जांच करने की आवश्यकता है यदि यह गणना करना है कि सर्वर-साइड संभव है। नहीं तो मुझे डर है कि, केवल समाधान थ्रॉटलिंग है।

— एंटोनी

Answer 1

आपको कई प्रकार के संरक्षण की आवश्यकता है।

सबसे पहले , आपको साइट ए की कुंजी को साइट बी पर उपयोग करने से रोकने की आवश्यकता है।

सिद्धांत रूप में, यदि कुंजी किसी डोमेन से बंधी है, तो आप refererहेडर पर निर्भर नहीं हो सकते हैं , लेकिन क्योंकि आप क्लाइंट सीधे स्क्रिप्ट को एम्बेड कर रहे हैं, तो आप क्लाइंट-साइड पर उचित रूप से भरोसा कर सकते हैं document.location। उस स्थान (या इसके अंश) को सीधे सर्वर पर भेजना अविश्वसनीय है; लेकिन आप इसका उपयोग सत्र कुंजी उत्पन्न करने के लिए कर सकते हैं:

1. client_keyAPI लाइब्रेरी के लिए क्लाइंट अनुरोध में एम्बेड करता है।
2. सर्वर होस्ट को निर्धारित करता है कि एपीआई तक पहुंच है, यदि कोई हो।
3. सर्वर एक सत्र कुंजी के लिए "नमक" चुनता है और इसे क्लाइंट को लाइब्रेरी [या किसी अन्य प्री-ऑर्ट एक्सचेंज के हिस्से के रूप में भेजता है]।
4. ग्राहक एक session_keyउपयोग की गणना करता है hash(document.location.host + session_salt)।
5. API कॉल के लिए क्लाइंट session_key+ का उपयोग करता है client_key।
6. सर्वर client_keyसत्र में 's होस्ट और "नमक" को देखकर , हैश की गणना और प्रदान की तुलना करके कॉल को मान्य करता है client_key।

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

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

• अनुरोधों / दूसरे / सत्र और अनुरोधों / घंटे / सत्र की संख्या को सीमित करें। (गतिविधि में स्पाइक्स संभवतः उचित हैं, लेकिन एकल क्लाइंट से ऊपर-औसत ट्रैफ़िक निरंतर नहीं है ।)
• सत्र / आईपी / घंटा की संख्या को सीमित करें।
• अनुरोधों / आईपी / घंटे की संख्या को सीमित करें। स्पाइक्स की अनुमति दें, लेकिन एकल आईपी से भारी ट्रैफ़िक कायम नहीं ।

तीसरा , जैसा कि आप पहले से ही कर रहे हैं: यातायात एन्क्रिप्ट करें। निश्चित रूप से, एनएसए इसे देखेगा; लेकिन हैकर हांक की संभावना कम है।

Answer 2

ऐसा लगता है कि आप यहां अपनी जावास्क्रिप्ट फ़ाइलों को संरक्षित संसाधनों में बना रहे हैं। और एक ही समय में एक प्रकार की टोकन पीढ़ी के साथ इसे बांधना। यह तो दिलचस्प है।

जिन सुरक्षा लोगों के साथ मैं काम करता हूं, वे आमतौर पर आईपी पते को हाथ से खारिज कर देते हैं क्योंकि आईपी खराब हो जाता है। लेकिन अगर आप एसएसएल के साथ मिलकर एक आईपी प्रतिबंध का उपयोग कर रहे हैं, तो यह आमतौर पर चाल है।

लेकिन आपको आईपी पते को "श्वेतसूची" करना होगा, अन्यथा कोई भी हैकर सामने के दरवाजे पर आ सकता है।

मुझे संदेह था, लेकिन मैं वास्तव में सोच रहा हूं कि आपकी योजना बहुत अच्छी तरह से काम करती है। यदि 1) .js फ़ाइल और उसके बाद की एपीआई कॉल टीएलएस (यानी एसएसएल या https) के साथ की जाती है, और 2) आईपी श्वेतसूची में हैं। तब मैं एक साहसिक बयान करूंगा और कहूंगा कि मुझे लगता है कि आप पीसीआई (क्रेडिट कार्ड) इंटरैक्शन के लिए भी एक सुरक्षा समीक्षा पास करेंगे।

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

या इसे इस तरह से रखें: एसएसएल के साथ, एक समर्पित हैकर को आपकी सूची नहीं मिल सकती है । (जब तक वे एसएसएल को नहीं तोड़ते, लेकिन तब वे अमेज़ॅन को भी तोड़ सकते थे)। एसएसएल के बिना, एक समर्पित हैकर आपकी कॉल को सूँघ सकता है, आईपी को खराब कर सकता है और आपकी सूची को नीचे खींच सकता है। इसलिए यह जोखिम पर निर्णय की तरह है।

मैं आईपी श्वेतसूची के साथ फैलने के तरीके के बारे में सोचने की कोशिश कर रहा हूं क्योंकि यह आमतौर पर एक दर्द है;) पूर्ण-विकसित ओउथ पर जाए बिना। मैं उस पर नूडल करूँगा।