PHP webservers को सुरक्षित करना


31

PHP अनुप्रयोगों में औसत सुरक्षा समस्याओं की तुलना में अधिक प्रतिष्ठा है। यह सुनिश्चित करने के लिए कि आप एप्लिकेशन को संभव के रूप में सुरक्षित करने के लिए क्या कॉन्फ़िगरेशन तकनीकों का उपयोग करते हैं?

मैं इस तरह के विचारों की तलाश कर रहा हूं:

  • कठोर PHP / Suhosin का उपयोग करना
  • Mod_security का उपयोग करना
  • Php.ini में register_globals और allow_url_fopen को अक्षम करना

मैं आमतौर पर लिनक्स का उपयोग करता हूं, लेकिन बेझिझक विंडोज समाधान भी सुझाता हूं।

जवाबों:


15
  1. अपनी PHP स्क्रिप्ट्स को उनके होम डायरेक्टरी और अंतिम अतिरिक्त एप्लिकेशन डायरेक्टरीज़ तक सीमित करने के लिए open_basedir निर्देश का उपयोग करें। यह अपने आप में बहुत कुशल है।

  2. कड़े php का उपयोग करें क्योंकि इसमें कुछ भी खर्च नहीं होता है और यह मदद कर सकता है।

  3. PHP स्क्रिप्ट्स को फाइल के मालिक (प्रति उपयोगकर्ता एक उपयोगकर्ता) के रूप में निष्पादित करने के लिए suPHP का उपयोग करें और 777 जैसी खराब अनुमतियों वाली फ़ाइलों का उपयोग करने से बचें ... suPHP आपको प्रति वेबसाइट php.ini पर भी अनुमति दे सकती है ताकि एक साइट की बेवकूफी हो आवश्यकता सब कुछ नष्ट नहीं करती।

  4. Mod_security एक बड़ा प्लस है लेकिन इसे अच्छी तरह से उपयोग करने और कॉन्फ़िगर करने की आवश्यकता है।


कुछ बुरी साइटों को वास्तव में register_globals और fopen की आवश्यकता होती है, इसलिए आप suPHP के साथ प्रति साइट php.ini का उपयोग करते हैं। एक साइट बस kamikaze जा सकती है और दूसरे (लगभग) पूरी तरह से सुरक्षित हो सकते हैं।
एंटोनी बेनकेमोन

4
यदि वे register_globals और fopen का उपयोग करते हैं, तो यह बताता है कि गुणवत्ता इतनी खराब है कि आप उनका उपयोग करके पुनर्विचार करना चाह सकते हैं :)
David Pashley

यदि वे 150 € / मो का भुगतान कर रहे हैं, तो आप पुनर्विचार नहीं करते हैं।
एंटोनी बेनकेमॉन

3

मेरे अनुभव में, PHP-आधारित वेब साइट पर अधिकांश कमजोरियाँ PHP में दोषों के बजाय खराब (साइट) डिज़ाइन का परिणाम हैं।

कुछ त्वरित सुझाव:

  • यूनिवर्सली फ़िल्टर इनपुट, आउटपुट से बचें। क्लेरिस्पिटॉन: फ़िल्टर का मतलब पलायन नहीं है, इसका मतलब है "अगर मुझे इस उपयोगकर्ता इनपुट में कुछ गड़बड़ लगती है, तो प्रस्तुत करने में विफल हो जाता है और उपयोगकर्ता को पुन: स्वरूपित करने के लिए कहता है।"
  • एस्सेलशेल्ड () का उपयोग करने के बजाय, केवल किसी भी उपयोगकर्ता इनपुट को शेल में निष्पादित करने की अनुमति न दें । यह खतरनाक है और शायद वास्तव में कभी आवश्यक नहीं है।
  • एक उत्पादन साइट पर phpinfo () जैसे कार्यों को कॉल करें (या यदि आप करते हैं, तो नीचे देखें *)।
  • वेब एप्लिकेशन डिजाइन करते समय, हमेशा विचार करें "क्या यह एक संभावित हमला वेक्टर है?" कहते हैं, एसक्यूएल इंजेक्शन। यदि उत्तर "हां" है, तो इसे तुरंत प्लग करें - "ठीक नहीं है", मैं इसे बाद में विकास में एक विशेषता के रूप में जोड़ दूंगा। " सुरक्षा कभी सुविधा नहीं है।
  • उपयोगकर्ता को कभी भी कच्ची त्रुटियों का उत्पादन करें; इसका मतलब यह है कि php.ini की display_errors = Off, log_errors = On सेट करना। ट्रैप रन-टाइम त्रुटियां और आउटपुट कुछ सुंदर। एक उदाहरण के रूप में ट्विटर की व्हेल को लें: यह उपयोगकर्ता को डिबग-स्तरीय जानकारी नहीं देगा, यह सिर्फ कहता है "वाह, कुछ टूट गया, कृपया ताज़ा करें"।

* आप एक छोटी पोस्ट पर भी नज़र रख सकते हैं, जिसे मैंने "Securing phpinfo (), सॉर्ट" लिखा था और टिप्पणियों को पढ़ने के लिए सुनिश्चित करें http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ यह एक त्वरित विचार था जो मुझे (कुछ हद तक) phpinfo () की रक्षा करना था, अगर मैं किसी तरह इसे एक उत्पादन साइट पर निकालना भूल गया।

अधिक सामान्य तरीके से, कुछ डेवलपर्स संवेदनशील कार्यों के लिए रैपर लिखते हैं जो यह जांचते हैं कि "उत्पादन साइट" ध्वज सेट है या नहीं, और उत्पादन में संवेदनशील फ़ंक्शन को अक्षम करता है।


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

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

3

अन्य पैरामीटर जिन्हें PHP को सख्त करने के लिए बदल दिया जाना चाहिए:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

फ़ाइल /var/log/phperror.log में सभी PHP त्रुटियों को संग्रहीत करें :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

1

मैंने अपने /etc/apt/sources.lst पर dotdeb रिपॉजिटरी जोड़ी है

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

चूंकि वे डेपियन की तुलना में php / apache / mysql को अधिक बार पैच करते हैं।


1

open_basedir"प्रति साइट" आधार पर स्थापित करने पर विचार करें । open_basedirएक php.ini सेटिंग है जो आपकी स्क्रिप्ट को परिभाषित सफेद सूची के बाहर फ़ाइलों तक पहुँचने से रोकेगी। यदि आपका सर्वर कई साइटों को होस्ट करता है, तो यह एक साइट को दूसरी साइट से डेटाबेस सेटिंग्स को पढ़ने से रोकेगा। यह कोर सिस्टम फ़ाइलों तक पहुँचने / संशोधन करने से php स्क्रिप्ट को भी रोकेगा। ओपन बेसिर सेट करना आसान है, बस php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/listप्रत्येक अपाचे वीहोस्ट को लाइन " " जोड़ें ।

सभी साइटों / फ़ोल्डरों के लिए PHP स्क्रिप्ट इंजन को बंद करने पर भी विचार करें, जिसमें PHP स्क्रिप्ट्स नहीं होनी चाहिए (जैसे एक अपलोड की गई छवि फ़ोल्डर)। फिर से, यह सरल है, किसी भी Apache VirtualHosts को php की आवश्यकता नहीं होने पर "php_admin_value engine off" जोड़ें। किसी निर्देशिका में PHP को निष्क्रिय करने के लिए, एक ही चीज़ को एक निर्देशिका टैग में रखें।

संभव के रूप में फ़ाइल अनुमतियों को चलाएं, Apache उपयोगकर्ता के लिए PHP स्क्रिप्ट तक पहुंच से बचें, यह एक रनिंग स्क्रिप्ट को उसी साइट / सर्वर पर स्वयं या अन्य स्क्रिप्ट को संशोधित करने से रोकता है। यदि संभव हो तो 777 अनुमतियों से बचें, एप्लिकेशन को चलाने और उन का उपयोग करने के लिए आवश्यक न्यूनतम अनुमतियों का पता लगाएं।

यदि आप कई साइटों की मेजबानी कर रहे हैं, प्रत्येक अपने स्वयं के डेटाबेस के साथ, प्रत्येक के लिए एक अलग MySQL / Postgres उपयोगकर्ता का उपयोग करें, और प्रत्येक उपयोगकर्ता पर अनुमतियाँ सेट करें जैसे कि उनके पास केवल प्रासंगिक डेटाबेस तक पहुंच हो। फिर से यह एक बदमाश स्क्रिप्ट को दूसरे एप्लिकेशन के डेटाबेस के साथ छेड़छाड़ करने से रोकेगा।

Suosin, HardenedPHP, mod_security और पसंद सभी मूल्यवान हैं, लेकिन इनका उपयोग कसकर लॉक किए गए कॉन्फ़िगरेशन के अलावा करते हैं, इसके बजाय नहीं।


0

सुहोसिन के पास पर्याप्त प्रदर्शन लागत है, इसलिए "लागत कुछ भी नहीं" टिप्पणी थोड़ी दूर है।


2
एक तेज़, हैक की गई वेबसाइट कितनी अच्छी है? :) कठोर- php.net/suhosin/benchmark.html एक बेंचमार्क पर 8.85% धीमा होने का सुझाव देता है। यह सुरक्षा प्रदान करता है के लिए स्वीकार्य हो सकता है। यह शायद एक जवाब के बजाय एक टिप्पणी होनी चाहिए थी।
डेविड पैस्ले

सुहोसिन मुख्य रूप से स्थानीय हमलों से बचाता है। इसलिए, यदि आप अपने सर्वर को उन लोगों के साथ साझा करते हैं जिन पर आपको भरोसा नहीं है, तो यह मंदी के लायक हो सकता है। यदि आपके पास अपना सर्वर है, या आपका अपना vm टुकड़ा है, तो मुझे यह बात दिखाई नहीं देती है।

0

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


नहीं, मैं PHP रनटाइम की सुरक्षा को बेहतर बनाने के तरीकों की तलाश कर रहा हूं।
डेविड पशले

0

सुहोसिन / mod_security / SuPHP का उपयोग निश्चित रूप से आपके PHP सर्वर को सुरक्षित करेगा। निष्पादन, पसथ्रू, सिस्टम और एस्सेलशेल्डक जैसे कुछ कार्यों को अक्षम करने से भी बहुत मदद मिलेगी।


1
एस्सेशेल्डकैम () सिर्फ स्ट्रिंग से बचने के लिए इस्तेमाल नहीं किया जाता है? यह किसी प्रक्रिया को निष्पादित करने का कोई तरीका प्रदान नहीं करता है। कोई व्यक्ति किसी समस्या के कारण इसका उपयोग कैसे कर सकता है?
डेविड पशले
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.