बैकएंड इंटरव्यू: क्या आप ऐसे आर्काइव्स को सुरक्षित रूप से प्रोसेस करेंगे जिनमें डीकंप्रेशन बम हो सकते हैं?

प्रॉम्प्ट और संदर्भ

उपयोगकर्ता बैकग्राउंड वायरस स्कैनिंग, टेक्स्ट निष्कर्षण, या बैच आयात के लिए ZIP या TAR.GZ आर्काइव अपलोड करते हैं। कोई हमलावर एक छोटी कंप्रेस्ड फ़ाइल अपलोड कर सकता है जो बहुत बड़े पैमाने पर फैलती है, रिकर्सिव नेस्टेड आर्काइव, या ऐसी एंट्री पाथ जो टारगेट डायरेक्टरी से बाहर निकल जाती हैं। अपलोड सीमाओं, फ़ॉर्मेट पार्सिंग, रिसोर्स बजट, आइसोलेशन, विफलता स्थितियों और क्लीनअप के बारे में बताएं।

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

इंटरव्यूअर क्या जांचता है

इंटरव्यूअर कंप्रेस्ड बाइट्स और निष्कर्षण की लागत के बीच अंतर की अपेक्षा करता है। इसमें फ़ाइलें, डायरेक्टरी गहराई, नेस्टिंग, CPU, मेमोरी, डिस्क और वॉल-क्लॉक (wall-clock) बजट शामिल करें। OWASP डीकंप्रेशन के बाद के साइज़ पर विचार करने की सलाह देता है; OWASP WSTG ज़िप बम को एक ऐसे आर्काइव के रूप में वर्णित करता है जो सेवा से इनकार (denial of service) उत्पन्न करने के लिए डिस्क या मेमोरी को समाप्त कर देता है।

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

30-सेकंड का उत्तर

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

चरण-दर-चरण डिज़ाइन

चरण 1: इनपुट और टास्क सीमाएं स्थापित करें

कंप्रेस्ड साइज़, प्रति-उपयोगकर्ता समवर्तीता (concurrency), कुल कोटा और रिक्वेस्ट रेट को सीमित करें। एक टास्क ID, टेनेंट, सोर्स ऑब्जेक्ट, फ़ॉर्मेट और स्थिति असाइन करें। मूल फ़ाइल को आइसोलेटेड गैर-निष्पादन योग्य (non-executable) स्टोरेज में स्टोर करें; एक वर्कर को अल्पकालिक रीड एक्सेस मिलता है और वह कभी भी अपलोड डेटा को कोड या कॉन्फ़िगरेशन के रूप में नहीं मानता है।

चरण 2: फ़ॉर्मेट्स की पहचान करें और पार्सर चुनें

केवल एक्सटेंशन या Content-Type पर भरोसा न करें; मैजिक बाइट्स और एक अनुमति सूची (allowlist) की जांच करें। ZIP, TAR और GZIP के लिए मेंटेन की जाने वाली लाइब्रेरी चुनें और उनके वर्ज़न पिन करें। एंट्री साइज़ मेटाडेटा प्रीफ़्लाइट में मदद करता है लेकिन केवल यही एकमात्र प्राधिकारी नहीं हो सकता; पढ़ते समय बाइट्स की गिनती जारी रखें। एन्क्रिप्टेड आर्काइव, अज्ञात तरीके और विकृत (malformed) हेडर को अस्वीकार या समीक्षा की जानी चाहिए।

चरण 3: बहुआयामी (multidimensional) बजट लागू करें

कंप्रेस्ड बाइट्स, विस्तारित बाइट्स, फ़ाइल काउंट, सिंगल-फ़ाइल साइज़, डायरेक्टरी गहराई, नेस्टेड आर्काइव गहराई, CPU समय, मेमोरी, डिस्क और वॉल क्लॉक के लिए सीमाएं परिभाषित करें। प्रत्येक टास्क की एक सख्त ऊपरी सीमा (hard ceiling) होती है। कंप्रेशन अनुपात एक चेतावनी को ट्रिगर कर सकता है, लेकिन यह विस्तारित-बाइट गिनती की जगह नहीं ले सकता क्योंकि फ़ॉर्मेट और डेटा अलग-अलग तरह से कंप्रेस होते हैं।

चरण 4: पाथ और फ़ाइल सिस्टम ऑब्जेक्ट्स को सुरक्षित रखें

प्रत्येक प्रविष्टि नाम को सामान्यीकृत (normalize) करें और एब्सोल्यूट पाथ, ट्रैवर्सल और नल बाइट्स को अस्वीकार करें। टास्क के लिए विशिष्ट डायरेक्टरी में निकालें और सत्यापित करें कि प्रत्येक अंतिम पाथ इसके अंदर ही रहे। डिफ़ॉल्ट रूप से सिमलैंक्स, हार्ड लिंक्स और डिवाइस फ़ाइलों को अस्वीकार करें। ओवरराइट-ऑर्डर की समस्याओं से बचने के लिए एक डुप्लिकेट-नाम नीति परिभाषित करें, जो आमतौर पर अस्वीकृति होती है।

चरण 5: निष्कर्षण और स्कैनिंग को अलग (isolate) करें

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

चरण 6: नेस्टिंग, रिकर्शन और कैंसलेशन को सीमित करें

जब उत्पाद को उनकी आवश्यकता न हो तो नेस्टेड आर्काइव को अस्वीकार करें। यदि नेस्टिंग की आवश्यकता है, तो अधिकतम गहराई, साझा कुल बजट और प्रत्येक परत पर पाथ जांच सेट करें; रिकर्शन को नया कोटा नहीं मिलना चाहिए। टाइमआउट, कैंसलेशन, वर्कर क्रैश और टेनेंट विलोपन सभी इडेम्पोटेंट (idempotent) क्लीनअप को ट्रिगर करते हैं ताकि अस्थायी फ़ाइलें शेष न रहें।

चरण 7: पब्लिकेशन और रिकवरी के लिए स्टेट मशीन का उपयोग करें

स्थितियां uploaded, inspecting, extracting, scanning, published, rejected और cleanup_failed हो सकती हैं। प्रत्येक प्रविष्टि द्वारा जांच और स्कैनिंग पास करने के बाद ही एटॉमिक रूप से प्रकाशित करें। सुरक्षित उपयोगकर्ता स्थिति में अगला कदम शामिल हो सकता है; आंतरिक इवेंट संरचित अस्वीकृति कोड, बजट उपयोग और लाइब्रेरी त्रुटियों को बनाए रखते हैं। पुन: प्रयास करने पर बजट को छोड़ना नहीं चाहिए या दो बार प्रकाशित नहीं करना चाहिए।

चरण 8: सीमाओं का परीक्षण और निरीक्षण करें

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

समझौते (Trade-offs), सीमाएं और सूचना लाभ

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

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

मॉडल उच्च-गुणवत्ता वाला उत्तर

“मैं अपलोड और निष्कर्षण को दो विश्वास सीमाओं (trust boundaries) में विभाजित करूंगा। एज कंप्रेस्ड बाइट्स, समवर्तीता और कोटा को सीमित करता है। कम-विशेषाधिकार प्राप्त, नेटवर्क-रहित कंटेनर में एक एसिंक्रोनस वर्कर एक मेंटेन किए गए पार्सर का उपयोग करता है और केवल एक टास्क डायरेक्टरी में लिखता है। जैसे ही यह प्रत्येक प्रविष्टि को पढ़ता है, यह विस्तारित बाइट्स और फ़ाइलों की गणना करता है और सिंगल-फ़ाइल साइज़, डायरेक्टरी गहराई, नेस्टेड गहराई, CPU, मेमोरी, डिस्क और वॉल-क्लॉक बजट लागू करता है।

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

सामान्य गलतियां

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

फॉलो-अप प्रश्न और उत्तर

क्या स्कैनिंग निष्कर्षण से पहले होनी चाहिए?

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

किस कंप्रेशन अनुपात पर अस्वीकार किया जाना चाहिए?

कोई क्रॉस-फ़ॉर्मेट सार्वभौमिक संख्या नहीं है। अलर्ट या जल्दी अस्वीकृति के लिए अनुपात का उपयोग करें, जबकि सख्त सीमाएं विस्तारित बाइट्स, एक फ़ाइल, फ़ाइल काउंट, CPU, डिस्क और वॉल क्लॉक को कवर करती हैं।

नेस्टेड आर्काइव को सुरक्षित रूप से कैसे समर्थित किया जा सकता है?

एक अधिकतम गहराई सेट करें, परतों में एक कुल बजट साझा करें, पाथ और लिंक जांच दोहराएं, और रिकर्शन को उसी वर्कर के समय और डिस्क कोटा के भीतर रखें।

क्या पार्सर द्वारा रिपोर्ट किए गए प्रविष्टि आकारों पर भरोसा किया जा सकता है?

वे चेतावनी संकेत हैं, प्राधिकरण नहीं। पढ़ते समय बाइट्स की गिनती जारी रखें और Zip64, विकृत हेडर, डेटा डिस्क्रिप्टर और ज्ञात लाइब्रेरी सीमाओं का ध्यान रखें।

क्या सीमा से अधिक टास्क का पुन: प्रयास किया जाना चाहिए?

बजट का उल्लंघन एक नियतात्मक (deterministic) अस्वीकृति है और इसका आँख मूंदकर पुन: प्रयास नहीं किया जाना चाहिए। केवल क्षणिक वर्कर विफलताओं का पुन: प्रयास करें, उसी बजट और इडेम्पोटेंट स्थिति के साथ एक नई आइसोलेटेड डायरेक्टरी बनाएं।