तो मुझे एक PHP फ़ाइल में मूल .ajax() POST विधि मिली है।क्या मुझे jQuery .ajax() के लिए एक CSRF टोकन चाहिए?
मुझे किस सुरक्षा उपायों की आवश्यकता है?
आसपास के कुछ पोस्ट एक छुपा एमडी 5 इनपुट फ़ील्ड का उपयोग करके उल्लेख कर रहे थे जिसे आप AJAX के माध्यम से भेजते हैं और PHP फ़ाइल में सत्यापित करते हैं। क्या यह एक अच्छी पर्याप्त विधि है?
सीएसआरएफ का जोखिम यह है कि एक बाहरी साइट आपके लिए डेटा भेज सकती है और उपयोगकर्ता ब्राउज़र स्वचालित रूप से प्रमाणीकरण कुकी भेज देगा।
आपको प्राप्त करने की कार्रवाई के लिए कुछ तरीका है (कि आपकी $.ajax() विधि POST डेटा भेज रही है) यह जांचने में सक्षम है कि अनुरोध बाहरी साइट की बजाय आपकी साइट पर किसी अन्य पृष्ठ से आया है।
ऐसा करने के कुछ तरीके हैं, लेकिन अनुशंसित तरीका उस अनुरोध को टोकन जोड़ना है जिसे आप जांच सकते हैं और हैकर्स नहीं मिल सकते हैं।
इसके सरलतम पर:
$.ajax() अनुरोध में एक पैरामीटर जोड़ें जिसमें टोकन शामिल है।हैकर आपके डीबी को प्राप्त कर सकते हैं नहीं और नहीं वास्तव में पृष्ठ आप उपयोगकर्ता के लिए भेज दिया है पढ़ सकते हैं (जब तक कि वे में एक XSS हमले मिलता है, लेकिन है कि एक और समस्या है) तो धोखा नहीं कर सकता टोकन।
सभी कि टोकन के माध्यम से मायने रखती है कि आप भविष्यवाणी कर सकते हैं (और मान्य) है यह और है कि हैकर नहीं कर सकता।
इस कारण से कुछ लंबा और यादृच्छिक उत्पन्न करना और डीबी में इसे स्टोर करना सबसे आसान है, लेकिन आप इसके बजाय कुछ एन्क्रिप्टेड बना सकते हैं। मैं केवल उपयोगकर्ता नाम MD5 नहीं होगा - अगर सीएसआरएफ हमलावर यह पता लगाते हैं कि आपके टोकन कैसे उत्पन्न करें, तो आपको हैक किया जाएगा।
टोकन को स्टोर करने का एक और तरीका कुकी में है (आपके डेटाबेस के बजाए), क्योंकि हमलावर आपकी कुकीज़ को पढ़ या बदल नहीं सकते हैं, बस उन्हें फिर से भेजा जा सकता है। फिर आप कुकी में HTTP पोस्ट डेटा मिलान टोकन में टोकन हैं।
आप इन्हें बहुत अधिक परिष्कृत बना सकते हैं, उदाहरण के लिए एक टोकन जो हर बार सफलतापूर्वक उपयोग किया जाता है (पुनर्वितरण को रोकता है) या उपयोगकर्ता और कार्रवाई के लिए विशिष्ट टोकन, लेकिन यह मूल पैटर्न है।
अनुरोध जालसाज़ी के मामले में, इससे कोई फर्क नहीं पड़ता कि क्लाइंट अनुरोध कैसे भेजता है, यह महत्वपूर्ण है कि यह कैसे प्राप्त हुआ। एक ही सीएसआरएफ नियम किसी अन्य प्रकार की पोस्ट के रूप में AJAX पोस्ट के लिए आवेदन करते हैं।
मैं CSRF prevention cheat sheet पढ़ने की सलाह देता हूं। प्रति उपयोगकर्ता गुप्त टोकन का उपयोग सुरक्षा का सबसे आम रूप है।
काफी आम भी प्रति-अनुरोध एक बार टोकन, पहली बार उपयोग करने के बाद विशिष्ट उपयोगकर्ता और विकलांगों के लिए अधिग्रहण कर लिया है। – Tadeck
@Tadeck यह दृष्टिकोण सीएसआरएफ की तुलना में डबल-सबमिशन को रोकने के लिए अधिक उपयोगी है। – rook
जैसा कि आपने संदर्भित स्रोत [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet) के भीतर बताया है, एक बार टोकन उच्च जोखिम वाले कार्यों के भीतर बहुत मजबूत सुरक्षा का उपयोग किया जाता है। यह "सीएसआरएफ_ की तुलना में डबल-सबमिशन को रोकने के लिए अधिक उपयोगी" होने के विपरीत कुछ है, यह सीएसआरएफ के खिलाफ आपके आवेदन को सुरक्षित करने का अधिक सख्त तरीका है। – Tadeck
कोई टोकन की आवश्यकता नहीं है, लेकिन आपको अभी भी सीएसआरएफ के खिलाफ राज्य बदलने वाले किसी भी कार्य की रक्षा करनी चाहिए।
ऐसा करने का एक आसान तरीका AJAX अनुरोध के साथ भेजा गया हैडर जोड़ रहा है। कोई यादृच्छिक टोकन की आवश्यकता नहीं है।
यह काम करता है क्योंकि:
बेशक सर्वर-साइड कोड को यह सुनिश्चित करने की आवश्यकता है कि शीर्षलेख उसकी क्रिया निष्पादित करने से पहले मौजूद है।
और जानकारी: What's the point of the X-Requested-With header?
उपयोगकर्ता किसी अन्य वेबसाइट से AJAX अनुरोध कैसे पोस्ट कर सकता है हालांकि [समान मूल नीति] (https://en.wikipedia.org/wiki/Same-origin_policy) ऐसे व्यवहार को रोकता है? – Songo
@ सोंगो सभी ब्राउज़रों का समर्थन नहीं करता है, दुर्भाग्य से। बहुत सारे प्रॉक्सी स्ट्रिप हेडर और उसे भी तोड़ते हैं। अंत में आप मूल से बाहर पोस्ट कर सकते हैं, भले ही आप AJAX का इरादा रखते हैं जिसका अर्थ यह नहीं है कि हमलावर होगा। असल में आपके पास एक समान मूल नीति होनी चाहिए, लेकिन क्योंकि यह अच्छी तरह से व्यवहार किए गए ब्राउज़र पर निर्भर करता है, आपको उस पर भरोसा नहीं करना चाहिए। एक सीएसआरएफ टोकन का उपयोग आपको ऐसा कुछ देता है जिसे आप सत्यापित कर सकते हैं भले ही समान-उत्पत्ति को बाधित किया गया हो। – Keith
@ सैंगो क्रोम के नवीनतम संस्करण के साथ भी, आप अभी भी अनुरोध प्राप्त कर सकते हैं (यानी '''' एक वेबपृष्ठ पर टैग) और यह काम करेगा। @ किथ मैं एक कुकी पर भरोसा नहीं करता क्योंकि ब्राउजर स्वचालित रूप से प्रत्येक अनुरोध के लिए कुकी को वेबपृष्ठ पर भेजता है। यदि हमलावर एक आईफ्रेम या एक फॉर्म का उपयोग करता है तो कुकी स्वचालित रूप से भेजी जाएगी मुझे विश्वास है। – arleslie