फाइल अपलोड सुरक्षा: आपत्ती विरुद्ध गंभीर संरक्षण

फाईल सुरक्षा थेट अपलोड करा ऍप्लिकेशन सर्व्हरवर सिस्टमला सेवा नाकारण्याचे हल्ले, दुर्भावनापूर्ण सामग्री, पार्सर असुरक्षा, स्टोरेजचा गैरवापर आणि अनधिकृत फाइल ऍक्सेस यांचा पर्दाफाश करू शकतो. तरीही संघ सहसा या जोखमींना सामान्य फॉर्म फील्डप्रमाणे हाताळतात.

हा अचूक निर्णय पुढील आपत्तीजनक आठवड्याची हमी देतो. वास्तविक उत्पादन वातावरण प्रतिकूल स्क्रिप्ट्स, दुर्भावनापूर्ण बॉट्स आणि बर्प सूट चालवणाऱ्या कंटाळलेल्या हॅकर्सने भरलेले आहे. येणाऱ्या फायलींबद्दल केलेली प्रत्येक धारणा कठोरपणे चाचणी होईपर्यंत पूर्णपणे खोटी राहते.

कचऱ्याचा ढीग: स्थानिक डिस्क्स आणि डेटाबेस ब्लॉब्स तुमचे उत्पादन वातावरण का भंग करतील

स्थानिक डिस्क स्टोरेजचे पाप

स्थानिक डिस्क्स लाइट फ्यूजसह आर्किटेक्चरल टाइम बॉम्ब म्हणून कार्य करतात. डेव्हलपमेंट एनवायरमेंटवर चालणारी सिंगल मशीन्स हा दृष्टिकोन चांगल्या प्रकारे हाताळतात, परंतु उत्पादन रहदारी लगेचच सर्वकाही खंडित करते.

लोड बॅलन्सर दुय्यम उदाहरणे फिरवतात, ज्यामुळे तुमचे अर्धे वापरकर्ते निराशाजनक 404 त्रुटींकडे लक्ष देत असतात कारण त्यांचे अवतार पूर्णपणे वेगळ्या सर्व्हरवर अडकलेले असतात.

BLOB डेटाबेस भ्रम

कुठेतरी, कोणीतरी नेहमी PostgreSQL किंवा MySQL सारख्या रिलेशनल डेटाबेसमध्ये कच्चा बायनरी डेटा संचयित करण्याची “मोठ्या मेंदूची” कल्पना मांडतो. हे नीटनेटके वाटते: सत्याचा एक स्रोत, एक बॅकअप काम, पूर्ण झाले; तथापि, प्रत्यक्षात, ती एक आपत्ती आहे.

प्रत्येक BLOB स्तंभ तुमचे बॅकअप बहु-तास क्रॉलमध्ये फुलवतो, तुमचा क्वेरी प्लॅनर कधीही हाताळण्यासाठी डिझाइन केलेला नसलेल्या डेटासह इंडेक्स मेमरी चोक करतो आणि नियमित स्कीमा स्थलांतराला सेवा आउटेजमध्ये बदलतो ज्यामुळे स्वतःचा घटना अहवाल मिळतो.

तुमचा डेटाबेस संरचित डेटासाठी आहे, 40MB व्हिडिओ फाइल होस्ट करण्यासाठी नाही कारण ते सोयीस्कर वाटले.

द ओन्ली सेन वे ऑब्जेक्ट स्टोरेज आणि नियुक्त URL

उद्योग मानक एका कारणासाठी अस्तित्वात आहे: समर्पित ऑब्जेक्ट स्टोरेज जसे की AWS S3, Cloudflare R2, किंवा Google Cloud Storage.

या प्रणाल्या मोठ्या प्रमाणावर अनियंत्रित बायनरी ब्लॉब्स संचयित करण्यासाठी आणि सर्व्ह करण्यासाठी उद्देशाने तयार केल्या आहेत आणि फाइल सर्व्हरच्या ताफ्यासाठी तुम्ही जेवढे खर्च कराल त्याच्या काही अंश त्यांची किंमत आहे. वास्तविक अनलॉक, तथापि, नियुक्त URL आहेत.

तुमच्या ॲप्लिकेशन सर्व्हरद्वारे प्रत्येक अपलोड रूट करण्याऐवजी, गौरवशाली मध्यस्थ म्हणून काम करणारी CPU सायकल बर्न करण्याऐवजी, तुम्ही एक अल्पायुषी, स्वाक्षरी केलेली URL व्युत्पन्न करा आणि क्लायंटला थेट बकेटवर अपलोड करू द्या. तुमच्या बॅकएंडचे एकमेव काम ते URL जारी करणे आणि नंतर निकाल सत्यापित करणे आहे.

झिरो ट्रस्ट आर्किटेक्चर: तुम्ही प्रत्येक अपलोडला थ्रेट ॲक्टरप्रमाणे का हाताळले पाहिजे

फाइल विस्तार खोटे आहेत

फाईलचे नाव .jpg ने संपते की नाही हे तपासणे तुम्हाला त्यामध्ये काय आहे याबद्दल काहीही सांगत नाही. malware.exe चे नाव बदलून profile_picture.png करण्यासाठी चार सेकंद लागतात, आणि एक साधा विस्तार तपासणी हसतमुखाने ते हलवेल.

रिअल व्हॅलिडेशन म्हणजे फाइलच्या बायनरी बफरचे मॅजिक नंबरचे प्रारंभिक बाइट्स वाचणे जे त्याचे खरे स्वरूप ओळखतात, फाईल नावाचा दावा काहीही असो.

अस्सल PNG नेहमी हेक्स स्वाक्षरी 89 50 4E 47 ने सुरू होते. बाकी कोणतीही गोष्ट PNG नसते.

सॅनिटायझेशन आणि भयानक डिरेक्टरी ट्रॅव्हर्सल

वापरकर्त्याने तुम्हाला पाठवलेल्या मूळ फाइल नावावर कधीही विश्वास ठेवू नका.

../../etc/passwd सारखी स्ट्रिंग किंवा अस्पष्ट स्क्रिप्ट टॅगने पॅक केलेले फाइलनाव सार्वजनिक अपलोड एंडपॉइंट चालवणाऱ्या प्रत्येकासाठी आणखी एक मंगळवार आहे.

नियम निरपेक्ष आहे: मूळ फाइलनाव पूर्णपणे काढून टाका, ते पुनर्स्थित करण्यासाठी एक यादृच्छिक UUIDv4 व्युत्पन्न करा आणि फाइलच्या वास्तविक सामग्रीद्वारे तुम्ही स्वतंत्रपणे सत्यापित केलेला एक्स्टेंशन जोडा. वापरकर्त्याने निवडलेले नाव तुमच्या स्टोरेज मार्गाला कधीही स्पर्श करत नाही.

झिप बॉम्ब आणि पिक्सेल पूर

मग तुम्हाला दुखापत करण्यासाठी पूर्णपणे डिझाइन केलेले पेलोड आहेत. एक झिप बॉम्ब डिस्कवर फक्त 42KB असू शकतो परंतु एकदा डिकंप्रेस केल्यावर पेटाबाइट्समध्ये विस्तारित होतो, कोणत्याही सर्व्हरला मर्यादा न ठेवता अनझिप करण्याचा प्रयत्न करणारा सर्व्हर त्वरित गोठवतो. पिक्सेल फ्लड इमेज प्रोसेसरवर तशाच प्रकारे कार्य करतात: एक लहान फाईल आकार 50,000 बाय 50,000 पिक्सेल सारखी अतर्क्य परिमाणे लपवू शकते, जी तुमची इमेज लायब्ररी ज्या क्षणी डीकोड केलेल्या बिटमॅपसाठी मेमरी वाटप करण्याचा प्रयत्न करते आणि आउट-ऑफ-मेमरी त्रुटी येते तेव्हा क्रॅश करते. दोन्ही हल्ले एकाच अंध स्थानाचे शोषण करतात: फाइल प्रत्यक्षात वापरत असलेल्या संसाधनांसाठी प्रॉक्सी म्हणून फाइल आकारावर विश्वास ठेवणे.

EXIF डेटा डॉक्सिंग

कच्च्या स्मार्टफोन फोटोंमध्ये पिक्सेलपेक्षा जास्त फोटो असतात. एम्बेडेड EXIF ​​मेटाडेटामध्ये नियमितपणे अचूक GPS निर्देशांक, डिव्हाइस मॉडेल आणि कॅमेरा अनुक्रमांक माहिती समाविष्ट असते ज्या वापरकर्त्यांना कधीही प्रसारित करण्याचा हेतू नसतो.

स्टोरेजपूर्वी तुमचा बॅकएंड सक्रियपणे हा मेटाडेटा काढून टाकत नसल्यास, तुम्ही एकावेळी तुमचा स्वतःचा वापरकर्ता आधार एक प्रोफाइल चित्र डॉक्स करत आहात.

फाइल अपलोड सुरक्षा: नेटवर्क एज गार्डरेल्स आणि दर मर्यादा लागू करणे

कार्यप्रदर्शन आणि प्रवाह – तुमचा इव्हेंट लूप चोकिंग थांबवा

मेमरी बफर वि. प्रवाह

1. संपूर्ण अपलोड केलेली फाइल थेट सर्व्हर RAM मध्ये वाचणे — fs.readFileSync किंवा समतुल्य बफरद्वारे — समवर्ती रहदारीची वाट पाहणारी लँडमाइन आहे.
2. मूठभर एकाचवेळी मोठे अपलोड तुमच्या कंटेनरची मेमरी मर्यादा ओलांडतील आणि OS चेतावणीशिवाय तुमची अर्ज प्रक्रिया नष्ट करून प्रतिसाद देईल.
3. असिंक्रोनस स्ट्रीम्स डेटाच्या भागावर प्रक्रिया करून, फाइल आकाराकडे दुर्लक्ष करून मेमरी फूटप्रिंट फ्लॅट ठेवून याचे निराकरण करतात.

पार्श्वभूमी कामगार हँड-ऑफ

1. एचटीटीपी रिक्वेस्ट लाइफसायकल दरम्यान व्हिडिओ ट्रान्सकोडिंग, इमेज कॉम्प्रेशन आणि अँटीव्हायरस स्कॅनिंग यासारखे जड पोस्ट-अपलोड काम, कधीही इनलाइन चालवू नये.
2. ते काम BullMQ, Celery किंवा RabbitMQ सारख्या पार्श्वभूमी कार्य रांगेत आहे, जे तुमचे वापरकर्ते ज्या विनंती-प्रतिसाद चक्राची वाट पाहत आहेत त्यापासून वेगळे करून, वास्तविक प्रक्रिया बँडच्या बाहेर होत असताना तुमच्या API ला 202 स्वीकारलेले मिलिसेकंदात परत करू देते.

निर्णय: प्रत्येक फाइलला थेट ग्रेनेडप्रमाणे हाताळणे

वीकेंड ट्यूटोरियलमध्ये फाइल अपलोड फसव्या रीतीने सोपे दिसतात आणि वास्तविक प्रमाणात सुरक्षितपणे हाताळणे खरोखर कठीण होते.

प्रत्येक स्तर संचयन, प्रमाणीकरण, दर मर्यादित करणे, प्रवाह करणे—तुमची सेवा कमी करण्याचा किंवा तुमचे बजेट कमी करण्याचा स्वतःचा मार्ग आहे.

तुमचे आर्किटेक्चर वेगळे, प्रमाणित, पुनर्नामित आणि काढून टाकेपर्यंत तुमच्या सर्व्हरला स्पर्श करणारी प्रत्येक फाइल थेट ग्रेनेडप्रमाणे हाताळा. कमी काहीही एक वैशिष्ट्य नाही; हे काउंटडाउन आहे.