Go CSRF / XSRF टोकन का उद्देश्य और फॉर्म सुरक्षा और मानक पैकेज की डिफ़ॉल्ट टोकन वैधता अवधि

नमस्ते, मैं अक्षम हूँ।
एक ऑनलाइन स्टोरेज जिसे मैंने व्यक्तिगत रूप से बनाया और उपयोग किया है
GitHub - haturatu/puremania: No security, very fast, web UI self-hosted online storage
है, लेकिन अगर आप इसके सामने प्रमाणीकरण जोड़ना चाहते हैं, तो मैंने एक प्रमाणीकरण प्रॉक्सी बनाया है।
GitHub - haturatu/auth-proxy: An authentication proxy server and frontend for a website without built-in authentication. JavaScript is supported, but it can also work without JS if using PHP-FPM. The backend is written in Go.
वास्तव में, यह लगभग पूरी तरह से जेमिनी के कारण है...
यह केवल उन अनुरोधों को प्रॉक्सी करता है जो प्रमाणीकरण पास करते हैं।
व्यवस्थापक उपयोगकर्ता API एंडपॉइंट के लिए एक Bearer टोकन जारी कर सकता है, और उस टोकन का उपयोग करके अनुरोध पास किए जा सकते हैं। हालांकि, इस मामले में, कुछ API एंडपॉइंट ऐसे भी हैं जिन्हें फ्रंट-एंड सत्रों से एक्सेस करने की आवश्यकता होती है, इसलिए वास्तव में, कुकीज़ और Bearer टोकन दोनों काम करेंगे।
यदि आप केवल API एंडपॉइंट्स को सुरक्षित करना चाहते हैं, तो आप वेब लॉगिन जैसे फ्रंट-एंड को एक निजी नेटवर्क में अलग कर सकते हैं और केवल API एंडपॉइंट्स को सार्वजनिक कर सकते हैं। इस तरह, उपयोगकर्ता निर्माण निजी नेटवर्क से किया जा सकता है, और उस उपयोगकर्ता का उपयोग करके API टोकन जारी करना और API प्रॉक्सी का उपयोग करना व्यावहारिक रूप से संभव है। (कृपया यह न कहें कि 'API गेटवे-आधारित OSS का उपयोग क्यों न करें?')।
वास्तव में, इस तरह, कुकीज़ और टोकन दोनों के साथ डबल ब्रूट-फोर्स हमला व्यावहारिक रूप से संभव हो जाता है, लेकिन खैर...

तो, यह लॉगिन के दौरान वेब फ्रंट-एंड की सुरक्षा के लिए फॉर्म सुरक्षा के बारे में है।
यदि JS लोड करना अनिवार्य कर दिया जाए तो अधिकांश समस्याएँ हल हो सकती हैं, लेकिन केवल JS पर निर्भर रहना उबाऊ नहीं है? इसलिए, मैंने JS के अलावा अन्य तरीकों से फॉर्म सुरक्षा बढ़ाने का फैसला किया।

CSRF / XSRF Token

यह इस बार का मुख्य बिंदु है, लेकिन यह वास्तव में क्या है?

सरल शब्दों में, यह सुनिश्चित करना है कि सर्वर-साइड और क्लाइंट-साइड अनुरोध मेरे सर्वर से एक्सेस किए गए और जारी किए गए थे, और यदि टोकन वैध है, तो इसे अनुमति दें।
उदाहरण के लिए,

<input type="hidden" name="xsrf_token" value="BeftikzaR8Oe6npnqXYC7WtBhuo:1760376550660">

ऐसा टोकन फ्रंट-एंड HTML में एम्बेड किया जाता है। यह value सर्वर-साइड गुप्त कुंजी द्वारा हस्ताक्षरित है। इसलिए सर्वर जानता है कि यह मेरे सर्वर से जारी किया गया था!
1760376550660 केवल UNIX समय में वर्णों की एक स्ट्रिंग है, लेकिन वर्तमान समय में इसकी क्या आवश्यकता है?
xsrftoken package - golang.org/x/net/xsrftoken - Go Packages

func ValidFor(token, key, userID, actionID string, timeout time.Duration) bool

इसका उपयोग उपरोक्त समय-सीमा निर्धारित करने के लिए किया जाता है।

वास्तव में, time पैकेज को शामिल करने के बाद, यह इस तरह दिखता है:

if !xsrftoken.ValidFor(clientToken, string(xsrfSecret), sessionID, r.URL.Path, 15*time.Minute) {

यदि यह तर्क नहीं दिया जाता है तो डिफ़ॉल्ट 24 घंटे है, जो काफी ढीला है, लेकिन मेरा मानना है कि यह XSRF Token का मूल रूप है, जहाँ केवल यह सत्यापित करना पर्याप्त है कि टोकन सर्वर द्वारा जारी किया गया था।

CSRF और XSRF में क्या अंतर है!

वास्तव में, बहुत अंतर नहीं लगता है।
उद्देश्य क्रॉस-साइट हमलों को रोकना है।

CSRF के मामले में
GitHub - gorilla/csrf: Package gorilla/csrf provides Cross Site Request Forgery (CSRF) prevention middleware for Go web applications & services 🔒
यह लाइब्रेरी मौजूद थी, और मैं इसे संयोग से यहाँ मिला।
gorilla/csrf CSRF भेद्यता डेमो

gorilla/csrf के कार्यान्वयन को बेहतर बनाने का एक तरीका यह है कि फॉर्म में उपयोग किए जाने वाले यादृच्छिक मान को उपयोगकर्ता आईडी से जुड़े एक एन्क्रिप्टेड टोकन से बदल दिया जाए। यह हमलावरों को अपने CSRF टोकन और कुकी मानों को लक्षित व्यक्ति के साथ बदलने से रोकेगा, क्योंकि हमलावर का CSRF टोकन एक अलग आईडी से मेल खाता है। वास्तव में, यह विधि x/net/xsrftokenHMAC का उपयोग करके उपयोगकर्ता आईडी, वैकल्पिक फॉर्म एक्शन और समाप्ति तिथि को प्रमाणित करने वाली लाइब्रेरी में लागू की गई है।

तो, मैंने सोचा कि यह एक मानक लाइब्रेरी है,
xsrftoken/xsrf.go
स्रोत देखकर आश्चर्य हुआ, टिप्पणियों सहित केवल 100 लाइनें! मुझे थोड़ी चिंता है कि SHA1 अभी भी उपयोग किया जा रहा है, लेकिन क्या यह अंततः अपग्रेड हो जाएगा?
खैर, अगर मानक लाइब्रेरी इतनी सरल है, तो यह उद्देश्य के लिए पर्याप्त है, और यदि आप SameSite सत्यापन करना चाहते हैं, तो शायद आपको gorilla/csrf का उपयोग करना चाहिए।

मानक लाइब्रेरी के लिए नोट्स

जैसा कि मैंने पहले उल्लेख किया है, डिफ़ॉल्ट टोकन की वैधता अवधि 24H है।
वास्तविक संचालन में, इस टोकन अवधि का दुरुपयोग होने की संभावना है, इसलिए इसे कम समय के लिए सेट करना बेहतर हो सकता है। यह मानते हुए कि यह टोकन फॉर्म भरने तक अनुरोध भेजने के लिए है, यदि कोई अन्य सुरक्षा उपाय नहीं हैं, तो 24 घंटे के लिए एक ही टोकन कई अनुरोधों को पास कर देगा, जिससे अनंत curl के साथ एक ही टोकन का पुन: उपयोग करके फॉर्म पर अनुरोध भेजकर ब्रूट-फोर्स हमला करना संभव हो जाता है।