मैं एक वेब सेवा का निर्माण कर रहा हूं जो विशेष रूप से जेएसओएन का अनुरोध और प्रतिक्रिया सामग्री (यानी, कोई फॉर्म एन्कोडेड पेलोड) के लिए उपयोग नहीं करता है।क्या सीएसआरएफ हमलों के लिए जेएसओएन वेब सेवाएं कमजोर हैं?
क्या सीएसआरएफ हमले के लिए एक वेब सेवा कमजोर है यदि निम्नलिखित सत्य हैं?
एक शीर्ष स्तर JSON ऑब्जेक्ट के बिना किसी भी
POSTअनुरोध, उदाहरण के लिए,{"foo":"bar"}, एक 400 उदाहरण के लिए के साथ अस्वीकार कर दिया जाएगा, सामग्री42के साथ एकPOSTअनुरोध इस प्रकार अस्वीकृत कर दिया जाएगा।application/jsonके अलावा किसी अन्य सामग्री प्रकार के साथ कोईPOSTअनुरोध एक 400 उदाहरण के लिए के साथ अस्वीकार कर दिया जाएगा, सामग्री प्रकारapplication/x-www-form-urlencodedके साथ एकPOSTअनुरोध इस प्रकार अस्वीकृत कर दिया जाएगा।सभी जीईटी अनुरोध Safe होंगे, और इस प्रकार किसी सर्वर-साइड डेटा को संशोधित नहीं करेंगे।
ग्राहकों को सत्र कुकी के माध्यम से प्रमाणित किया जाता है, जो वेब सेवा उन्हें JSON डेटा के साथ एक पोस्ट के माध्यम से सही उपयोगकर्ता नाम/पासवर्ड जोड़ी प्रदान करने के बाद देता है, उदा।
{"username":"[email protected]", "password":"my password"}।
अनुषंगी प्रश्न: PUT और DELETE अनुरोध कभी CSRF की चपेट में हैं? मैं पूछता हूं क्योंकि ऐसा लगता है कि अधिकांश (सभी?) ब्राउज़र इन तरीकों को HTML रूपों में अस्वीकार करते हैं।
संपादित करें: जोड़ा गया आइटम # 4।
संपादित करें: अब तक बहुत अच्छी टिप्पणियां और उत्तर हैं, लेकिन किसी ने भी एक विशिष्ट सीएसआरएफ हमला नहीं किया है जिस पर यह वेब सेवा कमजोर है।
सत्र और कुकी बनती मूल्यों के माध्यम से आपके अनुरोध tokenize, स्वच्छ जो कुछ निर्देशों आपके द्वारा भेजी JSON के माध्यम से ट्रिगर कर रहे हैं, अतिरिक्त स्वाद –
मैं डॉन के लिए नमक एक अच्छा जवाब देने के लिए यहां पर्याप्त जानकारी नहीं है। आप प्रमाणीकरण की किस विधि का उपयोग कर रहे हैं? वेब सेवा के उद्देश्य वाले उपभोक्ता कौन हैं (यानी, आपकी सेवा के समान होस्ट पर साइट के उपयोगकर्ता?) – McGarnagle
आपके सभी वर्तमान सत्यापन पूरी तरह से समझदार हैं और आपके हमले की सतह को सीमित करते हैं, लेकिन वे वास्तव में कुछ भी संबोधित नहीं करते हैं सीएसआरएफ भेद्यता क्या है के साथ करो। – Cheekysoft