Cloudflare Turnstile लगाएँ—सर्वर जाँच छोड़ी तो सुरक्षा शून्य

Cloudflare Turnstile का विजेट लगाने के बाद हर फ़ॉर्म टोकन को सर्वर से Siteverify पर जाँचें। Cloudflare के सर्वर सत्यापन निर्देश स्पष्ट करते हैं कि अकेला विजेट फ़ॉर्म की रक्षा नहीं करता: कोई व्यक्ति चुनौती पूरी किए बिना फ़ॉर्म के पते पर मनमाना टोकन भेज सकता है। संदेश भेजने या खाता बनाने जैसी कार्रवाई केवल सफल सर्वर जाँच के बाद चलनी चाहिए।

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

विजेट और कुंजियाँ कैसे जोड़ें

Cloudflare में Turnstile विजेट बनाते समय उस वेबसाइट के अनुमत होस्टनाम निर्धारित करें। Cloudflare की आरंभिक मार्गदर्शिका के अनुसार हर विजेट की सार्वजनिक साइट-कुंजी ब्राउज़र में लगती है, जबकि उससे जुड़ी गुप्त कुंजी सर्वर पर सत्यापन के काम आती है। गुप्त कुंजी को पेज के स्रोत या ब्राउज़र में चलने वाली स्क्रिप्ट में न रखें।

सामान्य वेब फ़ॉर्म में Turnstile की आधिकारिक स्क्रिप्ट और साइट-कुंजी वाला विजेट जोड़ें। चुनौती पूरी होने पर विजेट टोकन बनाता है; सामान्य फ़ॉर्म में वह छिपे हुए फ़ील्ड के माध्यम से अनुरोध के साथ जाता है। उस फ़ील्ड का निर्धारित नाम cf-turnstile-response है, हालाँकि विजेट का विन्यास बदलकर दूसरा नाम रखा जा सकता है। सर्वर को उसी नाम से वर्तमान फ़ॉर्म अनुरोध का टोकन पढ़ना होगा।

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

Siteverify को अनुरोध कैसे भेजें

फ़ॉर्म अनुरोध मिलते ही पहले टोकन की मौजूदगी और उसका रूप जाँचें। खाली टोकन पर आगे का काम रोक दें। टोकन मिलने पर सर्वर से Siteverify के आधिकारिक पते पर POST अनुरोध भेजें; उसमें secret नाम से गुप्त कुंजी और response नाम से प्राप्त टोकन दें। चाहें तो remoteip नाम से आगंतुक का आईपी पता भी भेज सकते हैं। ये मान ब्राउज़र से सीधे Siteverify को भेजने के बजाय आपके सर्वर से जाने चाहिए, ताकि गुप्त कुंजी उजागर न हो।

Siteverify अनुरोध को प्रपत्र के मानों या JSON के रूप में स्वीकार करता है और उत्तर JSON में देता है। अपने सर्वर पर उत्तर आने की समय-सीमा रखें तथा अनुपलब्ध सेवा, अधूरा उत्तर और असफल सत्यापन को अस्वीकृत अनुरोध मानें। केवल बाहरी अनुरोध का पूरा हो जाना पर्याप्त नहीं है: उत्तर में success का मान सत्य होने पर ही फ़ॉर्म की निर्धारित कार्रवाई चलाएँ। यदि उत्तर पढ़ा ही नहीं जा सका, तो उसे सफल मानकर संदेश भेजना या खाता बनाना सुरक्षा जाँच को निष्प्रभावी कर देगा।

सर्वर का निर्णय क्रम छोटा और स्पष्ट रखा जा सकता है:

1. फ़ॉर्म के आवश्यक मान और उसके साथ आया टोकन पढ़ें; टोकन न हो तो कार्रवाई रोकें।
2. सर्वर पर रखी गुप्त कुंजी तथा टोकन Siteverify को भेजें और उत्तर की समय-सीमा लागू करें।
3. सफल उत्तर मिलने पर, जहाँ लागू हो, लौटे वेबसाइट होस्टनाम और निर्धारित कार्रवाई की पहचान को अपेक्षित मानों से मिलाएँ।
4. सभी आवश्यक जाँचें पूरी हों तभी फ़ॉर्म का काम करें; अन्य स्थिति में उसे अस्वीकार करें।

सफल उत्तर का संदर्भ भी मिलाएँ

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

इन अपेक्षित मानों को सर्वर के विन्यास से लें, अनुरोधकर्ता के भेजे मानों से नहीं। उदाहरण के लिए, यदि पंजीकरण फ़ॉर्म के लिए अलग कार्रवाई पहचान तय है, तो संपर्क फ़ॉर्म की पहचान वाला उत्तर पंजीकरण की अनुमति न दे। यह एक सशर्त उदाहरण है; जाँच केवल उन्हीं पहचान मानों पर लागू करें जिन्हें आपने अपने विजेट में वास्तव में निर्धारित किया है।

समाप्त और दोबारा इस्तेमाल हुए टोकन पर क्या करें

Turnstile का टोकन बनने के बाद पाँच मिनट तक मान्य रहता है और उसका सत्यापन केवल एक बार हो सकता है। देर से जमा हुए फ़ॉर्म या पहले जाँचे जा चुके टोकन पर Siteverify का timeout-or-duplicate संकेत आ सकता है। ऐसे उत्तर को स्वीकार न करें; विजेट रीसेट करके नया टोकन लें और उपयोगकर्ता को फ़ॉर्म फिर जमा करने दें। पहले वाले टोकन को नए फ़ॉर्म अनुरोध में दोहराना समाधान नहीं है।

गलत या विकृत टोकन के लिए नया टोकन माँगें। गुप्त कुंजी गायब या अमान्य होने का संकेत मिले, तो सर्वर का विन्यास जाँचें; उपयोगकर्ता से चुनौती दोहरवाने से वह समस्या नहीं सुलझेगी। सेवा तक पहुँचने में रुकावट या अपठनीय उत्तर मिले, तो कार्रवाई रोकें, उपयोगकर्ता को सामान्य त्रुटि बताएँ और तकनीकी कारण सर्वर के सुरक्षित अभिलेख में रखें। जहाँ संभव हो, फ़ॉर्म में भरे मान सुरक्षित रखें ताकि दोबारा प्रयास में उन्हें फिर न भरना पड़े।

यदि सर्वर को सत्यापन का उत्तर नहीं मिला, तो यह अस्पष्ट हो सकता है कि पिछला अनुरोध Siteverify तक पहुँचा था या नहीं। ऐसे एक ही सत्यापन प्रयास को दोहराने के लिए वैकल्पिक idempotency_key में एक ही विशिष्ट पहचान भेजी जा सकती है। यह उपाय नेटवर्क के कारण दोहराए गए सत्यापन अनुरोध के लिए है; उपयोगकर्ता की नई फ़ॉर्म प्रस्तुति में नया टोकन चाहिए।

परीक्षण कुंजियों से पूरे प्रवाह की जाँच करें

Cloudflare की परीक्षण-कुंजी सूची सफल सत्यापन, असफल सत्यापन और पहले इस्तेमाल हुए टोकन का उत्तर जाँचने के लिए अलग कुंजियाँ देती है। परीक्षण साइट-कुंजी और परीक्षण गुप्त कुंजी को जोड़े में बदलें: सफल रास्ते में फ़ॉर्म की कार्रवाई चले, जबकि असफल और दोहराव वाले रास्तों में वह रुके। बिना टोकन का सीधा फ़ॉर्म अनुरोध भी भेजें; सर्वर को उसे अस्वीकार करना चाहिए।

परीक्षण कुंजियाँ कृत्रिम टोकन बनाती हैं। उत्पादन की गुप्त कुंजी ऐसे टोकन स्वीकार नहीं करती और परीक्षण गुप्त कुंजी वास्तविक टोकन स्वीकार नहीं करती। इसलिए वातावरण बदलते समय साइट-कुंजी तथा उससे जुड़ी गुप्त कुंजी साथ बदलें। उत्पादन में हर उस सर्वर मार्ग पर समान सत्यापन लागू करें जिससे संरक्षित कार्रवाई पूरी हो सकती है; अन्यथा विजेट वाले पेज को छोड़कर उसी कार्रवाई तक पहुँचना संभव रहेगा।

यह भी पढ़ें:

• नकली सॉफ़्टवेयर डाउनलोड असली जैसा—स्थापना के बाद सुरक्षा भी बंद हो सकती है
• MCP सर्वर जोड़ने से पहले रुकें—छह सुरक्षा दरवाजे जाँचें
• Cloudflare के बॉट नियम खुद बदलेंगे—मुख्य सुरक्षा अभी Enterprise तक