लॉन्च से पहले वेबसाइट सुरक्षा ऑडिट

लॉन्च से पहले वेबसाइट सुरक्षा ऑडिट

1. लॉन्च से पहले ऑडिट की आवश्यकता क्यों है

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

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

लॉन्च से पहले एक ऑडिट समझौता, डेटा लीक, और डाउनटाइम के जोखिम को कम करता है, और आर्किटेक्चर में कमजोर स्थानों को उजागर करने में भी मदद करता है। कभी-कभी एक प्रोजेक्ट केवल सतह पर 'स्वच्छ' दिखता है: इंटरफेस तैयार है, पृष्ठ खुलते हैं, भुगतान काम करते हैं, लेकिन हार्डकोडेड रहस्य, पुरानी पुस्तकालयें, या खुले एंडपॉइंट नीचे रहते हैं। यही कारण है कि एक वेबसाइट सुरक्षा ऑडिट प्रकाशन से पहले किया जाना चाहिए, बाद में नहीं।

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

2. वेबसाइट सुरक्षा ऑडिट में क्या शामिल है

एक पूर्ण ऑडिट केवल एक स्कैनर और होमपेज पर एक त्वरित नज़र नहीं है। यह आमतौर पर एक साथ कई परतों को कवर करता है, क्योंकि एक भेद्यता कोड, सर्वर वातावरण, या एप्लिकेशन की अपनी लॉजिक में रह सकती है।

• स्रोत कोड विश्लेषण: असुरक्षित संचालन, डेटा-हैंडलिंग त्रुटियों, हार्डकोडेड रहस्यों, और प्राधिकरण मुद्दों की तलाश करना।
• कॉन्फ़िगरेशन समीक्षा: वेब सर्वर, रिवर्स प्रॉक्सी, डेटाबेस, कंटेनर, पर्यावरण चर, और पहुँच नियम।
• उपयोगकर्ता और सेवा खाता अनुमतियों की समीक्षा: कौन क्या एक्सेस कर सकता है, और क्या कोई अत्यधिक विशेषाधिकार हैं।
• इनपुट फ़ॉर्म और एपीआई की जाँच: मान्यता, फ़िल्टरिंग, इंजेक्शन और पैरामीटर छेड़छाड़ के खिलाफ सुरक्षा।
• CMS, थीम, और प्लगइन्स का विश्लेषण: संस्करण प्रासंगिकता, ज्ञात मुद्दे, अनावश्यक मॉड्यूल।
• नेटवर्क सेटिंग्स की समीक्षा: HTTPS, सुरक्षा हेडर, CORS, प्रशासनिक इंटरफेस की उपलब्धता, खुले पोर्ट।

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

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

3. कमजोरियों के लिए साइट की जांच करना: प्रमुख तरीके

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

मैनुअल विश्लेषण

जहां स्वचालन संदर्भ को समझने में संघर्ष करता है, वहां मैनुअल समीक्षा की आवश्यकता होती है। उदाहरण के लिए, एक स्कैनर जल्दी से एक तकनीकी दोष ढूंढ सकता है, लेकिन केवल एक व्यक्ति एक ऑर्डर फॉर्म में असंगत अनुक्रम, उपयोगकर्ता भूमिकाओं के बीच अजीब निर्भरता, या एक अनुरोध में आईडी बदलकर किसी और के डेटा तक पहुंचने की क्षमता को नोटिस करेगा। मैनुअल विश्लेषण जटिल तर्क के लिए विशेष रूप से उपयोगी है: खाता डैशबोर्ड, भुगतान, प्रशासनिक क्षेत्र, एकीकरण और एपीआई।

यहां, आप केवल यह जांचते हैं कि क्या कोई त्रुटि मौजूद है, बल्कि यह भी कि इसका उपयोग कैसे किया जा सकता है। क्या प्राधिकरण को बायपास किया जा सकता है? क्या अनुरोध में अतिरिक्त पैरामीटर भेजे जा सकते हैं? यदि उपयोगकर्ता की भूमिका बदल दी जाती है तो क्या होता है? एप्लिकेशन कहां ग्राहक पर अधिक भरोसा करता है जितना उसे करना चाहिए?

कमजोरी स्कैनर

स्वचालित स्कैनर सामान्य मुद्दों को जल्दी से खोजने में मदद करते हैं: खुले निर्देशिका, पुराने घटक संस्करण, असुरक्षित हेडर, कमजोर TLS सेटिंग्स, और SQL इंजेक्शन या XSS के ज्ञात पैटर्न, और यह जांचने की एक उपयोगी पहली परत है, विशेष रूप से जब प्रोजेक्ट बड़ा हो और इसे पूरी तरह से मैन्युअल रूप से समीक्षा नहीं किया जा सकता।

लेकिन स्कैनरों की सीमाएं हैं। वे अक्सर झूठे सकारात्मक उत्पन्न करते हैं और व्यावसायिक तर्क को अच्छी तरह से नहीं समझते हैं। इसलिए उनके परिणामों की आलोचनात्मक रूप से समीक्षा करने की आवश्यकता होती है: वास्तव में क्या महत्वपूर्ण है, और क्या केवल शोर है। एक चेतावनी जो चिंताजनक लगती है, यह स्वचालित रूप से नहीं बताती कि कमजोरियों का वास्तव में शोषण किया जा सकता है।

सामान्य OWASP मुद्दों की जांच करना

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

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

प्राधिकरण और डेटा हैंडलिंग का परीक्षण

सबसे मूल्यवान चरणों में से एक यह जांचना है कि उपयोगकर्ता लॉग इन करने के बाद सिस्टम डेटा को कैसे संभालता है, और यह पर्याप्त नहीं है कि "उपयोगकर्ता नाम और पासवर्ड स्वीकार किए जाते हैं।" आपको यह समझने की आवश्यकता है कि इसके बाद क्या होता है: क्या कोई किसी और के प्रोफ़ाइल तक पहुँच सकता है, एक आदेश को संशोधित कर सकता है, यदि वे एक रिकॉर्ड ID जानते हैं तो डेटा निर्यात कर सकते हैं, या ऐसा कार्य कर सकते हैं जो निषिद्ध होना चाहिए?

फार्म में डेटा हैंडलिंग पर भी यही लागू होता है। क्या इनपुट सर्वर पर मान्य किया जाता है, केवल ब्राउज़र में नहीं? क्या एक स्क्रिप्ट, SQL टुकड़ा, अत्यधिक लंबा स्ट्रिंग, या अप्रत्याशित फ़ाइल प्रारूप प्रस्तुत किया जा सकता है? ये प्रश्न सरल लगते हैं, लेकिन अक्सर एक सुरक्षित प्रोजेक्ट को एक समस्याग्रस्त प्रोजेक्ट से अलग करते हैं।

4. रिलीज से पहले वेब प्रोजेक्ट की सुरक्षा कैसे जांचें

पूर्व-लॉन्च समीक्षा को चरण दर चरण किया जाना चाहिए। आदर्श रूप से, यह लाइव सर्वर पर नहीं, बल्कि एक स्टेजिंग वातावरण में होता है जो उत्पादन के करीब है। यह महत्वपूर्ण है: वही समस्या स्थानीय मशीन पर कुछ नहीं दिखा सकती है और फिर अचानक तैनाती के बाद प्रकट हो सकती है क्योंकि PHP के एक अलग संस्करण, एक अन्य nginx कॉन्फ़िगरेशन, या कंटेनर-विशिष्ट व्यवहार के कारण।

1. एक स्टेजिंग वातावरण सेट करें जो उत्पादन कॉन्फ़िगरेशन को दर्शाता है।
2. विभिन्न भूमिकाओं के साथ परीक्षण खाते: अतिथि, उपयोगकर्ता, मध्यस्थ, प्रशासक।
3. सुनिश्चित करें कि रहस्य रिपॉजिटरी, लॉग या फ्रंटेंड बंडल में समाप्त नहीं हुए हैं।
4. निर्भरता, CMS, प्लगइन्स, पुस्तकालय पैकेज और छवियों को अपडेट करें।
5. HTTPS, प्रमाणपत्र की वैधता और सुरक्षित संस्करण के लिए रीडायरेक्ट की जांच करें।
6. बुनियादी सुरक्षा हेडर और CSP नीति सेट करें।
7. CORS, प्रशासन पैनलों की उपलब्धता और सेवा इंटरफेस को लॉक करने की जांच करें।
8. एक बैकअप बनाएं और समस्याएं उत्पन्न होने पर रोलबैक योजना तैयार करें।

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

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

यदि प्रोजेक्ट कॉर्पोरेट, जटिल, या कई एकीकरणों से जुड़ा है, तो रिलीज़ और समर्थन संरचना को पहले से सोचना सहायक होता है। इस संदर्भ में, यह एक दृष्टिकोण का पालन करने में मदद करता है जो स्पष्ट रूप से सामग्री में समझाया गया है एक संरचना जो वास्तव में काम करती है: आर्किटेक्चर जितना स्पष्ट होगा, हर स्तर पर सुरक्षा की जांच करना उतना ही आसान होगा।

5. लॉन्च से पहले आम कमजोरियाँ

रिलीज से पहले, जो समस्याएँ सबसे अधिक दिखाई देती हैं वे असाधारण नहीं होतीं, बल्कि बहुत सामान्य होती हैं। वे बानाल होती हैं क्योंकि इन्हें जल्दी में छोड़ना आसान होता है।

• कमजोर प्रमाणीकरण: छोटे पासवर्ड, कोई ब्रूट-फोर्स सुरक्षा नहीं, कोई दो-कारक सत्यापन नहीं।
• SQL इंजेक्शन: असुरक्षित क्वेरी निर्माण, विशेष रूप से पुराने प्रशासन पैनलों और कस्टम फ़िल्टर में।
• XSS: उपयोगकर्ता इनपुट को बिना एस्केप किए प्रदर्शित करना, विशेष रूप से टिप्पणियों, खोज और प्रोफाइल में।
• असुरक्षित फ़ाइल अपलोड: प्रकार, एक्सटेंशन, आकार या सामग्री की कोई मान्यता नहीं।
• CORS गलतियाँ: अत्यधिक व्यापक अनुमतियाँ जो अन्य डोमेन तक पहुँच को उजागर करती हैं।
• खुले प्रशासन पैनल: अनुमानित पते पर बिना IP प्रतिबंधों या अतिरिक्त सुरक्षा के सुलभ।
• लॉग लीक: व्यक्तिगत डेटा, टोकन, और तकनीकी रहस्य इवेंट लॉग में।

एक और सामान्य समस्या “अस्थायी” सुधार हैं जो अंततः हमेशा के लिए रह जाते हैं, और उदाहरण के लिए, डेवलपर्स एक परिदृश्य को जल्दी से परीक्षण करने के लिए एक जांच को निष्क्रिय कर देते हैं, फिर इसे वापस चालू करना भूल जाते हैं। या वे एक सेवा एंडपॉइंट छोड़ देते हैं जो “कल की आवश्यकता होगी,” लेकिन यह महीनों तक एक सार्वजनिक सर्वर पर जीवित रहता है।

एक और सामान्य जोखिम तीसरे पक्ष के घटकों में असुरक्षित सेटिंग्स हैं। औपचारिक रूप से, साइट का कोड साफ हो सकता है, लेकिन एक पुराना CMS प्लगइन या कमजोर डेटाबेस कॉन्फ़िगरेशन उस सभी देखभाल को रद्द कर सकता है।

6. ऑडिट कौन करता है और कौन से उपकरणों का उपयोग किया जाता है

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

काम में आमतौर पर कई प्रकार के उपकरणों का उपयोग किया जाता है:

• स्रोत कोड और निर्भरता विश्लेषक;
• वेब कमजोरियों के स्कैनर;
• TLS, हेडर, और कॉन्फ़िगरेशन की जांच के लिए उपकरण;
• हाथ से अनुरोध और प्राधिकरण परीक्षण के लिए उपकरण;
• लॉन्च के बाद विसंगतियों का पता लगाने के लिए निगरानी और लॉगिंग सिस्टम।

यह समझना महत्वपूर्ण है कि उपकरण अनुभव का स्थान नहीं लेते हैं, और एक अच्छा विशेषज्ञ हमेशा स्कैनर के परिणामों की तुलना परियोजना की वास्तुकला से करता है। यदि आप ऐसा नहीं करते हैं, तो आप या तो झूठी अलार्म पर घबराते हैं या वास्तव में खतरनाक दोष को चूक जाते हैं।

कुछ परियोजनाओं में, केवल सुरक्षा पर ही नहीं, बल्कि रिलीज के बाद चल रही निगरानी पर भी ध्यान देना उपयोगी होता है। यदि एक साइट ऐसे वातावरण में काम करती है जिसमें बार-बार अपडेट, एकीकरण और अस्थिर ट्रैफिक होता है, तो निगरानी भी उपयोगी हो जाती है। एक संबंधित कार्य एक website monitoring platform द्वारा संभाला जाता है, यदि आपको केवल उपलब्धता को ट्रैक करने की आवश्यकता नहीं है, बल्कि आउटेज और परिवर्तनों पर उपयोगकर्ता की प्रतिक्रियाओं को भी ट्रैक करना है।

7. समस्याएँ मिलने के बाद क्या करना है

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

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

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

यदि परियोजना पहले से ही लॉन्च के करीब है, तो टीम के लिए एक संक्षिप्त रिपोर्ट और पूर्व-रिलीज़ क्रियाओं की एक अलग सूची होना सहायक होता है। ऐसा दस्तावेज़ तब समय बचाता है जब निर्णय जल्दी लेना हो और विवरण पर चर्चा करने का समय न हो। बड़े साइटों के लिए, यह विशेष रूप से महत्वपूर्ण है: वहाँ, सुरक्षा केवल कोड से ही नहीं, बल्कि पोस्ट-लॉन्च समर्थन से भी जुड़ी होती है। यह सामग्री में अच्छी तरह से परिलक्षित होता है लॉन्च के बाद वेबसाइट समर्थन.

8. निष्कर्ष: प्रकाशन से पहले एक न्यूनतम चेकलिस्ट

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

• CMS, ढांचा, प्लगइन्स, और निर्भरताएँ अपडेट की गई हैं।
• फाइलों, फ़ोल्डरों, प्रशासनिक क्षेत्रों, और API के लिए पहुँच अधिकारों की जाँच की गई है।
• सभी रहस्य, टोकन, और सेवा पासवर्ड सुरक्षित हैं।
• HTTPS सक्षम है, प्रमाणपत्र और रीडायरेक्ट सही तरीके से कॉन्फ़िगर किए गए हैं।
• फॉर्म, प्राधिकरण, फ़ाइल अपलोड, और प्रमुख उपयोगकर्ता प्रवाह का परीक्षण किया गया है।
• बैकअप बनाए गए हैं और एक रोलबैक योजना तैयार है।
• पहचाने गए मुद्दों को ठीक करने के बाद एक फॉलो-अप चेक किया जाता है।

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

इसलिए, एक पूर्व-प्रकाशन समीक्षा एक अलग चरण नहीं है "पैरानॉयड के लिए," बल्कि एक सामान्य इंजीनियरिंग आदत है। जितनी जल्दी यह प्रक्रिया का हिस्सा बनता है, उतनी ही कम वजहें होती हैं कि इसे आपातकालीन मरम्मत मोड में याद किया जाए।