Safe Browsing API की मदद से, आपके क्लाइंट ऐप्लिकेशन, असुरक्षित वेब रिसॉर्स की लगातार अपडेट होने वाली Google की सूचियों के हिसाब से, यूआरएल की रीयलटाइम या सूची के आधार पर जांच कर सकते हैं. असुरक्षित वेब संसाधनों के उदाहरण हैं: सोशल इंजीनियरिंग साइटें (फ़िशिंग साइटें और गलत पहचान दिखाकर धोखा देने वाली साइटें), मैलवेयर या अनचाहे सॉफ़्टवेयर होस्ट करने वाली साइटें. सुरक्षित ब्राउज़िंग की सूची में मौजूद किसी भी यूआरएल को असुरक्षित माना जाता है.
यह पता लगाने के लिए कि कोई यूआरएल, सुरक्षित ब्राउज़िंग की किसी सूची में शामिल है या नहीं, क्लाइंट urls.search या hashes.search में से किसी एक का इस्तेमाल कर सकते हैं.
नया क्या है?
नया डेटा
आम तौर पर, सुरक्षित ब्राउज़िंग क्लाइंट, समय-समय पर खतरों की सूचियां डाउनलोड करते हैं. इनका इस्तेमाल संभावित खतरों से मिलान करने के लिए किया जाता है. समय के साथ, खतरों की संख्या और उनकी गति, दोनों में बढ़ोतरी हुई है. इसलिए, खतरों की स्थानीय सूचियां, आधुनिक खतरों से निपटने में कम असरदार साबित हुई हैं.
इस अंतर को कम करने के लिए, हम प्रोटोकॉल को check-by-default पर सेट करने की सुविधा उपलब्ध करा रहे हैं. पहले V4 में, प्रोटोकॉल को allow-by-default पर सेट करने की सुविधा उपलब्ध थी. इसके लिए, "ग्लोबल कैश मेमोरी" के तौर पर जानी जाने वाली, ऐसी साइटों की सूची डाउनलोड करने की सुविधा शुरू की गई है जो शायद सुरक्षित हैं. अगर कोई यूआरएल ग्लोबल कैश में नहीं मिलता है, तो क्लाइंट को एपीआई की मदद से यह जांच करनी चाहिए कि यूआरएल से कोई खतरा तो नहीं है.
डिफ़ॉल्ट रूप से जांच करने की इस सुविधा के साथ-साथ, सेवा में डेटा को अपडेट करने की सुविधा भी बेहतर की गई है. इससे नए खतरों से तुरंत और रीयल-टाइम में सुरक्षा मिलती है.
आईपी पते की निजता
Safe Browsing API, आईपी पतों का इस्तेमाल सिर्फ़ ज़रूरी नेटवर्किंग के लिए करता है. साथ ही, इनका इस्तेमाल DoS से बचाव के लिए भी किया जाता है.
हमने एक कंपैनियन एपीआई लॉन्च किया है. इसे Safe Browsing Oblivious HTTP Gateway API के नाम से जाना जाता है. इससे निजता की अतिरिक्त गारंटी मिलती है. यह Oblivious HTTP का इस्तेमाल करके, असली उपयोगकर्ताओं के आईपी पतों को Google से छिपाता है. यह इस तरह काम करता है कि तीसरे पक्ष की कोई कंपनी, उपयोगकर्ता के अनुरोध के एन्क्रिप्ट (सुरक्षित) किए गए वर्शन को मैनेज करती है. इसके बाद, उसे Google को भेजती है. इसलिए, तीसरे पक्ष के पास सिर्फ़ आईपी पतों का ऐक्सेस होता है और Google के पास सिर्फ़ अनुरोध के कॉन्टेंट का ऐक्सेस होता है. तीसरा पक्ष, Oblivious HTTP Relay (जैसे, Fastly की यह सेवा) को मैनेज करता है. वहीं, Google, Oblivious HTTP Gateway को मैनेज करता है. यह एक वैकल्पिक कंपैनियन एपीआई है. Google की सुरक्षित ब्राउज़िंग की सुविधा के साथ इसका इस्तेमाल करने पर, असली उपयोगकर्ताओं के आईपी पते Google को नहीं भेजे जाते.
ज़्यादा जानकारी के लिए, Safe Browsing Oblivious HTTP Gateway API से जुड़ा दस्तावेज़ देखें.
खोज विधियां
आइए, यूआरएल की रीयल-टाइम में जांच करने के लिए उपलब्ध अलग-अलग तरीकों के बारे में जानें.
urls.search
यह क्लाइंट ऐप्लिकेशन को, सुरक्षित ब्राउज़िंग सेवा को यूआरएल भेजने की अनुमति देता है. इससे यह पता लगाया जा सकता है कि यूआरएल से कोई खतरा तो नहीं जुड़ा है.
फ़ायदे
- यूआरएल की सामान्य जांच: इसमें असली यूआरएल के साथ अनुरोध भेजा जाता है. इसके जवाब में सर्वर, यूआरएल के साथ उनसे जुड़े खतरों की जानकारी देता है.
कमियां
- यूआरएल की गोपनीयता बनाए नहीं रखी गई है: अनुरोध में, जांच किए जा रहे रॉ यूआरएल शामिल हैं.
अगर फ़ायदे/नुकसान आपकी ज़रूरत के मुताबिक हैं, तो urls.search का इस्तेमाल करें, क्योंकि इसे इस्तेमाल करना आसान है.
तरीके के इस्तेमाल की सेवा की शर्तें पढ़ें, क्योंकि ये hashes.search से अलग होती हैं.
hashes.search
इस कुकी की मदद से, क्लाइंट ऐप्लिकेशन यह जांच कर सकते हैं कि यूआरएल के सेट में कोई ज्ञात खतरा तो नहीं है. हालांकि, इससे सेवा को असली यूआरएल का पता नहीं चलता. ऐसा सिर्फ़ यूआरएल का हैश प्रीफ़िक्स देकर किया जाता है. जवाब में, ज्ञात खतरों के पूरे हैश शामिल होंगे. साथ ही, इसमें शार्ड हैश प्रीफ़िक्स भी होगा.
फ़ायदे
- यूआरएल की निजता: अनुरोध में, हैश किए गए यूआरएल का सिर्फ़ 4-बाइट हैश प्रीफ़िक्स होता है.
- कंपैटिबिलिटी: इस तरीके में, यूआरएल कैननलाइज़ेशन और हैशिंग को क्लाइंट मैनेज करता है. इसलिए, यह तरीका उन मोड के साथ आसानी से इंटिग्रेट हो जाता है जो लोकल डेटाबेस का इस्तेमाल करते हैं. जैसे, रीयल-टाइम मोड और लोकल लिस्ट मोड.
कमियां
- जटिल यूआरएल की जांच: इस तरीके से अनुरोध करने के लिए, आपको यूआरएल को कैननिकल बनाने, सफ़िक्स/प्रीफ़िक्स एक्सप्रेशन बनाने, और SHA256 हैश का हिसाब लगाने का तरीका पता होना चाहिए. साथ ही, असुरक्षित सूचियों या ग्लोबल कैश की स्थानीय कॉपी से तुलना करने का तरीका भी पता होना चाहिए.
अगर आपको यूआरएल की निजता को प्राथमिकता देनी है और रीयल-टाइम मोड या लोकल लिस्ट मोड का इस्तेमाल करना है, तो हमारा सुझाव है कि आप hashes.search का इस्तेमाल करें.
HashList तरीके
इन तरीकों से क्लाइंट, असुरक्षित साइटों की सूचियों और ग्लोबल कैश के हैश किए गए वर्शन को डाउनलोड और सेव कर सकते हैं. क्लाइंट इस जानकारी का इस्तेमाल करके यह तय कर सकते हैं कि उन्हें उन यूआरएल की रीयल-टाइम खोज करनी चाहिए या नहीं जिनके बारे में सवाल पूछा गया है.
ये तरीके, रीयल-टाइम मोड और स्थानीय सूची मोड के काम करने के लिए ज़रूरी हैं.
इन तरीकों का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, लोकल डेटाबेस पेज देखें.
अनुरोध के उदाहरण
इस सेक्शन में, Safe Browsing को ऐक्सेस करने के लिए, सीधे तौर पर एचटीटीपी एपीआई का इस्तेमाल करने के कुछ उदाहरण दिए गए हैं. आम तौर पर, जनरेट की गई भाषा बाइंडिंग का इस्तेमाल करने का सुझाव दिया जाता है. इसकी वजह यह है कि यह एन्कोडिंग और डिकोडिंग को आसानी से अपने-आप मैनेज करती है. कृपया उस बाइंडिंग के दस्तावेज़ देखें.
urls.search का इस्तेमाल करके एचटीटीपी अनुरोध का उदाहरण:
GET https://safebrowsing.googleapis.com/v5alpha1/urls:search?key=INSERT_YOUR_API_KEY_HERE&urls=testsafebrowsing.appspot.com/
hashes.search का इस्तेमाल करके एचटीटीपी अनुरोध का उदाहरण:
GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ
hashLists.batchGet का इस्तेमाल करके एचटीटीपी अनुरोध का उदाहरण:
GET https://safebrowsing.googleapis.com/v5/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw-4b
सभी रिस्पॉन्स बॉडी, प्रोटोकॉल-बफ़र फ़ॉर्मैट में पेलोड होती हैं. इन्हें डिकोड किया जा सकता है.