हमारे पास कुछ डेवलपर हैं जो हमारे सर्वर पर सक्षम होने के लिए allow_url_fopen मांग रहे हैं। इन दिनों मानक क्या है और यदि libcurl सक्षम है तो वास्तव में अनुमति देने के लिए कोई अच्छा कारण है?क्या मुझे PHP में 'allow_url_fopen' की अनुमति देनी चाहिए?
पर्यावरण है: Windows 2003, पीएचपी 5.2.6, FastCGI
आप निश्चित रूप से बंद करने के लिए allow_url_include सेट करना चाहते हैं, जो रूप में अच्छी तरह allow_url_fopen के जोखिम को कम कर के कई।
लेकिन क्योंकि नहीं पीएचपी के सभी संस्करणों allow_url_include है, कई के लिए सबसे अच्छा अभ्यास fopen बंद करने के लिए है। सभी सुविधाओं के साथ, वास्तविकता यह है कि यदि आपको अपने आवेदन के लिए इसकी आवश्यकता नहीं है, तो इसे अक्षम करें। यदि आपको इसकी आवश्यकता है, तो कर्ल मॉड्यूल शायद इसे बेहतर कर सकता है, और allow_url_fopen अक्षम करने के लिए कर्ल का उपयोग करने के लिए आपके एप्लिकेशन को दोबारा करने से कम से कम निर्धारित क्रैकर को रोक सकता है।
अरे बेन, मैंने कुछ मामलों को देखा है जहां चर() (या fopen()) शामिल करने के लिए चर को पारित किया जाता है, जिसे डेवलपर द्वारा स्थानीय फ़ाइल का संदर्भ देने के लिए माना जाता है, लेकिन इसके बजाय वे दुर्भावनापूर्ण PHP कोड संग्रहीत ऑफ़साइट का संदर्भ देने वाले URL हैं। मैं कुछ गंभीर कारणों के बारे में सोच सकता हूं कि क्यों कोई भी शामिल करना चाहता है ("http: // ..") और इसके परिणामस्वरूप वास्तविक कार्यक्षमता उस कार्यक्षमता को बंद कर सुधार कर रही है। Http://en.wikipedia.org/wiki/Remote_File_Inclusion –
@ बेन जेम्स: कुछ समय पहले हमें क्रैक किया गया है, सुरक्षा के कारण हमारे अद्यतित वाणिज्यिक मंच पैकेज और अन्य पुराने सॉफ्टवेयर में भी गिरावट आई है। Allow_url_include और allow_url_fopen को बंद करने से लगभग हर हमले को रोक दिया गया। – tacone
libcurl का उपयोग फ़ाइल_get_contents() का उपयोग करने से कहीं अधिक सुरक्षित क्यों होगा यदि मैं एक ही यूआरएल डाउनलोड करता हूं और उसी तरह डेटा का उपयोग करता हूं? एक ही बात है। Libcurl का उपयोग करने के रूप में और डाउनलोड की गई सामग्री को eval() 'बाहरी यूआरएल में शामिल करने से कहीं अधिक सुरक्षित नहीं है। यह सिर्फ नकली "परेशान होने से सुरक्षा" है, जैसे विंडोज विस्टा आपको दो बार पूछता है यदि आप वास्तव में, वास्तव में उस कार्यक्रम को चलाने के लिए चाहते हैं। –
क्रॉस साइट स्क्रिप्टिंग हमलों परेशान कर सकती हैं ताकि के खिलाफ एक वोट है। और आपको बिल्कुल "allow_url_include" सेट करना चाहिए, या आप चोट की दुनिया में रहेंगे।
AFAIK के पास XSS के साथ कुछ लेना देना नहीं है, लेकिन स्थानीय फ़ाइलों को लोड करने के साथ। – ananda
मुझे लगता है कि इस सवाल का जवाब आप कैसे अच्छी तरह से भरोसा अपने डेवलपर्स जिम्मेदारी से सुविधा का उपयोग करने के लिए नीचे आता है? बाहरी यूआरएल से डेटा किसी अन्य अविश्वसनीय इनपुट की तरह व्यवहार किया जाना चाहिए और जब तक यह समझा जाता है, तो बड़ा सौदा क्या है?
तरह से मैं यह है कि यदि आप बच्चों की तरह अपने डेवलपर्स का इलाज और जाने के लिए उन्हें तेज चीजों को संभाल कभी नहीं है, तो आप डेवलपर के सुरक्षित कोड लिखने की जिम्मेदारी कभी नहीं सीख होगा देखते हैं।
यह विकास के प्रकार पर निर्भर करता है। यदि आपका प्रोटोटाइप तब 'allow_url_fopen' को सक्षम करता है तो ठीक है हालांकि libcurl और file_get_contents के बीच कोई महत्वपूर्ण गति अंतर नहीं है और इसे सक्षम करना केवल सुविधा का मामला है।
उत्पादन सर्वर के लिए libcurl के लिए किसी भी कॉल एक सुरक्षा लेखापरीक्षा करने के कारण चिह्नित किया जाना चाहिए। अगर 'allow_url_fopen' सक्षम है तो fopen और file_get_contents को चाहिए। 'Allow_url_fopen' को अक्षम करने से शोषण को रोका नहीं जाता है, यह केवल उन तरीकों की संख्या को सीमित करता है जिन्हें वे किया जा सकता है।
बड़ी समस्या है कि allow_url_fopen अधिक सुरक्षित नहीं है, इसलिए यदि आप एक यूआरएल कर्ल का उपयोग करने से फ़ाइल सहेजना चाहते हैं, तो आप फ़ाइल को बचाने के लिए fopen/file_get से गुजरना होगा है।
- कर्ल URL से दूरस्थ सामग्री प्राप्त करने में ही अच्छा है। (आवश्यक नहीं allow_url_fopen)
- कर्ल fopen या File_get साथ जोड़ा जाना चाहिए यदि आप अपने सर्वर के लिए दूरस्थ फ़ाइल सहेजना चाहते हैं। (curl साथ अनिवार्य allow_url_fopen)
Php इसे और अधिक सुरक्षित बनाने के लिए अन्य तरीके खोजने होंगे।
यह गलत है; आप cur_url_fopen को सक्षम किए बिना फ़ाइल को ठीक से सहेज सकते हैं, भले ही आपको कर्ल का उपयोग करके सामग्री प्राप्त हो। –
मैं यह नहीं करूँगा। साथ ही, अधिकांश PHP आधारित हमलों का मानना है कि होस्ट लिनक्स चला रहा है, इसलिए उनमें से कुछ वैसे भी विफल हो जाते हैं। – tacone