महत्वपूर्ण चेतावनी — CVE-2025-9212: WP Dispatcher (≤ 1.2.0) में प्रमाणित (सदस्य) मनमाना फ़ाइल अपलोड

प्रकाशित तिथि: 3 अक्टूबर 2025  |  गंभीरता: उच्च — CVSS 9.9  |  प्रभावित संस्करण: WP Dispatcher ≤ 1.2.0  |  रिपोर्ट किया गया: क्रेग वेब

एक हांगकांग स्थित सुरक्षा विशेषज्ञ के रूप में, मैं WP Dispatcher प्लगइन को प्रभावित करने वाली उच्च-जोखिम की भेद्यता के लिए एक तकनीकी सलाह और शमन मार्गदर्शन प्रकाशित कर रहा हूँ। यह दोष प्रमाणित उपयोगकर्ताओं को सदस्य भूमिका के साथ मनमाने फ़ाइलें अपलोड करने की अनुमति देता है। सफल शोषण के परिणामस्वरूप वेबशेल तैनाती, दूरस्थ कोड निष्पादन और पूर्ण साइट समझौता हो सकता है। नीचे दिया गया मार्गदर्शन साइट के मालिकों, प्रशासकों और घटना प्रतिक्रिया करने वालों के लिए लिखा गया है जिन्हें जल्दी कार्रवाई करनी चाहिए।.

कार्यकारी सारांश

• क्या: WP Dispatcher (≤ 1.2.0) में प्रमाणित मनमाना फ़ाइल अपलोड जो निम्न-privilege उपयोगकर्ताओं को फ़ाइलें सबमिट करने की अनुमति देता है जिन्हें प्लगइन सही तरीके से मान्य या प्रतिबंधित नहीं करता।.
• प्रभाव: दूरस्थ कोड निष्पादन, स्थायी बैकडोर, डेटा चोरी और साइट अधिग्रहण वास्तविक परिणाम हैं यदि एक निष्पादन योग्य फ़ाइल (जैसे, PHP वेबशेल) को वेब-सुलभ स्थान में रखा जाता है।.
• वर्तमान स्थिति: प्रकटीकरण के समय कोई आधिकारिक प्लगइन पैच उपलब्ध नहीं था। तत्काल शमन की आवश्यकता है।.
• तत्काल कार्रवाई: उत्पादन साइटों पर जहां संभव हो, प्लगइन को हटा दें या निष्क्रिय करें; अपलोड एंडपॉइंट्स पर वेब-लेयर ब्लॉक्स (वर्चुअल पैचिंग) लागू करें; अपलोड निर्देशिकाओं में PHP निष्पादन को रोकें; संदिग्ध फ़ाइलों और खातों के लिए ऑडिट करें; यदि समझौता संदिग्ध है तो क्रेडेंशियल्स को घुमाएँ।.

यह इतना खतरनाक क्यों है

मनमाना फ़ाइल अपलोड भेद्यताएँ एक प्राथमिक सुरक्षा सीमा को बायपास करती हैं — फ़ाइल सिस्टम और वेब सर्वर। यदि एक हमलावर वेब रूट के तहत एक निष्पादन योग्य फ़ाइल रख सकता है, तो वे कोड निष्पादित कर सकते हैं, स्थिरता स्थापित कर सकते हैं, और पूर्ण समझौते तक बढ़ सकते हैं।.

यह उदाहरण विशेष रूप से गंभीर है क्योंकि:

• केवल एक सदस्य खाता आवश्यक है — ऐसे खाते आमतौर पर साइट आगंतुकों द्वारा बनाए जाते हैं।.
• प्रकटीकरण के समय कोई आधिकारिक पैच उपलब्ध नहीं था।.
• शोषण को स्वचालित किया जा सकता है और कई साइटों पर चल रहे भेद्य प्लगइन के खिलाफ स्केल किया जा सकता है।.
• प्लगइन की कार्यक्षमता फ़ाइल इनपुट को स्वीकार करने के लिए प्रतीत होती है, जो उपयोगी अपलोड वेक्टर की संभावना को बढ़ाती है।.

उच्च प्रभाव और शोषण के लिए निम्न बाधा को देखते हुए, उजागर साइटों को तत्काल रोकथाम प्राथमिकताओं के रूप में मानें।.

तकनीकी जड़ें — मनमाना फ़ाइल अपलोड भेद्यताएँ आमतौर पर कैसे होती हैं

शोषणशीलता आमतौर पर सरल कोडिंग त्रुटियों के संयोजन से उत्पन्न होती है। कोड का ऑडिट करते समय, इन असुरक्षित पैटर्न की जांच करें:

• क्षमता जांच का अभाव (जैसे, कोई current_user_can(‘upload_files’) सत्यापन नहीं)।.
• फ़ॉर्म/AJAX सबमिशन के लिए कोई nonce या मूल सत्यापन नहीं।.
• फ़ाइल प्रकारों या एक्सटेंशन के लिए केवल क्लाइंट-साइड मान्यता; कोई सर्वर-साइड प्रवर्तन नहीं।.
• फ़ाइल नाम की सफाई की कमी और डबल एक्सटेंशन या ट्रैवर्सल अनुक्रमों की स्वीकृति।.
• अपलोड को सीधे वेब-एक्सेसिबल निर्देशिकाओं में सहेजना बिना अपलोड किए गए स्क्रिप्ट के निष्पादन को रोकने के।.
• फ़ाइल सामग्री और MIME प्रकार को सर्वर-साइड पर निरीक्षण करने के बजाय सामग्री-प्रकार हेडर या ब्राउज़र जांचों पर भरोसा करना।.

इस WP डिस्पैचर मामले में, तथ्य यह है कि सब्सक्राइबर फ़ाइलें अपलोड कर सकते हैं, यह स्पष्ट रूप से अनुपस्थित क्षमता जांच या अपर्याप्त सर्वर-साइड सत्यापन को इंगित करता है।.

शोषण परिदृश्य (वास्तविक उदाहरण)

1. सब्सक्राइबर एक PHP बैकडोर अपलोड करता है
   हमलावर एक सब्सक्राइबर खाता पंजीकृत करता है या उसे समझौता करता है और कमजोर अपलोड एंडपॉइंट का उपयोग करके एक फ़ाइल रखता है जैसे avatar.php.jpg जिसमें PHP कोड होता है। यदि सर्वर इसे स्वीकार करता है और इसे एक वेब-एक्सेसिबल स्थान में संग्रहीत करता है और निष्पादन संभव है (डबल एक्सटेंशन या गलत कॉन्फ़िगर किए गए हैंडलर्स), तो हमलावर वेबशेल को सक्रिय कर सकता है।.
2. स्टेज्ड टेकओवर
   प्रारंभिक कोड निष्पादन के बाद हमलावर व्यवस्थापक उपयोगकर्ता बनाता है, दुर्भावनापूर्ण प्लगइन्स स्थापित करता है या स्थिरता बनाए रखने के लिए थीम फ़ाइलों को संशोधित करता है। वे सफाई प्रयासों से बचने के लिए क्रोन जॉब्स या डेटाबेस बैकडोर जोड़ सकते हैं।.
3. मास स्कैनिंग और समझौता
   हमलावर WP डिस्पैचर ≤ 1.2.0 चला रहे साइटों के लिए स्कैन कर सकते हैं और कई लक्ष्यों पर स्वचालित अपलोड कर सकते हैं, यदि शमन अनुपस्थित हैं तो बड़े पैमाने पर समझौता हो सकता है।.

समझौते के संकेत (IoCs)

यदि आप शोषण का संदेह करते हैं तो इन संकेतों की खोज करें:

• असामान्य फ़ाइलें wp-content/uploads/ या अन्य वेब-एक्सेसिबल निर्देशिकाओं में: फ़ाइलें जिनमें .php, .phtml, .phar, .php5 या .shtml एक्सटेंशन, या .htaccess अपलोड फ़ोल्डरों में गिराई गई फ़ाइलें।.
• डबल एक्सटेंशन वाली फ़ाइलें (उदाहरण के लिए छवि.jpg.php) या यादृच्छिक नाम वाली फ़ाइलें जो PHP कोड शामिल करती हैं।.
• नए या संशोधित व्यवस्थापक खाते, या मौजूदा खातों में अप्रत्याशित परिवर्तन।.
• अप्रत्याशित निर्धारित कार्य (wp_cron प्रविष्टियाँ) या परिवर्तन 11. संदिग्ध सामग्री के साथ।.
• संशोधित थीम या प्लगइन फ़ाइलें (हेडर, फ़ुटर, functions.php).
• वेब सर्वर से अज्ञात आईपी पते के लिए आउटगोइंग कनेक्शन।.
• सब्सक्राइबर खातों से प्लगइन अपलोड एंडपॉइंट्स पर POST अनुरोध दिखाने वाली एक्सेस लॉग प्रविष्टियाँ।.
• वेबशेल गतिविधि के बाद उच्च CPU या अप्रत्याशित संसाधन स्पाइक्स।.

यदि आप किसी घटना का संदेह करते हैं तो फोरेंसिक विश्लेषण के लिए लॉग और फ़ाइल सिस्टम छवियों को संरक्षित करें।.

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

• POST अनुरोध admin-ajax.php या प्लगइन एंडपॉइंट्स के साथ मल्टीपार्ट/फॉर्म-डेटा उन खातों से जो सब्सक्राइबर हैं।.
• अनुरोध जहाँ मल्टीपार्ट पेलोड में PHP कोड शामिल है जैसे <?php.
• नए बनाए गए फ़ाइलों के लिए अनुरोध /wp-content/uploads/ जो पहले 404 लौटाते थे लेकिन अब 200 लौटाते हैं।.
• डेटाबेस संचालन जो उच्च भूमिका वाले उपयोगकर्ताओं को बनाते या संशोधित करते हैं।.
• एक्सेस लॉग में संदिग्ध अनुरोधों के पास टाइमस्टैम्प किए गए फ़ाइल सिस्टम परिवर्तन।.

अपलोड निर्देशिकाओं के भीतर संदिग्ध फ़ाइल निर्माण के लिए अलर्ट सेट करें और उन POSTs के लिए जो निष्पादन योग्य पेलोड शामिल करते हैं।.

तात्कालिक निवारण (चरण दर चरण)

1. यदि संभव हो, तो साइट को रखरखाव मोड या सुधार के लिए सुरक्षित विंडो में रखें। यदि संभव नहीं है, तो तुरंत ब्लॉकिंग नियंत्रण लागू करें।.
2. प्रभावित साइटों से WP डिस्पैचर प्लगइन को निष्क्रिय और हटा दें। यदि तत्काल हटाना असंभव है, तो वेब परत पर प्लगइन के अपलोड एंडपॉइंट्स को ब्लॉक करें।.
3. अपलोड निर्देशिकाओं में PHP निष्पादन को वेब सर्वर कॉन्फ़िगरेशन के माध्यम से रोकें (.htaccess के लिए Apache, nginx के लिए स्थान नियम)।.
4. संदिग्ध फ़ाइलों के लिए अपलोड निर्देशिकाओं और वेब रूट को स्कैन करें और किसी भी विसंगति को क्वारंटाइन करें।.
5. यदि समझौता होने का संदेह है तो सभी प्रशासनिक और सेवा क्रेडेंशियल्स (WordPress व्यवस्थापक, डेटाबेस, FTP, SSH) को घुमाएँ।.
6. WordPress सॉल्ट/कीज़ को पुनः उत्पन्न करें wp-config.php यदि आपको सत्र या कुकी समझौता होने का संदेह है।.
7. उपयोगकर्ताओं का ऑडिट करें और किसी भी अप्रत्याशित खातों को हटा दें या सुरक्षित करें।.
8. यदि आप समझौते की पुष्टि करते हैं और बैकडोर को पूरी तरह से समाप्त नहीं कर सकते, तो ज्ञात स्वच्छ बैकअप से पुनर्स्थापित करें।.
9. आधिकारिक प्लगइन फिक्स उपलब्ध होने तक आगे के शोषण प्रयासों को रोकने के लिए वेब-लेयर ब्लॉकिंग नियम (वर्चुअल पैच) लागू करें।.
10. यदि आगे बढ़ने के लिए सुनिश्चित नहीं हैं या यदि सक्रिय समझौते के सबूत हैं, तो तुरंत एक योग्य घटना प्रतिक्रिया विशेषज्ञ से संपर्क करें।.

त्वरित सुधार स्निप्पेट

इन सर्वर और WordPress स्निप्पेट्स का उपयोग आपातकालीन उपायों के रूप में करें। उत्पादन में लागू करने से पहले परिवर्तनों का परीक्षण एक स्टेजिंग वातावरण में करें जहाँ संभव हो।.

1) Apache — /wp-content/uploads/ के लिए .htaccess

2) Nginx कॉन्फ़िगरेशन स्निप्पेट (सर्वर ब्लॉक के अंदर)

location ~* /wp-content/uploads/.*\.(php|phtml|php5|phar)$ {

3) सब्सक्राइबर्स के लिए अपलोड को ब्लॉक करने के लिए WordPress फ़िल्टर (आपातकालीन)

<?php

नोट: यह एक आपातकालीन उपाय है। पूर्ण सुधार और पैचिंग के बाद हटा दें।.

उदाहरण WAF / वर्चुअल पैच नियम

ये उदाहरण नियम आपको वेब-लेयर सुरक्षा बनाने में मदद करने के लिए प्रदान किए गए हैं। झूठे सकारात्मक से बचने के लिए अपने वातावरण के अनुसार अनुकूलित और परीक्षण करें।.

1) ModSecurity — मल्टीपार्ट बॉडी के अंदर PHP कोड का पता लगाएं

SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" "phase:2,t:none,chain,deny,status:403,msg:'PHP सामग्री के साथ अपलोड को ब्लॉक करें'"

2) निषिद्ध एक्सटेंशन के साथ अपलोड को ब्लॉक करें

SecRule FILES_TMPNAMES "@rx \.(php|phtml|php5|phar)$" "phase:2,deny,status:403,msg:'कार्यकारी फ़ाइल अपलोड अवरुद्ध'"

3) संदिग्ध फ़ाइल नामों और डबल एक्सटेंशन को अवरुद्ध करें

SecRule ARGS_NAMES|ARGS "@rx \.(php|phtml|php5|phar)$" "phase:2,deny,status:403,msg:'फ़ाइल नाम में अवरुद्ध एक्सटेंशन है'"

4) प्लगइन अपलोड एंडपॉइंट्स पर POST को अवरुद्ध करें (उदाहरण)

SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "phase:1,chain,deny,status:403,msg:'संदिग्ध admin-ajax अपलोड अवरुद्ध करें'"

यदि आपकी वेब परत WordPress कुकीज़ को भूमिकाओं से संबंधित कर सकती है, तो सब्सक्राइबर से मैप की गई भूमिकाओं से अपलोड को अवरुद्ध करने पर विचार करें, क्योंकि यह एक उन्नत उपाय है (सभी WAFs इस क्षमता का समर्थन नहीं करते)।.

हार्डनिंग सिफारिशें (तत्काल पैच के अलावा)

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

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

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

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

पहचान पैटर्न और SIEM नियम (उदाहरण)

• फ़ाइलों के निर्माण पर अलर्ट करें /wp-content/uploads/ एक्सटेंशन के साथ: php, phtml, phar.
• पर POSTs पर अलर्ट करें admin-ajax.php या प्लगइन एंडपॉइंट्स के साथ मल्टीपार्ट/फॉर्म-डेटा जहाँ पेलोड में शामिल हैं <?php.
• अलर्ट करें जब एक निम्न-privilege खाता (सदस्य) एक अपलोड क्रिया करता है जो सामान्यतः उच्च भूमिकाओं के लिए आरक्षित होती है।.
• भूमिका के साथ उपयोगकर्ताओं के निर्माण पर अलर्ट करें 19. भूमिका (या सीधे क्षमताओं में हेरफेर करता है) बिना कॉलर के अधिकारों की पुष्टि किए, तो विशेषाधिकार वृद्धि होगी। इस वास्तविक स्पेस मामले में,.
• अलर्ट करें जब महत्वपूर्ण 11. संदिग्ध सामग्री के साथ। क्रोन या प्लगइन सेटिंग्स से संबंधित प्रविष्टियाँ अप्रत्याशित रूप से बदलती हैं।.

डेवलपर सुधार (प्लगइन लेखक को क्या करना चाहिए)

डेवलपर्स को फ़ाइल प्रबंधन को एक उच्च-जोखिम संचालन के रूप में मानना चाहिए और मजबूत सर्वर-साइड नियंत्रण लागू करना चाहिए:

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

दीर्घकालिक: शासन, पैचिंग और प्लगइन स्वच्छता

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

सामान्य प्रश्न (FAQ)

क्या मुझे तुरंत प्लगइन हटाना चाहिए या बस इसे निष्क्रिय करना चाहिए?

यदि आप साइट को रखरखाव में ले जा सकते हैं, तो हमले की सतह को हटाने के लिए प्लगइन को हटा दें। यदि हटाना व्यावहारिक नहीं है, तो प्लगइन को निष्क्रिय करें और जब तक आप इसे सुरक्षित रूप से हटा नहीं सकते, तब तक इसके एंडपॉइंट्स को वेब परत पर ब्लॉक करें।.

क्या मैं सभी अपलोड को बस ब्लॉक कर सकता हूँ?

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

अगर मेरी साइट पहले से ही इस कमजोरियों से प्रभावित थी तो क्या होगा?

उपरोक्त घटना प्रतिक्रिया चेकलिस्ट का पालन करें। यदि वेबशेल या स्थायी बैकडोर पाए जाते हैं, तो सत्यापित स्वच्छ बैकअप से पुनर्स्थापना पर विचार करें और क्रेडेंशियल रोटेशन करें। स्वचालित सफाई स्क्रिप्ट पर केवल भरोसा न करें जब तक कि आप यह पुष्टि न कर सकें कि वे सभी स्थायी तंत्रों को हटा देते हैं।.

समापन विचार

यह कमजोरियां यह दर्शाती हैं कि फ़ाइल अपलोड हैंडलिंग किसी भी वेब एप्लिकेशन में सबसे संवेदनशील विशेषताओं में से एक है। निम्न-privilege खाते जैसे कि सब्सक्राइबर को निष्पादन योग्य कोड रखने की अनुमति नहीं होनी चाहिए जहाँ वेब सर्वर इसे चला सके।.

तुरंत कार्रवाई करें: शोषण वेक्टर को अवरुद्ध करें, कमजोर प्लगइन को हटा दें या अक्षम करें, समझौते के लिए स्कैन करें, और स्तरित सुरक्षा अपनाएं। यदि आपको तकनीकी शमन या घटना प्रतिक्रिया लागू करने में मदद की आवश्यकता है, तो तुरंत एक योग्य सुरक्षा पेशेवर से संपर्क करें।.

सलाह एक हांगकांग सुरक्षा विशेषज्ञ द्वारा तैयार की गई है। रक्षा उद्देश्यों के लिए तकनीकी मार्गदर्शन प्रदान किया गया है। अविश्वसनीय कोड न चलाएं और उत्पादन में तैनात करने से पहले हमेशा नियंत्रित वातावरण में परिवर्तनों का परीक्षण करें।.