php

जीईटी और पोस्ट पैरामीटर में प्रमाणीकरण की आवश्यकता है, न केवल कुकीज़ में सीएसआरएफ को रोकना;php
HTTP रेफरर शीर्षलेख की जांच करना;

विकिपीडिया पर इस पोस्ट को देखा था और सोच रहा था कि कैसे मैं उन्हें

ठीक लागू कर सकते हैं ... मैं Kohana PHP ढांचे का उपयोग कर रहा हूँ और मैं संदर्भ शीर्ष निर्धारित करने के लिए सुविधा है, लेकिन वास्तव में क्या करना मैं रेफरर हेडर में जांचता हूं? फ्रेमवर्क फ़ंक्शन केवल रेफरर

का URL देता है और मैं GET और POST पैराम्स को कैसे सत्यापित करूं? क्या के खिलाफ? संग्रहीत जानकारी? अपेक्षित प्रकार?

स्रोत

2009-11-23 yretuta

सीएसआरएफ को रोकने के लिए आप एक बार टोकन, POST'ed और वर्तमान सत्र से जुड़े प्रमाणित करना चाहते हैं। निम्नलिखित की तरह कुछ। । ।

पृष्ठ जहाँ उपयोगकर्ता अनुरोधों एक रिकार्ड नष्ट करने के लिए पर:

confirm_save.php: जब यह वास्तव में रिकॉर्ड को हटाने की बात आती है

confirm.php

<?php session_start(); $token= md5(uniqid()); $_SESSION['delete_customer_token']= $token; session_write_close(); ?> <html> <body> <form method="post" action="confirm_save.php"> <input type="hidden" name="token" value="<?php echo $token; ?>" /> Do you really want to delete? <input type="submit" value=" Yes " /> <input type="button" value=" No " onclick="history.go(-1);" /> </form> </body> </html>

फिर

<?php 
session_start(); 
$token = $_SESSION['delete_customer_token']; 
unset($_SESSION['delete_customer_token']); 
session_write_close(); 
if ($token && $_POST['token']==$token) { 
    // delete the record 
} else { 
    // log potential CSRF attack. 
} 
?>

टोकन को अनुमान लगाने में कठिनाई होनी चाहिए, प्रत्येक हटाए गए अनुरोध के लिए अद्वितीय, केवल $ _POST के माध्यम से स्वीकार किया गया है और कुछ मिनटों के बाद समाप्त हो गया है (इस उदाहरण में समाप्ति नहीं हुई है)।

स्रोत

2009-11-23 01:41:45 leepowers

सत्र की समाप्ति पर्याप्त नहीं होनी चाहिए? मेरा मतलब है कि एक कस्टम फ़ंक्शन के साथ समाप्ति की जांच न करें। –

सत्र CSRF @JavierConstanzo को नहीं रोकते हैं। कभी-कभी वे सप्ताह या उससे अधिक के लिए रहते हैं।यदि आपका सत्र अभी भी सक्रिय है, तो सीएसआरएफ हमले के साथ वेबसाइट खोलने पर क्या होता है? –

आप अपने सर्वर @EdsonMedina को ऐसे सत्र रखने के लिए क्यों कॉन्फ़िगर करेंगे जो सप्ताह तक चलते हैं? मुझे पता है कि सीएसआरएफ को रोकने के लिए सत्र पर्याप्त नहीं हैं, मैं इसका मतलब नहीं लगा रहा था। –

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

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

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

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

स्रोत

2009-11-23 01:42:17 Einstein

बहुत सच है, HTTP रेफरर हेडर आसानी से जाली जा सकती है और सीएसआरएफ के खिलाफ कोई वास्तविक सुरक्षा प्रदान नहीं करती है। – leepowers

[नोट:] कोहाना फ्रेमवर्क को अस्वीकार कर दिया गया है, कोहाना PHP 7 के लिए नया कांटा https://koseven.ga/ है और यह सीएसआरएफ कार्यक्षमता का समर्थन करता है सुरक्षा वर्ग है।

आप आधिकारिक कोज़वेन सुरक्षा सुविधा का उपयोग कर सकते हैं। यहां koseven security class का एक लिंक है।

स्रोत

2015-11-13 13:00:38 Faraz

उत्तर

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