वर्डप्रेस ऑडिट कर रहे हैं? अपने प्लगइन्स से शुरू करें

सारांश

अधिकांश वर्डप्रेस सुरक्षा ऑडिट उल्टे हैं: वे कोर अपडेट और स्कैनर रिपोर्ट पर जोर देते हैं जबकि वास्तव में नुकसान पहुंचाने वाली कमजोरियाँ प्लगइन्स में होती हैं। एक SANS व्हाइट पेपर में पाया गया कि 96% से अधिक पारिस्थितिकी तंत्र की कमजोरियाँ थर्ड-पार्टी प्लगइन्स से उत्पन्न होती हैं, और लगभग 43% को किसी प्रमाणीकरण की आवश्यकता नहीं होती है। यह लेख एक छोटी इन-हाउस मार्केटिंग टीम के लिए प्लगइन-पहली ऑडिट के माध्यम से चलता है, एक ऐसी साइट की कहानी का उपयोग करते हुए जो हैक हो गई क्योंकि हर कोई गलत परत को स्कैन कर रहा था। आप हर प्लगइन को इन्वेंट्री और वर्गीकृत करना, बिना प्रमाणीकरण के हमले की सतहों का परीक्षण करना, मैन्युअल रूप से उपयोगकर्ताओं और लॉग्स की समीक्षा करना, और निष्कर्षों को जोखिम की भाषा में अनुवाद करना सीखेंगे जिसे एक गैर-तकनीकी बॉस समझ सके। परिणाम एक चेकबॉक्स अभ्यास के बजाय एक त्रैमासिक ट्राइएज अनुष्ठान है।

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

संख्याएँ इसका समर्थन करती हैं। वर्डप्रेस प्लगइन्स को स्कैन करने पर एक SANS व्हाइट पेपर ने पाया कि वर्डप्रेस पारिस्थितिकी तंत्र में 96% से अधिक कमजोरियाँ थर्ड-पार्टी प्लगइन्स से उत्पन्न होती हैं, थीम्स 4% और कोर 1% से कम। लगभग 43% दोषों का बिना किसी प्रमाणीकरण के शोषण किया जा सकता है। इसलिए जब आपकी ऑडिट अपनी अधिकांश ऊर्जा कोर पर खर्च करती है, तो आप पेड़ों की जांच कर रहे हैं जबकि बगल के प्लगइन निर्देशिका में जंगल की आग शुरू होती है।

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

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

आप 2017 से चल रही एक वर्डप्रेस साइट के साथ एक छोटी मार्केटिंग टीम पर हैं। इसमें एक कस्टम इवेंट-पंजीकरण प्लगइन है जिसे एक फ्रीलांसर ने 2019 में बनाया था, एक संपर्क फ़ॉर्म प्लगइन जिसमें फ़ाइल अपलोड फ़ील्ड है, और एक स्लाइडर प्लगइन जो बेचा गया था और अब सार्वजनिक अपडेट पेज नहीं है। यह एक असामान्य स्टैक नहीं है। यह वह जगह है जहाँ आपकी ऑडिट शुरू होती है।

---

प्लगइन इन्वेंटरी आपकी सुरक्षा नीति है

हर प्लगइन और थीम की इन्वेंट्री लें। संस्करण, अंतिम अपडेट तिथि, विक्रेता अभी भी जीवित है या नहीं, और क्या कोई वास्तव में इसका उपयोग करता है, लिखें। फिर प्रत्येक को एक बकेट में वर्गीकृत करें: अनुरक्षित और उपयोग किया गया, अनुरक्षित और अनुपयोगी, परित्यक्त लेकिन उपयोग किया गया, परित्यक्त और अनुपयोगी। अनुपयोगी लोगों को तुरंत हटा दें। "यह केवल $50/माह है" बचाव को अनदेखा करें — एक अनुपयोगी प्लगइन एक दायित्व है, सुविधा नहीं। परित्यक्त-लेकिन-उपयोग किए गए लोगों के लिए, निर्णय लें: इसे बदलें, या जोखिम स्वीकार करें और इसे एक जोखिम रजिस्टर में लिखें जिसे आपके बॉस ने देखा है।

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

हमले की सतह	वर्डप्रेस ज्ञात कमजोरियों का हिस्सा	ऑडिट प्राथमिकता
थर्ड-पार्टी प्लगइन्स	96% से अधिक	सर्वोच्च — इन्वेंट्री, स्कैन, परीक्षण, बदलें
थीम्स	लगभग 4%	मध्यम — केवल यदि कस्टम या पुराना हो
वर्डप्रेस कोर	1% से कम	कम — पैच रखें, आगे बढ़ें

जब SecurityWeek ने 2024 में 8,000 से अधिक नई वर्डप्रेस कमजोरियों की गणना की, तो विशाल बहुमत इस प्रकार की थीं: प्लगइन समस्याएँ, कोर पैच नहीं। एक स्कैनर आपको उन लोगों के बारे में बताएगा जिन्हें सार्वजनिक किया गया है और CVE दिया गया है। यह आपको बिना CVE वाले कस्टम फ्रीलांसर कोड के बारे में नहीं बताएगा, क्योंकि किसी ने कभी इसे ध्यान से नहीं देखा है। वह मैन्युअल देखना आपका काम है। प्लगइन-विशिष्ट जांच की गहन जानकारी के लिए, अपने वर्डप्रेस प्लगइन्स की सुरक्षा ऑडिट करना देखें।

---

इसे एक अजनबी की तरह परखें: 43% जिन्हें पासवर्ड की आवश्यकता नहीं है

आपके स्कैनर ने पहले ही आपको बता दिया है कि कुछ भी गलत नहीं है। अब वह करें जो वह नहीं कर सकता: लॉगिन के बिना, बाहर से साइट की जांच करें। हर फ़ाइल अपलोड फ़ील्ड, हर फ़ॉर्म जो POST संसाधित करता है, हर admin-ajax समापन बिंदु से शुरू करें। क्या अपलोड वास्तव में फ़ाइल सामग्री की जांच करता है, या केवल एक्सटेंशन? अपलोड की गई फ़ाइलें कहाँ जाती हैं, और क्या वेब सर्वर उस निर्देशिका में PHP निष्पादित कर सकता है? प्लगइन दोषों के 43% जिन्हें किसी प्रमाणीकरण की आवश्यकता नहीं होती है, आमतौर पर ठीक इन्हीं जगहों पर होते हैं: बिना प्रमाणीकरण के संग्रहीत XSS, मनमाना फ़ाइल अपलोड, और PHP ऑब्जेक्ट इंजेक्शन।

संपर्क फ़ॉर्म प्लगइन आगंतुकों को एक रिज्यूमे संलग्न करने देता है। यह आगंतुक के मूल फ़ाइल नाम का उपयोग करके फ़ाइल का नाम बदलता है, इसलिए आप "resume.php" अपलोड करते हैं और यह इसे /uploads/contact/ फ़ोल्डर में सहेजता है जो डिज़ाइन द्वारा लिखने योग्य है। यदि सर्वर उस निर्देशिका में PHP चलाने की भी अनुमति देता है, तो हमलावर को अभी-अभी एक वेबशेल मिल गई है। Fastly ने वर्डप्रेस प्लगइन्स में बिना प्रमाणीकरण के संग्रहीत XSS के सक्रिय शोषण का दस्तावेजीकरण किया है — यह एक विशिष्ट स्लाइड-डेक जोखिम नहीं है। आपका परीक्षण सरल है: ज्ञात सामग्री वाली एक फ़ाइल बनाएं, उसे अपलोड करें, और देखें कि क्या वह अपने मूल नाम और प्रकार के साथ वापस आती है। फिर एक .php फ़ाइल अपलोड करने का प्रयास करें। यदि यह .php के रूप में वापस आती है, तो आपको अभी एक शोषण योग्य छेद मिला है।

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

---

स्कैनर क्या नहीं देख सकता: उपयोगकर्ता, लॉग्स और पुराना कोड

गतिशील परीक्षण वह पकड़ते हैं जो अभी उजागर है। मैन्युअल समीक्षा वह पकड़ती है जो पहले से अंदर है। उपयोगकर्ता खातों से शुरू करें: एडमिन सूची खोलें और उन खातों की तलाश करें जो आपने नहीं बनाए हैं। एक मुफ्त-मेल पते और पीछे कोई मानव न होने वाला "support" नाम का एडमिन एक बैकडोर है, सहकर्मी नहीं। wp-content/uploads में फ़ाइल टाइमस्टैम्प की जांच करें जो आपकी सामग्री नहीं है। सर्वर एक्सेस लॉग की जांच करें जो किसी व्यक्ति के ब्राउज़र के बजाय बॉट के curl कमांड जैसा दिखता है।

इवेंट प्लगइन में एक "speaker photo" अपलोड है जो uploads/event-headshots/ में सहेजता है। परीक्षण के दौरान आपको एक ऐसी फ़ाइल मिलती है जो आपकी नहीं है — एक छोटी PHP फ़ाइल जिसका नाम यादृच्छिक लगता है। वह आपका वेबशेल है। यह उसी अपलोड दोष के माध्यम से वहाँ पहुंची जिसका आपने दो सप्ताह पहले परीक्षण किया था, और अब तक एक स्कैनर इसे "देख" नहीं पाएगा क्योंकि यह एक प्लगइन कमजोरी नहीं है; यह एक का सबूत है। मैन्युअल समीक्षा इसे ढूंढती है, हटाती है, और इसे वहाँ रखने वाले IP पते के लिए लॉग की जांच करती है। Invicti ने नोट किया है कि प्लगइन्स में PHP ऑब्जेक्ट इंजेक्शन बढ़ रहा है, और यह ब्लैक-बॉक्स स्कैन के लिए लगभग अदृश्य है क्योंकि दुर्भावनापूर्ण ऑब्जेक्ट केवल निष्पादन के दौरान ही प्रकट होता है। इसे देखने का एकमात्र तरीका उपयोगकर्ता-आपूर्ति इनपुट पर unserialize() कॉल करने जैसे खतरनाक पैटर्न के लिए कोड पढ़ना है। कस्टम प्लगइन की कुछ सौ पंक्तियाँ पढ़ना एक घटना-प्रतिक्रिया रिटेनर का भुगतान करने से सस्ता है।

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

---

अपने बॉस को घबराहट पैदा किए बिना सच बताना

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

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

---

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