TL;DR

• पहुँचता जाँचकर्ता <= 1.30.0 में एक योगदानकर्ता-स्तरीय IDOR एक प्रमाणित उपयोगकर्ता (योगदानकर्ता भूमिका) को उन वस्तुओं तक पहुँचने या उन्हें संशोधित करने की अनुमति देता है जिनकी उन्हें अनुमति नहीं होनी चाहिए।.
• CVE: CVE-2025-57886। पहुँचता जाँचकर्ता 1.30.1 में ठीक किया गया।.
• गंभीरता निर्धारित: CVSS 5.4 (मध्यम / निम्न पैच प्राथमिकता) — प्रभाव साइट सेटअप और प्लगइन के उपयोग पर निर्भर करता है।.
• तात्कालिक क्रियाएँ: 1) प्लगइन को 1.30.1+ में अपडेट करें, 2) पैच होने तक प्लगइन UI तक योगदानकर्ता पहुँच को प्रतिबंधित करें, 3) अनधिकृत वस्तु पहुँच पैटर्न को ब्लॉक करने के लिए WAF / आभासी पैचिंग सक्षम करें।.
• यदि आप कई साइटें चलाते हैं, तो उन साइटों को अपडेट करने को प्राथमिकता दें जहाँ योगदानकर्ता खाते गैर-विश्वसनीय उपयोगकर्ताओं के लिए मौजूद हैं या जहाँ प्लगइन मिशन-क्रिटिकल है।.

पृष्ठभूमि: IDOR क्या है और यह क्यों महत्वपूर्ण है

असुरक्षित प्रत्यक्ष वस्तु संदर्भ (IDOR) तब होते हैं जब एक एप्लिकेशन एक आंतरिक वस्तु पहचानकर्ता (उदाहरण के लिए, एक डेटाबेस पंक्ति ID, फ़ाइल पथ, या टोकन) को एक URL या पैरामीटर में उजागर करता है और सर्वर-साइड पर उचित प्राधिकरण जांच लागू करने में विफल रहता है। हमलावर जो उस पहचानकर्ता को बदल सकते हैं, वे अन्य उपयोगकर्ताओं के डेटा या क्रियाओं तक पहुँच प्राप्त कर सकते हैं।.

IDOR के सामान्य परिणामों में शामिल हैं:

• अन्य उपयोगकर्ताओं के रिकॉर्ड (फ़ाइलें, रिपोर्ट, सेटिंग्स) पढ़ना या संशोधित करना।.
• यदि एंडपॉइंट में प्राधिकरण की कमी है तो किसी और के रूप में क्रियाएँ करना (पोस्ट करना, हटाना, कॉन्फ़िगरेशन बदलना)।.
• संवेदनशील डेटा (ईमेल पते, अपलोड की गई फ़ाइलें) निकालना।.

IDOR अक्सर प्रमाणीकरण की आवश्यकता होती है, लेकिन इससे वे हानिरहित नहीं हो जाते। यदि एक हमलावर एक निम्न-विशिष्टता खाता (योगदानकर्ता/लेखक) पंजीकृत या प्राप्त कर सकता है, तो वे प्रशासकों के लिए निर्धारित संसाधनों तक पहुँच प्राप्त करके प्रभाव को बढ़ा सकते हैं।.

पहुँचता जाँचकर्ता समस्या को सरल भाषा में

• एक सुरक्षा शोधकर्ता ने पहुँचता जाँचकर्ता प्लगइन में एक IDOR की रिपोर्ट की जो योगदानकर्ता भूमिका वाले उपयोगकर्ता को अन्य उपयोगकर्ताओं या वैश्विक डेटा से जुड़े वस्तुओं (रिपोर्ट, स्कैन, या प्रशासनिक संसाधन) तक पहुँचने की अनुमति देती थी।.
• प्लगइन संस्करण <= 1.30.0 ने सही ढंग से सत्यापित नहीं किया कि प्रमाणित उपयोगकर्ता अनुरोधित वस्तुओं के लिए अधिकृत था।.
• प्लगइन लेखक ने 1.30.1 जारी किया जिसमें सुधार शामिल है - सर्वर-साइड प्राधिकरण जांचें यह सुनिश्चित करने के लिए कि अनुरोधित वस्तुएं अनुरोधकर्ता के लिए संबंधित हैं या अनुमति प्राप्त हैं।.

महत्वपूर्ण विवरण:

• इस भेद्यता के लिए एक प्रमाणित खाता (योगदानकर्ता) की आवश्यकता होती है।.
• CVSS मध्यम है क्योंकि शोषण के लिए प्रमाणीकरण की आवश्यकता होती है, लेकिन वास्तविक प्रभाव इस पर निर्भर करता है कि प्लगइन क्या संग्रहीत और उजागर करता है (जैसे, अटैचमेंट, URLs, या स्कैन डेटा)।.
• भेद्यता 1.30.1 में ठीक की गई है - अपडेट करने से जोखिम समाप्त हो जाता है।.

यह जल्दी से कैसे जांचें कि आप प्रभावित हैं

1. वर्डप्रेस प्रशासन में, प्लगइन्स → स्थापित प्लगइन्स पर जाएं और “एक्सेसिबिलिटी चेकर” खोजें।”
2. यदि स्थापित संस्करण <= 1.30.0 है तो आप प्रभावित हैं; 1.30.1 या बाद के संस्करण में अपडेट करें।.
3. यदि आप तुरंत अपडेट नहीं कर सकते:
   • अस्थायी रूप से प्लगइन को निष्क्रिय करें।.
   • या यह सीमित करें कि कौन प्लगइन तक पहुंच सकता है (नीचे तात्कालिक शमन देखें)।.

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

शोषण परिदृश्य (एक हमलावर क्या कर सकता है)

• एक दुर्भावनापूर्ण योगदानकर्ता प्लगइन द्वारा उजागर वस्तु पहचानकर्ताओं की गणना करता है (URLs, फ़ॉर्म फ़ील्ड, AJAX पैरामीटर में IDs) और उन्हें अन्य उपयोगकर्ताओं के स्कैन परिणामों या अपलोड किए गए अटैचमेंट्स तक पहुंचने के लिए दोहराता है।.
• एक योगदानकर्ता डेटा को निर्यात या देख सकता है जिसे उन्हें नहीं देखना चाहिए (निजी स्कैन डेटा, साइट निदान, संवेदनशील टोकन वाले URLs)।.
• यदि प्लगइन अपलोड की गई फ़ाइलों (एक्सेसिबिलिटी रिपोर्ट के लिए अटैचमेंट) को संग्रहीत या संदर्भित करता है, तो एक हमलावर अन्य उपयोगकर्ताओं द्वारा अपलोड की गई फ़ाइलों तक पहुंच सकता है।.
• यदि प्लगइन कॉन्फ़िगरेशन या बाहरी सिस्टम के लिए लिंक उजागर करता है, तो एक हमलावर फॉलो-अप हमलों के लिए उपयोगी जानकारी एकत्र कर सकता है।.

प्रभाव भिन्न होता है - कुछ साइटें केवल गैर-संवेदनशील एक्सेसिबिलिटी स्कैन मेटाडेटा को उजागर कर सकती हैं, जबकि अन्य PII या आंतरिक URLs को उजागर कर सकती हैं। जांचें कि आपकी साइट प्लगइन का उपयोग कैसे करती है।.

पहचान: प्रयासित शोषण का पता लगाने के लिए कैसे

IDOR प्रयासों से सामान्यतः जुड़े पैटर्न के लिए सर्वर और एप्लिकेशन लॉग की निगरानी करें:

• समान एंडपॉइंट पर अनुक्रमिक परिवर्तनों के साथ पुनरावृत्त अनुरोध (जैसे, id=1, id=2, id=3)।.
• योगदानकर्ता-भूमिका खाते जो केवल व्यवस्थापक के लिए एंडपॉइंट या संसाधनों पर अनुरोध कर रहे हैं जिन्हें वे सामान्यतः नहीं देख सकते।.
• संसाधन एंडपॉइंट्स तक पहुंच की असामान्य रूप से उच्च दर जो विभिन्न मालिक आईडी लौटाते हैं।.
• प्लगइन AJAX एंडपॉइंट्स पर अनुरोध जो विभिन्न खातों से वस्तु आईडी या पथ शामिल करते हैं।.

एक्सेस लॉग में खोजने के लिए उदाहरण संकेतक (प्लगइन एंडपॉइंट्स को अपनी साइट पर वास्तविक एंडपॉइंट पथ से बदलें):

• क्वेरी स्ट्रिंग पैटर्न: /wp-admin/admin-ajax.php?action=ac_get_report&report_id=123
• एक आईपी या उपयोगकर्ता खाते से अनुक्रमिक संख्यात्मक अनुरोध
• योगदानकर्ता खातों द्वारा संसाधन पहुंच पर 200 प्रतिक्रियाएं जो सामान्यतः निषिद्ध होनी चाहिए

यदि आप संदिग्ध गतिविधि पाते हैं, तो प्रभावित उपयोगकर्ताओं के लिए क्रेडेंशियल्स को घुमाने पर विचार करें और नीचे दिए गए घटना प्रतिक्रिया चरणों का पालन करें।.

तात्कालिक उपाय (अभी क्या करना है)

1. प्लगइन को 1.30.1 या बाद के संस्करण में अपडेट करें (प्राथमिकता, तेज, और पूर्ण सुधार)।.
2. यदि आप तुरंत अपडेट नहीं कर सकते:
   • उच्च-जोखिम साइटों पर प्लगइन को हटा दें या निष्क्रिय करें।.
   • योगदानकर्ता भूमिका की क्षमताओं को अस्थायी रूप से सीमित करें (नीचे क्षमता सख्ती देखें)।.
   • जब तक आप अपडेट नहीं कर सकते, तब तक अपने WAF के साथ पहुंच को अवरुद्ध करके प्लगइन एंडपॉइंट्स को निष्क्रिय करें (AJAX एंडपॉइंट्स के लिए पैटर्न-आधारित नियम)।.
3. उपयोगकर्ता खातों का ऑडिट करें:
   • अनावश्यक योगदानकर्ता खातों को हटा दें या परिवर्तित करें।.
   • हाल ही में बनाए गए संदिग्ध खातों की जांच करें।.
4. अपलोड और फ़ाइल पहुंच को सख्त करें:
   • सुनिश्चित करें कि अपलोड की गई फ़ाइलें उन स्थानों में संग्रहीत हैं जो अनुमति जांच को लागू करते हैं।.
   • जहां संभव हो, आंतरिक अपलोड पथों की सीधी सूची या सार्वजनिक पहुंच को रोकें (हस्ताक्षरित URL या पुनर्लेखन नियमों का उपयोग करें)।.
5. लॉग की निगरानी करें और पहचान अनुभाग में वर्णित संख्या पैटर्न के लिए अलर्ट सेट करें।.
6. यदि आप उजागर होने का संदेह करते हैं तो संवेदनशील रहस्यों को घुमाएं (API टोकन, कुंजी, या एकीकरण क्रेडेंशियल्स)।.

क्षमता सख्त करना: व्यावहारिक वर्डप्रेस कदम

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

<?php

नोट्स:

• इस पर दीर्घकालिक समाधान के रूप में भरोसा न करें। जितनी जल्दी हो सके प्लगइन को अपडेट करें।.
• पहले एक स्टेजिंग साइट पर परिवर्तनों का परीक्षण करें। क्षमता समायोजन संपादकीय कार्यप्रवाह को प्रभावित कर सकते हैं।.

WAF और वर्चुअल पैचिंग: ये कैसे मदद करते हैं, और क्या कॉन्फ़िगर करना है

एक WAF आपको आधिकारिक समाधान लागू करते समय सुरक्षा प्रदान कर सकता है, जो IDOR पर निर्भर शोषण पैटर्न को अवरुद्ध करता है। वर्चुअल पैचिंग (vPatching) का अर्थ है एक सुरक्षात्मक नियम लागू करना जो दुर्भावनापूर्ण अनुरोधों को रोकता है और उन्हें कमजोर कोड तक पहुँचने से रोकता है।.

IDOR सुरक्षा के लिए लागू करने के लिए प्रमुख WAF नियम:

• पैरामीटर छेड़छाड़ का पता लगाना: उन अनुरोधों को अवरुद्ध करें जहां वस्तु पहचानकर्ताओं को वैध उपयोग के लिए असामान्य तरीकों से बदला गया है (क्रमिक IDs की त्वरित गणना)।.
• भूमिका-आधारित एंडपॉइंट सुरक्षा: योगदानकर्ता भूमिका सत्रों द्वारा या वैध प्रशासन कुकीज़/नॉनसेस के बिना अनुरोधों द्वारा किए गए प्लगइन प्रशासन या AJAX एंडपॉइंट्स के लिए अनुरोधों को अवरुद्ध करें।.
• अनुरोध दर-सीमित करना: एक प्रमाणित खाते को थ्रॉटल करें जो कई अनुक्रमिक वस्तु पहुंच अनुरोध कर रहा है।.
• सामान्य हमले के वेक्टर को अवरुद्ध करें: संदिग्ध संदर्भों, ज्ञात बुरे IPs, या ज्ञात स्वचालन फिंगरप्रिंट के साथ अनुरोधों को अस्वीकार करें।.

अनुशंसित अस्थायी नियम: प्लगइन के एंडपॉइंट्स पर अनुरोधों का निरीक्षण करें और जब अनुरोध एक गैर-मालिक योगदानकर्ता द्वारा किया जाता है तो 403 लौटाएं जो दूसरे उपयोगकर्ता के लिए वस्तु पहचानकर्ताओं से संबंधित है। वर्चुअल पैच अस्थायी सुरक्षात्मक उपाय हैं जब तक आप आधिकारिक अपडेट स्थापित नहीं करते हैं और उन्हें अपस्ट्रीम समाधान के स्थान पर नहीं लेना चाहिए।.

घटना प्रतिक्रिया: यदि आपको संदेह है कि आपको शोषित किया गया था

यदि आप इस सुरक्षा भेद्यता से संबंधित दुरुपयोग के संकेत पाते हैं, तो एक मानक घटना प्रतिक्रिया कार्यप्रवाह का पालन करें:

1. शामिल करें:
   • प्रभावित साइटों पर तुरंत प्लगइन (1.30.1+) को अपडेट करें या अस्थायी रूप से प्लगइन को निष्क्रिय करें।.
   • यदि अपडेट संभव नहीं है, तो कमजोर एंडपॉइंट्स तक पहुंच को अवरुद्ध करने के लिए WAF नियम लागू करें और संदिग्ध योगदानकर्ता खातों को निलंबित करें।.
2. सबूत को संरक्षित करें:
   • फोरेंसिक्स के लिए प्रासंगिक लॉग (वेब सर्वर, PHP, प्लगइन लॉग) और प्रभावित फ़ाइलों की प्रतियां सहेजें।.
   • समय मुहरें, IP पते, और उपयोगकर्ता खाता पहचानकर्ताओं को नोट करें।.
3. जांच करें:
   • अप्रत्याशित फ़ाइल अपलोड, नए प्रशासनिक उपयोगकर्ता, या दुर्भावनापूर्ण अनुसूचित कार्यों की तलाश करें।.
   • प्लगइन वस्तु IDs से संबंधित अनधिकृत परिवर्तनों के लिए डेटाबेस तालिकाओं की जांच करें।.
4. समाप्त करें:
   • किसी भी वेबशेल, बैकडोर या दुर्भावनापूर्ण क्रोन जॉब्स को हटा दें।.
   • उन API कुंजियों और प्रमाणपत्रों को घुमाएं जो उजागर हो सकते हैं।.
5. पुनर्प्राप्त करें:
   • यदि आवश्यक हो तो साफ किए गए बैकअप को पुनर्स्थापित करें और सभी प्लगइन्स और WP कोर को अपडेट करें।.
   • सख्त उपयोगकर्ता नियंत्रण और प्रमाणपत्र फिर से लागू करें।.
6. समीक्षा करें और सीखें:
   • यह समझने के लिए एक मूल कारण विश्लेषण करें कि पहुंच कैसे हुई और कौन से नियंत्रण विफल हुए।.
   • घटना प्लेबुक को अपडेट करें और सभी साइटों पर सीखे गए पाठों को लागू करें।.

यदि आप समझते नहीं हैं कि समझौते का दायरा क्या है, तो एक पेशेवर घटना प्रतिक्रियाकर्ता को शामिल करें।.

दीर्घकालिक हार्डनिंग और सर्वोत्तम प्रथाएँ

• न्यूनतम विशेषाधिकार का सिद्धांत: योगदानकर्ता अनुमतियों को केवल आवश्यकतानुसार सीमित करें। फ़ाइलें अपलोड करने की क्षमता को हटा दें जब तक कि यह आवश्यक न हो।.
• प्लगइन शासन: केवल विश्वसनीय स्रोतों से प्लगइन्स स्थापित करें और साइटों के बीच प्लगइन्स और संस्करणों का एक सूची बनाए रखें।.
• नियमित स्कैनिंग और SCA: कमजोर संस्करणों का पता लगाने के लिए सॉफ़्टवेयर संरचना विश्लेषण या प्लगइन निगरानी उपकरणों का उपयोग करें।.
• स्टेजिंग और परीक्षण: पहले एक स्टेजिंग वातावरण में प्लगइन अपडेट लागू करें; जल्दी परीक्षण करें और फिर रोल आउट करें।.
• दो-कारक प्रमाणीकरण: जहां संभव हो, योगदानकर्ता और उससे ऊपर की भूमिकाओं वाले सभी खातों के लिए 2FA की आवश्यकता करें।.
• ऑडिट ट्रेल्स और अलर्टिंग: लॉग को केंद्रीकृत करें और असामान्य उपयोगकर्ता व्यवहार (उच्च अनुरोध दरें, अनुक्रमिक आईडी पहुंच) के लिए अलर्ट सेट करें।.
• बैकअप और पुनर्स्थापना योजना: सुनिश्चित करें कि बैकअप अद्यतित हैं और नियमित रूप से परीक्षण किए जाते हैं।.

उदाहरण डेवलपर सुधार पैटर्न

एक वैचारिक स्तर पर, IDOR के लिए सुधार हमेशा सर्वर-साइड पर स्वामित्व या अनुमतियों की पुष्टि करना होता है इससे पहले कि एक ऑब्जेक्ट लौटाया जाए। वर्डप्रेस प्लगइन कोड में एक सामान्य जांच:

$report_id = intval( $_GET['report_id'] ?? 0 );

मुख्य बिंदु:

• प्रमाणीकरण के लिए कभी भी क्लाइंट-साइड नियंत्रण (JS जांच, छिपे हुए फ़ील्ड) पर भरोसा न करें।.
• हमेशा आने वाले आईडी को मान्य और साफ करें।.
• ऑब्जेक्ट संवेदनशीलता के लिए उपयुक्त क्षमता जांच का उपयोग करें; स्वामी जांच सामान्य हैं।.

पहचान नियम और WAF हस्ताक्षर (उच्च स्तर)

यदि आप एक WAF का प्रबंधन करते हैं, तो उन नियमों पर विचार करें जो निम्नलिखित व्यवहारों का पता लगाते हैं और उन्हें रोकते हैं:

• प्लगइन एंडपॉइंट्स के लिए प्रमाणित अनुरोध जहां report_id, scan_id, file_id जैसे पैरामीटर दिखाई देते हैं, और अनुरोध करने वाला उपयोगकर्ता मालिक नहीं है।.
• एक ही IP या खाते से एक छोटे समय में अनुक्रमिक पूर्णांक ID वाले अनुरोध (enumeration)।.
• admin-ajax.php पर AJAX कॉल जो प्लगइन-विशिष्ट क्रिया नाम ले जाते हैं जिनमें कुकी/क्षमता प्रवाह मेल नहीं खाते।.
• अनुरोध जहां Contributor भूमिका की कुकी का उपयोग केवल प्रशासनिक संसाधनों को लाने के लिए किया जाता है।.

कार्यान्वयन WAF प्रौद्योगिकी के अनुसार भिन्न होते हैं। यदि आपका WAF उपयोगकर्ता भूमिका पहचान का समर्थन करता है (सत्र कुकी + सर्वर सत्यापन के माध्यम से), तो आप भूमिका-आधारित अनुमति/अस्वीकृति नियम बना सकते हैं। अन्यथा व्यवहार और पैरामीटर नियमों का उपयोग करें।.

विभिन्न साइट प्रकारों के लिए जोखिम मूल्यांकन

• केवल संपादकों और प्रशासकों के साथ छोटे ब्रोशर साइट: Contributors का उपयोग न होने पर कम जोखिम।.
• बहु-लेखक ब्लॉग और सदस्यता साइटें: उच्च जोखिम क्योंकि Contributor या सदस्य भूमिकाएँ मौजूद हो सकती हैं और IDOR का शोषण करने के लिए उपयोग की जा सकती हैं।.
• संवेदनशील डेटा संग्रहीत करने वाले प्लगइन एकीकरण वाली साइटें: यदि प्लगइन वस्तुओं में PII या निजी URL शामिल हैं तो उच्च जोखिम।.
• कई Contributors के साथ एजेंसी या ग्राहक साइटें: पूरे बेड़े में पैचिंग को प्राथमिकता दें।.

हमेशा अपनी साइट के विशिष्ट जोखिम और उपलब्ध Contributor खातों का मूल्यांकन करें।.

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: मैं Accessibility Checker प्लगइन का उपयोग नहीं करता - क्या मैं प्रभावित हूँ?

उत्तर: नहीं। केवल वे साइटें जो Accessibility Checker संस्करण <= 1.30.0 चला रही हैं, प्रभावित हैं।.

प्रश्न: मैंने 1.30.1 में अपडेट किया लेकिन फिर भी लॉग में संदिग्ध पहुंच देखता हूँ - अब क्या?

उत्तर: अपडेट आवश्यक है। अपडेट करने के बाद, लॉग की निगरानी जारी रखें और समझौते के संकेतों के लिए स्कैन करें। यदि आप पैचिंग से पहले सफल शोषण का संदेह करते हैं, तो ऊपर दिए गए घटना प्रतिक्रिया चरणों का पालन करें।.

प्रश्न: क्या आभासी पैचिंग पर भरोसा करना सुरक्षित है?

उत्तर: आभासी पैचिंग एक उत्कृष्ट अंतरिम सुरक्षा उपाय है लेकिन यह अपस्ट्रीम फिक्स का विकल्प नहीं है। अपडेट करते समय समय खरीदने और जोखिम को कम करने के लिए आभासी पैचिंग लागू करें।.

प्रश्न: क्या मुझे इसके बजाय Contributor खातों को निष्क्रिय करना चाहिए?

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

चेकलिस्ट: अब क्या करें (चरण-दर-चरण)

1. प्लगइन संस्करण की पुष्टि करें। यदि <= 1.30.0 है, तो तुरंत 1.30.1+ पर अपडेट करें।.
2. यदि आप तुरंत अपडेट नहीं कर सकते:
   • प्लगइन को निष्क्रिय करें या
   • लक्षित एंडपॉइंट्स को ब्लॉक करने के लिए WAF नियम / वर्चुअल पैच लागू करें या
   • योगदानकर्ता खातों को अस्थायी रूप से प्रतिबंधित करें।.
3. योगदानकर्ता भूमिकाओं का ऑडिट करें और अनावश्यक खातों को हटा दें।.
4. अनुक्रमण पैटर्न और असामान्य फ़ाइल डाउनलोड के लिए लॉग की निगरानी करें।.
5. पैचिंग के बाद समझौते के संकेतों की जांच के लिए मैलवेयर और फ़ाइल अखंडता स्कैन चलाएं।.
6. सुनिश्चित करें कि बैकअप सत्यापित हैं और ऑफसाइट संग्रहीत हैं।.
7. प्लगइन अपडेट का कार्यक्रम बनाएं और सभी स्थापित प्लगइनों का इन्वेंटरी रखें।.