2012-05-10 10 views
6

क्या $_POST डेटा सुनिश्चित करने का कोई तरीका है जो मेरा कोड प्राप्त हुआ है, न कि बाहरी रूप से। असल में मैं नहीं चाहता कि कोई व्यक्ति $_POST को सार्वभौमिक रूप से उपलब्ध पृष्ठ जैसे खाता निर्माण में धोखा दे सके। खाता निर्माण पृष्ठ किसी भी उपयोगकर्ता द्वारा सुलभ है, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि केवल मेरे खाता_क्रिएशन फॉर्म द्वारा सबमिट किया गया डेटा संसाधित हो जाए।

एकमात्र चीज जिसे मैं सोच सकता था $_SESSION शुरू कर रहा था, और उसके बाद एक छुपा इनपुट का उपयोग कर फॉर्म में session_id की आपूर्ति कर रहा था। $ _POST पर छिपे हुए इनपुट के मूल्य को वर्तमान session_id के विरुद्ध मिलान किया जाएगा।

यदि इस परिणाम को प्राप्त करने के लिए कोई बेहतर तरीका है? अगर मैं इसे सुनने की आशा करता हूं।

उत्तर

7

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

ऐसा कहकर, ऐसी चीजें हैं जो सबमिट किए जा रहे डेटा को प्रतिबंधित और मान्य करने में आपकी सहायता कर सकती हैं। सबसे पहले, यह आवश्यक है कि उपयोगकर्ता (सत्र) कुकीज़ का उपयोग कर लॉग इन हो। यह अज्ञात उपयोगकर्ताओं द्वारा यादृच्छिक अनुरोध को समाप्त करता है। दूसरा, आप एक टोकन को एक छिपे हुए फ़ील्ड के रूप में एम्बेड कर सकते हैं जिसे आप उपयोगकर्ता के सत्र में भी सहेजते हैं। POST अनुरोध को मान्य होने के लिए उस टोकन को शामिल करने की आवश्यकता है। टोकन बस एक छद्म-यादृच्छिक स्ट्रिंग है।
आप फॉर्म फ़ील्ड्स के हैश तैयार करके इसे बढ़ा सकते हैं, जिसे आप उपयोगकर्ता को सबमिट करने की अपेक्षा करते हैं। यदि फॉर्म मान केवल पढ़ने के लिए ही किया जाना चाहिए, तो आप मान को हैश में भी शामिल कर सकते हैं। जैसे:

$rand = md5(mt_rand()); 
$hash = sha1('lastname:firstname:email:' . $rand); 

$_SESSION['rand'] = $rand; 
$_SESSION['hash'] = $hash; 

// on form submit: 

$keys = array_keys($_POST); 
$checkHash = sha1(join(':', $keys) . ':' . $_SESSION['rand']); 
if ($checkHash != $_SESSION['hash']) { 
    die('Form submission failed token validation'); 
} 

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

यह अभी भी इसका मतलब यह नहीं है कि उपयोगकर्ता वास्तव में डेटा जमा करने के लिए आपके फॉर्म का उपयोग करता है।

1

उपयोगकर्ता सत्यापन, उपयोगकर्ता_आईपी और कुछ अन्य $ _SERVER vars जैसे अतिरिक्त सत्यापन जोड़ने के लिए थोड़ा बेहतर है - वे दो हैं जिनका मैं उपयोग करता हूं।

तो, जैसा कि आप वर्णन करते हैं, अद्वितीय आईडी (या सत्र आईडी) बनाएं, लेकिन एजेंट और आईपी से भी थोड़ा अतिरिक्त सत्यापन जोड़ें। मूर्ख प्रमाण नहीं है, लेकिन सुरक्षा की एक और छोटी परत जोड़ता है।

संपादित करें: मुझे यह जोड़ना चाहिए कि आप उपयोगकर्ता एजेंट को वापस नहीं भेजते हैं; उस सर्वर की ओर रखें और चुपचाप सत्र आईडी के खिलाफ चुपचाप मान्य करें।

इसके अलावा, यदि कोई सबमिशन प्रमाणीकरण में विफल रहता है, तो कभी भी यह नहीं बताएं कि उपयोगकर्ता को वापस क्यों - इस तरह धोखा नहीं जानता कि उन्हें आपकी ट्रैकिंग कैसे करें। आप "5 invalids और आप बाहर हैं" ट्रैकिंग भी जोड़ सकते हैं, लेकिन इसके लिए आपको लॉगिन करने की आवश्यकता है।

1

सत्र आईडी का उपयोग करना निश्चित रूप से ऐसा करने का एक तरीका है। लेकिन अन्य विकल्प हैं (यदि सभी नहीं) जिनमें से कुछ डेटा छिपे हुए क्षेत्र के रूप में जोड़ना शामिल है।

  1. एक कैप्चा का उपयोग करें। यह हमेशा प्रत्येक पृष्ठ लोड के लिए अद्वितीय होगा और इसलिए अपने फॉर्म का उपयोग करना अनिवार्य है।
  2. यादृच्छिक डेटा जेनरेट करें और इसे डीबी में संग्रहीत करें (या केवल $_SESSION चर) और फ़ॉर्म सबमिट होने के बाद इसे जांचें।

विकल्प एक है जिसे मैं उपयोगकर्ता निर्माण फ़ॉर्म के लिए अनुशंसा करता हूं क्योंकि यह डबल ड्यूटी खींचता है। यह सुनिश्चित करता है कि $_POST डेटा आपके स्वयं के फॉर्म से आ रहा है, यह आपके स्वयं के फॉर्म के स्वचालित सबमिशन को रोकता है।

0

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

0

फॉर्म में एक अद्वितीय मूल्य डालने और सर्वर साइड सत्र में संग्रहीत मूल्य से मिलान करने के बहुत अच्छे उल्लेख हैं। ऐसा करें, लेकिन यह भी सोचें कि क्या होता है जब कोई उपयोगकर्ता बैक बटन का उपयोग करता है और संभवतः फॉर्म को दो बार सबमिट करने का प्रयास करता है, या वे दूसरी ब्राउज़र विंडो (उसी सत्र!) खोलते हैं, या वे आपकी साइट पर कई रूपों का उपयोग करते हैं।

अपने सिस्टम को न सोचकर पागल बग न बनाएं।

+0

इसके लिए धन्यवाद मैंने इस कार्रवाई के अन्य प्रभावों के बारे में सोचा नहीं था। हालांकि मुझे लगता है कि इन मुद्दों को इस तरह से इस्तेमाल किया जा सकता है जैसे कि अगर (! जारी ($ _ सत्र ['हैश']) {{हैश} बनाएं {अन्य मौजूदा हैश} का उपयोग करें। –

2
$ref = $_SERVER['HTTP_REFERER']; 
if($ref !== 'some site path/index.php') 
{ 
    die("Access Denied!"); 
} 

यह एक बाहर के प्रभाव से अपने डेटाबेस के लिए डेटा पोस्ट करने से ज्यादातर लोगों को रोकने चाहिए।

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