PHP के मूल कार्यों को unfiltered इनपुट के साथ उपयोग करने के लिए कितने सुरक्षित हैं?

शायद मैं थोड़ा उलझन में हूं, लेकिन जैसा कि मैं एक संपर्क मॉड्यूल को फिर से लिख रहा हूं, निम्नलिखित प्रश्न ध्यान में आया:PHP के मूल कार्यों को unfiltered इनपुट के साथ उपयोग करने के लिए कितने सुरक्षित हैं?

क्या मैं php के मूल कार्यों में unfiltered इनपुट का उपयोग कर सकता हूं?

यह एक डेटाबेस में डाल करने के लिए सामान, स्क्रीन करने के लिए उत्पादन, आदि को साफ़ करने में आसान है, लेकिन अगर उदाहरण के लिए निम्नलिखित बयान खतरनाक हो सकता है मैं सोच रहा था:

if (file_exists($_POST['brochure'])) { 
     // do some stuff 
    }

अगर किसी को किसी भी तरह पोस्ट करने में कामयाब उस पृष्ठ पर, उपर्युक्त कोड का शोषण किया जा सकता है?

उपर्युक्त कोड केवल एक उदाहरण है, मैं किसी अन्य प्रसंस्करण के दौरान उपयोग किए जाने वाले अन्य कार्यों के बारे में सोच सकता हूं।

संपादित करें: धन्यवाद सब लोग, उदाहरण में file_exists वास्तव में एक स्वच्छता समारोह के हिस्से के लेकिन जब सफाई है, php कार्यों के लिए इस्तेमाल किया जा रहा है ताकि यह तेजी से एक चिकन और अंडे की कहानी बनता जा रहा है: कार्यों का उपयोग करने के लिए, मेरे पास है साफ करने के लिए, लेकिन साफ करने के लिए मुझे कार्यों का उपयोग करना है।

वैसे भी, मुझे अब कुछ नए विचार मिल गए हैं।

स्रोत

2009-03-12 jeroen

हाँ। मुझे बस इतना करना होगा कि आपके पृष्ठ पर "/ etc/passwd", या "शामिल/dbconnection.php" (या कुछ भी) पोस्ट करें, और //do some stuff वास्तव में क्या है, मैं संवेदनशील जानकारी को हटा, संशोधित या पढ़ सकता हूं । file_exists फ़ंक्शन स्वयं कुछ भी नहीं करेगा जो आप उम्मीद नहीं करेंगे, लेकिन आप दुर्भावनापूर्ण उपयोगकर्ताओं को अपने तर्क का शोषण करने की उम्मीद कर सकते हैं।

हमेशा अपने उपयोगकर्ता इनपुट को स्वच्छ करें। हमेशा। आप केवल एक विशेष फ़ोल्डर से फ़ाइल को पकड़ने की आशा रखते हैं तो अनुमति नहीं .. या/इनपुट में

स्रोत

2009-03-12 00:25:42 nickf

सकता है 'विवरणिका' = '../../../../.htaccess'

कि एक दिलचस्प सवाल है।

मेरे कंप्यूटर पर अपाचे लिस्टिंग या इन्हें .ht * और .ini और .php.inc फ़ाइलों को अस्वीकार करने के लिए सेट है, लेकिन अब आप मुझे चिंतित हैं।

स्रोत

2009-03-12 00:24:28 m42

php apache तुलना में बहुत अधिक फ़ाइलों तक पहुँच नहीं है। .ht * और .ini फ़ाइलों को प्रदर्शित करने से अपाचे को रोकना php को पढ़ने से रोक नहीं पाएगा। – Marius

@ मैरियस यह बहुत सच है। – UnkwnTech

उत्कृष्ट बिंदु gents। मैं यहां चौंकाने वाली चीजें सीख रहा हूं :) – m42

PHP के builtins काम नहीं चलेगा बुरा इनपुट पर "अप्रत्याशित" चीजें (जैसे, file_exists("foo; rm -r /") कहेंगे "नहीं, फ़ाइल 'foo; rm -r /' मौजूद नहीं है") ... और यदि वे करते हैं, तो यह एक बग है जिसे आप ज़ेंड के खिलाफ फाइल कर सकते हैं।

बेशक

, इस अपने कोड का शोषण से नहीं लोग बंद करता है (जैसे, file_exists("../hidden/shell.php")) है, तो आप चाहिए अभी भी (वास्तव में, आप चाहिए हमेशा) सावधान जब चारों ओर उपयोगकर्ता के आपूर्ति इनपुट गुजर हो।

स्रोत

2009-03-12 00:26:55

अपने आप में, यह उचित रूप से सुरक्षित दिखता है, लेकिन इसका उपयोग जानकारी प्रकट करने के लिए किया जा सकता है। यह किसी हमले को विशेष फ़ाइलों की उपस्थिति (या अनुपस्थिति) की जांच करने की अनुमति दे सकता है (उदा। /etc/passwd, /proc/*, आदि)।

तो इस उदाहरण में, आपको यह सुनिश्चित करना चाहिए कि $_POST['brochure'] केवल उन वैध इनपुट को स्वीकार करने के लिए स्वच्छताकृत है जो संभवतः वैध फ़ाइल नामों से मेल खाते हैं। .. वाले किसी भी इनपुट को ड्रॉप करें, या यह / से शुरू होता है।

अन्य कार्य संभवतः बहुत खराब दुष्प्रभाव हो सकता है ...

स्रोत

2009-03-12 00:26:57 Alnitak

मान्य फ़ाइल नामों की हमेशा मौजूदा सूची रखने की आपकी विधि क्या है? आपके द्वारा जांच की जाने वाली सभी संभावनाओं के मैन्युअल रूप से अद्यतन हैश/सरणी? यदि $ ब्रोशर $ निर्देशिका में नहीं है हैश? – m42

किसी सूची की आवश्यकता नहीं है, आमतौर पर केवल एक regexp जो स्पष्ट तरीकों को फ़िल्टर करता है कि एक हमलावर निर्देशिका के बाहर मौजूद किसी फ़ाइल को एक्सेस कर सकता है जहां फ़ाइलों को सेवा के लिए लक्षित किया जाता है। – Alnitak

आप वास्तव में सभी इनपुट को छानने की आदत में होना चाहिए, लेकिन आप http://www.hardened-php.net/ जो एक सख्त पैच और 'Suhosin' वितरित करता है की जाँच करना चाहते हो सकता है, डिफ़ॉल्ट रूप से जो कई द्विआधारी वितरण में है (OpenSUSE, मैंड्रिवा और Debian/Ubuntu)

स्रोत

2009-03-12 00:28:09

धन्यवाद, मेरे पास पहले से ही पैच स्थापित है। – jeroen

सच है कि आप पूछने के लिए कि अपने जवाब है। यह सुरक्षित नहीं है।

file_exists() दूसरों के जितना बुरा नहीं है, लेकिन यदि आप उस फ़ंक्शन के लिए स्रोत कोड नहीं देखते हैं, तो आप डेटा पास कर रहे हैं, और जानते हैं कि यह उपयोगकर्ता इनपुट को कैसे प्रबंधित करता है, तो आप एक मौका ले रहे हैं।

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

हमेशा एक शत्रुतापूर्ण उपयोगकर्ता मान और सबसे खराब वे संभवतः अगर वे अपने स्रोत कोड देखा कर सकता है।

स्रोत

2009-03-12 00:29:11 danieltalsky

वर्षों से सुरक्षा भेद्यता PHP के स्रोत में पाई गई है, जैसे कि फ़ंक्शन बफर ओवरफ्लो शैली के हमलों के लिए संदिग्ध थे Suhosin एक परियोजना है जो कुछ जोखिम को हटाने के लिए PHP को पैच करती है।

स्रोत

2009-03-12 00:29:39

-1

क्या डेटाबेस स्ट्रिंग के साथ होता है कि यह लिया गया और कहीं एक जोखिम है कि इस्तेमाल किया जा सकता है। अपने प्रश्न के उत्तर के लिए, चरण को हटाने के बारे में सोचें जहां आप स्ट्रिंग को स्टोर करते हैं और फिर इसे पुनर्प्राप्त करते हैं। आप इसे तुरंत उपयोग करते हैं, और आपके पास समान जोखिम हैं।

स्रोत

2009-03-12 00:29:42 gbarry

धन्यवाद, लेकिन मुझे डर है कि मेरे पास कोई सुराग नहीं है जिसके बारे में आप बात कर रहे हैं। आपका क्या अर्थ है? – jeroen

मेरा मतलब यह है कि unfiltered उपयोगकर्ता इनपुट का उपयोग हमेशा PHP में खतरनाक माना जाता है। किसी के लिए शोषण करने के लिए किसी के लिए यह बहुत आसान है। डेटाबेस के संबंध में आप इससे परिचित लग रहे थे; मैं यह इंगित कर रहा था कि समस्या उसमें नहीं है लेकिन उपयोगकर्ता इनपुट के साथ ही है। – gbarry

मैं बिल्कुल भी उन कार्यों पर भरोसा नहीं होता।

यह निश्चित रूप से दृढ़ता से ध्वनि हो सकता है, हालांकि जब मैं पिछले आठ वर्षों में लोगों और उनके सी कोड की गुणवत्ता को बारीकी से देखता हूं, वापस करता हूं, तो मैं लगातार डर में हूं।

स्रोत

2009-03-12 00:31:45 mark

PHP के मूल कार्यों को unfiltered इनपुट के साथ उपयोग करने के लिए कितने सुरक्षित हैं?

उत्तर

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