PHP में UNLINK सुरक्षा जोखिमों से कैसे बचें?

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

तो मुझे केवल उस उपयोगकर्ता के लिए फ़ाइल को हटाने की अनुमति देने के लिए मुझे कैसे करना चाहिए?

कृपया मुझे अन्य बातों के भी पता है अगर आपको लगता है मैं यहाँ कुछ गलत या कुछ और कर रहा हूँ जाने क्या आपके मन में है और आपको लगता है कि यह उपयोगी होगा:)

मेरे PHP कोड:

<?php 

    $photo_id  = $_GET['photo_id']; 
    $thumbnail_id = $_GET['thumbnail_id'];  

    function deletePhotos($id){ 
     return unlink($id); 
    } 

    if(isset($photo_id)){ 
     deletePhotos($photo_id); 
    } 
    if(isset($thumbnail_id)){ 
     deletePhotos($thumbnail_id); 
    } 


?>

मेरे AJAX कोड:

function deletePhoto(photo, thumbnail){ 

     var photos = encodeURIComponent(photo); 
     var thumbnails = encodeURIComponent(thumbnail); 

     if (window.XMLHttpRequest) {// code for IE7+, Firefox, Chrome, Opera, Safari 
      xmlhttp=new XMLHttpRequest(); 
     } else {// code for IE6, IE5 
      xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
     } 

     xmlhttp.onreadystatechange=function() { 
      if (xmlhttp.readyState==4 && xmlhttp.status==200) { 
       document.getElementById("media").innerHTML=xmlhttp.responseText; 
      } 
     } 
     xmlhttp.open("GET", "http://192.168.2.104/images/users/delete_photo.php?photo_id="+photos+"&thumbnail_id="+thumbnails, true); 
     xmlhttp.send(); 
    }

स्रोत

2010-08-05 Adam

AJAX लेना देना नहीं है सुरक्षा के साथ। सर्वर के दृष्टिकोण से, AJAX कॉल नियमित से अलग नहीं है। आपकी समस्या AJAX में नहीं बल्कि प्राधिकरण की कमी में है। जल्द ही आप इसे समझते हैं, जितनी जल्दी आप अपनी समस्या का समाधान करते हैं। –

हाय @ कोल। श्रापनेल, मुझे नहीं लगता कि आप पूरी तरह से सही हैं, क्योंकि 'AJAX' के बिना मुझे फ़ाइल बनाने की आवश्यकता नहीं है जो कोई भी एक्सेस कर सकता है और जीईटी अनुरोध के साथ कुछ भी हटा सकता है। अन्यथा मुझे पता है कि यहां समस्या प्राधिकरण के साथ है इसलिए मैंने इस सवाल से पूछा है, तो मुझे केवल उस उपयोगकर्ता के लिए फ़ाइल को हटाने की अनुमति देने के लिए कैसे करना चाहिए? – Adam

उपयोगकर्ता बिना किसी फ़ाइल को कैसे हटा सकता है पटकथा? –

आपको किसी भी तरह उपयोगकर्ता को प्रमाणीकृत करने की आवश्यकता है।

आपके उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड के साथ प्रमाणित करने की आवश्यकता है।

PHP सत्र को याद रखने के लिए उपयोग किया जा सकता है, और आपको फ़ाइल स्वामित्व जानकारी संग्रहीत करने के लिए सर्वर पर डेटाबेस तालिका या टेक्स्ट फ़ाइल का उपयोग करना चाहिए।

फिर, कुछ भी अनलिंक करने से पहले, आपके तर्क को यह सुनिश्चित करना चाहिए कि वर्तमान में "प्रमाणीकृत" उपयोगकर्ता फ़ाइल का स्वामी है।

स्रोत

2010-08-05 14:02:50

यदि आप लॉग इन करना चाहते हैं, तो उपयोगकर्ता लॉग इन है। अगर मैं उन उपयोगकर्ताओं तक पहुंचने की अनुमति नहीं देता जो लॉग इन नहीं हैं, तो थोड़ा बेहतर है, लेकिन जो उपयोगकर्ता लॉग इन हैं अभी भी एक-दूसरे की फाइलों को हटा सकते हैं। – Adam

यही कारण है कि आपको किसी अन्य तालिका में फ़ाइल स्वामित्व को स्टोर करने की आवश्यकता है, और कुछ भी अनलिंक करने से पहले आप सुनिश्चित करते हैं कि "प्रमाणीकृत" उपयोगकर्ता फ़ाइल का स्वामी है। –

यहां एकमात्र समझदार उत्तर है। @CIRK उपरोक्त उस टिप्पणी को सुनो। यही एकमात्र समाधान है। आप पूरी तरह गलत तरीके से जा रहे हैं। AJAX आपकी समस्या नहीं है –

तस्वीरों के साथ निर्देशिका को अनलिंक करना सीमित करें। यही है, पथ में .. की अनुमति न दें, या realpath() करने के बाद पूरा पथ देखें। अन्यथा, उपयोगकर्ता delete_photo.php?photo_id=../../../../etc/passwd का अनुरोध कर सकता है और सिस्टम को तोड़ सकता है।

स्रोत

2010-08-05 14:04:47 Sjoerd

यदि वे एक अलग चरित्र सेट में '..' एन्कोड करते हैं, तो यह संभावित रूप से गुजर सकता है। मैंने अतीत में इसके बारे में पढ़ा है। –

@ वादिह हां, लेकिन यह एक दोष था (मुझे अपाचे में लगता है) जो तब से तय किया गया था। –

यदि php रूट के रूप में चल रहा है तो मुझे लगता है कि आपके हाथों में बड़ी समस्याएं हैं। – rook

अपने PHP में:

सुनिश्चित करें $ _GET [ 'photo_id'] और $ _GET [ 'thumbnail_id'] शामिल नहीं है "../"
यह भी सुनिश्चित करें कि आप एक basepath पहले जोड़ें बनाना आईडी के लिए।

अन्यथा उपयोगकर्ता किसी भी फ़ाइल को हटा सकते हैं।

स्वामित्व के लिए, आपको उस जानकारी को संग्रहीत करना होगा जो सर्वर की ओर कहीं भी फ़ाइल का मालिक है (उदाहरण के लिए एक MySQL-DB)। फिर फ़ाइल को हटाने से पहले आपको इस स्थान से परामर्श लेना चाहिए।

स्रोत

2010-08-05 14:05:06 JochenJung

-1

एक अलग सुझाव: डिस्क पर फ़ाइलों को स्टोर न करें, लेकिन उन्हें डेटाबेस में रखें। यह आपकी साइट + स्क्रिप्ट और "उपयोगकर्ता डेटा" के बीच एक बहुत स्पष्ट अंतर रखता है।

(किसी ने मुझे एक बार कहा था कि फाइलें फाइलें थीं, और डेटाबेस डेटा के लिए थे, और वे अलग हैं, लेकिन जैसा कि मैंने इसे देखा है, फाइलों में डेटा भी है। Mysql में कुछ भी डालने के लिए एक आदर्श LONGBLOB प्रकार है, और आप कर सकते हैं एक ही डेटा पंक्ति है, जो चीजों को स्वच्छ और सरल रहता है)

स्रोत

2010-08-05 14:11:41 mvds

छवियों के मामले में मुझे नहीं लगता कि डेटाबेस में उन्हें प्रदर्शित करना एक अच्छा विचार है (प्रदर्शन कारणों से)। उन्हें प्रदर्शित करते समय कारण डेटाबेस से पढ़ने के लिए आपको एक PHP स्क्रिप्ट की आवश्यकता होती है। चूंकि छवियां पृथक HTTP अनुरोध हैं, इसके परिणामस्वरूप डेटाबेस के लिए कई कनेक्शन होंगे, जिन्हें स्थापित करने की आवश्यकता है। – JochenJung

+1 यह एक अच्छा विचार है। – rook

फ़ैई, माइक्रोसॉफ्ट शेयरपॉइंट 3.0 करता है (डीबी में फाइलों को स्टोर करता है)। मैं इस निर्णय से जरूरी नहीं हूं, क्योंकि मैं एक आस्तिक हूं कि 'फाइल सिस्टम' को टैबलेट डेटा के लिए 'फाइल' और 'डेटाबेस' स्टोर करने के लिए इस्तेमाल किया जाना चाहिए। लेकिन कुछ डिजाइनों में यह डिजाइन पैटर्न समझ में आएगा। –

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

जैसा कि मैंने पहले कहा था, varaibles नाम दें ताकि वे सही लग सकें। जब मैं एक varaiable में "आईडी" देखते हैं। मैं स्वचालित रूप से एक प्रोग्रामर के रूप में मानता हूं कि यह एक संख्यात्मक var है।

स्रोत

2010-08-05 14:13:55 Anraiki

आईडी कोई अंक नहीं है: डी यह 'efb03_orange.png' की तरह कुछ उनके सामने कुछ अद्वितीय सामग्री के साथ' file_name' है। समस्या यह है कि इस खंड में मैंने अभी तक डेटाबेस में कुछ भी नहीं भेजा है। तो मुझे नहीं पता कि कैसे लॉग इन किया गया उपयोगकर्ता उपयोगकर्ता का फ़ाइल है या नहीं। – Adam

मुझे लगता है कि var के लिए ब्रेकिंग नामकरण सम्मेलन की तरह। $ ImagePlaceholder की तरह होना चाहिए। मैं आपकी टिप्पणी के जवाब में और अपडेट करूंगा। – Anraiki

मैं सिर्फ देखा कि ... और घेरा से अधिक व्यक्ति कूद बनाने आवश्यक नहीं हो सकता एक बार फ़ाइल के मालिक के "सत्यापन" के माध्यम से चला जाता है। – Anraiki

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

बस कुछ की तरह

$photo_id = basename($_GET['photo_id'];) 
$filename = $filebase.$_SESSION['user_id']."/".$photo_id; 
if (file_exists($filename) unlink ($filename);

स्रोत

2010-08-05 14:42:14

एक ही समस्या पड़ा है और इसके चारों ओर PHP के ftp_delete समारोह का उपयोग कर गया

स्रोत

2011-06-07 08:05:59 WIGPIP

PHP में UNLINK सुरक्षा जोखिमों से कैसे बचें?

उत्तर

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