बैकएंड इंटरव्यू: आप एक सुरक्षित फ़ाइल अपलोड API कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और लागू होने वाले परिदृश्य

एक मल्टी-टेनेंट B2B दस्तावेज़ सेवा प्रमाणित उपयोगकर्ताओं को PDF, JPEG और PNG अटैचमेंट अपलोड करने की अनुमति देती है, जिसमें प्रति फ़ाइल 20 MiB की सीमा होती है। प्रोसेसिंग के बाद, केवल उसी टेनेंट के अधिकृत सदस्य ही फ़ाइल डाउनलोड कर सकते हैं। क्लाइंट बाइट्स, मूल फ़ाइल नाम, एक्सटेंशन, Content-Type और घोषित आकार को नियंत्रित करता है, इसलिए इनमें से प्रत्येक मान अविश्वसनीय (untrusted) है।

सुरक्षित अपलोड, स्कैनिंग, पब्लिशिंग और डाउनलोड API डिज़ाइन करें। समझाएं कि यह डिज़ाइन निम्नलिखित को कैसे रोकता है:

• वेब शेल्स, स्पूफ़ किए गए प्रकार, डबल एक्सटेंशन, पाथ ट्रैवर्सल और ऑब्जेक्ट ओवरराइट;
• दुर्भावनापूर्ण PDF, इमेज-पार्सर कारनामों (exploits), मैलवेयर और पॉलीग्लॉट फ़ाइलें;
• क्रॉस-टेनेंट एक्सेस, लीक हुए सार्वजनिक ऑब्जेक्ट URL और खतरनाक इनलाइन रेंडरिंग;
• अत्यधिक बड़े अनुरोध (oversized requests), समाप्त हो चुके स्टोरेज कोटे, स्कैन विवाद (contention) और स्कैनर आउटेज;
• स्कैन पास करने के बाद फ़ाइल का बदला जाना, साथ ही डुप्लिकेट पूर्णता (completion) कॉल्स से स्थिति का दूषित होना।

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

इंटरव्यूअर क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार इनवेरिएंट्स (invariants) स्थापित कर सकता है? वे बाइट्स जिन्होंने सुरक्षा निर्णय पास नहीं किया है, क्वारंटीन में रहती हैं और व्यावसायिक उपयोगकर्ताओं द्वारा पढ़ी नहीं जा सकतीं, एप्लिकेशन द्वारा पार्स नहीं की जा सकतीं, या एप्लिकेशन के प्राथमिक ऑरिजिन से प्रस्तुत नहीं की जा सकतीं। क्लाइंट फ़ाइल नाम कभी भी स्टोरेज पाथ नहीं बनता है। प्रत्येक रीड को फिर से अधिकृत किया जाता है।

दूसरा, क्या वे टाइप वैलिडेशन के लिए डिफेंस इन डेप्थ (गहन रक्षा) को समझते हैं? एक एक्सटेंशन, अनुरोध Content-Type, फ़ाइल सिग्नेचर और पार्सर परिणाम प्रत्येक केवल आंशिक साक्ष्य प्रदान करते हैं। सेवा को एक व्यावसायिक अनुमति सूची (allowlist), सामान्यीकरण (normalization), संरचनात्मक पार्सिंग, मैलवेयर स्कैनिंग और जहां उपयुक्त हो, पुनः एन्कोडिंग या कंटेंट डिसआर्म और पुनर्निर्माण को जोड़ना चाहिए।

तीसरा, क्या वे एक स्पष्ट एसिंक्रोनस स्टेट मशीन डिज़ाइन कर सकते हैं? बाइट्स प्राप्त करने का केवल यह अर्थ है कि एक ऑब्जेक्ट क्वारंटीन तक पहुँच गया है। इसका मतलब यह नहीं है कि फ़ाइल उपलब्ध है। API को सटीक पुनः प्रयास (retry), टाइमआउट और क्लीनअप नियमों के साथ प्रोसेसिंग, उपलब्ध, अस्वीकृत और तकनीकी-विफलता स्थितियों की आवश्यकता होती है।

चौथा, क्या वे स्कैनिंग रेस (scanning race) को पकड़ते हैं? एक स्कैनर बाइट्स के एक विशिष्ट अनुक्रम का न्याय करता है। यदि उसी ऑब्जेक्ट कुंजी को बाद में ओवरराइट किया जा सकता है, तो एक AVAILABLE रिकॉर्ड उस सामग्री की ओर इशारा कर सकता है जिसे कभी स्कैन नहीं किया गया था। निर्णय को एक अपरिवर्तनीय (immutable) ऑब्जेक्ट संस्करण या सामग्री हैश से बांधना चाहिए, और पब्लिशिंग सशर्त होनी चाहिए।

पांचवां, क्या वे थ्रेट मॉडल में पुनर्प्राप्ति (retrieval) को शामिल करते हैं? एक रैंडम कुंजी अनुमान लगाने की क्षमता को कम करती है लेकिन टेनेंट और ऑब्जेक्ट प्राधिकरण को प्रतिस्थापित नहीं करती है। डाउनलोड के लिए एक नियंत्रित हैंडलर या अल्पकालिक हस्ताक्षरित URL (short-lived signed URL), सुरक्षित प्रतिक्रिया हेडर, एक अलग ऑरिजिन और एक जानबूझकर बनाई गई कैशिंग नीति की आवश्यकता होती है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• फ़ाइल का उपयोग कैसे किया जाएगा? केवल-डाउनलोड, ब्राउज़र पूर्वावलोकन, टेक्स्ट निष्कर्षण, थंबनेल निर्माण और तृतीय-पक्ष प्रोसेसिंग के अलग-अलग जोखिम हैं। प्रत्येक अतिरिक्त पार्सर एक अटैक सर्फेस जोड़ता है।
• क्या तीन प्रारूप पर्याप्त हैं? यह परिदृश्य ZIP, Office और अन्य सभी प्रारूपों को अस्वीकार कर सकता है। अभिलेखागार (archives) का समर्थन करने के लिए गहराई, सदस्य संख्या, विस्तारित आकार और संपीड़न अनुपात पर सीमाओं की आवश्यकता होगी।
• उपयोगकर्ता कैसे प्रमाणित होता है? कुकी प्रमाणीकरण CSRF नियंत्रण पेश करता है। एक बियरर टोकन को अभी भी सही CORS, स्कोप और लीकेज नियंत्रण की आवश्यकता होती है।
• क्या डायरेक्ट-टू-ऑब्जेक्ट-स्टोरेज अपलोड आवश्यक है? एक API छोटी फ़ाइलों को स्ट्रीम कर सकता है। उच्च समवर्तीता (concurrency) पर, यह एक क्वारंटीन ऑब्जेक्ट के लिए स्कोप किया गया अल्पकालिक क्रेडेंशियल जारी कर सकता है और अपलोड के बाद वास्तविक ऑब्जेक्ट को सत्यापित कर सकता है।
• कौन अपलोड, स्थिति का निरीक्षण, डाउनलोड और हटा सकता है? टेनेंट भूमिकाओं, ऑब्जेक्ट स्वामित्व और ऑडिट आवश्यकताओं को अलग से परिभाषित करें; केवल यह जांचना पर्याप्त नहीं है कि उपयोगकर्ता लॉग इन है।
• स्कैनिंग SLA क्या है? प्रतीक्षा समय, पुनः प्रयास गणना, विफल-बंद (fail-closed) व्यवहार और आउटेज के दौरान उपयोगकर्ता को दिखाई गई स्थिति को परिभाषित करें।
• क्या अनुपालन या निवास (residency) आवश्यकताएं हैं? एन्क्रिप्शन कुंजियाँ, प्रतिधारण (retention), ऑडिट रिकॉर्ड, विलोपन और बैकअप क्लीनअप बाधित हो सकते हैं।
• सफलता क्या मानी जाती है? संग्रहीत बाइट्स, पास हुआ स्कैन और अधिकृत डाउनलोड तीन मील के पत्थर हैं जो अलग-अलग API सिमेंटिक्स के हकदार हैं।

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

\"मैं तीन इनवेरिएंट्स के साथ शुरुआत करूंगा: एक अनस्कैन की गई फ़ाइल केवल क्वारंटीन में मौजूद होती है; सर्वर स्टोरेज कुंजी उत्पन्न करता है जबकि मूल फ़ाइल नाम प्रतिबंधित मेटाडेटा रहता है; और प्रत्येक डाउनलोड टेनेंट और ऑब्जेक्ट प्राधिकरण करता है। लाइफ़साइकिल PENDING_UPLOAD → QUARANTINED → SCANNING → AVAILABLE/REJECTED/FAILED है।

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

डाउनलोड के लिए, सेवा टेनेंट और ऑब्जेक्ट अनुमति की पुन: जांच करती है, फिर एक अल्पकालिक हस्ताक्षरित URL लौटाती है या Content-Disposition: attachment, एक सटीक सुरक्षित प्रकार और X-Content-Type-Options: nosniff के साथ ऑब्जेक्ट को स्ट्रीम करती है। स्कैनर की विफलता ऑब्जेक्ट को अनुपलब्ध छोड़ देती है और सीमित पुनः प्रयासों को ट्रिगर करती है। कोटा, दर सीमाएं, समवर्तीता, टाइमआउट और लाइफ़साइकिल क्लीनअप संसाधनों को सीमित करते हैं। मैं टाइप स्पूफ़िंग, शत्रुतापूर्ण फ़ाइल नामों, एक परीक्षण मैलवेयर नमूने, अत्यधिक बड़े स्ट्रीम, डुप्लिकेट पूर्णता, ऑब्जेक्ट प्रतिस्थापन और क्रॉस-टेनेंट एक्सेस के साथ डिज़ाइन को मान्य करूंगा।\"

चरण-दर-चरण गहन विश्लेषण

चरण 1: विश्वास सीमा और सुरक्षा इनवेरिएंट्स को परिभाषित करें

क्लाइंट प्रत्येक मल्टीपार्ट बाइट, फ़ाइल नाम, Content-Type, घोषित आकार और अनुरोध अनुक्रम को नियंत्रित करता है। API गेटवे, एप्लिकेशन सेवाएं, ऑब्जेक्ट-स्टोर इवेंट और स्कैन कतारें भी काम को डुप्लिकेट, विलंबित या पुन: व्यवस्थित कर सकती हैं। इन इनवेरिएंट्स के इर्द-गिर्द डिज़ाइन का निर्माण करें:

1. एक क्वारंटीन ऑब्जेक्ट के पास कोई सार्वजनिक रीड एक्सेस नहीं होती है और इसे वेब सर्वर द्वारा निष्पादित नहीं किया जा सकता है।
2. केवल एक अधिकृत AVAILABLE ऑब्जेक्ट डाउनलोड किया जा सकता है।
3. व्यावसायिक रिकॉर्ड का tenant_id प्रमाणित संदर्भ से आता है, न कि स्वतंत्र रूप से आपूर्ति किए गए अनुरोध फ़ील्ड से।
4. मूल फ़ाइल नाम कभी भी पाथ निर्माण या ऑब्जेक्ट लुकअप में भाग नहीं लेता है।
5. एक सुरक्षा निर्णय अपरिवर्तनीय बाइट्स से बंधता है; पब्लिशिंग उस निर्णय को दूसरे संस्करण में स्थानांतरित नहीं कर सकती है।
6. एक अपवाद, टाइमआउट, या अनिश्चित परिणाम हमेशा विफल-बंद (fail-closed) होता है।

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

चरण 2: एक स्टेट मशीन के साथ उपलब्धता से रसीद को अलग करें

एक न्यूनतम स्टेट मशीन है:

PENDING_UPLOAD
  ├─ bytes verified ─> QUARANTINED ─> SCANNING
  │                                      ├─ safe ─> AVAILABLE
  │                                      ├─ malicious/invalid ─> REJECTED
  │                                      └─ scanner unavailable ─> FAILED
  └─ expired/abandoned ─> EXPIRED

POST /uploads एक सत्र बनाता है और एक upload_id लौटाता है। डायरेक्ट अपलोड के लिए, यह एक अल्पकालिक क्रेडेंशियल भी लौटाता है जो केवल निर्दिष्ट क्वारंटीन ऑब्जेक्ट को लिख सकता है। POST /uploads/{id}/complete विश्वसनीय सत्यापन और स्कैनिंग को ट्रिगर करता है, इसलिए 202 Accepted उपयुक्त है। GET /uploads/{id} स्थिति की रिपोर्ट करता है। डाउनलोड एंट्री पॉइंट केवल AVAILABLE के लिए दिखाई देता है।

प्रत्येक संक्रमण (transition) एक डेटाबेस शर्त का उपयोग करता है। उदाहरण के लिए, केवल वर्तमान में QUARANTINED में मौजूद रिकॉर्ड ही SCANNING में प्रवेश कर सकता है। इसलिए एक डुप्लिकेट कतार वितरण या बार-बार कॉल किया गया कम्प्लीट कॉल एक ही संक्रमण को अधिकतम एक बार लागू करता है। FAILED का अर्थ है तकनीकी प्रसंस्करण विफलता; REJECTED का अर्थ है कि फ़ाइल या नीति अमान्य थी। उन्हें एक अस्पष्ट त्रुटि में संयोजित करने से पुनर्प्राप्ति और ऑडिटेबिलिटी कमजोर होती है।

चरण 3: बाइट्स को सुरक्षित रूप से प्राप्त करें और संसाधनों को सीमित करें

सत्र निर्माण के समय, अपलोड अनुमति, शेष टेनेंट कोटा, उपयोगकर्ता दर और अनुरोधित व्यावसायिक प्रारूप की जांच करें। एक यादृच्छिक upload_id और ऑब्जेक्ट कुंजी जैसे कि quarantine/{tenant-id}/{uuid} उत्पन्न करें। लंबाई, नियंत्रण वर्णों और यूनिकोड के लिए मूल फ़ाइल नाम को सामान्यीकृत करें, फिर इसे केवल प्रदर्शन मेटाडेटा के रूप में बनाए रखें।

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

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

चरण 4: टाइप वैलिडेशन, पार्सिंग और दुर्भावनापूर्ण-सामग्री स्कैनिंग को संयोजित करें

जांच सस्ते से लेकर महंगे तक चल सकती है, लेकिन कोई भी एकल परत AVAILABLE उत्पन्न नहीं कर सकती है:

1. सामान्यीकृत एक्सटेंशन पर PDF, JPEG और PNG अनुमति सूची लागू करें।
2. क्लाइंट Content-Type को एक संकेत के रूप में मानें। स्पष्ट बेमेल को अस्वीकार करें, लेकिन इसे कभी भी प्रमाण के रूप में उपयोग न करें।
3. सिग्नेचर और पूरी संरचना का निरीक्षण करें ताकि एक मान्य मैजिक प्रीफ़िक्स ही पर्याप्त न हो।
4. यह पुष्टि करने के लिए एक अद्यतन, विवश पार्सर का उपयोग करें कि पूरी फ़ाइल को पार्स किया जा सकता है।
5. एक अलग वर्कर में मैलवेयर स्कैनिंग चलाएं और इंजन और नियमों के संस्करण रिकॉर्ड करें।
6. डिकोड की गई छवियों को पुनः एन्कोड करें, और जब जोखिम मॉडल इसे उचित ठहराता है तो PDF के लिए कंटेंट डिसआर्म और पुनर्निर्माण पर विचार करें।

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

चरण 5: पब्लिश करने से पहले निर्णय को अपरिवर्तनीय बाइट्स से बांधें

स्कैन कार्य एक अपरिवर्तनीय क्वारंटीन version_id को पढ़ता है और SHA-256 की गणना करता है। इसके परिणाम में कम से कम upload_id, ऑब्जेक्ट संस्करण, हैश, वास्तविक आकार, पता चला प्रकार, स्कैनिंग इंजन संस्करण और निर्णय शामिल हैं।

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

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

चरण 6: डाउनलोड को अधिकृत करें और ब्राउज़र व्याख्या को नियंत्रित करें

GET /files/{id}/download प्रमाणीकरण से वर्तमान टेनेंट प्राप्त करता है, फिर ऑब्जेक्ट स्वामित्व, भूमिका, विलोपन स्थिति और AVAILABLE स्थिति की जांच करता है। एक UUID इनमें से किसी भी जांच को नहीं हटाता है। प्राधिकरण के बाद, एप्लिकेशन ऑब्जेक्ट को स्ट्रीम कर सकता है या एक ऑब्जेक्ट और ऑपरेशन से बंधा एक अल्पकालिक हस्ताक्षरित URL जारी कर सकता है।

जिन अटैचमेंटों को पूर्वावलोकन की आवश्यकता नहीं है, उनके लिए Content-Disposition: attachment, एक सुरक्षित रूप से एन्कोड किया गया प्रदर्शन फ़ाइल नाम, सर्वर-पुष्ट मीडिया प्रकार और X-Content-Type-Options: nosniff लौटाएं। मुख्य एप्लिकेशन के कुकी डोमेन से फ़ाइल ऑरिजिन को अलग करने से सक्रिय सामग्री द्वारा प्राथमिक सत्र को प्रभावित करने की संभावना कम हो जाती है। हस्ताक्षरित URL को अल्पकालिक रखें क्योंकि उपयोगकर्ता की अनुमति बदलने से आमतौर पर पहले से जारी किया गया URL तुरंत रद्द नहीं होता है।

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

चरण 7: विफलता, आइडम्पोटेंसी, कोटा और अवलोकनीयता डिज़ाइन करें

जब स्कैनिंग का समय समाप्त हो जाता है या वह अनुपलब्ध होती है, तो फ़ाइल अनुपलब्ध रहती है। एक वर्कर बैकऑफ़ के साथ सीमित संख्या में पुन: प्रयास कर सकता है। समाप्त हो चुके पुन: प्रयास नियंत्रित मैन्युअल या स्वचालित पुनर्प्राप्ति के लिए FAILED में प्रवेश करते हैं। एक निश्चित दुर्भावनापूर्ण या संरचनात्मक रूप से अमान्य परिणाम REJECTED में प्रवेश करता है, और क्वारंटीन बाइट्स प्रतिधारण नीति के अनुसार हटा दिए जाते हैं।

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

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

चरण 8: एक प्रतिकूल मैट्रिक्स (adversarial matrix) के साथ पूरे पाथ को मान्य करें

कम से कम, परीक्षण करें:

1. .jpg.php, मिश्रित केस, नल बाइट्स और अत्यधिक बड़े यूनिकोड फ़ाइल नाम;
2. स्पूफ़ किया गया Content-Type, एक शत्रुतापूर्ण पूंछ के साथ एक मान्य उपसर्ग, विकृत PDF और पॉलीग्लॉट फ़ाइलें;
3. एक सुरक्षित वातावरण में EICAR परीक्षण फ़ाइल, साथ ही ऐसे नमूने जो पार्सर टाइमआउट या संसाधन सीमाओं को हिट करते हैं;
4. ठीक 20 MiB, एक बाइट अधिक, अनुपलब्ध लंबाई, धीमी धाराएं (slow streams) और कई समवर्ती अपलोड;
5. वही आइडम्पोटेंसी कुंजी, समवर्ती कम्प्लीट कॉल्स, डुप्लिकेट कतार संदेश और बासी स्कैन परिणाम;
6. स्कैनिंग के दौरान ऑब्जेक्ट प्रतिस्थापन का प्रयास, यह साबित करते हुए कि एक संस्करण या हैश बेमेल पब्लिश नहीं हो सकता है;
7. किसी अन्य टेनेंट द्वारा स्थिति पढ़ना, डाउनलोड करना या ऑब्जेक्ट को हटाना, जिसमें प्रत्येक अनुरोध अस्वीकार कर दिया गया हो;
8. स्कैनर आउटेज, जॉब टाइमआउट, एप्लिकेशन रीस्टार्ट और अनाथ क्लीनअप;
9. अटैचमेंट, मीडिया प्रकार, nosniff, कैशिंग और हस्ताक्षरित-URL समाप्ति के लिए डाउनलोड व्यवहार।

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

मजबूत नमूना उत्तर

\"मैं अपलोड को क्वारंटीन, निर्णय और पब्लिशिंग चरणों में विभाजित करूंगा, इस इनवेरिएंट के साथ कि व्यावसायिक उपयोगकर्ता कभी भी उन बाइट्स को नहीं पढ़ सकते हैं जिन्होंने निर्णय पास नहीं किया है। सत्र बनाते समय, मैं प्रमाणीकरण से tenant_id प्राप्त करता हूं, भूमिका, 20 MiB सीमा, टेनेंट कोटा और PDF/JPEG/PNG अनुमति सूची की जांच करता हूं, और एक यादृच्छिक, गैर-ओवरराइट करने योग्य क्वारंटीन कुंजी उत्पन्न करता हूं। मूल फ़ाइल नाम लंबाई-सीमित, सामान्यीकृत प्रदर्शन मेटाडेटा बना रहता है।

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

स्कैनर एक अपरिवर्तनीय संस्करण पढ़ता है और SHA-256 की गणना करता है। एक रिकॉर्ड केवल तभी AVAILABLE बन सकता है जब वह अभी भी SCANNING हो और संस्करण और हैश दोनों स्कैन इनपुट से मेल खाते हों। इसलिए स्कैन के बाद किसी सुरक्षित फ़ाइल को बदलने से पुराने निर्णय का पुन: उपयोग नहीं किया जा सकता है। एक स्कैनर आउटेज सीमित पुनः प्रयासों के साथ विफल-बंद होता है; निश्चित दुर्भावनापूर्ण या गैर-अनुरूप सामग्री REJECTED बन जाती है।

प्रत्येक डाउनलोड स्ट्रीमिंग या अल्पकालिक URL जारी करने से पहले टेनेंट, ऑब्जेक्ट अनुमति और AVAILABLE स्थिति की जांच करता है। अटैचमेंट एक अलग ऑरिजिन, Content-Disposition: attachment और X-Content-Type-Options: nosniff का उपयोग करते हैं। फिर मैं स्थिति अवधि, क्वारंटीन बाइट्स, कतार आयु और स्कैनर संस्करण की निगरानी करते हुए टाइप स्पूफ़िंग, EICAR, अत्यधिक बड़े स्ट्रीम, डुप्लिकेट पूर्णता, ऑब्जेक्ट-प्रतिस्थापन रेस, क्रॉस-टेनेंट रीड और स्कैनर आउटेज का परीक्षण करूंगा।\"

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

• केवल एक्सटेंशन की जांच करना → डबल एक्सटेंशन, केस परिवर्तन और प्रच्छन्न सामग्री इसे बायपास कर देते हैं → एक व्यावसायिक अनुमति सूची, सामान्यीकरण, सिग्नेचर, संरचनात्मक पार्सिंग और स्कैनिंग को संयोजित करें।
• Content-Type पर भरोसा करना → क्लाइंट अनुरोध हेडर चुन सकता है → इसका उपयोग केवल प्रारंभिक फ़िल्टरिंग के लिए करें और सर्वर पर अंतिम प्रकार का पता लगाएं।
• मूल फ़ाइल नाम को पाथ के रूप में उपयोग करना → पाथ ट्रैवर्सल, ओवरराइट और फ़ाइलसिस्टम-सामान्यीकरण बग संभव हो जाते हैं → एक यादृच्छिक ऑब्जेक्ट कुंजी उत्पन्न करें और नाम को केवल प्रतिबंधित मेटाडेटा के रूप में बनाए रखें।
• संग्रहीत बाइट्स को तुरंत डाउनलोड करने योग्य बनाना → स्कैनिंग समाप्त होने से पहले दुर्भावनापूर्ण बाइट्स उजागर हो जाते हैं → क्वारंटीन का उपयोग करें और AVAILABLE को एकमात्र पब्लिशिंग शर्त बनाएं।
• यह दावा करना कि एंटीवायरस पास सुरक्षा की गारंटी देता है → नए नमूने, पार्सर बग और सक्रिय सामग्री अभी भी संभव हैं → अलगाव, न्यूनतम पार्सिंग, सुरक्षित हेडर और प्राधिकरण बनाए रखें।
• ओवरराइट करने योग्य कुंजी को स्कैन करना → एक पासिंग परिणाम बाद में प्रतिस्थापन बाइट्स पर लागू हो सकता है → एक अपरिवर्तनीय संस्करण या सामग्री हैश को बांधें और सशर्त रूप से पब्लिश करें।
• UUID को प्राधिकरण के रूप में मानना → एक लीक हुई ऑब्जेक्ट ID क्रॉस-टेनेंट रीड को सक्षम कर सकती है → स्थिति, डाउनलोड और विलोपन के लिए ऑब्जेक्ट प्राधिकरण निष्पादित करें।
• डायरेक्ट अपलोड के बाद क्लाइंट पूर्णता पर भरोसा करना → क्लाइंट आकार, प्रकार या स्वामित्व के बारे में झूठ बोल सकता है → सर्वर पर विश्वसनीय ऑब्जेक्ट मेटाडेटा और बाइट साक्ष्य पढ़ें।
• स्कैनर आउटेज के दौरान विफल-खुला (fail-open) होना → एक बुनियादी ढांचा विफलता एक सुरक्षा बाईपास बन जाती है → विफल-बंद (fail-closed) हों, सीमाओं के भीतर पुनः प्रयास करें, और एक सटीक प्रसंस्करण स्थिति उजागर करें।
• केवल प्रति-फ़ाइल आकार को सीमित करना → कई व्यक्तिगत रूप से मान्य फ़ाइलें स्टोरेज और स्कैनिंग को समाप्त कर सकती हैं → टेनेंट कोटा, दरें, समवर्तीता और कतार बैकप्रेशर लागू करें।
• प्राथमिक ऑरिजिन पर मनमानी फ़ाइलों को इनलाइन रेंडर करना → ब्राउज़र व्याख्या और सक्रिय सामग्री मुख्य सत्र को प्रभावित कर सकती है → डिफ़ॉल्ट रूप से अटैचमेंट डाउनलोड करें और फ़ाइल ऑरिजिन को अलग करें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: जब आप पहले से ही मैजिक बाइट्स की जांच करते हैं तो पूरी संरचना को पार्स क्यों करें?

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

अनुवर्ती 2: क्या डायरेक्ट-टू-ऑब्जेक्ट-स्टोरेज अपलोड बैकएंड सुरक्षा को बायपास करता है?

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

अनुवर्ती 3: स्कैनर आउटेज के दौरान उपयोगकर्ता का अनुभव क्या होना चाहिए?

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

अनुवर्ती 4: डाउनलोड को अभी भी attachment और nosniff की आवश्यकता क्यों है?

प्राधिकरण तय करता है कि बाइट्स किसे प्राप्त हों। प्रतिक्रिया हेडर प्रभावित करते हैं कि ब्राउज़र उनकी व्याख्या कैसे करता है। attachment डाउनलोड का पक्ष लेता है, और nosniff ब्राउज़र को सामग्री सूँघने (content sniffing) के माध्यम से सर्वर-घोषित प्रकार को ओवरराइड करने से रोकता है। एक अलग फ़ाइल ऑरिजिन सक्रिय सामग्री की मुख्य एप्लिकेशन के कुकीज़ और स्क्रिप्ट संदर्भ तक पहुंच को और सीमित करता है।

अनुवर्ती 5: यदि ZIP की अनुमति है तो कौन से नियंत्रण आवश्यक हो जाते हैं?

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

अनुवर्ती 6: आप कैसे साबित करते हैं कि किसी रेस ने निर्णय को दूषित नहीं किया?

स्कैन कार्य में अपरिवर्तनीय इनपुट संस्करण और SHA-256 रिकॉर्ड करें। पब्लिशिंग एक सशर्त डेटाबेस अपडेट का उपयोग करती है जिसके लिए वर्तमान रिकॉर्ड को ठीक उसी संस्करण और हैश के साथ SCANNING बने रहने की आवश्यकता होती है। एक परीक्षण स्कैनिंग के दौरान लॉजिकल ऑब्जेक्ट को ओवरराइट करता है और एक पुराना परिणाम देता है; पब्लिशिंग विफल होनी चाहिए। ऑडिट इवेंट इनपुट संस्करण, निर्णय और अंतिम स्वीकृत ऑब्जेक्ट को जोड़ते हैं।