हैक की गई सामग्री: जब किसी विज्ञापनदाता की नहीं बल्कि खुद साइट की सुरक्षा भंग होती है, तो वास्तव में क्या होता है

पहला संकेत शायद ही कभी किसी आधिकारिक स्रोत से आता है। यह Search Console में कुछ अजीब URL हो सकते हैं जिन्हें टीम में किसी को भी बनाया हुआ याद नहीं, या ऑर्गेनिक ट्रैफ़िक में बिना किसी स्पष्ट कारण के आई गिरावट हो सकती है जो सामान्य डैशबोर्ड में नज़र नहीं आती, या कोई विज्ञापनदाता यह पूछते हुए लिख सकता है कि उसके लिस्टिंग पेज को साइट से असंबंधित किसी जगह पर क्यों रीडायरेक्ट किया जा रहा है। कभी-कभी कोई विज़िटर बताता है कि ब्राउज़र ने पेज खोलने से मना कर दिया। इनमें से कुछ भी किसी विज्ञापनदाता की धोखाधड़ी जैसा नहीं लगता, और न ही यह उस स्थिति जैसा है जहाँ किसी दुर्भावनापूर्ण विज्ञापन के कारण साइट को फ़्लैग कर दिया जाता है जबकि साइट के अपने कोड की इसमें कोई गलती नहीं होती।

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

हमलावर वास्तव में कैसे अंदर घुसता है, और यह शायद ही कभी नाटकीय होता है

इस स्तर पर लगभग कोई भी किसी वयस्क क्लासिफाइड्स डायरेक्टरी को खास तौर पर निशाना नहीं बनाता। आम पैटर्न यह है कि कोई बॉट खुले वेब पर किसी भी ऐसी साइट को ढूँढता है जो किसी ज्ञात, बिना पैच की गई खामी वाला कोई खास सॉफ़्टवेयर चला रही हो, ठीक वैसे ही जैसे वह रेस्टोरेंट की साइटों या लॉ फ़र्मों के ब्लॉग को खोजता है। साइट इसलिए निशाने पर आती है क्योंकि वह संयोगवश वही CMS, वही प्लगइन या वही पुरानी लाइब्रेरी चला रही होती है जो दस लाख अन्य साइटें चला रही होती हैं, न कि इसलिए कि किसी ने उसे देखकर तय किया हो कि यह मेहनत के लायक है।

पुराना सॉफ़्टवेयर एक वास्तविक और आम कारण है, लेकिन यह पूरी कहानी नहीं है, और इसे पूरी कहानी मानने से असल एंट्री पॉइंट्स में से आधे असुरक्षित रह जाते हैं। Sucuri की हैक्ड वेबसाइट रिपोर्ट, जो 2023 में उसके द्वारा साफ़ की गई साइटों पर आधारित है, बताती है कि संक्रमण के समय 39.1% प्रभावित CMS इंस्टॉलेशन पुराना सॉफ़्टवेयर चला रहे थे, जो पिछले साल के 50.58% से कम है। उसी रिपोर्ट में यह भी पाया गया कि जब Sucuri ने सुधार कार्य की बारीकी से जाँच की, तो उन साइटों में से केवल लगभग 14% में ही कोई पहचान योग्य कमज़ोर प्लगइन या थीम मौजूद थी। दूसरे शब्दों में, जिन साइटों को उसने साफ़ किया, उनमें से अधिकतर असल में उस सॉफ़्टवेयर खामी से हैक नहीं हुई थीं जिसे कोई ऑपरेटर सबसे पहले ठीक करने की उम्मीद करता।

तस्वीर का दूसरा आधा हिस्सा क्रेडेंशियल्स का है। Verizon की 2025 डेटा ब्रीच इन्वेस्टिगेशंस रिपोर्ट, जो सिर्फ़ वेबसाइटों पर नहीं बल्कि उसके द्वारा ट्रैक किए जाने वाले हर उद्योग पर नज़र डालती है, में पाया गया कि चोरी किए गए या अंदाज़े से लगाए गए क्रेडेंशियल्स, हमलावरों के पहली पकड़ बनाने के तरीके के रूप में, शोषित सॉफ़्टवेयर कमज़ोरियों से थोड़ा आगे निकले: 22% ब्रीच बनाम 20%। यह आँकड़ा सिर्फ़ क्लासिफाइड्स साइटों से नहीं बना है, लेकिन यह उससे मेल खाता है जो Sucuri खास तौर पर CMS प्लेटफ़ॉर्म की सफ़ाई में देखता है। कई साल पहले किसी असंबंधित ब्रीच में लीक हुए किसी निजी ईमेल अकाउंट से दोबारा इस्तेमाल किया गया एडमिन पासवर्ड, व्यवहार में, किसी बिना पैच वाले प्लगइन जितना ही संभावित रास्ता है।

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

Google असल में इसे क्या कहता है, और यह दुर्भावनापूर्ण विज्ञापन से अलग समस्या क्यों है

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

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

पेज इंजेक्शन आमतौर पर वह पैटर्न है जिसे ऑपरेटर सबसे आखिर में खोजते हैं, और यह समझना उपयोगी है कि हमलावर अपनी खुद की इस्तेमाल करके फेंक देने वाली साइट बनाने के बजाय यह मेहनत क्यों करता है। जिस डोमेन का पहले से इतिहास है, मौजूदा बैकलिंक हैं, और सर्च रिज़ल्ट्स में स्थापित स्थिति है, वह स्पैम कंटेंट को रैंकिंग में एकदम नए डोमेन की तुलना में कहीं ज़्यादा तेज़ी से "साफ़" करके घुसा देता है, इसलिए हमलावर खुद से शुरुआत से प्रतिष्ठा बनाने के बजाय किसी मौजूदा साइट की प्रतिष्ठा उधार लेना पसंद करते हैं। यह कहीं और बताए गए बाहरी लिंक हमले से अलग तंत्र है: वहाँ हमला बाहर से अन्य साइटों के लिंक टारगेट की ओर इशारा करता है; यहाँ, स्पैम पेज टारगेट के अपने ही डोमेन पर, उसकी अपनी फ़ाइल संरचना के भीतर रहने के लिए बनाए जाते हैं।

एक बार जब यह सामग्री साइट पर मौजूद हो जाती है, तो नतीजे एक के बाद एक जुड़ते जाते हैं। Search Console की सिक्योरिटी इश्यूज़ रिपोर्ट सीधे उस प्रॉपर्टी को फ़्लैग करती है, कुछ पेजों को नतीजों से हटाया जा सकता है या लिस्टिंग में चेतावनी से बदला जा सकता है, और Chrome का Safe Browsing विज़िटरों को वही लाल इंटरस्टिशियल स्क्रीन दिखाना शुरू कर सकता है जिसका ज़िक्र विज्ञापन नेटवर्क वाले मामले के लिए पहले किया जा चुका है, लेकिन इस बार यह इसलिए शुरू होता है क्योंकि साइट वास्तव में दुर्भावनापूर्ण या भ्रामक सामग्री होस्ट कर रही है, न कि किसी खराब क्रिएटिव के उसमें से गुज़रने की वजह से।

चेतावनी हटवाना: वह क्रम जो असल में काम करता है

Google का अपना मार्गदर्शन क्रम के बारे में खास तौर पर स्पष्ट है, और व्यवहार में जो ज़्यादातर समय बर्बाद होता है वह इन कदमों को गलत क्रम में उठाने से होता है। पहला काम है इंजेक्ट की गई सामग्री के हर एक उदाहरण को ढूँढकर हटाना, न कि सिर्फ़ उस नमूना पेज को जिसे Search Console ने समस्या के उदाहरण के रूप में बताया था। वह पता एक नमूना है, पूरी सूची नहीं, और जो सफ़ाई उसे ठीक करने के बाद रुक जाती है, वह आमतौर पर असली इंजेक्शन का ज़्यादातर हिस्सा जस का तस छोड़ देती है।

दूसरा काम यह पता लगाना है कि हमलावर कैसे अंदर आया और ठीक उसी छेद को बंद करना, चाहे वह कोई बिना पैच वाला प्लगइन हो, कोई लीक हुआ क्रेडेंशियल हो, या कोई गलत कॉन्फ़िगर की गई परमिशन हो, क्योंकि एंट्री पॉइंट ठीक किए बिना स्पैम पेज हटाना बस घड़ी को तब तक रीसेट कर देता है जब तक वही हमलावर, या वही ऑटोमेटेड स्कैन, उसी दरवाज़े से वापस नहीं आ जाता। Google का दस्तावेज़ स्पष्ट रूप से कहता है कि सुधार पूरी साइट को कवर करना चाहिए, सिर्फ़ होमपेज या किसी विज़िटर द्वारा बताए गए पेज को नहीं, और उसी गाइड के एक संबंधित हिस्से में एडमिन एक्सेस वाले अकाउंट से जुड़े हर पासवर्ड को बदलने की सलाह दी गई है: CMS लॉगिन, होस्टिंग कंट्रोल पैनल, FTP या SFTP, और डेटाबेस, ठीक इसलिए क्योंकि एंट्री पॉइंट अक्सर उस पेज के बजाय इनमें से कोई एक होता है जहाँ लक्षण दिखाई दिया।

जो हिस्सा ऑपरेटर सबसे ज़्यादा उलट देते हैं, वह है Google से दोबारा जाँच करने के लिए कब कहना। ऊपर बताई गई सफ़ाई वास्तव में पूरी होने से पहले रिव्यू माँगने से कुछ भी तेज़ नहीं होता; Google साफ़ तौर पर कहता है कि समस्या के अब भी मौजूद रहते हुए रिव्यू माँगना सिर्फ़ उस समय को बढ़ाता है जितनी देर साइट फ़्लैग की हुई रहती है। रिव्यू का समय श्रेणी के हिसाब से अलग-अलग होता है: सीधे-सादे मैलवेयर का रिव्यू आमतौर पर कुछ दिन लेता है, फ़िशिंग का लगभग एक दिन, लेकिन इंजेक्ट किए गए स्पैम पेजों वाली हैक की गई सामग्री के रिव्यू में कई हफ़्ते तक लग सकते हैं, क्योंकि Google इस श्रेणी को ऐसी मानता है जिसमें ऑटोमेटेड रीचेक के बजाय वाकई मैनुअल जाँच की ज़रूरत पड़ सकती है।

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

इस व्यवसाय के बजट में वाकई इसे क्या रोकता है

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

ऊपर बताए गए Sucuri और Verizon के आँकड़े असल में जो दिखाते हैं उसे देखते हुए, क्रेडेंशियल अनुशासन का वज़न पैचिंग जितना ही है। इसका मतलब है साइट को छू सकने वाले हर अकाउंट के लिए एक अलग पासवर्ड, जो याद रखने के बजाय किसी पासवर्ड मैनेजर में जनरेट और सेव किया गया हो; जहाँ भी टू-फ़ैक्टर ऑथेंटिकेशन उपलब्ध हो वहाँ उसे चालू करना; और स्टाफ़ या मॉडरेटर्स के बीच साझा किए गए लॉगिन न रखना, क्योंकि साझा लॉगिन ऐसा एक्सेस भी है जिसे कुछ गलत होने पर किसी एक व्यक्ति तक वापस ट्रेस नहीं किया जा सकता।

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

आखिरी हिस्सा बस जल्दी पता लगाना है। Search Console के अपने ईमेल अलर्ट सिक्योरिटी इश्यूज़ रिपोर्ट को ऐसे इनबॉक्स तक पहुँचाते हैं जिसे वाकई कोई पढ़ता है, न कि यह होने देना कि ऑपरेटर को समस्या का पता किसी विज़िटर की शिकायत से या दिनों-हफ़्तों बाद ऑर्गेनिक ट्रैफ़िक के धीरे-धीरे बहने से चले। इनमें से किसी भी कदम की कीमत समय से ज़्यादा नहीं है, और ये सब अभी करना, चेतावनी वाली स्क्रीन द्वारा पहले ही एक हफ़्ते का ट्रैफ़िक खा लेने और सफ़ाई सुलझने के इंतज़ार के बाद करने से कहीं सस्ता है।

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