PHP छवि अपलोड सुरक्षा दृष्टिकोण

मैं वर्तमान को बदलने के लिए एक PHP स्क्रिप्ट विकसित करता हूं, जिसमें विभिन्न बाजारों/देशों के लिए बहुत अधिक जोखिम होगा। दूसरों के बीच यह स्क्रिप्ट एक फोटो अपलोड कार्यक्षमता प्रदान करता है।PHP छवि अपलोड सुरक्षा दृष्टिकोण

इस मुद्दे के बारे में बहुत कुछ पढ़ने के बाद, मैंने नीचे वर्णित दृष्टिकोण का पालन किया। मैं इसकी सुरक्षा पर आपकी टिप्पणियों की गहराई से सराहना करता हूं।

तस्वीर को वेब रूट के बाहर एक निजी 777 फ़ोल्डर में अपलोड किया गया है।
सफेद सूचीबद्ध एक्सटेंशन के लिए एक जांच की जाती है (केवल jpgs, gifs, pngs को अनुमति दें) बाकी सब कुछ हटा दिया जाता है।
न्यूनतम-अधिकतम आयामों और फोटो वैधता की जांच के लिए getimagesize का उपयोग करें।
मिमटाइप और फ़ाइल एक्सटेंशन मिलान की जांच करें।
अपलोड की गई तस्वीर का आकार std आयामों में बदलना (imagecopyresampled का उपयोग करना)।
बनाई गई फ़ाइलों को jpg के रूप में सहेजना।
मूल फ़ाइल को हटाने।
एक नए (यादृच्छिक नाम नहीं) यानी img51244.jpg के साथ फोटो सहेजें।
गैर-अनुमानित एल्गोरिदम के अनुसार नई तस्वीरों को एक सार्वजनिक फ़ोल्डर (777 अनुमतियों) की परिवर्तनीय उप-निर्देशिकाओं में ले जाएं। आईई, img10000.jpgphotos/a/f/0/img10000.jpg पर संग्रहीत किया जाएगा जबकि img10001.jpgphotos/0/9/3/img10001.jpg पर संग्रहीत किया जाएगा। यह अन्य कारणों से किया जाता है (स्थिर सामग्री के लिए सबडोमेन का उपयोग या सीडीएन का उपयोग)।

स्क्रिप्ट लिनक्स समर्पित सर्वर पर चलती है।

स्रोत

2011-09-06 Alex

यहां मेरे यहां कुछ भी नहीं निकलता है। फ़ोल्डर पर 777 अनुमति के अलावा - जैसा कि मैं इसे समझता हूं, अगर इसमें 777 अनुमतियां हैं, तो यह निजी नहीं है। लेकिन जहां तक मैं यह कह सकता हूं, केवल तभी मायने रखता है जब आपके सर्वर से समझौता किया गया था (जो कम से कम इस स्क्रिप्ट के माध्यम से मुझे दिखाई नहीं देता) – jammypeach

777 सुरक्षित नहीं लगता है। Http://stackoverflow.com/questions/3644138/secure-user-image-upload-capabilities-in-php – ajreal

से संबंधित संभावित संभवतः बहुत उदार अनुमतियों को छोड़कर, मेरे लिए बहुत अच्छा लगता है। शायद वे कुछ हद तक सीमित हो सकते हैं? अन्यथा, यह सब कुछ आवश्यक है जो मैं सोच सकता हूं, जिसमें EXIF डेटा –

आपको अपलोड किए गए फ़ाइल आकार की भी जांच करनी चाहिए, क्योंकि getimagesize कभी-कभी उपलब्ध RAM स्मृति से अधिक हो सकता है। यह मानना भी अच्छा है कि आपकी स्क्रिप्ट किसी भी बिंदु पर क्रैश हो सकती है (उदाहरण के लिए जब बिजली नीचे जाती है), तो आपको बाएं, अनियंत्रित फ़ाइलों को हटाने के लिए कुछ साफ-सफाई प्रक्रियाओं को लागू करना चाहिए।

स्रोत

2011-09-06 08:44:04

अधिकतम अपलोड करने योग्य फ़ाइलइज़ पहले ही php.ini में सीमित है। – Maerlyn

हां यह है, लेकिन इसका मतलब यह नहीं है कि रैम सीमा से अधिक से बचने के लिए पर्याप्त है। –

यदि यह php.ini में आकार से अधिक है तो आपको '_ _FILES' में फ़ाइल नाम नहीं मिलता है - इसलिए आप इसका आकार नहीं देख सकते हैं। – Maerlyn

-1

यह एक बिल्कुल पूरा दृष्टिकोण है, लेकिन मुझे कोई कोड निष्पादन रोकथाम तंत्र नहीं दिख रहा है।

आपको यह सुनिश्चित करना चाहिए कि छवि की सामग्री कभी शामिल नहीं है (शामिल या आवश्यकता कॉल के साथ) या eval() के माध्यम से निष्पादित।

अन्यथा, फ़ाइल के अंत में शामिल PHP कोड निष्पादित किया जा सकता है।

आप छवि सामग्री के अंदर php कोड (file_get_contents के साथ, और फिर उदाहरण के लिए "<? Php" के लिए एक regex खोज करने का प्रयास कर सकते हैं) लेकिन मुझे नष्ट किए बिना संदिग्ध कोड को खत्म करने के लिए 100% सुरक्षित तरीका नहीं मिला कुछ (मान्य) छवियों।

स्रोत

2011-09-06 08:44:38

मुझे नहीं लगता है कि जब तक आपका सर्वर गलत कॉन्फ़िगर नहीं किया जाता है तब तक एक जेपीजी फ़ाइल में PHP कोड निष्पादित किया जाएगा? –

इसमें कोई बात नहीं है, क्योंकि यह स्पष्ट है कि कोई भी eval को कॉल करने या छवि पर शामिल करने वाला नहीं है। मैं किसी भी परिदृश्य के बारे में नहीं सोच सकता जहां कोई ऐसा करने के बारे में सोचता है (जब तक कि वह अभी PHP का उपयोग शुरू नहीं कर लेता)। –

जैसे ही resampled फ़ोटो होती हैं, मूल फ़ाइल हटा दी जाती है। इसका उपयोग केवल उस क्रम में निम्न php फ़ंक्शंस के साथ किया जाता है: move_uploaded_file, filesize, getimagesize, imagecreatefromjpeg, imagecopyresampled। – Alex

chmod 0777 के साथ एक निर्देशिका परिभाषा के अनुसार, आपके सर्वर में लॉग इन अन्य उपयोगकर्ताओं के लिए सार्वजनिक है, निजी नहीं। सही अनुमतियां 700 होंगी और apache (या जो भी उपयोगकर्ता आपका वेबसर्वर चलता है) के स्वामित्व में होगा। मुझे यकीन नहीं है कि आप यहां PHP की डिफ़ॉल्ट अस्थायी निर्देशिका का उपयोग क्यों नहीं करेंगे, क्योंकि यह वेब रूट के बाहर भी होता है।
एक सफेद सूची एक अच्छा विचार है। सही कार्यान्वयन के लिए सावधान रहें। उदाहरण के लिए, regexp /.png/ वास्तव में apng.php से मेल खाता है।
यह कदम एक अच्छा विचार है। यह मूल रूप से फ़ाइल जादू की जांच करता है।
सख्ती से जरूरी नहीं है। पिछले दो चरणों में, हमने यह निर्धारित किया है कि एक्सटेंशन और फ़ाइल प्रारूप सही हैं। यदि आपको क्लाइंट द्वारा निर्दिष्ट एक सही एमआईएम प्रकार की आवश्यकता है, तो आपको यह भी जांचना चाहिए कि दिए गए एमआईएम प्रकार और ऊपर निर्धारित एक समतुल्य है।

चरण 5 से 8 सुरक्षा-संबंधित नहीं हैं।

चरण 9: मुझे लगता है कि आपकी साइट सभी को हर फोटो देखने की अनुमति देती है। यदि ऐसा नहीं है, तो आपके पास पर्याप्त URL के साथ एक यूआरएल योजना होनी चाहिए (कहें, छवि का हैशसम)।

स्रोत

2011-09-06 08:46:44 phihag

(-1) 777 का अर्थ वेब के माध्यम से accessabilty के मामले में सार्वजनिक नहीं है - यही वह बात है जिसके बारे में वह बात कर रहा है। और आपके regex उदाहरण का तात्पर्य है कि यह किसी भी तरह की imortance है ... और बीटीडब्ल्यू exe एक विंडोज एक्सटेंशन है ...: -/ – Raffael

@ Raffael1984 मुझे लगता है कि फिहाग जानता है कि। यह अभी भी एक ही वेब सर्वर * पर अन्य उपयोगकर्ताओं के लिए पहुंच के संदर्भ में सार्वजनिक है, जो * एक * मुद्दा है। लेकिन मैं सहमत हूं कि चरण 2) यदि आप करते हैं तो अनावश्यक है 3) ठीक से –

@ रैफेल 1 9 84 सच। मुझे यकीन नहीं है कि वह कदम क्यों जरूरी है। उत्तर अपडेट किया गया। – phihag

PHP छवि अपलोड सुरक्षा दृष्टिकोण

उत्तर

संबंधित मुद्दे