लेख में बताए अनुरोध और प्रतिक्रिया के रास्ते का वैचारिक चित्रण: एक अनुरोध, एक सुरक्षा पैनल, ऑरिजिन, एक जाँच चरण और दो संभावित नतीजे, पहुँचाया जाना या ब्लॉक होना। यह Cloudflare का असल ढाँचा नहीं है।
Cloudflare ने ऐसी वेब एप्लिकेशन फ़ायरवॉल क्षमताएँ पेश की हैं जो HTTP अनुरोधों को उनकी ऑरिजिन प्रतिक्रियाओं के साथ जाँचती हैं। यह तरीक़ा संदिग्ध अनुरोधों को उन सबूतों से अलग करने में मदद करता है जो बताते हैं कि दोहन कामयाब हुआ हो सकता है, और साथ ही चुनी हुई प्रतिक्रियाओं को अनुरोध करने वाले तक पहुँचने से पहले ब्लॉक करने देता है।
एक वेब एप्लिकेशन फ़ायरवॉल अनुरोध के एप्लिकेशन तक पहुँचने से पहले किसी संवेदनशील फ़ाइल तक पहुँचने की कोशिश पहचान सकता है। लेकिन जब वह अनुरोध अंदर जाने दिया जाता है, तो एक दूसरा सवाल अहम हो जाता है: एप्लिकेशन ने कैसे जवाब दिया?
Cloudflare अपनी घोषणा में इस समस्या को फ़ाइल-डाउनलोड वाले एक काल्पनिक एंडपॉइंट से समझाता है, जिस पर यह अनुरोध आता है:
GET /download?file=../../config/database.ini
पाथ ट्रैवर्सल का यह क्रम अनुमति वाली डाउनलोड डायरेक्टरी से बाहर निकलने की कोशिश दिखाता है। अनुरोध-आधारित वेब एप्लिकेशन फ़ायरवॉल (WAF) इस पैटर्न को पहचानकर उसे ऑरिजिन (वह सर्वर जो एप्लिकेशन चलाता है) के प्रोसेस करने से पहले ही ब्लॉक कर सकता है।
लेकिन अगर अनुरोध एप्लिकेशन तक पहुँच जाए, तो केवल उसकी सामग्री से नतीजा तय नहीं हो सकता। सर्वर उस पाथ को ठुकरा सकता है, कोई त्रुटि लौटा सकता है, या कोई कॉन्फ़िगरेशन फ़ाइल उजागर कर सकता है।
21 October 2026 को Cloudflare ने full-transaction detection (पूर्ण लेन-देन पहचान) पेश किया, जिसमें उसने अपने WAF को इस तरह बढ़ाया कि आने वाले HTTP अनुरोधों का मूल्यांकन उनकी संबंधित ऑरिजिन प्रतिक्रियाओं के साथ हो।
कंपनी ने प्रतिक्रिया नियम भी पेश किए जो चुनी हुई ऑरिजिन प्रतिक्रियाओं को अनुरोध करने वाले तक पहुँचने से रोक सकते हैं।
तकनीकी बदलाव सिद्धांत रूप में सीधा है: पहले से दिखने वाले संकेतों पर पूरी तरह निर्भर रहने के बजाय, एप्लिकेशन के अनुरोध को प्रोसेस कर लेने के बाद HTTP आदान-प्रदान का मूल्यांकन करने का एक और मौक़ा रक्षकों को मिलता है।
Cloudflare के WAF से गुज़रता अनुरोध
अनुरोध-चरण WAF ऑरिजिन एप्लिकेशन के आने वाले अनुरोध को सँभालने से पहले काम करता है।
Cloudflare URL पाथ, क्वेरी पैरामीटर, हेडर और अन्य उपलब्ध अनुरोध डेटा जैसे गुणों की जाँच कर सकता है। कॉन्फ़िगर किए गए नियमों के आधार पर वह अनुरोध को अनुमति दे सकता है, ब्लॉक कर सकता है, या कोई और समर्थित कार्रवाई कर सकता है।
फ़ाइल-डाउनलोड के उदाहरण में, जल्दी ब्लॉक करने से ऑरिजिन ट्रैवर्सल की कोशिश को प्रोसेस करने से बच जाता है।
लेकिन सभी एप्लिकेशन संदिग्ध इनपुट को एक ही तरह नहीं समझते। रूटिंग, इनपुट सत्यापन, फ़ाइल-सिस्टम अनुमतियों या एप्लिकेशन के व्यवहार में अंतर की वजह से, कोई पेलोड एक माहौल में हानिरहित और दूसरे में दोहन योग्य हो सकता है।
Full-transaction पहचान एक दूसरा निरीक्षण बिंदु जोड़ता है।
जब अनुरोध ऑरिजिन तक जाता है, तो Cloudflare मूल अनुरोध का मिलान एप्लिकेशन की बनाई HTTP प्रतिक्रिया से कर सकता है। दोहन से मेल खाते सबूत पहचानने के लिए, मैनेज्ड डिटेक्शन सिग्नेचर संदिग्ध इनपुट के साथ प्रतिक्रिया के संकेतों को भी ध्यान में ले सकते हैं।
मान लें डाउनलोड एंडपॉइंट HTTP 200 लौटाता है और ऐसी सामग्री जो किसी सुरक्षित कॉन्फ़िगरेशन फ़ाइल जैसी पहचानी जा सके। यह मेल केवल ट्रैवर्सल स्ट्रिंग की तुलना में जानकारी उजागर होने के बारे में अधिक मज़बूत निष्कर्ष का समर्थन कर सकता है।
स्टेटस कोड अपने आप में उजागर होने को साबित नहीं करेगा। प्रासंगिक सबूत माँगे गए ऑपरेशन और प्रतिक्रिया में असल में क्या था, इन दोनों का आपसी संबंध होगा।
अगर प्रतिक्रिया-चरण का कोई ब्लॉकिंग नियम मेल खाता है, तो Cloudflare ऑरिजिन प्रतिक्रिया को आगे भेजने के बजाय उसकी जगह WAF ब्लॉक पेज (Cloudflare के उदाहरण में HTTP 403 के साथ) या कॉन्फ़िगर किया हुआ विकल्प रख सकता है।
नतीजे में बने प्रोसेसिंग मॉडल में दो लागू करने के बिंदु हैं: एक तब जब ऑरिजिन अनुरोध को चलाए उससे पहले, और दूसरा तब जब ऑरिजिन जवाब दे चुका हो पर प्रतिक्रिया पहुँचाई न गई हो।
लेख में बताए प्रोसेसिंग मॉडल का TechiesJournal का वैचारिक चित्र, यह Cloudflare का आधिकारिक चित्र नहीं है।
चित्र 1 का पाठ रूप
- एक क्लाइंट HTTP अनुरोध भेजता है।
- ऑरिजिन से पहले: अनुरोध-चरण WAF लागू करने का बिंदु 1 है। अगर वह ब्लॉक करता है तो अनुरोध ऑरिजिन से पहले ही अस्वीकृत हो जाता है।
- अगर वह जारी रखता है तो ऑरिजिन अनुरोध को प्रोसेस करके HTTP प्रतिक्रिया बनाता है।
- ऑरिजिन के जवाब देने के बाद और डिलीवरी से पहले: अनुरोध और प्रतिक्रिया के संकेतों का मिलान होता है।
- प्रतिक्रिया नियम लागू करने का बिंदु 2 है। अगर वह अनुमति देता है या लॉग करता है तो ऑरिजिन की प्रतिक्रिया पहुँचाई जाती है। अगर वह ब्लॉक करता है तो प्रतिक्रिया की जगह WAF ब्लॉक आता है।
प्रतिक्रिया के सबूत क्या बदलते हैं
एक संदिग्ध अनुरोध यह साबित किए बिना भी हमले की कोशिश उजागर कर सकता है कि एप्लिकेशन कमज़ोर था।
प्रतिक्रिया की जानकारी यह तय करने में मदद कर सकती है कि एप्लिकेशन ने कामयाब दोहन से मेल खाते ढंग से बर्ताव किया या नहीं।
पाथ ट्रैवर्सल पेलोड के बाद एक्सेस-अस्वीकृत प्रतिक्रिया आना, उसके बाद पहचानने योग्य निजी कॉन्फ़िगरेशन डेटा आने से अलग बात है। इसी तरह, किसी संदिग्ध इनपुट पर केवल सामान्य त्रुटि आना, ऐसी प्रतिक्रिया से अलग सबूत देता है जिसमें वह जानकारी हो जो आमतौर पर अनुरोध करने वाले को उपलब्ध नहीं होती।
Cloudflare के शुरुआती full-transaction पहचान चुनी हुई चर्चित कमज़ोरियों पर केंद्रित हैं। कंपनी का कहना है कि वह कवरेज को डेटा उजागर होने और डेटा निकासी के अन्य रूपों तक बढ़ाना चाहती है।
यह अतिरिक्त संदर्भ संदिग्ध ट्रैफ़िक की जाँच को बेहतर कर सकता है, ख़ासकर जब बड़ी संख्या में प्रोब होने से केवल-अनुरोध वाले अलर्ट को प्राथमिकता देना मुश्किल हो।
यह यह तय करने का कोई सार्वभौमिक तरीक़ा नहीं है कि हमला कामयाब हुआ या नहीं। कुछ कामयाब हमले कोई विशिष्ट HTTP प्रतिक्रिया नहीं बनाते, जबकि वैध एप्लिकेशन प्रतिक्रियाएँ कभी-कभी संदिग्ध आउटपुट जैसी दिख सकती हैं।
इसका मूल्य डिटेक्शन सिग्नेचर, एप्लिकेशन के ख़ास व्यवहार और अनुरोध-पक्ष व प्रतिक्रिया-पक्ष के संकेतों के आपसी संबंध पर निर्भर करता है।
डिटेक्शन मेटाडेटा और प्रतिक्रिया नियम
Cloudflare डिटेक्शन को लागू करने से अलग रखता है।
एक डिटेक्शन मेल खाते पैटर्न की पहचान करता है और नतीजे को लेन-देन के मेटाडेटा के रूप में उपलब्ध कराता है। एक नियम तय करता है कि उस नतीजे को लॉग किया जाए या प्रतिक्रिया ब्लॉक करने में इस्तेमाल किया जाए।
Full-transaction सिग्नेचर के लिए Cloudflare ने तीन प्रतिक्रिया-पक्ष मेटाडेटा फ़ील्ड पेश किए:
| फ़ील्ड | अर्थ |
|---|---|
cf.waf.signature.response.confidence | मेल खाते सिग्नेचर के लिए विश्वास मान |
cf.waf.signature.response.categories | मेल खाते सिग्नेचर से जुड़ी श्रेणियाँ |
cf.waf.signature.response.ref | मेल खाते सिग्नेचर की संदर्भ ID, अधिकतम 10 |
ये फ़ील्ड सुरक्षा टीमों को अनुकूलित नीतियाँ बनाते समय प्रतिक्रिया-पक्ष के डिटेक्शन नतीजों को अनुरोध के संदर्भ के साथ जोड़ने देते हैं।
उदाहरण के लिए, कोई टीम किसी संवेदनशील प्रशासनिक पाथ पर अतिरिक्त पाबंदी लगा सकती है और असंबंधित एप्लिकेशन रूट को अछूता छोड़ सकती है।
प्रतिक्रिया नियम उन सिग्नेचर फ़ील्ड के बिना भी, अनुरोध और प्रतिक्रिया के गुणों का सीधे मूल्यांकन करके काम कर सकता है।
Cloudflare का प्रकाशित उदाहरण /admin URL उपसर्ग, आंतरिक प्रमाणीकरण दर्शाने वाला एक अनुरोध हेडर, HTTP 200 प्रतिक्रिया और HTML कंटेंट टाइप को जोड़ता है।
नियम का इरादा तब सफल प्रशासन-पेज प्रतिक्रिया को ब्लॉक करना है जब अपेक्षित प्रमाणीकरण चिह्न मौजूद न हो, /admin की हर विज़िट को उजागर होना माने बिना।
यह अंतर उपयोगी है क्योंकि प्रतिक्रिया नियम केवल अनुरोध के URL को नहीं, बल्कि ऑरिजिन के असल HTTP व्यवहार को भी देख सकते हैं।
जब कोई कॉन्फ़िगर किया प्रतिक्रिया नियम किसी लेन-देन को ब्लॉक करता है, तो अनुरोध करने वाले तक पहुँचाने से पहले ऑरिजिन की प्रतिक्रिया बदल दी जाती है।
हालाँकि, जैसा Cloudflare की घोषणा में कहा गया है, किसी प्रतिक्रिया को ब्लॉक करने से वे काम वापस नहीं होते जो एप्लिकेशन पहले ही कर चुका है।
अगर अनुरोध ने डेटाबेस में बदलाव किया, कोई कमांड चलाई या कोई और सर्वर-साइड ऑपरेशन शुरू किया, तो प्रतिक्रिया नियम उस साइड इफ़ेक्ट को पलट नहीं सकता।
इसलिए प्रतिक्रिया-चरण की ब्लॉकिंग चुने हुए प्रतिक्रिया-उजागर होने के लिए एक नियंत्रण तंत्र है, अनुरोध-चरण सुरक्षा, एप्लिकेशन प्राधिकरण या कमज़ोरी दुरुस्त करने का विकल्प नहीं।
Cloudflare ग्राहकों को क्या उपलब्ध है?
Cloudflare की 21 October की घोषणा के अनुसार, full-transaction पहचान उन ज़ोन के लिए आम तौर पर उपलब्ध है जिनका ट्रैफ़िक Cloudflare से प्रॉक्सी होता है।
मैनेज्ड प्रतिक्रिया सुरक्षा और कस्टम प्रतिक्रिया नियम Free समेत सभी प्लान में जारी किए गए।
Cloudflare एक मैनेज्ड प्रतिक्रिया नियम-समूह, Cloudflare Managed Response Firewall Default, देता है, जो Cloudflare के अनुसार डिफ़ॉल्ट रूप से हर अनुरोध पर चलता है और अपनी PHP पोस्ट के अनुसार सभी प्लान में, Free समेत, अपने आप तैनात किया गया था। इसलिए ग्राहकों को अलग-अलग सिग्नेचर-आधारित नीतियाँ बनाए बिना सुरक्षा मिलती है। मेल खाता मैनेज्ड नियम प्रतिक्रिया को ब्लॉक करके मानक WAF ब्लॉक पेज लौटा सकता है। इन सुरक्षाओं के लागू होने की सीमा को समायोजित किया जा सकता है।
सभी प्लान अधिकतम तीन कस्टम प्रतिक्रिया नियम भी बना सकते हैं, जो Log और Block कार्रवाइयों का समर्थन करते हैं। ये नियम ग्राहक के प्लान में उपलब्ध अनुरोध और प्रतिक्रिया गुणों को जोड़ सकते हैं।
दो अहम पाबंदियाँ हैं।
पहली, कस्टम प्रतिक्रिया नियम अभी प्रतिक्रिया-बॉडी पर नहीं लिखे जा सकते। Cloudflare के मैनेज्ड full-transaction पहचान सिग्नेचर प्रतिक्रिया के संकेत जाँच सकते हैं, पर ग्राहक अभी अपनी प्रतिक्रिया-बॉडी शर्तें नहीं लिख सकते।
दूसरी, मैनेज्ड डिटेक्शन से अनुकूलित नीतियाँ बनाने के लिए नए cf.waf.signature.response.* फ़ील्ड भुगतान करने वाले ग्राहकों के लिए हैं। Cloudflare ने कहा कि क्षमता की घोषणा के समय वे फ़ील्ड अभी ग्राहक खातों में रोल आउट हो रहे थे।
इसलिए प्रतिक्रिया-नियम इंजन की उपलब्धता को हर डिटेक्शन फ़ील्ड तक पहुँच के साथ नहीं मिलाना चाहिए।
प्रशासक Cloudflare डैशबोर्ड में Security → Security Rules के अंतर्गत प्रतिक्रिया-चरण नियंत्रण पा सकते हैं। Cloudflare संबंधित डिटेक्शन जानकारी Security Analytics में भी दिखाता है और मेल खाती नियम कार्रवाइयों को Security Events में दर्ज करता है।
किसी प्रोडक्शन एप्लिकेशन के लिए पहला काम यह जाँचना है कि कौन से सिग्नेचर मेल खा रहे हैं, कौन से रूट प्रभावित हैं, और कॉन्फ़िगर की गई प्रतिक्रिया कार्रवाई उचित है या नहीं। अगर संबंधित उजागर होना किसी एक एंडपॉइंट तक सीमित हो, तो व्यापक ब्लॉकिंग नीति अनावश्यक हो सकती है।
PHP2Shell की प्रतिक्रिया क्यों मायने रखती थी
Cloudflare ने यह नई क्षमता October 2026 की उन PHP कमज़ोरियों के लिए सुरक्षा विकसित करते समय पेश की, जिन्हें आम तौर पर PHP2Shell कहा जाता है।
कंपनी ने बताया कि हमलावर पहले से लागू अनुरोध-आधारित सुरक्षा से बचने की कोशिश में अनुरोध पेलोड बदल रहे थे। ऑरिजिन की प्रतिक्रियाएँ जाँचने से इस बारे में अतिरिक्त सबूत मिले कि कौन सी कोशिशें कामयाब हुई हो सकती हैं।
उस अनुभव ने शुरुआती full-transaction सिग्नेचर में योगदान दिया।
TechiesJournal इन कमज़ोरियों और पैचिंग की ज़रूरतों को पहले ही अपनी PHP की गंभीर vulnerabilities: कौन प्रभावित है, क्या हो सकता है और सुरक्षित रूप से patch कैसे करें में कवर कर चुका है। यहाँ प्रासंगिक बात वह WAF प्रोसेसिंग मॉडल है जो उन रक्षात्मक प्रयासों से उभरा।
केवल संदिग्ध अनुरोध पैटर्न पर निर्भर रहने के बजाय, यह व्यवस्था अब पहचान और अमल में मदद के लिए एप्लिकेशन की प्रतिक्रिया से चुने हुए संकेत इस्तेमाल कर सकती है।
यह ख़ासकर संभावित जानकारी उजागर होने के मामलों में प्रासंगिक है, जहाँ प्रतिक्रिया में ही इसका सबूत हो सकता है कि एप्लिकेशन से क्या बाहर गया।
यह कमज़ोर सॉफ़्टवेयर को पैच करने की ज़रूरत ख़त्म नहीं करता। प्रतिक्रिया नियम कभी-कभी जानकारी को पहुँचने से रोक सकता है, पर वह इसकी गारंटी नहीं दे सकता कि हर एक्सप्लॉइट पहचान योग्य प्रतिक्रिया बनाएगा, या ऑरिजिन पर हो चुके नुक़सान को रोक देगा।
यह सुरक्षा संचालन में कहाँ बदलाव लाता है
एप्लिकेशन सुरक्षा टीमों के लिए व्यावहारिक फ़र्क़ अमल को रोकने, प्रतिक्रिया को नियंत्रित करने और नतीजे की जाँच करने के बीच है।
अनुरोध-चरण नियंत्रण किसी संदिग्ध ऑपरेशन को एप्लिकेशन के प्रोसेस करने से पहले रोक सकते हैं।
प्रतिक्रिया-चरण नियंत्रण प्रोसेसिंग हो जाने के बाद मेल खाती ऑरिजिन प्रतिक्रिया को क्लाइंट तक पहुँचने से रोक सकते हैं।
अनुरोध-प्रतिक्रिया मिलान घटना की जाँच के लिए अतिरिक्त सबूत दे सकता है, जिससे जवाब देने वाले प्रयास किए गए हमलों और दिखाई देने वाले असर से जुड़ी गतिविधि में फ़र्क़ कर पाते हैं।
ये क्षमताएँ एक-दूसरे की पूरक हैं, पर वे एक ही सुरक्षा काम नहीं करतीं।
Cloudflare का full-transaction पहचान HTTP आदान-प्रदान के उस हिस्से में दृश्यता जोड़ता है जिसे केवल-अनुरोध वाली जाँच समझा नहीं सकती। उसके प्रतिक्रिया नियम, चुनी हुई ऑरिजिन सामग्री के एज से बाहर जाने से पहले, एक संगत लागू करने का बिंदु बनाते हैं।
सार्थक बदलाव यह है कि चुने हुए डिटेक्शन और नियंत्रण फ़ैसले लेने के लिए WAF अब केवल इतना ही नहीं, कि अनुरोध करने वाले ने क्या आज़माया, बल्कि इस सबूत का भी इस्तेमाल कर सकता है कि एप्लिकेशन ने कैसे जवाब दिया। बची हुई सीमा भी उतनी ही अहम है: ऑरिजिन के कोई कार्रवाई कर चुकने के बाद, उसकी प्रतिक्रिया को ब्लॉक करने से वह कार्रवाई पलट नहीं सकती।
और गहराई में
- Cloudflare: Introducing full transaction detection for Cloudflare WAF, Daniele Molteni, Elie Roudninski और Nick Downie, 21 October 2026। full-transaction पहचान, प्रतिक्रिया नियम, सिग्नेचर मेटाडेटा, उपलब्धता और लागू करने की सीमाओं को कवर करने वाला प्राथमिक इंजीनियरिंग और प्रोडक्ट खुलासा।
- Cloudflare: Cloudflare deploys protections against php2shell vulnerability, Daniele Molteni, Dan Jones और Kuber Nandwani, 21 October 2026, 23 October 2026 को अपडेट किया गया। उस PHP कमज़ोरी की प्रतिक्रिया का संचालन संदर्भ जिसने Cloudflare के अनुरोध-और-प्रतिक्रिया डिटेक्शन के काम में योगदान दिया।
- Cloudflare Developer Documentation: Attack Signature Detection। Cloudflare के डिटेक्शन को शमन से अलग रखने पर पृष्ठभूमि दस्तावेज़। नए प्रतिक्रिया-विशिष्ट मेटाडेटा फ़ील्ड 21 October की घोषणा में बताए गए हैं।
- इस साइट पर संबंधित लेख: PHP की गंभीर vulnerabilities: कौन प्रभावित है, क्या हो सकता है और सुरक्षित रूप से patch कैसे करें, कमज़ोरियों और पैचिंग की ज़रूरतों के बारे में, यहाँ जाँचे गए WAF ढाँचे से अलग।
स्रोत समीक्षा: 26 October 2026। उत्पाद व्यवहार, प्लान उपलब्धता और रोलआउट की जानकारी Cloudflare के आधिकारिक खुलासे से ली गई है। यह लेख डिटेक्शन प्रणाली की प्रभावशीलता की स्वतंत्र पुष्टि का दावा नहीं करता।