flawopen.com/फ़ाइल समावेशन/PHP include()
क्या उपयोगकर्ता इनपुट के साथ PHP include() सुरक्षित है?
नहीं। include() चुनी गई फ़ाइल को PHP के रूप में पार्स करता है, लेकिन प्रभाव उपलब्ध फ़ाइल और उसकी सामग्री पर निर्भर करता है। दोष wrapper के माध्यम से स्रोत दिखा सकता है या अनपेक्षित स्थानीय फ़ाइल शामिल कर सकता है। हमलावर-नियंत्रित PHP तभी निष्पादित होगा जब हमलावर PHP टैग वाली सामग्री नियंत्रित कर सके और ऐप उस फ़ाइल को शामिल करे। दूरस्थ URL समावेशन भी PHP कॉन्फ़िगरेशन पर निर्भर है। उपयोगकर्ता की चुनी कुंजी को स्थिर अनुमति-सूची से जोड़ें; अनुरोध से include पथ न बनाएँ।
<?php // User-controlled path: unintended local file include $_GET['page'] . '.php'; // Example selector: ../../private/sample // Impact depends on the resolved file and // whether it contains PHP code to interpret. // Remote URL inclusion requires the relevant // URL wrapper and allow_url_include setting. // Wrappers can change which resource is read; // php://filter is a read filter, not a path // containment check.
<?php // Allowlist: input selects a KEY, // never a path or wrapper. $pages = [ 'home' => __DIR__ . '/pages/home.php', 'about' => __DIR__ . '/pages/about.php', 'contact' => __DIR__ . '/pages/contact.php', ]; $key = $_GET['page'] ?? 'home'; if (!is_string($key) || !array_key_exists($key, $pages)) { http_response_code(404); exit; } include $pages[$key];
स्थानीय समावेशन अपने-आप कोड निष्पादन क्यों नहीं है
स्थानीय समावेशन अपने-आप कोड निष्पादित नहीं करता। PHP शामिल फ़ाइल को पार्स करता है: वैध PHP टैग के भीतर निर्देश शामिल करने वाले संदर्भ में चलते हैं; अन्य बाइट आउटपुट बन सकते हैं। निष्पादन के लिए हमलावर-नियंत्रित PHP वाली पहुँच योग्य फ़ाइल या अन्य शोषणीय व्यवहार चाहिए। अपलोड या लॉग-लेखन दोष श्रृंखला बना सकता है यदि वह नियंत्रित PHP सामग्री ऐसी फ़ाइल में रखे जिसे बाद में शामिल किया जाता है।
php://filter स्ट्रीम खोलते समय फ़िल्टर लागू करता है। असुरक्षित पठन या समावेशन प्रवाह में उपयुक्त फ़िल्टर स्रोत-पाठ को निष्पादित किए बिना उजागर कर सकता है; पहुँच wrapper, अनुमतियों और कॉन्फ़िगरेशन पर निर्भर है।
पथ साफ़ करना सही समाधान क्यों नहीं
../ हटाना, स्थिर एक्सटेंशन जोड़ना या निर्देशिका का उपसर्ग लगाना यह सिद्ध नहीं करता कि अंतिम संसाधन स्वीकृत है। एन्कोडिंग, निरपेक्ष पथ, प्लेटफ़ॉर्म नियम और wrapper अर्थ बदल सकते हैं। संसाधन-नाम पर उपयोगकर्ता का नियंत्रण हटाएँ: ऐप द्वारा परिभाषित स्थिर कुंजियाँ ही स्वीकारें।
यदि पथ हल करना आवश्यक हो, तो realpath() से canonicalize करें और Path Traversal मार्गदर्शिका की तरह निर्देशिका सीमा जाँचें। परिणाम को स्वीकृत फ़ाइलों तक सीमित रखें तथा symlink और जाँच-उपयोग दौड़ पर विचार करें। स्थिर लक्ष्यों की अनुमति-सूची अधिक सुरक्षित है।
अक्सर पूछे जाने वाले प्रश्न
यह विकल्प include/require के URL wrappers बंद करता है। PHP में यह डिफ़ॉल्ट रूप से बंद है और PHP 7.4 से deprecated है। यह दूरस्थ समावेशन का जोखिम घटाता है, लेकिन स्थानीय traversal या असुरक्षित स्थानीय include नहीं रोकता। इसे बंद रखें और लक्ष्य पर उपयोगकर्ता का नियंत्रण हटाएँ।
PHP 5.3.4 ने पथ-प्रबंधन में null-byte truncation ठीक किया। पुरानी तकनीक के न चलने को सुरक्षा न मानें: अविश्वसनीय include लक्ष्य अब भी असुरक्षित हैं।
require और _once रूप भी लक्ष्य शामिल करके पार्स करते हैं; विफलता और दोहराव का व्यवहार अलग है, पर अविश्वसनीय लक्ष्य सुरक्षित नहीं होता। readfile() और file_get_contents() PHP के रूप में पार्स किए बिना डेटा लौटाते हैं; अविश्वसनीय पथ traversal या खुलासा कर सकता है।