TL;DR

7. WP JobHunt (संस्करण 7.7 तक) में संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) मौजूद है। एक प्रमाणित उपयोगकर्ता जिसके पास उम्मीदवार स्तर के विशेषाधिकार हैं, प्लगइन के स्थिति 8. क्षेत्र में एक तैयार किया गया मान प्रस्तुत कर सकता है जो संग्रहीत हो सकता है और बाद में उचित एस्केपिंग या प्राधिकरण जांच के बिना प्रशासन या अन्य पृष्ठों में प्रदर्शित हो सकता है। शोषण के लिए एक विशेषाधिकार प्राप्त उपयोगकर्ता को संग्रहीत पेलोड के साथ इंटरैक्ट करना आवश्यक है (उदाहरण के लिए, डैशबोर्ड में एक रिकॉर्ड देखना)। प्रकटीकरण के समय कोई आधिकारिक प्लगइन सुधार नहीं था। यह पोस्ट भेद्यता, जोखिम प्रोफ़ाइल, व्यावहारिक शमन, डेवलपर सुधार, पहचान विधियाँ, और पुनर्प्राप्ति कदमों को समझाती है — एक हांगकांग सुरक्षा प्रैक्टिशनर के दृष्टिकोण से जो स्थानीय और क्षेत्रीय साइट मालिकों को सलाह दे रहा है।.

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

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

11. यहां तक कि जब किसी भेद्यता को कुछ स्कोरिंग स्रोतों द्वारा “कम” के रूप में वर्गीकृत किया जाता है, तो तीसरे पक्ष की सामग्री स्वीकार करने वाले प्लगइनों में संग्रहीत XSS को उन साइटों पर तुरंत ध्यान में लिया जाना चाहिए जहां कर्मचारी नियमित रूप से उपयोगकर्ता द्वारा प्रस्तुत रिकॉर्ड की समीक्षा करते हैं।.

भेद्यता सारांश (तकनीकी)

• भेद्यता प्रकार: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)
• 12. वेक्टर: प्लगइन एक प्रमाणित उम्मीदवार उपयोगकर्ता से एक तैयार किया गया स्थिति 13. मान स्वीकार करता है और संग्रहीत करता है।.
• 14. मूल कारण: संग्रहीत करने या प्रदर्शित करने से पहले प्राधिकरण जांचों की कमी और अपर्याप्त इनपुट स्वच्छता/एस्केपिंग। उम्मीदवार स्तर के उपयोगकर्ता ऐसे मान सेट करने में सक्षम हैं जो बिना उचित एस्केपिंग के संदर्भों में प्रदर्शित होते हैं। स्थिति 15. शोषण की पूर्वापेक्षाएँ: हमलावर को एक प्रमाणित उम्मीदवार खाता चाहिए। एक विशेषाधिकार प्राप्त उपयोगकर्ता को संग्रहीत पेलोड को निष्पादित करने के लिए देखना या इंटरैक्ट करना आवश्यक है — उपयोगकर्ता इंटरैक्शन आवश्यक है।.
• 16. प्रभावित संस्करण: WP JobHunt ≤ 7.7.
• 17. CVE: CVE-2025-7782
• 18. नोट: क्योंकि संग्रहीत XSS डेटाबेस में बना रहता है, खतरनाक प्रविष्टियाँ तब तक बनी रहती हैं जब तक कि उन्हें स्वच्छ नहीं किया जाता या हटा नहीं दिया जाता, भले ही प्रारंभिक हमले का वेक्टर बंद हो जाए।

19. हमलावर एक उम्मीदवार खाता पंजीकृत करता है या उपयोग करता है और सेट करता है.

हमले के परिदृश्य

1. हमलावर एक उम्मीदवार खाता पंजीकृत करता है या उसका उपयोग करता है और सेट करता है स्थिति 1. एक तैयार किए गए JavaScript पेलोड या दुर्भावनापूर्ण HTML के लिए क्षेत्र। प्लगइन उस मान को संग्रहीत करता है।.
2. 2. एक प्रशासक नौकरी या उम्मीदवार सूचियों को देखता है; पृष्ठ को प्रस्तुत करता है स्थिति 3. क्षेत्र को बिना एस्केप किए, प्रशासक के ब्राउज़र में स्क्रिप्ट निष्पादन को ट्रिगर करता है।.
3. 4. संभावित पोस्ट-एक्सप्लॉइट क्रियाएँ प्रशासक सत्र कुकीज़ की चोरी, CSRF-जैसे प्रवाह के माध्यम से प्रशासक क्रियाओं को मजबूर करना, अतिरिक्त बैकडोर डालना, या नए विशेषाधिकार प्राप्त उपयोगकर्ताओं या फ़ाइल परिवर्तनों के माध्यम से स्थिरता बनाना शामिल हैं।.

5. क्योंकि निष्पादन के लिए एक विशेषाधिकार प्राप्त उपयोगकर्ता को संग्रहीत सामग्री के साथ इंटरैक्ट करना आवश्यक है, खतरे का मॉडल मध्यम है लेकिन वास्तविक है - विशेष रूप से उन साइटों के लिए जहां उम्मीदवार रिकॉर्ड को नियमित रूप से प्रशासकों द्वारा समीक्षा की जाती है।.

6. जोखिम विश्लेषण - कौन और क्या जोखिम में है?

• 7. साइटें जो उम्मीदवार या नियोक्ता सामग्री को स्वीकार करती हैं और जहां प्रशासक नियमित रूप से उम्मीदवार/नौकरी रिकॉर्ड की जांच करते हैं।.
• 8. भर्ती प्लेटफ़ॉर्म, एचआर पोर्टल, या बहु-उपयोगकर्ता कार्यप्रवाह जहां गैर-विश्वसनीय भूमिकाएँ रिकॉर्ड बना या संशोधित कर सकती हैं।.
• 9. प्रभाव प्रशासक के विशेषाधिकार और सत्र सुरक्षा (कुकी फ़्लैग, SameSite, आदि) पर निर्भर करता है। जो सामग्री इंजेक्शन के रूप में शुरू होता है वह सत्रों या क्रियाओं के दुरुपयोग होने पर पूर्ण साइट समझौते में बढ़ सकता है।.

10. साइट मालिकों के लिए तात्कालिक क्रियाएँ (तेज़ प्रतिक्रिया)

11. एक हांगकांग सुरक्षा पेशेवर के रूप में, मैं व्यावहारिक containment कदमों की सलाह देता हूँ जिन्हें आप जल्दी कर सकते हैं। ये स्थायी कोड सुधार उपलब्ध होने तक अस्थायी उपाय हैं।.

1. अस्थायी रोकथाम:
   • 12. उम्मीदवार प्रस्तुतियों को निष्क्रिय करें या सार्वजनिक उम्मीदवार पंजीकरण को हटा दें जब तक कि एक सुधार उपलब्ध न हो।.
   • 13. यह सीमित करें कि कौन उम्मीदवार खातों को बना सकता है - प्रशासक अनुमोदन की आवश्यकता करें या खुली पंजीकरण को निष्क्रिय करें।.
   • 14. उन पृष्ठों तक पहुँच को प्रतिबंधित करें जो केवल विश्वसनीय उपयोगकर्ताओं के लिए क्षेत्र को प्रस्तुत करते हैं (सर्वर-स्तरीय ACLs या एक्सेस-नियंत्रण प्लगइन्स)। स्थिति 15. यदि संचालन के लिए संभव हो, तो WP JobHunt प्लगइन को निष्क्रिय करें जब तक कि एक पैच जारी न हो।.
   • 16. प्रशासक खातों को मजबूत करें:.
2. 17. सभी प्रशासक खातों के लिए मजबूत पासवर्ड लागू करें और दो-कारक प्रमाणीकरण सक्षम करें।
   • 18. जहां संभव हो, IP द्वारा प्रशासक पहुँच को प्रतिबंधित करें और भूमिकाओं को सीमित करें ताकि कम खातों को संवेदनशील स्क्रीन तक पहुँच मिल सके।.
   • 19. सक्रिय सत्रों की समीक्षा करें और उन खातों के लिए सत्रों को अमान्य करें जो संदिग्ध गतिविधि दिखाते हैं।.
   • सक्रिय सत्रों की समीक्षा करें और उन खातों के लिए सत्रों को अमान्य करें जो संदिग्ध गतिविधि दिखाते हैं।.
3. डेटाबेस का निरीक्षण करें:
   • स्क्रिप्ट फ़्रैगमेंट, टैग, या संदिग्ध HTML के लिए नौकरी और उम्मीदवार तालिकाओं की खोज करें स्थिति फ़ील्ड और समान कॉलम में। संदिग्ध प्रविष्टियों को बदलें या साफ़ करें और एक फोरेंसिक कॉपी रखें।.
4. उपयोगकर्ता खातों का ऑडिट करें:
   • हाल ही में बनाए गए उम्मीदवार खातों की समीक्षा करें और किसी भी ऐसे खाते को हटा दें या चिह्नित करें जिसे आप नहीं पहचानते।.
5. बैकअप:
   • सामूहिक परिवर्तनों से पहले एक पूर्ण बैकअप (फाइलें + डेटाबेस) बनाएं। फोरेंसिक उद्देश्यों के लिए एक कॉपी ऑफ़लाइन रखें।.
6. निगरानी करें:
   • उम्मीदवार गतिविधि के तुरंत बाद असामान्य POSTs या व्यवस्थापक पृष्ठ लोड के लिए सर्वर लॉग की जांच करें। प्रासंगिक एंडपॉइंट्स पर लॉगिंग और अलर्टिंग बढ़ाएं।.

ये संकुचन क्रियाएँ जोखिम को कम करती हैं। मूल कारण को पूरी तरह से ठीक करने के लिए एक डेवलपर-स्तरीय पैच की आवश्यकता है।.

डेवलपर मार्गदर्शन - मूल कारण को कैसे ठीक करें

डेवलपर्स और रखरखाव करने वालों को संग्रहीत XSS जोखिमों को समाप्त करने के लिए इन सुरक्षित कोडिंग प्रथाओं को लागू करना चाहिए:

1. प्राधिकरण जांच लागू करें

   सुनिश्चित करें कि केवल स्पष्ट अनुमतियों वाले भूमिकाएँ ही सबमिट या बदल सकती हैं स्थिति. । स्थिति को सर्वर-साइड स्थिरांक से मैप करें और केवल विश्वसनीय भूमिकाओं को उन्हें बदलने की अनुमति दें।.

   // अस्वीकृत करें यदि उपयोगकर्ता नौकरी की स्थिति प्रबंधित नहीं कर सकता है

2. स्थिति मानों के लिए एक श्वेतसूची का उपयोग करें

   $allowed_statuses = array( 'open', 'closed', 'draft', 'pending' );

3. इनपुट पर साफ़ करें और आउटपुट पर एस्केप करें

   इनपुट को साफ़ करें (जैसे, sanitize_text_field) और आउटपुट को एस्केप करें esc_html(), esc_attr(), या wp_kses() जैसे उपयुक्त हो।.

   // संग्रहित करने से पहले साफ़ करें;

4. नॉन्स और CSRF सुरक्षा

   सभी फ़ॉर्म सबमिशन और AJAX एंडपॉइंट्स को नॉन्स का उपयोग करना चाहिए (चेक_एडमिन_रेफरर / चेक_ajax_referer) और उन्हें सर्वर-साइड पर सत्यापित करें।.

5. संदर्भ-जानकारी वाले एस्केपिंग

   उपयोग करें esc_attr() HTML विशेषताओं के लिए, esc_js() या wp_json_encode() जावास्क्रिप्ट संदर्भों के लिए, और esc_html() बॉडी सामग्री के लिए।.

6. डेटाबेस क्वेरी का ऑडिट करें

   हमेशा उन मानों को एस्केप करें जब डेटाबेस से प्राप्त डेटा प्रदर्शित किया जा रहा हो।.

7. REST एंडपॉइंट की समीक्षा करें

   यदि प्लगइन REST API एंडपॉइंट्स को उजागर करता है, तो अनुमति कॉलबैक के भीतर क्षमताओं को मान्य करें और आने वाले डेटा को साफ करें।.

WAF और वर्चुअल पैचिंग - अस्थायी सुरक्षा

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

सामान्य सुरक्षा उपायों में शामिल हैं:

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

वर्चुअल पैच अस्थायी उपाय हैं - ये जोखिम को कम करते हैं लेकिन कोड-स्तरीय सुधार और Thorough डेटाबेस सफाई की आवश्यकता को प्रतिस्थापित नहीं करते हैं।.

व्यावहारिक वर्चुअल पैच कैसे लिखे जाते हैं (तकनीकी)

संग्रहीत XSS के लिए प्रभावी WAF नियम सामान्य इंजेक्शन पैटर्न पर ध्यान केंद्रित करते हैं जबकि झूठे सकारात्मक को न्यूनतम करते हैं। उदाहरणात्मक सुरक्षा जांच:

• अवरुद्ध करें स्थिति मान जो शामिल हैं 9. या विशेषताओं जैसे onload=, त्रुटि होने पर=, 11. साइट मालिकों के लिए तात्कालिक कदम, या जावास्क्रिप्ट:.
• जब साइट अनुक्रमित स्थितियों का उपयोग करती है, तो एक सख्त अनुमत सेट में उपस्थित नहीं मानों को अवरुद्ध करें।.
• AJAX/REST एंडपॉइंट्स के लिए मान्य नॉनसेस या प्रमाणीकरण हेडर की आवश्यकता; अपेक्षित टोकन गायब होने पर कॉल को अवरुद्ध करें।.

वैचारिक छद्म-नियम तर्क:

// यदि अनुरोध में 'स्थिति' है और

इन नियमों को साइट के सामान्य ट्रैफ़िक और श्वेतसूचियों के अनुसार समायोजित किया जाना चाहिए ताकि निर्दोष अनुरोधों को अवरुद्ध करने से बचा जा सके।.

पहचान - यह कैसे पहचानें कि क्या आप लक्षित थे या प्रभावित हुए

1. वेब लॉग: POST/AJAX अनुरोधों के लिए एक्सेस लॉग और एप्लिकेशन लॉग की खोज करें जो प्लगइन एंडपॉइंट्स के साथ हैं स्थिति टैग या स्क्रिप्ट फ़्रैगमेंट शामिल हैं।.
2. डेटाबेस: संग्रहीत मानों के लिए उम्मीदवार/कार्य तालिकाओं का निरीक्षण करें जो , script, या इनलाइन इवेंट हैंडलर्स शामिल हैं।.
3. ब्राउज़र साक्ष्य: यदि एक व्यवस्थापक रिकॉर्ड देखते समय पॉपअप, अप्रत्याशित रीडायरेक्ट, या अजीब ब्राउज़र व्यवहार का अनुभव करता है तो कंसोल आउटपुट/नेटवर्क ट्रेस कैप्चर करें।.
4. व्यवस्थापक गतिविधि: संदिग्ध घटनाओं के समय साइट सेटिंग्स में अप्रत्याशित परिवर्तनों, नए व्यवस्थापक उपयोगकर्ताओं, फ़ाइल संशोधनों, या असामान्य अनुसूचित कार्यों की जांच करें।.
5. मैलवेयर स्कैनिंग: इंजेक्टेड सामग्री और अज्ञात फ़ाइलों के लिए फ़ाइल और DB स्कैन चलाएँ।.

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

एक घटना के बाद सफाई करना

1. साइट को अलग करें — व्यवस्थापक पहुंच को प्रतिबंधित करें और साइट को रखरखाव मोड में डालने पर विचार करें।.
2. सबूत को संरक्षित करें: पूर्ण बैकअप लें (फ़ाइलें + DB) और WAF लॉग और सर्वर लॉग को बनाए रखें।.
3. दुर्भावनापूर्ण संग्रहीत पेलोड की पहचान करें और हटाएँ, लेकिन सुरक्षित फोरेंसिक कॉपी में मूल को संरक्षित करें।.
4. प्रशासनिक पासवर्ड रीसेट करें और सत्रों को अमान्य करें।.
5. API कुंजियाँ, SSH कुंजियाँ, और अन्य क्रेडेंशियल्स को घुमाएँ जो उजागर हो सकते हैं।.
6. अतिरिक्त बैकडोर के लिए स्कैन करें और हटाएँ (संदिग्ध PHP फ़ाइलें, संशोधित कोर फ़ाइलें, अज्ञात प्लगइन/थीम)।.
7. यदि आवश्यक हो तो ज्ञात-अच्छे बैकअप से पुनर्स्थापित करें।.
8. स्थायी सुधार लागू करें: प्लगइन को अपडेट करें या ऊपर वर्णित कोड को पैच करें।.
9. केवल गहन सत्यापन और निगरानी के बाद ही पहुंच को फिर से सक्षम करें।.
10. प्रक्रियाओं में सुधार के लिए एक पोस्ट-मॉर्टम करें (कम से कम विशेषाधिकार, कार्यप्रवाह की समीक्षा, पहचान नियम)।.

दीर्घकालिक डेवलपर सर्वोत्तम प्रथाएँ

• कम से कम विशेषाधिकार का सिद्धांत: सुनिश्चित करें कि उम्मीदवार-स्तरीय भूमिकाएँ व्यवस्थापक UI में दिखाए गए फ़ील्ड को बिना बचने के परिवर्तित नहीं कर सकतीं।.
• जल्दी साफ करें, देर से बचें: प्राप्ति पर इनपुट को साफ करें और संदर्भ के अनुसार आउटपुट पर बचें।.
• स्वीकार्य मूल्यों के लिए काले सूचियों की तुलना में सफेद सूचियों को प्राथमिकता दें।.
• सभी इनपुट को अविश्वसनीय मानें, यहां तक कि प्रमाणित उपयोगकर्ताओं से भी।.
• इंजेक्टेड स्क्रिप्ट के प्रभाव को सीमित करने के लिए सामग्री सुरक्षा नीति (CSP) अपनाएँ।.
• DB संचालन के लिए तैयार किए गए बयानों और पैरामीटरयुक्त प्रश्नों का उपयोग करें।.
• सुरक्षित कुकी ध्वज लागू करें (HttpOnly, Secure, उपयुक्त SameSite)।.
• CI/CD पाइपलाइनों में स्वचालित कोड स्कैनिंग और निर्भरता जांच को एकीकृत करें।.

भूमिका मैपिंग और क्षमता जांच क्यों महत्वपूर्ण हैं

यहाँ मुख्य मुद्दा अनुपस्थित प्राधिकरण है। उम्मीदवार उपयोगकर्ताओं को प्रशासनिक इंटरफेस में प्रदर्शित क्षेत्रों में मनमाना HTML लिखने में सक्षम नहीं होना चाहिए। क्रियाओं को क्षमताओं से मैप करना (उदाहरण के लिए, नौकरी_स्थिति_प्रबंधित करें) यह नियंत्रित करना सरल बनाता है कि कौन संवेदनशील क्षेत्रों को बदल सकता है, और कच्चे भूमिका नामों पर निर्भर रहने की तुलना में वातावरणों में अधिक पोर्टेबल है।.

सामान्य प्रश्न

प्रश्न: यदि मैं अभी प्लगइन अपडेट नहीं कर सकता, तो क्या आभासी पैचिंग पर्याप्त है?

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

प्रश्न: क्या मुझे सुरक्षित रहने के लिए सभी उम्मीदवार रिकॉर्ड हटाने चाहिए?

उत्तर: डेटा हटाना विनाशकारी है और अक्सर अनावश्यक होता है। संदिग्ध प्रविष्टियों की पहचान करें और उन्हें साफ करें, रिकॉर्ड को संशोधित करने से पहले फोरेंसिक प्रतियां रखें, और जांच करते समय साइट को सीमित करें।.

प्रश्न: मैं इस कमजोरियों के खिलाफ प्रयासों की निगरानी कैसे करूं?

उत्तर: WP JobHunt एंडपॉइंट्स पर अवरुद्ध या संदिग्ध अनुरोधों के लिए वेब और WAF लॉग की निगरानी करें, HTML/script पेलोड्स वाले POSTs पर अलर्ट करें, स्थिति और प्रशासनिक पृष्ठ विसंगतियों के लिए सूचनाएं सक्षम करें।.

जिम्मेदार प्रकटीकरण समयरेखा (सारांश)

• शोधकर्ता ने अनुपस्थित प्राधिकरण और संग्रहीत XSS की खोज की स्थिति क्षेत्र के माध्यम से।.
• CVE असाइन किया गया: CVE-2025-7782।.
• प्रकटीकरण के समय, प्रभावित संस्करणों के लिए प्लगइन रिपॉजिटरी में कोई आधिकारिक पैच मौजूद नहीं था ≤ 7.7।.

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

उदाहरण सुरक्षित कोड पैटर्न (डेवलपर संदर्भ)

सर्वर-साइड प्राधिकरण, सख्त व्हाइटलिस्टिंग, सफाई, और एस्केपिंग के लिए संदर्भ पैटर्न:

1) व्हाइटलिस्ट + क्षमता जांच:

function update_job_status( $job_id, $new_status ) {

2) आउटपुट पर उचित एस्केपिंग:

$stored_status = get_post_meta( $job_id, '_job_status', true );

3) REST एंडपॉइंट उदाहरण:

register_rest_route( 'jobhunt/v1', '/job/(?P\d+)/status', array(

समापन व्यावहारिक चेकलिस्ट

• यदि आपके पास WP JobHunt ≤ 7.7 है, तो तुरंत कार्रवाई करें: जोखिम भरे सबमिशन पॉइंट्स को निष्क्रिय करें, उम्मीदवार पंजीकरण को सीमित करें, और एक पैच जारी होने तक अनुरोध-स्तरीय सुरक्षा पर विचार करें।.
• डेवलपर्स: व्हाइटलिस्ट-आधारित स्थितियों, क्षमता जांच, नॉनसेस, और उचित सफाई + एस्केपिंग को लागू करें।.
• यदि आपको समझौता होने का संदेह है: अलग करें, लॉग/बैकअप को संरक्षित करें, संग्रहीत पेलोड को हटा दें, क्रेडेंशियल्स को घुमाएं, और एक गहन सफाई और सत्यापन करें।.

एक हांगकांग सुरक्षा विशेषज्ञ के रूप में: तेज़ containment, विस्तृत लॉगिंग, और सावधानीपूर्वक फोरेंसिक संरक्षण को प्राथमिकता दें। संग्रहीत XSS सूक्ष्म हो सकता है - विशेषाधिकार प्राप्त उपयोगकर्ताओं की सुरक्षा और संग्रहीत डेटा की सफाई पर ध्यान केंद्रित करें, न कि केवल सतही अनुरोध वेक्टर का उपचार करें।.