2015-12-01 9 views
6

कई संसाधनों का दावा है कि (source1) (source2)सीएसआरएफ केवल बैकएंड आरईएसटी अनुप्रयोग के लिए जेएसओएन उपभोग करने के लिए अनिवार्य है?

RESTful वेब सेवाओं द्वारा उजागर संसाधनों के लिए, यह सुनिश्चित करें कि किसी भी PUT, पोस्ट बनाने के लिए, और DELETE अनुरोध क्रॉस साइट रिक्वेस्ट फोर्जरी से सुरक्षित है के लिए महत्वपूर्ण है।

CSRF वेब सुरक्षा के बारे में चिंता की एक न्यूनतम के साथ सभी आवेदनों के लिए अनिवार्य है

हालांकि the Spring Security docs कहते हैं: किसी भी अनुरोध है कि द्वारा एक ब्राउज़र द्वारा संसाधित किया जा सकता है के लिए

उपयोग CSRF संरक्षण सामान्य उपयोगकर्ता यदि आप केवल सेवा बना रहे हैं जो गैर-ब्राउज़र क्लाइंट द्वारा उपयोग की जाती है, तो आप शायद सीएसआरएफ सुरक्षा अक्षम कर सकते हैं।

तो, क्या किसी एप्लिकेशन के लिए सीएसआरएफ को अक्षम करना ठीक है?

  • केवल एक REST API
  • केवल JSON (चेकों अनुरोध Content-Type हैडर)
+0

अच्छा, एप्लिकेशन क्या करता है? यदि जेसन इसे स्वीकार करता है तो '{"कमांड": "नूक ब्रह्मांड"} की तरह कुछ है, तो आप यह सुनिश्चित करने के लिए सुरक्षा का डब्ल्यूईई बीआईटी प्राप्त कर सकते हैं कि स्नोटनेज्ड छोटी स्क्रिप्टकिड्डी अगले दरवाजे को उस आदेश को जारी नहीं कर सकता ... –

+0

तथ्य यह है कि यह एचटीएमएल की सेवा नहीं करता है और केवल जेएसओएन का उपभोग करता है, यह महत्वपूर्ण नहीं है। क्या मायने रखता है: ब्राउज़र क्लाइंट से आने वाली आरईएसटी सेवा को लक्षित करने के अनुरोध हैं या नहीं। –

+0

@JBNizet वे ब्राउज़र में चल रहे जावास्क्रिप्ट से आते हैं, लेकिन HTML फॉर्म सबमिट करने से नहीं, क्योंकि सामग्री प्रकार एप्लिकेशन/जेसन के साथ फ़ॉर्म सबमिट करना असंभव है। –

उत्तर

3

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

कारण यह है कि: यदि आपका एपीआई उपभोक्ता आपके एप्लिकेशन में कुकीज (जो स्वचालित रूप से ब्राउज़र द्वारा संग्रहीत होते हैं) के माध्यम से आपके आवेदन में प्रमाणित/अधिकृत नहीं है, तो हमलावर सफल सीएसआरएफ हमले करने के लिए किसी अन्य वेब पेज का उपयोग नहीं कर सकता (HTTP अनुरोध भेजें ब्राउज़र से अपने एपीआई की कुकीज़ के साथ अन्य पेज)।

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

CSRF टोकन पर Http Session आधारित उत्पन्न होता है:

+1

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

+0

आपका मतलब सामग्री प्रकार है? अच्छी तरह से आंशिक रूप से लेकिन आम तौर पर मैं नहीं देखता कि आप क्लाइंट के बिना सफल सीएसआरएफ हमले कैसे कर सकते हैं जो ब्राउज़र की तरह काम करता है - दूसरे शब्दों में जो कुकीज़ संग्रहीत करता है (जो आपको अधिकृत करता है) और आपके एपीआई और किसी भी दुर्भावनापूर्ण वेब पेज पर अनुरोध कर सकता है (एपीआई अनुरोधों की कुकीज़ फिर से लेता है) – d1x

+0

कुकीज़ को सीएसआरएफ हमलों में शामिल करने की आवश्यकता नहीं है। मैं HTTP बेसिक ऑथ (मान लीजिए) का उपयोग करके mybank.com में लॉग इन हूं, मैं evil.com दर्ज करता हूं जहां

है और मैं evil.com पर सबमिट पर क्लिक करता हूं अभी भी एक सीएसआरएफ हमले के बावजूद कोई कुकीज़ शामिल नहीं थी। –

1

सुंदर आसान यह समझाने के लिए। यदि आपका एपीआई http सत्र धारण कर रहा है, तो आप इसे सीएसआरएफ टोकन के साथ सुरक्षित रूप से सुरक्षित करना चाहते हैं, BUT अधिकांश आरईएसटी सेवाओं को स्टेटलेस होने के लिए डिज़ाइन किया गया है, उस स्थिति में आप CSRF टोकन का उपयोग नहीं कर सकते/नहीं कर सकते हैं।

+0

सुनिश्चित नहीं है कि यह सही है या नहीं। आप बिना ब्राउज़र के HTTP-सत्र (उदाहरण के लिए बीयरर टोकन के साथ) पर हमला करना चाहते हैं (या क्लाइंट जो स्वचालित रूप से कुकीज़ भेजता है)? – d1x

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