क्या JSON वेब सेवाएँ CSRF हमलों के लिए असुरक्षित हैं?


82

मैं एक वेब सेवा का निर्माण कर रहा हूं जो विशेष रूप से JSON को उसके अनुरोध और प्रतिक्रिया सामग्री (यानी, कोई फ़ॉर्म एन्कोडेड पेलोड) के लिए उपयोग नहीं करता है।

यदि निम्नलिखित सत्य हैं, तो क्या CSRF हमले के लिए एक वेब सेवा असुरक्षित है?

  1. POSTशीर्ष-स्तरीय JSON ऑब्जेक्ट के बिना कोई भी अनुरोध, जैसे, {"foo":"bar"}400 के साथ अस्वीकार कर दिया जाएगा। उदाहरण के लिए, POSTसामग्री के साथ एक अनुरोध 42इस प्रकार अस्वीकार कर दिया जाएगा।

  2. POSTसामग्री-प्रकार के अलावा किसी भी अनुरोध को application/json400 के साथ अस्वीकार कर दिया जाएगा। उदाहरण के लिए, POSTसामग्री-प्रकार के साथ एक अनुरोध application/x-www-form-urlencodedइस प्रकार अस्वीकार कर दिया जाएगा।

  3. सभी GET अनुरोध सुरक्षित होंगे , और इस प्रकार किसी भी सर्वर-साइड डेटा को संशोधित नहीं किया जाएगा ।

  4. ग्राहकों को एक सत्र कुकी के माध्यम से प्रमाणित किया जाता है, जो JSON डेटा के साथ POST के माध्यम से एक सही उपयोगकर्ता नाम / पासवर्ड जोड़ी प्रदान करने के बाद वेब सेवा उन्हें देती है, जैसे {"username":"user@example.com", "password":"my password"}

अनुषंगी प्रश्न: क्या PUTऔर DELETEअनुरोध कभी सीएसआरएफ के लिए असुरक्षित हैं? मैं पूछता हूं क्योंकि ऐसा लगता है कि अधिकांश (सभी?) ब्राउज़र एचटीएमएल रूपों में इन विधियों को अस्वीकार करते हैं।

संपादित करें: जोड़ा गया आइटम # 4।

संपादित करें: अब तक बहुत सारी अच्छी टिप्पणियां और उत्तर, लेकिन किसी ने भी एक विशिष्ट सीएसआरएफ हमले की पेशकश नहीं की है, जो इस वेब सेवा के लिए असुरक्षित है।


सत्र और कुकी युग्मित मूल्यों के माध्यम से अपने अनुरोधों को टोकन दें, जमा किए गए JSON के माध्यम से आप जो भी निर्देशन कर रहे हैं उसे
पवित्र करें

मुझे नहीं लगता कि अच्छा जवाब देने के लिए यहां पर्याप्त जानकारी है। आप प्रमाणीकरण की किस पद्धति का उपयोग कर रहे हैं? वेब सेवा के अभिप्राय उपभोक्ता कौन हैं (यानी, आपकी सेवा के समान होस्ट के साइट के उपयोगकर्ता?)
मैकगर्ल

1
आपके सभी वर्तमान सत्यापन पूरी तरह से समझदार हैं और आपकी हमले की सतह को सीमित करते हैं, लेकिन वे वास्तव में सीएसआरएफ की भेद्यता क्या है, इसके साथ कुछ भी करने के लिए संबोधित नहीं करते हैं।
Cheekysoft


2
@ DavidBalažic वेक्टर क्या है? यदि आप AJAX के बारे में बात कर रहे हैं, तो समान-मूल नीतियाँ इसे रोकेंगी।
djsmith

जवाबों:


73

मनमाना मीडिया प्रकारों के साथ सीएसआरएफ अनुरोधों को मनमाने ढंग से लागू करना केवल एक्सएचआर के साथ प्रभावी रूप से संभव है, क्योंकि एक फॉर्म की विधि GET और POST तक सीमित है और एक फॉर्म का POST संदेश निकाय भी तीन प्रारूपों और application/x-www-form-urlencoded, तक ही सीमित हैmultipart/form-datatext/plain । हालाँकि, प्रपत्र डेटा एन्कोडिंग के साथ text/plainअभी भी मान्य JSON डेटा वाले अनुरोधों को बनाना संभव है

तो एकमात्र खतरा XHR- आधारित CSRF हमलों से आता है। और वे केवल तभी सफल होंगे जब वे एक ही मूल से हों, इसलिए मूल रूप से आपकी अपनी साइट से किसी भी तरह (जैसे एक्सएसएस)। एक सुरक्षा के रूप में कॉर्स (यानी एक्सेस-कंट्रोल-अलाउंस-ओरिजिन: * सेट नहीं करने) की गलती से सावधान रहें। कॉर्स बस ग्राहकों को प्रतिक्रिया पढ़ने से रोकता है। संपूर्ण अनुरोध अभी भी सर्वर द्वारा भेजा और संसाधित किया जा रहा है।


9
जैसा कि मैंने आपके लिंक किए गए उत्तर पर टिप्पणी की है, मैं यह दावा करता हूं कि यदि टेक्नॉलॉजी / एप्लिकेशन को जेनसन की आवश्यकता नहीं है, तो टेक्स्ट / प्लेन का उपयोग वास्तव में JSON के जालसाजी के लिए किया जा सकता है, जैसे कि pentestmonkey.net/blog/csrf-xml.post-request जैसी तकनीकों का उपयोग करके ।

8
यह उत्तर आज तक सही है, लेकिन शायद जल्द ही गलत होगा। W3C HTML मानक में enctype = "application / json" जोड़ने पर विचार कर रहा है: darobin.github.io/formic/specs/json इसलिए स्थायी सुरक्षा के लिए POST निकाय के प्रकार पर निर्भर न रहें , CSRF टोकन का उपयोग करें।
लॉर्डऑफइंपल्स

@LordOfThePigs फोर्जिंग वैध JSON टेक्स्ट / प्लेन के साथ पहले से ही संभव है ।
गंबू 3

@Gumbo सही है, लेकिन आप वर्तमान application/jsonमें इस उत्तर में CSRF हमलों को रखने के लिए उपयोग किए जाने वाले सिद्धांत को सेट नहीं कर सकते । प्रस्तावित मानक आपको उत्तरजीविता सेट करने की अनुमति देगा application/json, जो उत्तर में उल्लिखित सामग्री प्रकार की जांच को हरा देगा और CSRF को आवेदन खोल देगा।
लॉर्डऑफइंपल्स

10
ऐसा लगता है कि मसौदा इस हमले को पूर्व-साम्राज्यित करता है। धारा 5 में कहा गया है कि application/jsonफॉर्म पोस्ट को उसी मूल नीति के अनुरूप होना चाहिए, जिसका अर्थ है कि हमला XHR से अधिक मजबूत नहीं है।
जेम्स_पिक

3

हाँ यह संभव है। आप एक हमलावर सर्वर को सेटअप कर सकते हैं जो पीड़ित सर्वर को लक्ष्य सर्वर पर एक 307 पुनर्निर्देशित करेगा। आपको फ़ॉर्म का उपयोग करने के बजाय POST भेजने के लिए फ़्लैश का उपयोग करने की आवश्यकता है।

संदर्भ: https://bugzilla.mozilla.org/show_bug.cgi?id=1436241

यह क्रोम पर भी काम करता है।


1

Ajax का उपयोग करते हुए JSON आधारित रेस्टफुल सेवाओं पर CSRF करना संभव है। मैंने इसे एक एप्लिकेशन (क्रोम और फ़ायरफ़ॉक्स दोनों का उपयोग करके) पर परीक्षण किया। आपको पहले से अनुरोध अनुरोध को समाप्त करने के लिए कंटेंट टाइप को टेक्स्ट / प्लेन और डेटा टाइप को JSON में बदलना होगा। फिर आप अनुरोध भेज सकते हैं, लेकिन सत्रदता भेजने के लिए, आपको अपने ajax अनुरोध में withCredentials ध्वज सेट करना होगा। मैं यहां और अधिक विस्तार से चर्चा करता हूं (संदर्भ शामिल हैं):

http://wsecblog.blogspot.be/2016/03/csrf-with-json-post-via-ajs.html


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

-1

मुझे बिंदु 3 से संबंधित कुछ संदेह हैं। हालांकि इसे सुरक्षित माना जा सकता है क्योंकि यह सर्वर की तरफ डेटा को नहीं बदलता है, डेटा को अभी भी पढ़ा जा सकता है, और जोखिम यह है कि उन्हें चुराया जा सकता है।

http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/


1
यह तभी काम करता है जब एपीआई द्वारा दी गई शीर्ष स्तर की वस्तु एक JSON सरणी होती है, क्योंकि जावास्क्रिप्ट ऐरे कंस्ट्रक्टर को ओवरराइड करने की अनुमति देता है। एक शीर्ष स्तर की वस्तु सुरक्षित है। Flask.pocoo.org/docs/0.10/security/#json-security पर अधिक ।
बस्टबेल्स

लेखक के अनुसार, " मुझे नहीं लगता कि किसी भी आधुनिक ब्राउज़र में यह दोष है ।"
फ्रैंकलिन यू

-6

यदि निम्नलिखित सत्य हैं, तो क्या CSRF हमले के लिए एक वेब सेवा असुरक्षित है?

हाँ। यह अभी भी HTTP है।

क्या PUT और DELETE अनुरोध कभी CSRF के लिए असुरक्षित हैं?

हाँ

ऐसा लगता है कि अधिकांश (सभी?) ब्राउज़र एचटीएमएल रूपों में इन विधियों को अस्वीकार करते हैं

क्या आपको लगता है कि एक HTTP HTTP अनुरोध करने का एकमात्र तरीका है?


3
सिर्फ इसलिए कि कोई सेवा HTTP का उपयोग करती है, वह CSRF के लिए असुरक्षित नहीं है। क्या आप एक वास्तविक सीएसआरएफ अटैक वेक्टर की पहचान कर सकते हैं, जिसके अनुसार यह सेवा, असुरक्षित है? और निश्चित रूप से मुझे नहीं लगता कि एक ब्राउज़र HTTP अनुरोध करने का एकमात्र तरीका है, लेकिन उपयोगकर्ता द्वारा जाली, क्रॉस-साइट अनुरोध बनाने में धोखा दिया जा सकता है, यह ब्राउज़र सबसे आम (केवल?) है। उम्मीद है।
djsmith

दूसरे शब्दों में, मुझे एक विशिष्ट CSRF अटैक वेक्टर दिखाते हैं जो किसी उपयोगकर्ता को मेरी वेब सेवा (जैसा कि वर्णित है) में PUT अनुरोध सबमिट करने के लिए PUT का उपयोग करता है। मेरा मानना ​​है कि यह संभव नहीं है।
djsmith

@ एसआईएमबीएन: क्या आप संदर्भों को या तो पोस्ट कर सकते हैं या अपने उत्तर की रक्षा कर सकते हैं? मैंने इस उत्तर पर मतदान नहीं किया है, मैं चाहूंगा कि आप पहले इसमें झंकार करें। धन्यवाद।
dotancohen

क्या गूगल फिर से नीचे है? सामग्री-प्रकार की चीज़ को छोड़कर, फ्लैश के पुराने संस्करणों (फ्लैश के अधिक हाल के संस्करणों में क्रॉस डोमियन कंट्रोल मॉडल है - लेकिन यह एचटीएमएल 5 से अलग है) - जार तस्करी के बारे में कैसे - pseudo-flaw.net/content/web-browsers/corrupted -जर्स (जावा सक्रिय संदर्भ में निष्पादित होता है लेकिन निष्क्रिय संदर्भ में जावास्क्रिप्ट को लागू कर सकता है)। इसके बाद DNS
विद्रोही

ब्राउज़र प्लगइन्स आपके CSRF कुकी को पढ़ सकते हैं और वे जिस भी हेडर को चाहते हैं, भेज सकते हैं, यहां तक ​​कि डिफैक्टो मानक CSRF प्रवर्तन तंत्र दुर्भावनापूर्ण ब्राउज़र प्लगइन के लिए असुरक्षित हैं।
djsmith 15
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.