क्रॉस-साइट रिक्वेस्ट फॉरगिरी हमलों (CSRF) को रोकने के लिए प्रामाणिकता टोकन का उपयोग किया जाता है। प्रामाणिकता टोकन को समझने के लिए, आपको पहले CSRF हमलों को समझना चाहिए।
CSRF
मान लीजिए कि आप लेखक हैं bank.com। आपके पास अपनी साइट पर एक फॉर्म है जिसका उपयोग जीईटी अनुरोध के साथ एक अलग खाते में पैसा स्थानांतरित करने के लिए किया जाता है:
एक हैकर सिर्फ सर्वर से एक HTTP अनुरोध भेज सकता है GET /transfer?amount=$1000000&account-to=999999, कह रहा है ना?
गलत। हैकर्स का हमला काम नहीं करेगा। सर्वर मूल रूप से सोचेंगे?
है ना? यह आदमी कौन है जो ट्रांसफर शुरू करने की कोशिश कर रहा है। यह खाते का स्वामी नहीं है, यह सुनिश्चित है।
सर्वर को यह कैसे पता चलता है? क्योंकि कोई session_idकुकी आवश्यककर्ता को प्रमाणित नहीं करता है।
जब आप अपने उपयोगकर्ता नाम और पासवर्ड के साथ साइन इन करते हैं, तो सर्वर session_idआपके ब्राउज़र पर एक कुकी सेट करता है। इस प्रकार, आपको अपने उपयोगकर्ता नाम और पासवर्ड के साथ प्रत्येक अनुरोध को प्रमाणित करने की आवश्यकता नहीं है। जब आपका ब्राउज़र session_idकुकी भेजता है , तो सर्वर जानता है:
ओह, वह जॉन डो है। उन्होंने सफलतापूर्वक 2.5 मिनट पहले हस्ताक्षर किए। वह जाने के लिए अच्छा है।
एक हैकर सोच सकता है:
हम्म। एक सामान्य HTTP अनुरोध काम नहीं करेगा, लेकिन अगर मुझे उस session_idकुकी पर अपना हाथ मिल सकता है, तो मैं सुनहरा हो जाऊंगा।
उपयोगकर्ता ब्राउज़र में bank.comडोमेन के लिए कुकीज़ का एक समूह होता है । जब भी उपयोगकर्ता bank.comडोमेन के लिए अनुरोध करता है, सभी कुकीज़ को साथ भेज दिया जाता है। जिसमें session_idकुकी भी शामिल है ।
इसलिए यदि कोई हैकर आपको GET अनुरोध करने के लिए मिल सकता है जो उसके खाते में धन स्थानांतरित करता है, तो वह सफल होगा। ऐसा करने में वह आपको कैसे चकरा सकता है? क्रॉस साइट अनुरोध के साथ क्षमा करें।
यह वास्तव में बहुत सुंदर है। हैकर सिर्फ आपको उसकी वेबसाइट पर जा सकता है। अपनी वेबसाइट पर, वह निम्नलिखित छवि टैग लगा सकता है:
<img src="http://bank.com/transfer?amount=$1000000&account-to=999999">
जब उपयोगकर्ता ब्राउज़र उस छवि टैग में आता है, तो वह उस यूआरएल के लिए एक GET अनुरोध कर रहा होगा। और जब से अनुरोध उसके ब्राउज़र से आता है, यह इसके साथ जुड़े कुकीज़ के सभी के साथ भेज देंगे bank.com। यदि उपयोगकर्ता ने हाल ही में साइन इन किया था bank.com... session_idकुकी सेट की जाएगी, और सर्वर सोचेंगे कि उपयोगकर्ता का मतलब 1,000,000 डॉलर को 999999 खाते में स्थानांतरित करना है!
ठीक है, बस खतरनाक साइटों की यात्रा न करें और आप ठीक हो जाएंगे।
यह पर्याप्त नहीं है। क्या होगा यदि कोई व्यक्ति उस छवि को फेसबुक पर पोस्ट करता है और यह आपकी दीवार पर दिखाई देता है? यदि आप XSS हमले के साथ दौरा कर रहे हैं, तो क्या होगा?
ये इतना भी बुरा नहीं। केवल GET अनुरोध असुरक्षित हैं।
सच नहीं। एक फॉर्म जो POST अनुरोध भेजता है, गतिशील रूप से उत्पन्न किया जा सकता है। सुरक्षा पर रेल गाइड से उदाहरण यहां दिया गया है :
<a href="http://www.harmless.com/" onclick="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = 'http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>
प्रामाणिकता टोकन
जब आपके ApplicationControllerपास यह है:
protect_from_forgery with: :exception
इस:
<%= form_tag do %>
Form contents
<% end %>
इसमें संकलित है:
<form accept-charset="UTF-8" action="/" method="post">
<input name="utf8" type="hidden" value="✓" />
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
Form contents
</form>
विशेष रूप से, निम्नलिखित उत्पन्न होता है:
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
CSRF हमलों से बचाने के लिए, यदि रेल अनुरोध के साथ भेजे गए प्रामाणिकता टोकन को नहीं देखती है, तो यह अनुरोध को सुरक्षित नहीं मानेगा।
एक हमलावर को कैसे पता होना चाहिए कि यह टोकन क्या है? प्रपत्र उत्पन्न होने पर हर बार एक अलग मान उत्पन्न होता है:
एक क्रॉस साइट स्क्रिप्टिंग (XSS) हमला - यही है। लेकिन यह एक अलग दिन के लिए एक अलग भेद्यता है।