PHP साझा मेजबान

Question

पर डीबी और सत्र-डेटा को सुरक्षित करना मैंने SQLite और filesystem पर संग्रहीत सत्रों का उपयोग करके एक PHP वेब-एप्लिकेशन लिखा था।

यह कार्यात्मक रूप से बढ़िया और आकर्षक कम रखरखाव है। लेकिन, अब इसे एक साझा मेजबान पर चलाने की जरूरत है।

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

कई DBMS ऐसे में MySQL के रूप में सत्र स्टोर करने की अनुशंसा यह स्थिति। तो पहले मैंने सोचा कि मैं बस ऐसा करूँगा, और SQLite डेटा को MySQL में भी ले जाउंगा। लेकिन फिर मुझे एहसास हुआ कि MySQL प्रमाण-पत्रों को वेब एप्लिकेशन उपयोगकर्ता द्वारा पठनीय करने की आवश्यकता है, इसलिए मैं वापस वर्ग में हूं।

मुझे लगता है कि PHPCGI के रूप में उपयोग करने का सबसे अच्छा समाधान है, इसलिए यह प्रत्येक वेब-एप्लिकेशन के लिए अलग-अलग उपयोगकर्ता के रूप में चलता है। यह बहुत अच्छा लगता है, लेकिन मेरा होस्ट ऐसा नहीं करता है यह mod_php का उपयोग करता है। क्या इसे सक्षम करने के लिए व्यवस्थापक के बिंदु-दृश्य से कोई कमी है? (प्रदर्शन, पिछड़ा संगतता, आदि)? यदि नहीं तो मैं उन्हें सक्षम करने के लिए कहूंगा।

अन्यथा, क्या मैं इस स्थिति में अपना डेटाबेस और सत्र डेटा सुरक्षित करने के लिए कुछ भी कर सकता हूं?

Answer 1

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

यदि आपका होस्टिंग प्रदाता इसे अनुमति देगा, तो एक अलग उपयोगकर्ता के तहत एक सीजीआई के रूप में PHP के रूप में चलने में मदद मिलेगी, लेकिन मुझे उम्मीद है कि एक महत्वपूर्ण प्रदर्शन हिट होगा, क्योंकि प्रत्येक अनुरोध को एक नई प्रक्रिया की आवश्यकता होगी। (आप एफसीजीआई को बेहतर प्रदर्शन करने वाले विकल्प के रूप में देख सकते हैं।)

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

इस स्थिति में, आपको यह तय करने की आवश्यकता है कि साझा होस्टिंग की कम लागत का व्यापार अपर्याप्त सुरक्षा को देखते हुए स्वीकार्य है या नहीं। यह आपके आवेदन पर निर्भर करेगा, और यह सुरक्षा को जोड़ने के लिए एक जटिल (और संभवतः यहां तक ​​कि बहुत प्रभावी) तरीके से आने की कोशिश करने के बजाय, आप केवल जोखिम को स्वीकार करने से बेहतर हैं।

Answer 2

मैं सुरक्षा को सभी या कुछ भी नहीं देखता हूं। ऐसे कदम हैं जिन्हें आप ले सकते हैं। वेब डीबी उपयोगकर्ता को केवल उन्हीं अनुमतियों को दें जिन्हें इसकी आवश्यकता है। हैंश के रूप में पासवर्ड स्टोर करें। ओपनिड लॉगिन का उपयोग करें ताकि उपयोगकर्ता SSL पर अपने प्रमाण-पत्र प्रदान कर सकें।

सीजीआई पर PHP धीमा हो सकता है और कुछ होस्ट बस एक से अधिक पर्यावरण का समर्थन नहीं करना चाहते हैं।

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

Answer 3

यदि आप सर्वर को साझा करने वाली साइटों से गोपनीयता और सुरक्षा के बारे में जागरूक हैं, तो एक साझा होस्ट एक वेबसाइट चलाने का कोई तरीका नहीं है। आपके वेब एप्लिकेशन के लिए सुलभ कुछ भी दूसरों के लिए उचित खेल है; इससे पहले कि वे इसे एक्सेस कर सकें, यह केवल समय की बात होगी (माना जाता है कि उन्हें आपके लिए ऐसा करने का प्रोत्साहन है)।

Answer 4

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

मेरे पास खाता नहीं है इसलिए मैं इसे कम नहीं कर सकता .. लेकिन गंभीरता से यह प्रश्न के लिए भी प्रासंगिक नहीं है।

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

ओपी में मुझे लगता है कि सीजीआई के रूप में PHP सबसे सुरक्षित समाधान है, जैसा कि आपने पहले ही स्वयं को सुझाव दिया है। लेकिन जैसा कि किसी और ने कहा कि इसके साथ एक प्रदर्शन मारा गया है।

जो कुछ आप देख सकते हैं वह आपके सत्र और डीबी को MySQL पर ले जा रहा है और safe_mode और/या open_basedir का उपयोग कर रहा है।

Answer 5

मैं कोड कोड के बजाय एक इंफ्रास्ट्रक्चर परिवर्तन के साथ समस्या का समाधान करूंगा। एक वीपीएस सर्वर के उन्नयन पर विचार करें। आजकल आप उन्हें बहुत सस्ती प्राप्त कर सकते हैं। मैंने वीपीएस की शुरुआत @ 10 $/mo देखी है।