महत्वपूर्ण अपडेट: YITH WooCommerce उत्पाद ऐड-ऑन (≤ 4.29.0) में SQL इंजेक्शन — साइट मालिकों और डेवलपर्स को अब क्या करना चाहिए

लेखक: हांगकांग सुरक्षा विशेषज्ञ

तारीख: 2026-05-20

सारांश: एक SQL इंजेक्शन सुरक्षा दोष (CVE-2026-42383) YITH WooCommerce उत्पाद ऐड-ऑन प्लगइन के संस्करणों को प्रभावित करता है जो 4.29.0 तक और इसमें शामिल हैं। इस मुद्दे को 4.29.1 में पैच किया गया है। यह सलाह जोखिम, तात्कालिक कार्रवाई, पहचान मार्गदर्शन, आभासी-पैच सुझाव, घटना प्रतिक्रिया, और हांगकांग और अंतरराष्ट्रीय WooCommerce स्टोर ऑपरेटरों के लिए दीर्घकालिक सख्ती का सारांश प्रस्तुत करती है।.

यह क्यों महत्वपूर्ण है (साधारण भाषा)

यदि आपका WooCommerce स्टोर YITH WooCommerce उत्पाद ऐड-ऑन (≤ 4.29.0) चला रहा है, तो Shop Manager भूमिका वाला एक उपयोगकर्ता SQL इंजेक्शन को सक्रिय कर सकता है जो आपके डेटाबेस के साथ इंटरैक्ट करता है। SQL इंजेक्शन डेटा को पढ़ या संशोधित कर सकता है, उपयोगकर्ता रिकॉर्ड को बाहर निकाल सकता है, या संदर्भ के आधार पर स्थायी बैकडोर स्थापित करने में मदद कर सकता है।.

हालांकि कुछ स्कोरिंग इस मुद्दे को कम प्राथमिकता के रूप में लेबल करती है क्योंकि यह एक विशेषाधिकार प्राप्त भूमिका की आवश्यकता होती है, हमलावर आमतौर पर शोषण को जोड़ते हैं और एकत्रित या खरीदी गई क्रेडेंशियल्स का उपयोग करते हैं। ई-कॉमर्स साइटें ग्राहक और आदेश डेटा रखती हैं; यहां तक कि एक भूमिका-प्रतिबंधित SQLi गंभीर प्रभाव पैदा कर सकता है।.

• CVE: CVE‑2026‑42383
• पैच किया गया: 4.29.1
• द्वारा रिपोर्ट किया गया: गुयेन बा खान्ह (रिपोर्ट किया 2026‑01‑26, सार्वजनिक सलाह 2026‑05‑20)
• CVSS: 7.6 (जैसा कि रिपोर्ट किया गया)

साइट मालिकों और प्रशासकों के लिए तात्कालिक क्रियाएँ

1. तुरंत अपडेट करें
   • यदि आप सुरक्षित रूप से अपडेट कर सकते हैं, तो YITH WooCommerce उत्पाद ऐड-ऑन को 4.29.1 या बाद के संस्करण में अपग्रेड करें। यह सबसे उच्च प्राथमिकता वाली कार्रवाई है।.
2. यदि आप तुरंत अपडेट नहीं कर सकते हैं
   • WAF स्तर पर अस्थायी आभासी पैचिंग लागू करें (नीचे उदाहरण दिए गए हैं)।.
   • Shop Manager भूमिका वाले उपयोगकर्ताओं की समीक्षा करें और उन्हें प्रतिबंधित करें; किसी भी अनजान खातों को हटा दें।.
   • अपडेट करने तक रखरखाव मोड या व्यवस्थापक पहुंच को प्रतिबंधित करने पर विचार करें।.
3. परिवर्तनों से पहले बैकअप लें
   • अपडेट या सुधार से पहले एक पूर्ण बैकअप (डेटाबेस + फ़ाइलें) लें। एक प्रति ऑफसाइट स्टोर करें।.
4. डेवलपर या होस्ट के साथ समन्वय करें
   • यदि सुनिश्चित नहीं हैं, तो सहायता के लिए अपने होस्टिंग प्रदाता या एक विश्वसनीय डेवलपर से पूछें।.

जोखिम मॉडल को समझना

• आवश्यक विशेषाधिकार: Shop Manager — अनाम शोषण जोखिम को कम करता है लेकिन समझौता किए गए या दुर्भावनापूर्ण विशेषाधिकार प्राप्त खातों से खतरे को समाप्त नहीं करता है।.
• प्रभाव: SQL इंजेक्शन — डेटाबेस को पढ़ना या संशोधित करना, ग्राहकों/आदेशों को लीक करना, खाता अधिग्रहण को सक्षम करना, या स्थिरता में सहायता करना।.
• संभावना: जहां प्लगइन अपडेट या खाता स्वच्छता ढीली है, वहां मध्यम करें।.

हमलावर क्रेडेंशियल प्राप्त करते हैं या विशेषाधिकार बढ़ाते हैं; भूमिका-प्रतिबंधित कमजोरियों को अभी भी त्वरित कार्रवाई की आवश्यकता होती है।.

हमलावर इस कमजोरी का दुरुपयोग कैसे कर सकते हैं (उच्च स्तर)

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

यहां कोई शोषण पेलोड प्रदान नहीं किए गए हैं; रक्षकों को मान लेना चाहिए कि यदि कमजोरी मौजूद है तो एक हमलावर प्रश्न तैयार कर सकता है।.

पहचान: लॉग और साइट व्यवहार में क्या देखना है

संदिग्ध गतिविधि के लिए इन स्रोतों की समीक्षा करें:

• वेब सर्वर और PHP लॉग: प्लगइन एंडपॉइंट्स या व्यवस्थापक AJAX एंडपॉइंट्स पर POST/GET अनुरोध जो दुकान प्रबंधक क्रियाओं से उत्पन्न होते हैं; पैरामीटर जिनमें SQL कीवर्ड (UNION, SELECT, INFORMATION_SCHEMA, ‘ –, /*, ;) शामिल हैं।.
• वर्डप्रेस ऑडिट/गतिविधि लॉग: नए/संशोधित दुकान प्रबंधक या व्यवस्थापक उपयोगकर्ता; उत्पादों, आदेशों, कूपनों में अप्रत्याशित संपादन; संपादक के माध्यम से प्लगइन/थीम फ़ाइल संपादन।.
• डेटाबेस विसंगतियाँ: wp_users, wp_usermeta, wp_options में अप्रत्याशित पंक्तियाँ; नए व्यवस्थापक खाते; बदले गए विशेषाधिकार।.
• फ़ाइल प्रणाली: अपलोड, wp-content, या थीम/प्लगइन निर्देशिकाओं में नए PHP फ़ाइलें (वेब शेल)।.
• अनुसूचित कार्य: असामान्य अनुरोध शुरू करने वाले नए या संशोधित क्रोन कार्य।.
• आउटबाउंड कनेक्शन: सर्वर से अज्ञात IPs/डोमेन के लिए अप्रत्याशित HTTP/HTTPS कनेक्शन (संभावित डेटा निकासी या C2)।.

यदि आप संदिग्ध प्रविष्टियाँ देखते हैं तो जांच के लिए लॉग और स्नैपशॉट को संरक्षित करें।.

घटना प्रतिक्रिया चेकलिस्ट (यदि आप समझौता होने का संदेह करते हैं)

1. अलग करें
   • साइट को रखरखाव मोड में रखें या जहां संभव हो, सार्वजनिक पहुंच को अस्थायी रूप से निष्क्रिय करें।.
   • व्यवस्थापक पासवर्ड को घुमाएं और सभी उच्च-विशेषाधिकार खातों के लिए MFA लागू करें।.
2. स्नैपशॉट लें और संरक्षित करें
   • फोरेंसिक विश्लेषण के लिए पूर्ण बैकअप (फाइलें + DB) लें; मौजूदा सबूतों को अधिलेखित न करें।.
3. सुधार करें
   • YITH WooCommerce Product Add‑Ons को 4.29.1 या बाद के संस्करण में अपडेट करें।.
   • अज्ञात उपयोगकर्ताओं को हटाएं और भूमिका/क्षमता परिवर्तनों की जांच करें।.
   • वेब शेल, बैकडोर और दुर्भावनापूर्ण क्रोन जॉब्स के लिए स्कैन करें; विश्वसनीय फोरेंसिक/स्कैनिंग उपकरणों का उपयोग करके पहचाने गए फ़ाइलों को हटाएं या साफ करें।.
4. सीमित करें और साफ करें
   • wp-config.php में वर्डप्रेस सॉल्ट और कुंजी घुमाएँ।.
   • API कुंजी और बाहरी एकीकरण क्रेडेंशियल्स को रीसेट करें जो उजागर हो सकते हैं।.
   • पुनर्स्थापना से पहले बैकअप को दुर्भावनापूर्ण सामग्री के लिए स्कैन करें।.
5. मजबूत करें
   • शॉप मैनेजर और प्रशासक खातों की संख्या को न्यूनतम करें।.
   • मजबूत पासवर्ड और MFA लागू करें।.
   • प्रशासनिक इंटरफ़ेस के माध्यम से प्लगइन/थीम फ़ाइल संपादन को अक्षम करें।.
6. सूचित करें
   • प्रभावित हितधारकों और ग्राहकों को सूचित करें जहां कानूनी रूप से आवश्यक हो।.
   • यदि डेटा निकासी का संदेह है तो पेशेवर फोरेंसिक विश्लेषण पर विचार करें।.

दीर्घकालिक सिफारिशें (सुरक्षा स्वच्छता)

• वर्डप्रेस कोर, थीम और प्लगइन्स को नियमित रूप से अपडेट रखें।.
• उच्च-विशेषाधिकार उपयोगकर्ताओं (प्रशासक और शॉप मैनेजर) की संख्या को सीमित करें।.
• मजबूत पासवर्ड का उपयोग करें और बहु-कारक प्रमाणीकरण (MFA) सक्षम करें।.
• एकीकरण और API कुंजी के लिए न्यूनतम विशेषाधिकार लागू करें।.
• अप्रयुक्त या परित्यक्त प्लगइन्स को हटा दें।.
• संस्करण के साथ बार-बार ऑफसाइट बैकअप बनाए रखें और पुनर्स्थापना से पहले बैकअप को स्कैन करें।.
• लॉग की निगरानी करें और असामान्य गतिविधि के लिए अलर्ट सेट करें।.

वर्चुअल पैचिंग: WAF नियम और सुझाव

यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो हमले की सतह को कम करने के लिए अस्थायी WAF वर्चुअल पैच लागू करें। ये शमन हैं, विक्रेता पैच के लिए प्रतिस्थापन नहीं।.

सामान्य रणनीति:

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

सुझाए गए WAF नियम (सामान्य)

1. अप्रत्याशित क्षेत्रों में क्लासिक SQL कीवर्ड को ब्लॉक करें

   नियम: उन अनुरोधों को ब्लॉक करें जिनमें ऐसे मान होते हैं जो SELECT, UNION, INFORMATION_SCHEMA, LOAD_FILE, INTO OUTFILE जैसे कीवर्ड से मेल खाते हैं जब उन्हें फ्री-टेक्स्ट क्षेत्रों में देखा जाता है।.

   छद्म-नियम: यदि एक पैरामीटर मान regex से मेल खाता है (?i)(\bयूनियन\b|\bसूचना_schema\b|\bचुनें\b|\bमें\s+आउटफ़ाइल\b|\bलोड_फाइल\b) तो ब्लॉक करें और लॉग करें।.

2. SQL टिप्पणी मार्कर या नियंत्रण वर्णों को अस्वीकार करें

   सरल स्ट्रिंग्स होने चाहिए ऐसे इनपुट में अनुक्रमों के साथ अनुरोधों को ब्लॉक करें '--, /*, */, ; या नल बाइट्स।.

3. ऐड-ऑन क्षेत्रों के लिए अपेक्षित इनपुट प्रोफाइल को लागू करें

   केवल अनुमति दें:

   • लेबल के लिए अल्फ़ान्यूमेरिक और सीमित विराम चिह्न ([-_ . ,])।.
   • मूल्य क्षेत्रों के लिए अंक और दशमलव बिंदु।.
   • अधिकतम लंबाई (जैसे, 255 या 100 वर्ण जैसे उपयुक्त)।.
4. प्रशासनिक AJAX और REST सुरक्षा

   प्रशासनिक POSTs के लिए मान्य WordPress नॉनस की आवश्यकता; सत्यापित नॉनस की कमी वाले अनुरोधों को ब्लॉक करें। प्रशासनिक AJAX/REST एंडपॉइंट्स को लॉगिन किए गए सत्रों तक सीमित करें और दुकान प्रबंधकों के लिए आईपी प्रतिबंधों पर विचार करें।.

5. लॉगिंग और निगरानी

   अनुरोधकर्ता आईपी, उपयोगकर्ता एजेंट, और POST बॉडी अंश के साथ ब्लॉक किए गए अनुरोधों पर लॉग और अलर्ट करें।.

उदाहरण ModSecurity-शैली नियम (अपने वातावरण के अनुसार अनुकूलित करें):

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "(?i:(union|select|information_schema|load_file|into\s+outfile))" \n "phase:2,rev:'1',msg:'SQL इंजेक्शन प्रयास - अनुरोध में संदिग्ध कीवर्ड',id:100500,deny,log,status:403,t:lowercase,t:trim"

ट्यूनिंग टिप्स: झूठे सकारात्मक से बचने के लिए लागू करने से पहले पहचान/लॉग मोड में नियमों का परीक्षण करें। पैटर्न को प्लगइन के एंडपॉइंट और पैरामीटर नामों के अनुसार अनुकूलित करें। जब संदेह हो, तो पहले लॉग करें, फिर पैटर्न को मान्य करने के बाद ब्लॉक करें।.

डेवलपर्स के लिए मार्गदर्शन (सुरक्षित कोडिंग और पैचिंग)

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

गहराई में रक्षा (तटस्थ, व्यावहारिक नियंत्रण)

• पैचिंग को एक्सेस नियंत्रण (कम विशेषाधिकार प्राप्त खाते), MFA, और नेटवर्क प्रतिबंधों के साथ मिलाएं जहां व्यावहारिक हो।.
• फ़ाइलों और मैलवेयर के लिए नियमित स्कैन बनाए रखें; कई पहचान विधियों का उपयोग करें (फ़ाइल अखंडता, हस्ताक्षर, ह्यूरिस्टिक्स)।.
• ऑडिट लॉगिंग सक्षम रखें और घटनाओं की जांच के लिए पर्याप्त रखरखाव विंडो के लिए लॉग बनाए रखें।.

चरण-दर-चरण शमन योजना (एक-घंटे की चेकलिस्ट)

1. प्लगइन संस्करण की पुष्टि करें: Plugins → Installed Plugins → YITH WooCommerce Product Add‑Ons। यदि ≤ 4.29.0 है, तो अपडेट को प्राथमिकता दें।.
2. त्वरित बैकअप: पूर्ण साइट बैकअप (फाइलें + DB)।.
3. प्लगइन को 4.29.1 में अपडेट करें; यदि आवश्यक हो तो रोल बैक के लिए बैकअप तैयार रखें।.
4. उपयोगकर्ताओं की समीक्षा करें: ऑडिट उपयोगकर्ता → सभी उपयोगकर्ता। अज्ञात शॉप प्रबंधकों/प्रशासकों को हटा दें। विशेषाधिकार प्राप्त खातों के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
5. एक विश्वसनीय मैलवेयर/फ़ाइल अखंडता स्कैनर के साथ साइट को स्कैन करें। सार्वजनिक पहुंच को फिर से सक्रिय करने से पहले विसंगतियों की जांच करें।.
6. यदि अपडेट तुरंत संभव नहीं है तो अस्थायी WAF नियम लागू करें; पहले लॉगिंग मोड में चलाएँ।.
7. प्रशासनिक अनुरोधों के लिए लॉगिंग और निगरानी बढ़ाएँ; विसंगतियों पर अलर्ट सेट करें।.
8. यदि समझौता होने का संदेह है तो API कुंजी और बाहरी एकीकरण क्रेडेंशियल्स को घुमाएँ।.
9. फॉलो-अप की योजना बनाएं: 24-48 घंटों के बाद पुनर्मूल्यांकन करें और एक प्लगइन अपडेट कैडेंस लागू करें।.

समझौते के संकेत (IOCs) और क्या खोजें

• अप्रत्याशित प्रशासनिक या दुकान प्रबंधक खाते।.
• wp_options में असामान्य परिवर्तन (स्वचालित अपडेट सेटिंग्स, अज्ञात क्रोन शेड्यूल)।.
• uploads/ में PHP फ़ाइलें जिनमें हाल के संशोधित टाइमस्टैम्प संदिग्ध समझौता विंडो से मेल खाते हैं।.
• वेब सर्वर से अपरिचित IPs/डोमेन के लिए आउटबाउंड कनेक्शन।.
• लॉग में डेटाबेस क्वेरी जो SQL कीवर्ड या लंबे संयोजित स्ट्रिंग्स को शामिल करती हैं जो इंजेक्शन प्रयासों का संकेत देती हैं।.

यदि IOCs मौजूद हैं, तो सबूत इकट्ठा करें और यदि सुनिश्चित नहीं हैं तो पेशेवर सुधार पर विचार करें।.

वर्चुअल पैचिंग: जिम्मेदारी से कैसे उपयोग करें

वर्चुअल पैचिंग तात्कालिक, अस्थायी सुरक्षा प्रदान करती है। सर्वोत्तम प्रथाएँ:

• नियमों को कमजोरियों के लिए संकीर्ण रूप से लक्षित करें।.
• झूठे सकारात्मक दरों को समझने के लिए पहले पहचान मोड में परीक्षण करें।.
• विक्रेता पैचिंग के बाद वर्चुअल पैच हटा दें, या यदि उपयुक्त हो तो उन्हें मजबूत, सामान्य सुरक्षा के रूप में रखें।.
• घटना के बाद के विश्लेषण के लिए अवरुद्ध प्रयासों के लॉग रखें।.

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

प्रश्न — यदि समस्या के लिए दुकान प्रबंधक की आवश्यकता है, तो क्या मैं सुरक्षित हूँ यदि केवल प्रशासकों के पास शक्तिशाली अनुमतियाँ हैं?

उत्तर — जरूरी नहीं। प्रशासक भी शक्तिशाली होते हैं; दुकान प्रबंधक खातों या उस भूमिका में बढ़ाए गए खातों की उपस्थिति महत्वपूर्ण है। समझौता किए गए विशेषाधिकार प्राप्त खातों का शोषण किया जा सकता है।.

प्रश्न — क्या मैं केवल बैकअप पर भरोसा कर सकता हूँ?

A — बैकअप आवश्यक हैं, लेकिन यदि समझौते के बाद लिए गए हैं तो उनमें दुर्भावनापूर्ण परिवर्तन हो सकते हैं। पुनर्स्थापना से पहले बैकअप स्कैन करें और पुनर्प्राप्ति के बाद क्रेडेंशियल्स को घुमाएं।.

Q — क्या WAF नियम पर्याप्त हैं?

A — WAF नियम जोखिम को जल्दी कम करते हैं लेकिन विक्रेता पैच का स्थान नहीं लेते। अस्थायी रूप से आभासी पैच का उपयोग करें, फिर विक्रेता सुधार लागू करें और पूर्ण सफाई करें।.

अपने डेवलपर या होस्ट को क्या बताएं (कॉपी-पेस्ट चेकलिस्ट)

• हम YITH WooCommerce Product Add‑Ons (≤ 4.29.0) में CVE‑2026‑42383 से प्रभावित हैं। कृपया 4.29.1 में अपडेट करें।.
• यदि तत्काल अपडेट संभव नहीं है, तो इस प्लगइन के एंडपॉइंट्स पर संदिग्ध SQL पेलोड को ब्लॉक करने के लिए लक्षित WAF नियम लागू करें और झूठे सकारात्मक से बचने के लिए ट्यून करें।.
• शॉप मैनेजर और प्रशासक भूमिकाओं का ऑडिट करें — अज्ञात खातों को हटा दें और MFA लागू करें।.
• एक पूर्ण मैलवेयर स्कैन चलाएं और अनधिकृत फ़ाइलों या क्रॉन प्रविष्टियों की जांच करें।.
• अपडेट से पहले एक बैकअप स्नैपशॉट प्रदान करें और किसी भी IOC को हटाने की पुष्टि करें।.

हांगकांग सुरक्षा परिप्रेक्ष्य से समापन विचार

व्यापक रूप से उपयोग किए जाने वाले प्लगइन्स में कमजोरियां सामने आती रहेंगी। एक सीमित घटना और एक बड़े उल्लंघन के बीच का अंतर पैचिंग, पहचान और प्रतिक्रिया में गति और अनुशासन है। स्टोर मालिकों के लिए: 4.29.1 में अपडेट करने को प्राथमिकता दें, उच्च-privilege खातों को कम करें, MFA सक्षम करें, और यदि आप तुरंत अपडेट नहीं कर सकते हैं तो अस्थायी WAF शमन का संचालन करें।.

यदि आपको WAF नियम समीक्षा, फोरेंसिक स्कैनिंग, या सुधार में हाथों-हाथ सहायता की आवश्यकता है, तो एक योग्य सुरक्षा पेशेवर या अपने होस्टिंग प्रदाता से संपर्क करें। त्वरित, मापी गई कार्रवाई व्यवसाय और नियामक जोखिम को कम करती है।.

— हांगकांग सुरक्षा विशेषज्ञ

परिशिष्ट A — त्वरित संदर्भ आदेश और प्रश्न

• प्लगइन संस्करण जांचें (WordPress प्रशासन): Plugins → Installed Plugins → YITH WooCommerce Product Add‑Ons
• WP‑CLI:

  wp प्लगइन सूची --स्थिति=सक्रिय | grep yith

• शॉप मैनेजर या प्रशासक भूमिकाओं वाले उपयोगकर्ताओं को खोजें (WP‑CLI):

  wp user list --role=shop_manager

• अपलोड में हाल ही में संशोधित PHP फ़ाइलों की खोज करें (Linux शेल):

  find wp-content/uploads -type f -name "*.php" -mtime -30

• समीक्षा के लिए हाल के DB परिवर्तनों को निर्यात करें — लॉकिंग से बचने के लिए अपने होस्ट/DBA से परामर्श करें।.

परिशिष्ट B — प्रशासकों के लिए WAF ट्यूनिंग चेकलिस्ट का उदाहरण

• SQL पैटर्न से मेल खाने वाले WAF नियमों के लिए लॉगिंग सक्षम करें।.
• 24–48 घंटों के लिए डिटेक्ट/लॉग मोड में परीक्षण नियम लागू करें।.
• नियमों को अस्वीकृति मोड में स्विच करने से पहले अवरुद्ध प्रविष्टियों को मान्य करें।.
• यदि संचालन की आवश्यकता हो तो चयनात्मक रूप से विश्वसनीय व्यवस्थापक आईपी को व्हitelist करें; व्यापक व्हitelist से बचें।.
• 4.29.1 में अपग्रेड करने के बाद, अस्थायी नियमों को हटा दें या सामान्य हार्डनिंग स्थिति के हिस्से के रूप में कड़े नियमों को बनाए रखें।.