TL;DR (हर साइट मालिक को क्या जानना चाहिए)

• डिटी न्यूज़ टिकर (संस्करण 3.1.39–3.1.45) में एक संग्रहीत XSS एक लेखक-स्तरीय उपयोगकर्ता को दुर्भावनापूर्ण JavaScript संग्रहीत करने की अनुमति देता है जिसे अन्य उपयोगकर्ताओं के ब्राउज़रों में निष्पादित किया जा सकता है।.
• यह कमजोरी डिटी 3.1.46 में ठीक की गई है। तुरंत 3.1.46 या बाद के संस्करण में अपडेट करें।.
• यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो प्लगइन को निष्क्रिय करने, लेखक की पहुंच को सीमित करने, अपने WAF के माध्यम से वर्चुअल पैचिंग लागू करने और संदिग्ध स्क्रिप्ट टैग के लिए सामग्री को स्कैन करने पर विचार करें।.
• चूंकि यह एक लेखक द्वारा संग्रहीत XSS है, इसलिए शोषण सामाजिक इंजीनियरिंग के माध्यम से प्राप्त किया जा सकता है जो एक व्यवस्थापक/संपादक को दुर्भावनापूर्ण सामग्री देखने के लिए लुभाता है - इसे गंभीरता से लें।.

संग्रहीत XSS क्या है - और “लेखक द्वारा संग्रहीत” क्यों महत्वपूर्ण है

संग्रहीत (स्थायी) XSS तब होता है जब एक हमलावर एक वेब एप्लिकेशन में एक दुर्भावनापूर्ण स्क्रिप्ट इंजेक्ट करता है जो उस पेलोड को संग्रहीत करता है (उदाहरण के लिए, डेटाबेस में)। बाद में, जब अन्य उपयोगकर्ता संग्रहीत सामग्री को देखते हैं, तो दुर्भावनापूर्ण स्क्रिप्ट उनके ब्राउज़रों में निष्पादित होती है।.

“लेखक द्वारा संग्रहीत XSS” का अर्थ है कि हमलावर को पेलोड रखने के लिए केवल लेखक-स्तरीय विशेषाधिकार की आवश्यकता होती है। कई वर्डप्रेस साइटों पर लेखक पोस्ट और विभिन्न प्रकार की सामग्री बना और संपादित कर सकते हैं। यह क्षमता एक हमलावर के लिए एक प्लगइन के डेटा स्टोर (इस मामले में, डिटी के टिकर आइटम या संबंधित मेटा) में XSS पेलोड को स्थायी बनाने के लिए पर्याप्त है। पेलोड तब चल सकता है जब एक व्यवस्थापक या संपादक व्यवस्थापक क्षेत्र में या फ्रंट-एंड पर टिकर को देखता है जहां प्लगइन टिकर को प्रस्तुत करता है।.

यह क्यों महत्वपूर्ण है:

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

कमजोरियों की विशिष्टताएँ (उच्च स्तर)

• प्रभावित प्लगइन: Ditty News Ticker
• कमजोर संस्करण: 3.1.39 — 3.1.45
• ठीक किया गया: 3.1.46
• प्रकार: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)
• शोषण के लिए आवश्यक विशेषाधिकार: लेखक (या कोई भी भूमिका जो टिकर सामग्री बनाने या संपादित करने में सक्षम हो)
• CVSS उदाहरण संदर्भ: मध्यम (इस वर्ग की समस्या को अक्सर मध्य-स्तरीय स्कोर सौंपा जाता है क्योंकि शोषण के लिए कुछ विशेषाधिकार और कभी-कभी उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है)

हम यहां प्रमाण-ऑफ-कल्पना शोषण कोड प्रकाशित नहीं करेंगे। मान लें कि कमजोरियों का उपयोग उस स्थान पर मनमाना JavaScript निष्पादित करने के लिए किया जा सकता है जहां Ditty सामग्री प्रदर्शित होती है या जहां Ditty प्रशासन पृष्ठ संग्रहीत टिकर सामग्री को प्रस्तुत करते हैं।.

हमले के परिदृश्य - हमलावर क्या कर सकता है

संग्रहीत XSS एक हमलावर को उन पीड़ितों पर ब्राउज़र संदर्भ देता है जो संक्रमित सामग्री को देखते हैं। संभावित दुर्भावनापूर्ण परिणामों में शामिल हैं:

• प्रशासन सत्र कुकीज़ या प्रमाणीकरण टोकन चुराना (यदि कुकीज़ HttpOnly और SameSite के माध्यम से ठीक से सुरक्षित नहीं हैं) या CSRF टोकन को बाहर निकालना।.
• पीड़ित के सत्र से प्रमाणित अनुरोध करके लॉगिन किए गए उपयोगकर्ता के ब्राउज़र के माध्यम से प्रशासनिक क्रियाएँ करना (पोस्ट बनाना या संशोधित करना, प्लगइन सेटिंग्स बदलना, बैकडोर स्थापित करना)।.
• UI ओवरले इंजेक्ट करना जो प्रशासनिक को क्रेडेंशियल्स प्रकट करने या खतरनाक क्रियाओं को मंजूरी देने के लिए धोखा देते हैं।.
• उपयोगकर्ताओं को फ़िशिंग पृष्ठों पर पुनर्निर्देशित करना या नकली लॉगिन स्क्रीन प्रदान करना।.
• स्थायी स्क्रिप्ट इंजेक्ट करना ताकि क्रिप्टोक्यूरेंसी खनन किया जा सके या अतिरिक्त पेलोड लोड किया जा सके।.
• वेब शेल, बैकडोर अपलोड करने या बुनियादी ढांचे पर कहीं और पिवट करने के लिए समझौता किए गए प्रशासनिक संदर्भ का उपयोग करें।.

क्योंकि लेखक पेलोड रख सकते हैं और प्रशासक या संपादक पीड़ित हो सकते हैं, हमले की सतह और प्रभाव तुच्छ नहीं हैं।.

यदि आप Ditty का उपयोग करने वाले किसी भी साइट के लिए जिम्मेदार हैं तो तत्काल कदम

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

पहचान: समझौते के संकेतकों (IoCs) की खोज कैसे करें

प्रमुख वर्डप्रेस तालिकाओं में संदिग्ध सामग्री के लिए स्कैन करें, विशेष रूप से जहां प्लगइन सामग्री संग्रहीत होने की संभावना है (wp_posts, wp_postmeta, wp_options, प्लगइन कस्टम तालिकाएँ)। स्क्रिप्ट टैग, इवेंट हैंडलर्स (onload, onclick), और संदिग्ध base64 डेटा पर ध्यान केंद्रित करें।.

इन पढ़ने-के-लिए-ही क्वेरीज़ को चलाएँ (यदि आपके टेबल प्रीफिक्स भिन्न हैं तो समायोजित करें):

SELECT ID, post_title, post_type, post_status FROM wp_posts WHERE post_content LIKE '%<script%';

SELECT meta_id, post_id, meta_key, meta_value;

स्क्रिप्ट टैग या संदिग्ध पेलोड के लिए Ditty प्लगइन तालिकाओं (यदि मौजूद हैं) की खोज करें। बदलें wp_ditty_* प्लगइन द्वारा उपयोग किए जाने वाले वास्तविक तालिका नामों के साथ:

SELECT * FROM wp_ditty_items WHERE content LIKE '%<script%';

आप पोस्ट खोजने के लिए WP-CLI का भी उपयोग कर सकते हैं:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

मैनुअल जांच:

• उन प्रशासनिक स्क्रीन की जांच करें जहाँ Ditty टिकर्स की सूची बनाता है — HTML स्रोत देखें और अप्रत्याशित ब्लॉकों की तलाश करें।.
• हाल ही में संशोधित पोस्ट/टिकर्स और उन खातों की जांच करें जिन्होंने उन्हें संशोधित किया।.
• प्लगइन एंडपॉइंट्स पर संदिग्ध POSTs के लिए एक्सेस लॉग की समीक्षा करें, या बड़े POST बॉडी जो पेलोड ले जा सकते हैं।.

नोट: हमलावर कभी-कभी पेलोड को एन्कोड करते हैं (जैसे, HTML संस्थाओं या base64 का उपयोग करके) ताकि सरल खोजों से बच सकें। संदिग्ध पैटर्न जैसे “javascript:” या एन्कोडेड स्ट्रिंग्स को शामिल करने के लिए खोजों का विस्तार करें।.

यदि आप दुर्भावनापूर्ण सामग्री पाते हैं — एक घटना प्रतिक्रिया चेकलिस्ट

1. अलग करें
   • जांच करते समय अस्थायी रूप से साइट को ऑफ़लाइन लें या प्रशासनिक क्षेत्र तक पहुँच को अवरुद्ध करें।.
   • /wp-admin/ पर HTTP प्रमाणीकरण जोड़ने पर विचार करें ताकि जोखिम कम हो सके।.
2. संरक्षित करें
   • किसी भी सुधार से पहले पूर्ण बैकअप (फाइलें + डेटाबेस) बनाएं ताकि आप समझौते का विश्लेषण कर सकें।.
3. समाप्त करें
   • Payload वाले दुर्भावनापूर्ण टिकर आइटम, पोस्ट, पोस्टमेटा या विकल्प हटा दें।.
   • Ditty प्लगइन को 3.1.46 या बाद के संस्करण में निष्क्रिय और अपडेट करें।.
   • अप्रत्याशित फ़ाइलों (वेब शेल) के लिए अपलोड और प्लगइन फ़ोल्डरों की जांच करें।.
   • यदि आवश्यक हो तो आधिकारिक पैकेज से प्लगइन को फिर से स्थापित करें।.
4. पुनर्प्राप्त करें
   • सभी व्यवस्थापक/संपादक/लेखक खातों के लिए पासवर्ड बदलें।.
   • API कुंजियाँ, OAuth टोकन और कोई भी क्रेडेंशियल जो उजागर हो सकते हैं, को रद्द करें और फिर से जारी करें।.
   • यदि आवश्यक हो तो समझौता किए गए खातों को फिर से बनाएं।.
5. घटना के बाद की मजबूती
   • अतिरिक्त लॉगिंग और निगरानी सक्षम करें।.
   • विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए मजबूत पासवर्ड और दो-कारक प्रमाणीकरण लागू करें।.
   • लेखक या उच्चतर विशेषाधिकार वाले उपयोगकर्ताओं की संख्या सीमित करें।.
   • भूमिका क्षमताओं की समीक्षा करें और उन्हें कड़ा करें।.
6. सूचना
   • यदि समझौता उपयोगकर्ता डेटा को प्रभावित करता है, तो लागू अधिसूचना कानूनों/नियमों का पालन करें।.

WAF या वर्चुअल पैच कैसे मदद करता है (व्यावहारिक वर्चुअल-पैच उदाहरण)

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

यहाँ कुछ उदाहरण नियम अवधारणाएँ हैं जिन्हें आप अपने वातावरण के लिए अनुकूलित कर सकते हैं (चित्रात्मक पैटर्न - उत्पादन से पहले स्टेजिंग में सावधानी से परीक्षण करें):

उदाहरण ModSecurity नियम (प्लगइन एंडपॉइंट्स के लिए अनुरोध निकायों में को ब्लॉक करें):

# अनुरोध निकायों में <script या on* हैंडलरों को ब्लॉक करें प्रशासन AJAX और Ditty एंडपॉइंट्स के लिए"

अनुरोध निकाय में संदिग्ध विशेषताओं को ब्लॉक करें (onload, onclick, javascript:):

SecRule REQUEST_URI "@rx (admin-ajax\.php|ditty|ditty-items)" \"

महत्वपूर्ण नोट्स:

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

WAF नियम ट्यूनिंग के लिए ठोस सुझाव (व्यावहारिक)

• नियमों के दायरे को सीमित करें: नियमों को केवल उन URIs पर लागू करें जो प्लगइन द्वारा उपयोग किए जाते हैं (जैसे, Ditty से संबंधित admin-ajax.php क्रियाएँ)।.
• उन URIs पर केवल POST/PUT विधियों के लिए अनुरोध शरीर का निरीक्षण करें।.
• अपेक्षित पेलोड प्रकारों के लिए जहां संभव हो, श्वेतसूची दृष्टिकोण का उपयोग करें (जैसे, ट ticker शीर्षकों में केवल अल्फ़ान्यूमेरिक और सुरक्षित विराम चिह्नों की अनुमति दें)।.
• इवेंट हैंडलर विशेषताओं और स्क्रिप्ट टैग की निगरानी और लॉग करें:
  • लॉग करने के लिए पैटर्न: “<script”, “javascript:”, “on\w+\s*=”, “eval(“, “setTimeout(“, “setInterval(“।.
• संपादकों द्वारा उपयोग किए जाने वाले वैध HTML स्निपेट को अवरुद्ध करने से बचें; अवरोधन से पहले लॉगिंग मोड का उपयोग करके ट्यून करें।.

विकास सुधार मार्गदर्शन (प्लगइन डेवलपर्स और एकीकरणकर्ताओं के लिए)

यदि आप प्लगइन्स या थीम विकसित या बनाए रखते हैं, तो संग्रहीत XSS को रोकने के लिए इन नियंत्रणों का पालन करें:

• सहेजने पर इनपुट को सैनिटाइज करें:
  • आने वाले डेटा के लिए WordPress सफाई का उपयोग करें (जैसे, सरल पाठ के लिए sanitize_text_field)।.
  • समृद्ध HTML इनपुट के लिए, wp_kses() के साथ एक सख्त अनुमत सूची और अनुमत टैग और विशेषताओं का नियंत्रित सेट का उपयोग करें।.
• आउटपुट पर एस्केप करें:
  • आउटपुट से पहले डेटा को तुरंत एस्केप करें: सामान्य पाठ के लिए esc_html(), विशेषताओं के लिए esc_attr(), JavaScript संदर्भों के लिए esc_js()।.
  • उस सामग्री के लिए जो सीमित HTML की अनुमति देनी चाहिए, wp_kses_post() या एक कस्टम wp_kses() नीति का उपयोग करें।.
• सर्वर-साइड पर भूमिकाओं और क्षमताओं को मान्य करें: क्लाइंट-साइड जांचों पर भरोसा न करें। सुनिश्चित करें कि सर्वर अंत बिंदु intended capabilities के लिए current_user_can() की पुष्टि करते हैं।.
• अविश्वसनीय भूमिकाओं से कच्चे HTML को संग्रहीत करने से बचें: यदि लेखकों को HTML प्रस्तुत करना आवश्यक है, तो इसे भारी सफाई करें या केवल सफाई/एस्केप आउटपुट के रूप में संग्रहीत करें।.

उदाहरण (छद्म कोड) — स्वच्छ करें और संग्रहित करें:

// जब टिकर सामग्री को सहेजते हैं

साइट के मालिकों और प्रशासकों के लिए सख्ती से अनुशंसाएँ

1. सब कुछ अपडेट रखें — प्लगइन्स, थीम और कोर को तुरंत अपडेट किया जाना चाहिए। सुरक्षा अपडेट को प्राथमिकता दें।.
2. न्यूनतम विशेषाधिकार नीति — लेखक, संपादक और प्रशासक क्षमताओं वाले उपयोगकर्ताओं की संख्या को सीमित करें। अप्रयुक्त खातों की समीक्षा करें और उन्हें हटा दें।.
3. मजबूत प्रमाणीकरण — अद्वितीय मजबूत पासवर्ड का उपयोग करें और सभी विशेषाधिकार प्राप्त खातों के लिए दो-कारक प्रमाणीकरण सक्षम करें।.
4. लॉगिंग और निगरानी — अपनी साइट और वेब सर्वर के लिए पहुंच और ऑडिट लॉग रखें। समय-समय पर समीक्षा करें। संदिग्ध प्रशासनिक क्षेत्र के POST या असामान्य खाता गतिविधि पर अलर्ट करें।.
5. बैकअप और पुनर्प्राप्ति। — नियमित, परीक्षण किए गए बैकअप बनाए रखें। कम से कम एक ऑफसाइट अपरिवर्तनीय प्रति रखें।.
6. एक मजबूत WAF और मैलवेयर स्कैनर का उपयोग करें — एक WAF HTTP स्तर पर शोषण प्रयासों को रोक सकता है; मैलवेयर स्कैनर ज्ञात दुर्भावनापूर्ण पेलोड को पकड़ते हैं। सुनिश्चित करें कि नए प्रकट कमजोरियों के लिए त्वरित प्रतिक्रिया के लिए आभासी पैचिंग उपलब्ध है।.
7. सामग्री की समीक्षा — लेखकों और योगदानकर्ताओं द्वारा उत्पादित सामग्री का समय-समय पर ऑडिट करें ताकि अप्रत्याशित HTML या स्क्रिप्ट का पता लगाया जा सके।.
8. सामग्री सुरक्षा नीति (CSP) लागू करें — एक अच्छी तरह से तैयार की गई CSP अनुमति प्राप्त स्क्रिप्ट स्रोतों को सीमित करके XSS प्रभाव को कम करती है। साइट की कार्यक्षमता को तोड़ने से बचने के लिए सावधानीपूर्वक परीक्षण करें।.

दीर्घकालिक निगरानी: सुधार के बाद क्या देखना है

• समान IPs या पैटर्न से Ditty अंत बिंदुओं पर बार-बार POST प्रयास।.
• प्रशासक अप्रत्याशित UI तत्वों या रीडायरेक्ट की रिपोर्ट कर रहे हैं।.
• बिना प्राधिकरण के नए प्रशासक या संपादक खाते बनाए गए।.
• आउटबाउंड कनेक्शन या अनुरोध जो वेब सर्वर द्वारा शुरू किए गए हैं जिन्हें आपने प्राधिकृत नहीं किया (संभावित बीकनिंग)।.
• wp_options या क्रोन शेड्यूल में परिवर्तन जो वेब इंटरफेस से उत्पन्न होते हैं।.

उदाहरण खोज और सफाई कमांड (व्यावहारिक)

पोस्टमेटा या विकल्पों में संभावित स्क्रिप्ट इंजेक्शन के लिए डेटाबेस खोजें (टेबल प्रीफिक्स समायोजित करें):

# पोस्ट"

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

संचार और पारदर्शिता

यदि आपकी साइट ग्राहक‑सामना करती है या उपयोगकर्ता डेटा संभालती है, तो हितधारकों के लिए एक सीधा, तथ्यात्मक संदेश तैयार करें। वर्णन करें:

• क्या हुआ (अत्यधिक तकनीकी विवरणों के बिना जो हमलावरों की मदद कर सकते हैं)।.
• आपने सुधार के लिए कौन से कदम उठाए हैं (अपडेट किया गया प्लगइन, फ़ायरवॉल नियम लागू किया, क्रेडेंशियल्स घुमाए)।.
• कोई अनुशंसित उपयोगकर्ता क्रियाएँ (जैसे, केवल तभी पासवर्ड बदलें जब क्रेडेंशियल एक्सपोजर का सबूत हो)।.
• आप पुनरावृत्ति को कैसे रोकेंगे।.

सक्रिय आभासी पैचिंग और प्रबंधित सुरक्षा पर विचार क्यों करें

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

अंतिम चेकलिस्ट - अभी क्या करना है

• डिटी को संस्करण 3.1.46 या बाद के संस्करण में अपडेट करें।.
• यदि आप तुरंत अपडेट नहीं कर सकते:
  • प्लगइन को निष्क्रिय करें या
  • लेखक क्षमताओं को सीमित करें और एक आभासी पैच/WAF नियम लागू करें।.
• पोस्ट, पोस्टमेटा, विकल्पों और प्लगइन तालिकाओं में इंजेक्टेड स्क्रिप्ट टैग के लिए स्कैन करें।.
• उच्च विशेषाधिकार उपयोगकर्ताओं के लिए क्रेडेंशियल्स घुमाएँ और उपयोगकर्ता भूमिकाओं की समीक्षा करें।.
• सुनिश्चित करें कि बैकअप हाल के और सुरक्षित हैं।.
• लॉग की निगरानी करें और संदिग्ध प्रशासनिक क्षेत्र की गतिविधियों के लिए अलर्ट सेट करें।.
• भविष्य की कमजोरियों के लिए संवेदनशीलता की खिड़की को छोटा करने के लिए पेशेवर सुरक्षा सहायता या प्रबंधित WAF पर विचार करें।.