2008-09-16 11 views
17

E.g.php-cgi के बजाय mod_php का उपयोग करना अधिक सुरक्षित है? या पारंपरिक cgi-scripts के बजाय mod_perl का उपयोग करना अधिक सुरक्षित है?क्या अपाचे मॉड्यूल बनाम सीजीआई (सुरक्षा से संबंधित) के बीच कोई अंतर है?

मुझे मुख्य रूप से सुरक्षा चिंताओं में रूचि है, लेकिन महत्वपूर्ण अंतर होने पर गति एक मुद्दा हो सकता है।

+2

मुझे लगता है कि यह प्रश्न पुराना है, लेकिन अब यह ** सर्वर फॉल्ट ** पर नहीं जाना चाहिए? –

+0

@smarinov, यह चाहिए। लेकिन जब पुराने धागे की बात आती है तो एसओ की एक अजीब नीति होती है, जो एक शब्द में बताती है: "आलस्य"। तो परवाह नहीं है। – Pacerier

उत्तर

15

सुरक्षा किस अर्थ में है? किसी भी तरह से यह वास्तव में निर्भर करता है कि कौन सी स्क्रिप्ट चल रही है और यह कितनी अच्छी तरह लिखी गई है। इन दिनों बहुत सारी स्क्रिप्ट आधा assed हैं और इनपुट सत्यापन सही ढंग से नहीं करते हैं।

मैं व्यक्तिगत रूप से fast_Gp को फास्टसीजीआई पसंद करता हूं क्योंकि अगर फास्टसीजीआई प्रक्रिया एक नया मर जाती है, तो मैंने देखा है कि mod_php अपाचे की पूरी तरह से मार डाला है।

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

एक अलग नोट पर, यदि आप अपाचे के नए कार्यकर्ता थ्रेडिंग समर्थन का उपयोग कर रहे हैं तो आप यह सुनिश्चित करना चाहते हैं कि आप mod_php का उपयोग नहीं कर रहे हैं क्योंकि कुछ एक्सटेंशन थ्रेड सुरक्षित नहीं हैं और दौड़ की स्थिति का कारण बनेंगे।

+0

मैं एक साल के लिए mod_php के साथ रहा हूं और मैंने कभी बच्चे की प्रक्रिया को अपाचे की पूरी तरह से मारने को नहीं देखा है। – wlf

+2

@wlf: इसे सुनकर खुशी हुई। –

+1

@wlf, 1 साल मुश्किल से लंबा है। 3 साल अब तो क्या यह अभी भी जीवित है? – Pacerier

2

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

+1

मुझे दिमाग में कोई विशेष खतरा नहीं है। लेकिन एक ही मशीन पर होस्ट किए गए कई पेज हैं। – Sarien

+0

आपको यह तय करना चाहिए कि आप पहले से खुद को कैसे सुरक्षित रखना चाहते हैं। क्या वे पृष्ठ एक ही व्यक्ति/संस्था के स्वामित्व में हैं? यदि नहीं, तो आपको अलग-अलग उपयोगकर्ताओं के रूप में अलग-अलग PHP स्क्रिप्ट चलाने के लिए विभिन्न समाधानों पर विचार करना चाहिए, उदाहरण के लिए (suphp, वर्चुअल होस्ट और रिवर्स प्रॉक्सीइंग का उपयोग करके, और अन्य) –

+0

@ विंकोवर्सलोविक, सामान्य खतरे का मॉडल। पीएच के स्रोत कोड को पढ़ने से prying आंखों को रोकें। – Pacerier

5

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

सीजीआई धीमा हो जाएगा, लेकिन आजकल इसके समाधान हैं, मुख्य रूप से फास्टसीजीआई और दोस्तों।

आपका खतरा मॉडल क्या है?

+0

यदि स्क्रिप्ट कमजोर है, तो इसका मतलब यह नहीं है कि हम सर्वर को सुरक्षित करना बंद कर देते हैं। दोनों को मजबूत होना चाहिए। खतरे का मॉडल अनधिकृत लोगों तक फ़ाइल पहुंच को रोकने के लिए है। एक्सेस केवल PHP स्क्रिप्ट के माध्यम से किया जाना चाहिए। – Pacerier

4

पीएचपी 5.2.6 के लिए पीएचपी install.txt डॉक से:

सर्वर मॉड्यूल में काफी बेहतर प्रदर्शन और सीजीआई द्विआधारी की तुलना में अतिरिक्त कार्यक्षमता प्रदान करते हैं।

आईआईएस/PWS के लिए:

चेतावनी

सीजीआई सेटअप का उपयोग करके, अपने सर्वर कई संभव हमलों के लिए खुला है। को उन हमलों से बचाने के तरीके के बारे में जानने के लिए कृपया हमारे सीजीआई सुरक्षा अनुभाग को पढ़ें।

+0

* "कृपया हमारे सीजीआई सुरक्षा अनुभाग को पढ़ें" * ... कहाँ? – Pacerier

8

यदि आप अपना स्वयं का सर्वर मॉड्यूल तरीके से चलाते हैं, तो यह कुछ हद तक तेज़ है। यदि आप किसी साझा सर्वर पर हैं तो आमतौर पर आपके लिए सीजीआई पक्ष पर निर्णय लिया जा चुका है। इसका कारण फाइल सिस्टम अनुमतियां हैं। एक मॉड्यूल के रूप में PHP http सर्वर (आमतौर पर 'अपाचे') की अनुमतियों के साथ चलता है और जब तक कि आप उस उपयोगकर्ता को अपनी स्क्रिप्ट को chmod नहीं कर सकते हैं, आपको उन्हें 777 - दुनिया को पठनीय करने के लिए chmod करना होगा।इसका मतलब है, हां, कि आपका सर्वर पड़ोसी उन्हें देख सकता है - इस बारे में सोचें कि आप डेटाबेस एक्सेस पासवर्ड कहां स्टोर करते हैं। अधिकांश साझा सर्वरों ने इसे phpsuexec जैसे सामानों का उपयोग करके हल किया है, और स्क्रिप्ट मालिक की अनुमतियों के साथ स्क्रिप्ट चलाते हैं, ताकि आप अपने कोड को 644 पर चिपका सकें। Phpsuexec केवल PHP के साथ सीजीआई के रूप में चलता है - यह सब या कम है , यह सिर्फ एक स्थानीय मशीन चीज है - दुनिया में बड़े पैमाने पर कोई फर्क नहीं पड़ता।

+2

644 अभी भी दुनिया को पठनीय है। – Forest

+0

[सीजीआई का सेटअप अधिक सुरक्षित है,] (http://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/)। लेकिन धीमी लेकिन http://stackoverflow.com/a/10439720/632951 भी देखें – Pacerier

3

mod_php या FastCGI जैसे मॉड्यूल सादे CGI से अविश्वसनीय रूप से तेज़ है .. बस CGI नहीं करें। जैसा कि अन्य ने कहा है, PHP प्रोग्राम स्वयं ही सबसे बड़ा सुरक्षा खतरा है, लेकिन यह अनदेखा कर रहा है कि साझा मेजबानों पर एक और विचार है।

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

भले ही आप अपनी होस्टिंग को नियंत्रित करते हैं, ध्यान रखें कि सर्वर पर एक और हैक किया गया वेब एप्लिकेशन दूसरों में एक कंडिशन हो सकता है।

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