क्या CSRF हमलों के खिलाफ लॉगिन फ़ॉर्म को टोकन की आवश्यकता है?

161

मैंने अब तक जो भी सीखा है, उससे टोकन का उद्देश्य एक हमलावर को फॉर्म जमा करने से रोकने के लिए है।

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

यह समझ में आता है क्योंकि शॉपिंग कार्ट फॉर्म के लिए कई वैध इनपुट हो सकते हैं, सभी हमलावर को एक आइटम जानना होगा जो वेबसाइट बेच रही है।

मैं समझता हूं कि इस मामले में टोकन कैसे काम करते हैं और सुरक्षा जोड़ते हैं, क्योंकि वे सुनिश्चित करते हैं कि उपयोगकर्ता ने वास्तव में भर दिया है और कार्ट में जोड़े गए प्रत्येक आइटम के लिए फ़ॉर्म का "सबमिट" बटन दबाया है।

हालांकि, क्या टोकन उपयोगकर्ता लॉगिन फॉर्म में कोई सुरक्षा जोड़ते हैं, जिसके लिए उपयोगकर्ता नाम और पासवर्ड की आवश्यकता होती है?

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

क्या CSRF के हमलों और टोकन के बारे में मेरी समझ सही है? और क्या वे उपयोगकर्ता लॉगिन फ़ॉर्म के लिए बेकार हैं क्योंकि मुझे संदेह है?

php token csrf

— php_learner
स्रोत

वे आपके राउटर को हाईजैक कर सकते हैं, क्योंकि आप शायद उस पर डिफ़ॉल्ट पासवर्ड का उपयोग करते हैं, और लॉगिन के लिए सीएसआरएफ-संरक्षित नहीं है।

— एबियस X

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

— मयंकपदीक्षित

126

हाँ। सामान्य तौर पर, आपको अपने लॉगिन फ़ॉर्म को किसी अन्य की तरह CSRF हमलों से सुरक्षित करने की आवश्यकता होती है।

अन्यथा आपकी साइट एक प्रकार के "विश्वसनीय डोमेन फ़िशिंग" हमले के लिए असुरक्षित है। संक्षेप में, एक सीएसआरएफ-कमजोर लॉगिन पृष्ठ एक हमलावर को पीड़ित के साथ एक उपयोगकर्ता खाता साझा करने में सक्षम बनाता है।

भेद्यता इस तरह से खेलती है:

हमलावर विश्वसनीय डोमेन पर एक होस्ट खाता बनाता है
हमलावर इस मेजबान खाते की साख के साथ पीड़ित के ब्राउज़र में एक लॉगिन अनुरोध करता है
हमलावर पीड़ित को भरोसेमंद साइट का उपयोग करने के लिए चकमा देता है, जहां वे नोटिस नहीं कर सकते हैं कि वे मेजबान खाते के माध्यम से लॉग इन हैं
हमलावर के पास अब किसी भी डेटा या मेटाडेटा का शिकार "एक्सेस" (जानबूझकर या अनजाने में) है, जबकि उसका ब्राउज़र होस्ट खाते के साथ लॉग इन था

एक उदाहरण के रूप में, YouTube पर विचार करें । YouTube ने उपयोगकर्ताओं को "अपने स्वयं के" इतिहास को देखने का एक रिकॉर्ड देखने की अनुमति दी, और उनका लॉगिन फ़ॉर्म CSRF- असुरक्षित था! इसलिए, एक हमलावर एक पासवर्ड के साथ एक खाता स्थापित कर सकता है, जिसे वे जानते थे, उस खाते का उपयोग करके पीड़ित को YouTube में लॉग इन करें - पीड़ित व्यक्ति जो वीडियो देख रहा था उसे घूरना।

इस टिप्पणी थ्रेड में कुछ चर्चा है जिसका तात्पर्य यह है कि "केवल" का उपयोग उस तरह के गोपनीयता उल्लंघन के लिए किया जा सकता है। शायद, लेकिन विकिपीडिया के CSRF लेख में अनुभाग उद्धृत करने के लिए :

लॉगिन CSRF विभिन्न उपन्यास हमलों को संभव बनाता है; उदाहरण के लिए, एक हमलावर बाद में अपनी वैध साख के साथ साइट पर लॉग इन कर सकता है और खाता में सहेजे गए गतिविधि इतिहास जैसी निजी जानकारी देख सकता है।

"उपन्यास हमलों" पर जोर। अपने उपयोगकर्ताओं के खिलाफ फ़िशिंग हमले के प्रभाव की कल्पना करें, और फिर कल्पना करें कि फ़िशिंग हमले उपयोगकर्ता की अपनी साइट के लिए विश्वसनीय बुकमार्क के माध्यम से काम कर रहे हैं! उपरोक्त टिप्पणी धागा से जुड़ा हुआ पेपर कई उदाहरण देता है जो सरल गोपनीयता हमलों से परे हैं।

— natevw
स्रोत

6

CSRF सुरक्षा कैसे मदद करती है? क्या हमलावर को अपने खुद के सीएसआरएफ टोकन मांगने और सिर्फ उसी के साथ जमा करने से रोकना है? चूंकि कोई प्रमाणित सत्र मौजूद नहीं है, इसलिए वेब सर्वर के पास एक टोकन को दूसरे पर पसंद करने का कोई कारण नहीं है।

— ए विल्सन

2

"क्या कुछ भी हमलावर को अपने खुद के सीएसआरएफ टोकन मांगने और सिर्फ उसी के साथ जमा करने से रोक रहा है?" - हाँ! CSRF रोकथाम तर्क के पीछे यह पूरी धारणा है। ब्राउज़रों ने किसी अन्य मूल को लक्षित करने के लिए एक फॉर्म सबमिट करने की अनुमति दी है, लेकिन उन्होंने कभी भी [जानबूझकर] जेएस को साइटों पर डेटा पढ़ने की अनुमति नहीं दी है, सिवाय ऑप्ट-इन कॉर्स के माध्यम से। जब तक आप CORS गलत की स्थापना की, हमलावर एक फ़ॉर्म प्रविष्टि (जिसमें टोकन एक मौजूदा CSRF शामिल हो सकते हैं ट्रिगर कर सकते हैं कुकीज़ ) लेकिन का कोई तरीका नहीं जानते हुए भी टोकन की आवश्यकता दूसरी प्रति भेजने के लिए (शरीर / हेडर में जैसे)। इसलिए CSRF कोड अस्वीकार कर देगा।

— natevw

7

मुझे लगता है कि आपकी अंतिम टिप्पणी गलत है (आप ए गलत समझते हैं कि ए। विल्सन क्या कह रहे थे)। हम कह रहे हैं कि एक हमलावर http://good.com/login.htmlएक ग्राहक में लोड कर सकता है , नेस्टेड सीएसआरएफ टोकन को पार्स कर सकता है, और फिर प्रकाशित http://bad.com/login.htmlकर सकता है जिसमें एक संशोधित रूप शामिल है जो पीड़ित के प्रकारों की परवाह किए बिना अपने उपयोगकर्ता नाम, पासवर्ड और टोकन को जमा करता है। कोर इसलिए लागू नहीं होता है क्योंकि आप लागू नहीं करते हैं। दो अलग-अलग ग्राहक मिले: हमलावर और पीड़ित। तो सवाल को दोहराना है: क्या CSRF सुरक्षा वास्तव में लॉगिन रूपों के लिए काम करती है?

— गिली

8

हां, CSRF एक लॉगिन फ़ॉर्म को क्रॉस-साइट अनुरोध जालसाजी से बचाएगा । प्रत्येक बार उत्पन्न होने पर एक उचित CSRF टोकन क्रिप्टोग्राफिक रूप से अद्वितीय होता है। निश्चित रूप से, हमलावर को स्वयं एक टोकन मिल सकता है, लेकिन यह अभी भी उस ब्राउज़र में [संभावित अनसेट] कुकी को कुकी नहीं देगा , और हमलावर के पास अच्छे डोमेन पर एक पृष्ठ से समझौता किए बिना कुकी को सेट करने का कोई तरीका नहीं है। (आपका उदाहरण CSRF और कुछ प्रकार के अजीब फ़िशिंग हमले के बीच थोड़ा उलझन में लगता है, हालांकि, मुझे यकीन नहीं है कि अगर मैं आपके वास्तविक प्रश्न का उत्तर दे रहा हूं ...)

— natevw

3

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

— you786

14

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

अंततः केवल एक चीज जो एक हमलावर कर सकता है वह आपके उपयोगकर्ताओं को स्पैमिंग विफल लॉगिन द्वारा असुविधाजनक है, जब सुरक्षा प्रणाली उपयोगकर्ता को कुछ समय के लिए लॉक कर सकती है।

— जॉन
स्रोत

2

वाह सुपर फास्ट जवाब! आपका बहुत बहुत धन्यवाद! अब मैं अपनी वेबसाइट का आत्मविश्वास से निर्माण जारी रख सकता हूं।

— php_learner

21

लॉग इन CSRF अभी भी उपयोगकर्ता की गोपनीयता पर हमले के लिए इस्तेमाल किया जा सकता seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@ स्क्वैल्ड: यह काफी दिलचस्प पेपर है, लिंक के लिए धन्यवाद। लेकिन यह उपयोगकर्ता को हमलावर के नियंत्रण में एक खाते के साथ लॉग इन करने पर टिका है और मानता है कि उपयोगकर्ता को एहसास नहीं होगा कि कुछ सही नहीं है और मानता है कि उपयोगकर्ता संवेदनशील जानकारी का उत्पादन करने जा रहा है जो तब सर्वर पर संग्रहीत होने वाला है। तो IMHO यह "क्लासिक" CSRF से काफी कम गंभीर है।

— जॉन

6

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

— स्क्वीड

1

कृपया आप इस बात पर विस्तार कर सकते हैं कि वे "आखिरकार एक ही चीज़ जो एक हमलावर कर सकता है, वह आपके उपयोगकर्ताओं को स्पैमिंग विफल लॉगिन द्वारा असुविधा पहुँचाता है, जब सुरक्षा प्रणाली उपयोगकर्ता को कुछ समय के लिए लॉक कर सकती है।"

— samthebest

0

हां , इसलिए अन्य वेबसाइटें आपके लॉगिन फॉर्म की नकल नहीं कर सकती हैं! इतना सरल है।

वे इसे करके क्या हासिल कर सकते हैं?

पहला: आप ऐसा नहीं चाहते।
दूसरा: यहां तक कि बहुत सरल विफलता के मामले:
- गलत पासवर्ड nन होने के कारण उपयोगकर्ता को अवरुद्ध करना । समय की मार से बचा जा सकता है।
- फ्लेस हैकिंग अलर्ट को रोका जा सकता है। आदि आदि।

— mayankcpdixit
स्रोत

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

— स्नैपडील

@ Snapey ब्राउज़र्स आमतौर पर JS को CSRF डेटा पढ़ने की अनुमति नहीं देते हैं। JS का उपयोग करके आप वास्तविक फ़ॉर्म सबमिट करने के अनुरोध की नकल नहीं कर सकते।

— mayankcpdixit

Csrf टोकन को अक्सर जावास्क्रिप्ट द्वारा उपयोग के लिए ग्राहक को दिया जाता है। मैं उन cors के बारे में बात नहीं कर रहा हूँ जो मैं हमलावर के बारे में ले रहा हूँ बस लॉगिन फ़ॉर्म का अनुरोध करने और क्रेडेंशियल्स को भरने के लिए। @mayankcpdxit आपको लगता है कि csrf क्रेडेंशियल स्टफिंग को रोकता है, जो ऐसा नहीं करता है।

— Snapey

सैद्धांतिक रूप से, हाँ इसे रोका नहीं जा सकता। लेकिन CSRF के बाद क्रेडेंशियल स्टफिंग को स्वचालित करना संभव नहीं है यदि आप iframes में CSRF फॉर्म लोड करना बंद कर देते हैं और क्रॉस-ऑरिज रीक की अनुमति देना बंद कर देते हैं।

— मयंकपदीक्षित ०

-1

CSRF सत्यापन पूर्व लॉगिन बहुत अधिक समझ में नहीं आता है IMHO।

लिंक के लिए @squiddle का धन्यवाद: seclab.stanford.edu/websec/csrf/csrf.pdf , हम पहले पन्ने पर पढ़ सकते हैं:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

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

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

— पैट्रिस गगनोन
स्रोत