2012-03-31 28 views
10

यह प्रश्न सीधे कोड के बारे में एक से अधिक बीमा है। एक ऑटोडिडैक्ट के रूप में मुझे पेशेवरों से ऐसी चीजों से पूछने की कई संभावनाएं नहीं थीं, इसलिए मैं यहां कोशिश करता हूं।सीएसआरएफ-छूट किस मामले में खतरनाक हो सकती है?

मैं Django-डॉक्स में दस्तावेजों (https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/) और उस पृष्ठ पर कुछ जानकारी पढ़ लिया है: http://cwe.mitre.org/top25/#CWE-352

जहां तक ​​मैं समझ चुके हैं, Django एक टोकन (पिन कोड के कुछ प्रकार के) एक को बचाता है उपयोगकर्ता। और यह सत्यापित करने के लिए कि वास्तव में वह है, उसे अगली बार अनुरोध करने पर उसे वापस करना होगा। और Google के कुछ लोगों ने पाया कि यह AJAX अनुरोधों के साथ भी संभव है, यही कारण है कि हमारे पास 1.2.6 के बाद से उनकी रक्षा करने की नई नीति भी है। और सीएसआरएफ किसी के बारे में कुछ है (बुरा, खतरनाक कोड, भ्रष्ट फाइलें या ऐसा कुछ) जो किसी और होने का नाटक करता है।

तो अगर मैं इस तरह की कुछ कोड है:

@csrf_exempt  
def grab(request): 
    """ 
    view to download an item 
    POST because it stores that a user has downloaded this item 
    """ 
    item_id = request.POST.get('item', None) 
    if not loop: return HttpResponseBadRequest('no item id provided') 
    item = Item.objects.get(pk=int(item_id)) 

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

मुझे यह भी समझ में नहीं आता कि कोई उपयोगकर्ता से सीएसआरएफ-टोकन चोरी क्यों नहीं कर सकता है और अभी भी मुझे (या उपयोगकर्ता) चाल करने के लिए उपयोग कर सकता है। तो मेरे पास इस विषय के बारे में कुछ प्रश्न हैं:

1) क्या ऊपर से मेरी धारणाएं हैं?

2) क्या कोई मुझे बता सकता है, क्या (और शायद कैसे) कुछ अच्छा आदमी गंदे चाल करने के लिए ऊपर दिए गए दृश्य का उपयोग नहीं कर सकता है, और वे क्या होंगे?

3) एक सीएसआरएफ एक मैन-इन-द-बीच हमले का एक उदाहरण है, क्या यह सिर्फ उससे संबंधित है, या यह कुछ अलग है?

4) ऐसे खतरों पर आगे पढ़ने के लिए कोई मूल्यवान लिंक?

शायद इनमें से कुछ प्रश्नों को अच्छी तरह से सूचित नहीं किया गया है, लेकिन मैं इसे प्राप्त करने की कोशिश कर रहा हूं। अगर कोई मेरी मदद कर सकता है तो मैं बहुत खुश हूं।

उत्तर

9

CSRF attacks नकली अनुरोध भेजने के लिए पीड़ित ब्राउज़र को मजबूर करने के बारे में हैं। एक आसान <img> या स्वचालित रूप से <form> दोनों को GET और POST विधि दोनों के लिए ऐसा करने के लिए पर्याप्त रूप से सबमिट किया गया है। और चूंकि अनुरोध ब्राउज़र द्वारा भेजे जाते हैं, यह किसी भी प्रमाणीकरण प्रमाण-पत्र भेजता है और इस प्रकार अनुरोधों को सर्वर के दृष्टिकोण से प्रामाणिक और वैध लगता है क्योंकि वे मूल रूप से उपयोगकर्ता के कार्यों द्वारा शुरू किए गए लोगों से अलग नहीं होते हैं।

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

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

+0

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

+0

@marue CSRF सर्वर पर दुर्भावनापूर्ण डेटा भेजने के बारे में नहीं है। यह मुख्य रूप से प्रतिरूपण के बारे में है क्योंकि हमलावर साइट पीड़ित की ओर से वैध और प्रामाणिक अनुरोध भेज सकती है। एवेसड्रॉपिंग, एमआईटीएम, और एक्सएसएस केवल एमएसआईजीटिंग सीएसआरएफ टोकन को समझने का माध्यम है (हालांकि अधिकांश प्रमाणीकरण प्रबंधन योजनाएं कुकीज़ आधारित सत्रों का उपयोग करती हैं, इसलिए आप इसके बजाय सत्र आईडी भी प्राप्त कर सकते हैं)। – Gumbo

+0

तो सीएसआरएफ सब कुछ है और "केवल" किसी ऐसे व्यक्ति होने का नाटक करने के बारे में है जो आप नहीं हैं? जहां केवल महत्वपूर्ण नहीं है, लेकिन बाकी सब कुछ एक अलग हमला वेक्टर है। – marue

6

CSRF हमले

मैं आपको एक और साइट (जहां संभवतः कुछ अधिकार हैं) के लिए एक वेबपेज जहाँ मैं कुछ कोड डाला (एक अनुरोध, आम तौर पर img या form के माध्यम से) को देखने में चाल।

अहानिकर उदाहरण

<img src="http://www.yoursite.net/changelanguage?lang=fr"> 

मैं निर्दयतापूर्वक को फ्रेंच अपने सत्र की भाषा बदल दिया है। अरे नहीं! आप सीएसआरएफ सुरक्षा को सुरक्षित रूप से हटा सकते हैं और एक डीबी हिट बचा सकते हैं।

खतरनाक उदाहरण

<img src="http://www.yourbank.net/sendmoney?amt=9999&account=123> 

यदि आप yourbank.net में समय पर लॉग इन (और यह कोई CSRF या किसी अन्य सुरक्षा मौजूद है), अब आपका खाता से हल्का महसूस करना चाहिए। (मैं 123 हूँ।)

<img src="http://www.yoursite.net/admin/users/123/edit?admin=1"> 

यदि आप yoursite.net में व्यवस्थापक के रूप में लॉग इन थे, तो हम दोनों हैं। (मैं 123 हूँ।)

+1

इन उदाहरणों के लिए काफी मददगार, धन्यवाद। – marue

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