सामान्य PHP सेटअप असुरक्षा?

10

मैं एक विश्वविद्यालय में सिस्टम प्रशासन के साथ काम करता हूं और बस कुछ के पार ठोकर खाई है जो शायद आम है, लेकिन मेरे लिए काफी झटका था।

सभी public_html निर्देशिकाओं और वेब क्षेत्रों को afs पर संग्रहीत किया जाता है, वेब सर्वर के लिए पढ़ने की अनुमति के साथ। चूंकि उपयोगकर्ताओं को अपने public_html में php स्क्रिप्ट रखने की अनुमति है, इसका मतलब यह है कि वे php (और मुख्य वेब फ़ाइलों!) से एक-दूसरे की फ़ाइलों तक पहुँच सकते हैं।

न केवल यह किसी भी .htaccess पासवर्ड सुरक्षा को पूरी तरह से बेकार कर देता है, यह उपयोगकर्ताओं को mysql डेटाबेस पासवर्ड और समान संवेदनशील जानकारी वाली php स्रोत फ़ाइलों को पढ़ने की भी अनुमति देता है। या यदि वे पाते हैं कि अन्य लोगों की निर्देशिकाएं हैं, जहां वेब सर्वरों की पहुंच है (जैसे व्यक्तिगत लॉग के लिए या सबमिट किए गए फॉर्म डेटा को बचाने के लिए) तो वे उन खातों में फ़ाइलों को संग्रहीत कर सकते हैं।

एक सरल उदाहरण:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

क्या यह एक आम समस्या है? और आप इसे आमतौर पर कैसे हल करते हैं?

अपडेट करें:

इनपुट के लिए धन्यवाद। दुर्भाग्य से, ऐसा लगता है कि कोई सरल जवाब नहीं है। इस तरह के एक बड़े साझा वातावरण में, उपयोगकर्ताओं को संभवतः इसे अधिक विकल्प नहीं दिया जाना चाहिए। सबसे अच्छा तरीका मुझे लगता है कि सभी "public_html" निर्देशिकाओं के लिए मुख्य कॉन्फ़िगरेशन में "open_basedir" सेट करने के लिए है, suphp चलाएं और केवल साफ php (कोई cgi स्क्रिप्ट, बैकटिक्स आदि के साथ बाहरी कमांड चलाने) की अनुमति दें।

इस तरह से नीति में बदलाव करने से बहुत सारी चीजें टूट जाएंगी, और संभवत: उपयोगकर्ताओं को अपने पिचफ़र्क को पकड़ने और हमें पीछा करने के लिए ... मैं अपने सहयोगियों के साथ इस पर चर्चा करूंगा और अगर सेटअप बदलने के तरीके पर निर्णय लेते हैं तो यहां अपडेट करेंगे।

apache-2.2 security php

— पुन्तुस
स्रोत

यह एक दिलचस्प सवाल है। मुझे यकीन है कि प्रमुख साझा होस्टिंग प्रदाताओं (जैसे ड्रीमहॉस्ट) पर, यह संभव नहीं है। लेकिन मुझे इसमें दिलचस्पी होगी कि वे इससे कैसे बचाते हैं। suphp, जैसा कि cstamas ने उल्लेख किया है, एक अच्छा समाधान की तरह दिखता है, लेकिन क्या यह सबसे होस्टिंग प्रदाता उपयोग करते हैं?

— लास मेजेस्टे

1

मैंने open_basedirउत्पादन साझा होस्टिंग सिस्टम पर नीचे दिए गए समाधान का उपयोग किया है , लेकिन हमने सभी को अपने स्वयं के vhost में विभाजित किया है - यकीन नहीं है कि यह एकल निर्देशिकाओं के लिए काम करता है ...

— voretaq7

8

एक suphp का उपयोग कर सकता है जो अपने मालिक के यूआईडी के साथ php स्क्रिप्ट चलाता है।

http://www.suphp.org

— cstamas
स्रोत

यह संभवतः उपरोक्त समस्या को हल नहीं करेगा (कम से कम एक साझा होस्टिंग वातावरण में ।htpasswd फाइलें आमतौर पर उस उपयोगकर्ता के स्वामित्व में होती हैं जो साइट और समूह (अपाचे) या दुनिया का मालिक होता है (क्योंकि उपयोगकर्ता सुरक्षा के बारे में जानकारी नहीं रखते / पढ़ते हैं) यहाँ तक कि सुपरहप के साथ वे उन फाइलों को भी पढ़ सकेंगे)

— voretaq7

@ voretaq7: कई अन्य प्रतिबंध लागू किए जा सकते हैं। जहां तक मुझे याद है आप उन फाइलों तक पहुंच से भी इनकार कर सकते हैं जो आपके पास नहीं हैं। तो यह ऊपर दिए गए हमले का नियम है।

— cstamas

मुझे पता है कि आप फाइलों पर अनुमतियों को प्रतिबंधित कर सकते हैं ("समूह / अन्य / किसी के द्वारा भी लिखने योग्य नहीं हो सकता"), लेकिन मुझे एफएस अनुमतियों से परे रीड को ब्लॉक करने का तरीका नहीं पता है। उनके पास है check_vhost_docroot, लेकिन AFAIK जो केवल स्क्रिप्ट पर लागू होता है ((मैं उस पर गलत हो सकता है)

— voretaq7

1

मुझे यकीन नहीं है कि अगर suphp इस तरह के माहौल में एक अच्छा समाधान है। उपयोगकर्ता के पास सभी प्रकार की अनुमतियाँ हो सकती हैं जो www-user के पास नहीं हैं। एक हमलावर जो php के माध्यम से एक रास्ता खोजता है, वह ssh कीज़ या की -टैब ढूँढ सकता है, या बैकडोर बनाने के लिए उपयोगकर्ताओं की लॉगिन स्क्रिप्ट बदल सकता है। और "vhosts" सेटिंग सार्वजनिक वर्चुअल होस्ट पर "/ ~ उपयोगकर्ता नाम" के माध्यम से public_html निर्देशिकाओं के उपलब्ध होने के बाद से सहायक नहीं हैं। मैं सोच रहा हूं कि public_html में स्क्रिप्ट पूरी तरह से अक्षम होनी चाहिए।

— पोंटस

4

मेरा सुझाव PHP की फाइलों तक पहुँच ( open_basedirप्रति के रूप में इसी तरह के निर्देशों के माध्यम से) को सीमित करना होगा : आप चाहते हैं कि उपयोगकर्ता अपने वेबरूट के तहत फ़ाइलों को खोलने / पढ़ने / लिखने में सक्षम हों, और शायद इसके ऊपर एक स्तर (खरोंच के लिए) अंतरिक्ष), लेकिन एक निर्देशिका नहीं है जहाँ वे उदाहरण के लिए htpasswdफ़ाइलें संग्रहीत करेंगे ।

एक निर्देशिका संरचना जैसे:

/Client
    /auth
    /site
        /www_root
        /www_tmp

इस आवश्यकता को पूरा करेगा: सुरक्षित रूप से open_basedirइंगित किया जा सकता है /Client/site, और htpasswdफाइलों में संग्रहीत /Client/auth( .htaccessफाइलों के साथ या httpd.confइसके बजाय उपयुक्त स्थान पर इंगित करने के लिए संशोधित)।
यह आपके क्लाइंट को किसी और की फ़ाइल खोलने से रोकता है, और एक लाभ के रूप में दुर्भावनापूर्ण उपयोगकर्ता /Client/authआपके कंप्यूटर पर सामान (या किसी और चीज़ में ) को नहीं पढ़ सकता है, जैसे /etc/passwd:-)

देखें http://php.net/manual/en/ini.core.php open_basedir और प्रति-vhost क्रियान्वयन पर अधिक विवरण के लिए।

— voretaq7
स्रोत

1

suphpजैसा कि cstamas द्वारा साझा किया गया है, एक साझा होस्टिंग वातावरण में भी एक बहुत अच्छा विचार है - इसमें थोड़ा ओवरहेड स्थापित हो रहा है, लेकिन मैं कहूंगा कि सुरक्षा लाभ पूरी तरह से इसके लायक है। FreeBSD जेल या समर्पित वर्चुअल मशीन की तरह अपने सभी PHP साइटों में से कुछ पर सैंडबॉक्सिंग करना सबसे बड़ी सुरक्षा जीत है।

— voretaq7

"open_basedir" उपयोगकर्ता को मुख्य वेब फ़ाइलों को अलग करने का एक सरल तरीका प्रतीत होता है, बशर्ते कि "public_html" इसे स्वयं के वर्चुअल होस्ट के माध्यम से परोसा जाए। लेकिन यह उपयोगकर्ताओं को एक दूसरे से सुरक्षित नहीं करता है, क्योंकि उनके पास अपने स्वयं के वर्चुअल होस्ट नहीं हैं। सही?

— पोंटस

मैंने open_basedir<डायरेक्टरी> डायरेक्टिव के अंदर सेटिंग करने की कोशिश नहीं की है , लेकिन मुझे लगता है कि यह स्वीकार्य होना चाहिए ("इसे आज़माएं और देखें" - सबसे बुरा यह काम नहीं कर सकता है :)

— voretaq7

1

अब तक ऐसा लगता है कि ओपन_बेडिर वह है जो अधिकांश व्यावसायिक वेब होस्ट उपयोग करते हैं (आमतौर पर ग्राहकों के पास अपने स्वयं के भुगतान किए गए डोमेन होते हैं या एक मुफ्त उपडोमेन प्राप्त होते हैं), लेकिन एक शैक्षणिक संस्थान में डायरेक्टरी-आधारित होमपेज़ के लिए, सुपहप सबसे अच्छा जवाब लगता है।

— लीज मेजेस्टे

1

नहीं, यह कोई आम समस्या नहीं है क्योंकि अधिकांश साझा होस्ट प्रत्येक उपयोगकर्ता के public_html निर्देशिका (या प्रत्येक उपयोगकर्ता के अपने स्वयं के vhost) में htaccess फ़ाइल में एक open_basedir फ़ाइल को परिभाषित करेंगे।

.htaccess फ़ाइल का उदाहरण:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

लेकिन सुनिश्चित करें कि आपने उपयोगकर्ता को ओपन_बेडिर को बदलने से रोकने के लिए .htaccess फ़ाइल पर सही अनुमतियाँ सेट की हैं (यदि वे इसे subdir / .htaccess में ओवरराइड करने का प्रयास करते हैं, तो यह काम नहीं करना चाहिए - लेकिन आपको यह सुनिश्चित करने के लिए संभवतः परीक्षण करना चाहिए) ।

HTH

सी।

— symcbean
स्रोत

2

यह नए खातों की कुछ प्रारंभिक सुरक्षा प्रदान करने में मदद कर सकता है। लेकिन यह तथ्य कि कोई उपयोगकर्ता इसे संपादित नहीं कर सकता है। इसे .htaccess फ़ाइल को हटाने के लिए प्रलोभन दिया जा सकता है (जो वे कर सकते हैं क्योंकि इसके लिए केवल public_html निर्देशिका तक पहुंच की आवश्यकता होती है) और अपना स्वयं का बनाएँ। प्रत्येक उपयोगकर्ता के लिए मुख्य कॉन्फ़िगरेशन में "<निर्देशिका>" को जोड़ना काम करेगा, लेकिन यहां उन्हें अभी भी php से बाहरी कमांड को बैकटिक करने की अनुमति है, जिसका अर्थ है कि ओपन_बेडिर को आसानी से दरकिनार किया जाता है।

— पोंटस

@Pontus: फ़ाइल को हटाने के बारे में अच्छी बात (मुझे यकीन नहीं है कि afs अपरिवर्तनीय फ़ाइल विशेषता का समर्थन करता है)। मैंने +1 दिया होगा यदि आपने कहा था कि चिरोट जेल में वेबसर्वर को चलाने से सभी प्रकार के प्रोग्राम निष्पादन कमजोरियों से बचाव होगा।

— सिम्बियन

1

AFS सरल यूनिक्स उपयोगकर्ता अनुमतियों की अनदेखी करता है। suPHP php प्रोग्राम को चलाने से पहले एक सेट्यूइड निष्पादित करता है, लेकिन यह प्रक्रिया को AFS तक पहुँचने के लिए आवश्यक केर्बेरस टोकन नहीं देता है और इसकी अनुमति तक ही सीमित है। suPHP को उस उपयोगकर्ता के रूप में AFS सिस्टम में प्रस्तुत करने से पहले उन टोकन को प्राप्त करने के लिए किसी तरह से संशोधित करना होगा। जहां तक मुझे पता है, वह नहीं किया गया है। (वास्तव में, मुझे यह प्रश्न तब मिला जब मैं यह देखना चाह रहा था कि क्या किसी और ने ऐसा किया है।)

— चार्ल्स बी
स्रोत