बाहरी http अनुरोधों को कैसे अवरुद्ध करें? (AJAX कॉल सुरक्षित करना)

Question

मैं डेटाबेस को अद्यतन करने के लिए पोस्ट का उपयोग करना चाहता हूं और नहीं चाहता कि लोग इसे मैन्युअल रूप से कर रहे हों, यानी, यह केवल क्लाइंट में AJAX के माध्यम से संभव होना चाहिए। क्या इस परिदृश्य में उपयोग करने के लिए कुछ प्रसिद्ध क्रिप्टोग्राफिक चाल है?

कहें कि मैं site.com/adduser/<userid> पर अपने डेटाबेस में एक नया उपयोगकर्ता डालने के लिए एक जीईटी अनुरोध जारी कर रहा हूं। कोई नकली अनुरोध जारी करके मेरे डेटाबेस को अधिक से अधिक कर सकता है।

Answer 1

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

Answer 2

यह किसी अन्य वेब पेज की तरह काम करता है: लॉगिन प्रमाणीकरण, रेफरर की जांच करें।

Answer 3

Prevent Direct Access To File Called By ajax Function प्रश्न का समाधान करने लगता है।

आप कर सकते हैं (अन्य समाधान के बीच में, मुझे यकीन है) ...

• उपयोग सत्र प्रबंधन (में प्रवेश करें एक सत्र बनाने के लिए);
• क्लाइंट को एक अनूठी कुंजी भेजें जिसे इसे समाप्त होने से पहले वापस करने की आवश्यकता है ( पुन: उपयोग नहीं किया जा सकता है, और बाद में उपयोग के लिए संग्रहीत नहीं किया जा सकता है);
• और/या जुड़े हुए उत्तरों में हेडर सेट करें।

लेकिन अगर लोग पर्याप्त मेहनत करते हैं तो कुछ भी खराब हो सकता है। एकमात्र पूरी तरह से सुरक्षित प्रणाली वह है जिसे कोई भी एक्सेस नहीं कर सकता है।

Answer 4

यह सीएसआरएफ के समान समस्या है - और समाधान समान है: AJAX अनुरोध में एक टोकन का उपयोग करें जिसे आपने व्यापक रूप से संग्रहीत किया है (या फिर पुन: उत्पन्न कर सकते हैं, उदाहरण के लिए sessin id का उपयोग करके पैरामीटर को एन्क्रिप्ट करके)। Chriss Shiflett पर इस पर कुछ समझदार नोट हैं, और PHP

Answer 5

के साथ सीएसआरएफ का पता लगाने के लिए OWASP project है। समाधान AJAX अनुरोधों के लिए बोल्ड लाइन जोड़ रहा है। इसके अलावा आपको बुनियादी प्रमाणीकरण को देखना चाहिए, यह एकमात्र संरक्षक नहीं होगा। आप अपने ajax पेज से

function callit() 
{ 
if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");} 
xmlhttp.onreadystatechange=function(){if(xmlhttp.readyState==4&&xmlhttp.status==200){document.getElementById('alp').innerHTML=xmlhttp.responseText;}} 
xmlhttp.open("get", "call.asp", true); 
**xmlhttp.setRequestHeader("X-Requested-With","XMLHttpRequest");** 
xmlhttp.send(); 
} 

पीएचपी इन कोड के साथ आय पकड़ कर सकते हैं

अजाक्स कॉल/एएसपी का अनुरोध किया गया पृष्ठ उत्तर

एएसपी

If Request.ServerVariables("HTTP_X-Requested-With") = "XMLHttpRequest" Then 
'Do stuff 
Else 
'Kill it 
End If 

पीएचपी

if(isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest')) 
{ 
//Do stuff 
} else { 
//Kill it 
} 

Answer 6

मुझे वास्तव में सर्वर तक पहुंच प्रतिबंधित करने की आवश्यकता नहीं है (हालांकि यह बहुत अच्छा होगा), मैं एक क्रिप्टोग्राफिक चाल की तलाश में हूं जो सर्वर को यह जानने की अनुमति देगा कि ऐप से चीजें कब आ रही हैं और उपयोगकर्ता द्वारा जाली नहीं है एक कठोर टोकन का उपयोग कर।

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

Answer 7

यह कुछ प्राधिकरण समस्या है: केवल अधिकृत अनुरोधों के परिणामस्वरूप एक नए उपयोगकर्ता का निर्माण होना चाहिए। तो जब ऐसा अनुरोध प्राप्त होता है, तो आपके सेवर को यह जांचने की आवश्यकता होती है कि यह उस क्लाइंट से है जो नए उपयोगकर्ताओं को बनाने के लिए अधिकृत है।

अब मुख्य मुद्दा यह तय करना है कि कौन सा अनुरोध अधिकृत है। ज्यादातर मामलों में, यह उपयोगकर्ता भूमिकाओं और/या कुछ टिकट प्रणाली के माध्यम से किया जाता है। उपयोगकर्ता भूमिकाओं के साथ, आपको उपयोगकर्ता पहचान और उपयोगकर्ता प्रमाणीकरण जैसे हल करने के लिए अतिरिक्त समस्याएं होंगी। लेकिन अगर यह पहले ही हल हो चुका है, तो आप आसानी से जैसे भूमिकाओं पर उपयोगकर्ताओं को मानचित्र कर सकते हैं ऐलिस एक व्यवस्थापक और बॉब नियमित उपयोगकर्ता है और केवल नए उपयोगकर्ता नए उपयोगकर्ता बनाने के लिए अधिकृत हैं।

Answer 8

यह हासिल किया जा सकता है।
जब भी आप कोई ऐसा पृष्ठ प्रस्तुत करते हैं जो ऐसा अनुरोध करना है। यादृच्छिक टोकन जेनरेट करें और उसे सत्र (प्रमाणीकृत उपयोगकर्ता के लिए) या डेटाबेस में संग्रहीत करें (यदि इस अनुरोध को सार्वजनिक रूप से अनुमति दी गई है)।
और बदले site.com/adduser/<userid> कॉल site.com/adduser/<userid>/<token>
बुला जब भी आप इस तरह के अनुरोध प्राप्त होता है, तो टोकन, वैध है या नहीं (सत्र या डेटाबेस से) है
मामले टोकन में सही है प्रक्रिया अनुरोध और सत्र से इस्तेमाल किया टोकन हटाने/db
की टोकन गलत होने पर, अनुरोध को अस्वीकार कर दें।