CRLF (%0D%0A) Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us at https://go.intigriti.com/hacktricks today, and start earning bounties up to $100,000!
Carriage Return (CR) और Line Feed (LF), मिलकर CRLF के रूप में जाने जाते हैं, HTTP प्रोटोकॉल में एक पंक्ति के अंत या एक नई पंक्ति की शुरुआत को दर्शाने के लिए विशेष वर्ण अनुक्रम हैं। वेब सर्वर और ब्राउज़र HTTP हेडर और प्रतिक्रिया के शरीर के बीच अंतर करने के लिए CRLF का उपयोग करते हैं। ये वर्ण HTTP/1.1 संचार में विभिन्न वेब सर्वर प्रकारों, जैसे Apache और Microsoft IIS, में सार्वभौमिक रूप से उपयोग किए जाते हैं।
CRLF इंजेक्शन में उपयोगकर्ता द्वारा प्रदान किए गए इनपुट में CR और LF वर्णों का सम्मिलन शामिल है। यह क्रिया सर्वर, एप्लिकेशन, या उपयोगकर्ता को गलत तरीके से यह समझाने के लिए प्रेरित करती है कि सम्मिलित अनुक्रम एक प्रतिक्रिया के अंत और दूसरी की शुरुआत है। जबकि ये वर्ण स्वाभाविक रूप से हानिकारक नहीं हैं, इनका दुरुपयोग HTTP प्रतिक्रिया विभाजन और अन्य दुर्भावनापूर्ण गतिविधियों का कारण बन सकता है।
एक लॉग फ़ाइल पर विचार करें जो एक प्रशासन पैनल में है और जिसका प्रारूप है: IP - Time - Visited Path
। एक सामान्य प्रविष्टि इस प्रकार दिख सकती है:
एक हमलावर इस लॉग को नियंत्रित करने के लिए CRLF इंजेक्शन का लाभ उठा सकता है। HTTP अनुरोध में CRLF वर्णों को इंजेक्ट करके, हमलावर आउटपुट स्ट्रीम को बदल सकता है और लॉग प्रविष्टियों को तैयार कर सकता है। उदाहरण के लिए, एक इंजेक्ट की गई अनुक्रम लॉग प्रविष्टि को इस प्रकार बदल सकती है:
यहाँ, %0d
और %0a
CR और LF के URL-कोडित रूपों का प्रतिनिधित्व करते हैं। हमले के बाद, लॉग भ्रामक रूप से प्रदर्शित करेगा:
The attacker thus cloaks their malicious activities by making it appear as if the localhost (an entity typically trusted within the server environment) performed the actions. The server interprets the part of the query starting with %0d%0a
as a single parameter, while the restrictedaction
parameter is parsed as another, separate input. The manipulated query effectively mimics a legitimate administrative command: /index.php?page=home&restrictedaction=edit
HTTP Response Splitting एक सुरक्षा कमजोरी है जो तब उत्पन्न होती है जब एक हमलावर HTTP प्रतिक्रियाओं की संरचना का लाभ उठाता है। यह संरचना हेडर को शरीर से अलग करती है एक विशेष वर्ण अनुक्रम का उपयोग करके, Carriage Return (CR) के बाद Line Feed (LF), जिसे सामूहिक रूप से CRLF कहा जाता है। यदि एक हमलावर प्रतिक्रिया हेडर में CRLF अनुक्रम डालने में सफल होता है, तो वे प्रभावी रूप से बाद की प्रतिक्रिया सामग्री को हेरफेर कर सकते हैं। इस प्रकार की हेरफेर गंभीर सुरक्षा समस्याओं का कारण बन सकती है, विशेष रूप से Cross-site Scripting (XSS)।
एप्लिकेशन एक कस्टम हेडर सेट करता है जैसे: X-Custom-Header: UserInput
एप्लिकेशन UserInput
के लिए मान को एक क्वेरी पैरामीटर, जैसे "user_input" से लाता है। उचित इनपुट मान्यता और एन्कोडिंग की कमी वाले परिदृश्यों में, एक हमलावर एक पेलोड तैयार कर सकता है जिसमें CRLF अनुक्रम शामिल होता है, उसके बाद दुर्भावनापूर्ण सामग्री होती है।
एक हमलावर एक विशेष रूप से तैयार 'user_input' के साथ एक URL तैयार करता है: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
इस URL में, %0d%0a%0d%0a
CRLFCRLF का URL-कोडित रूप है। यह सर्वर को CRLF अनुक्रम डालने के लिए धोखा देता है, जिससे सर्वर बाद के भाग को प्रतिक्रिया शरीर के रूप में मानता है।
सर्वर हमलावर के इनपुट को प्रतिक्रिया हेडर में दर्शाता है, जिससे एक अनपेक्षित प्रतिक्रिया संरचना उत्पन्न होती है जहां दुर्भावनापूर्ण स्क्रिप्ट को ब्राउज़र द्वारा प्रतिक्रिया शरीर के भाग के रूप में व्याख्यायित किया जाता है।
Browser to:
और सर्वर हेडर के साथ प्रतिक्रिया करता है:
अन्य उदाहरण: (से https://www.acunetix.com/websitesecurity/crlf-injection/)
आप URL पथ के अंदर पेलोड भेज सकते हैं ताकि सर्वर से प्रतिक्रिया को नियंत्रित किया जा सके (उदाहरण यहां):
Check more examples in:
HTTP Header Injection, अक्सर CRLF (Carriage Return and Line Feed) इंजेक्शन के माध्यम से शोषित किया जाता है, हमलावरों को HTTP हेडर डालने की अनुमति देता है। यह XSS (Cross-Site Scripting) फ़िल्टर या SOP (Same-Origin Policy) जैसे सुरक्षा तंत्रों को कमजोर कर सकता है, जिससे संवेदनशील डेटा, जैसे CSRF टोकन, तक अनधिकृत पहुंच या कुकी प्लांटिंग के माध्यम से उपयोगकर्ता सत्रों में हेरफेर हो सकता है।
एक हमलावर HTTP हेडर इंजेक्ट कर सकता है ताकि CORS (Cross-Origin Resource Sharing) को सक्षम किया जा सके, SOP द्वारा लगाए गए प्रतिबंधों को बायपास करते हुए। यह उल्लंघन दुर्भावनापूर्ण मूल से स्क्रिप्टों को एक अलग मूल से संसाधनों के साथ बातचीत करने की अनुमति देता है, संभावित रूप से संरक्षित डेटा तक पहुंच प्राप्त करता है।
CRLF इंजेक्शन का उपयोग एक पूरी तरह से नई HTTP अनुरोध बनाने और इंजेक्ट करने के लिए किया जा सकता है। इसका एक उल्लेखनीय उदाहरण PHP के SoapClient
क्लास में है, विशेष रूप से user_agent
पैरामीटर के भीतर। इस पैरामीटर में हेरफेर करके, एक हमलावर अतिरिक्त हेडर और बॉडी सामग्री डाल सकता है, या यहां तक कि पूरी तरह से एक नया HTTP अनुरोध इंजेक्ट कर सकता है। नीचे एक PHP उदाहरण है जो इस शोषण को प्रदर्शित करता है:
इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए मूल स्रोत की जांच करें.
आप आवश्यक हेडर इंजेक्ट कर सकते हैं ताकि बैक-एंड कनेक्शन को खुला रखे प्रारंभिक अनुरोध का उत्तर देने के बाद:
Afterward, a second request can be specified. This scenario typically involves HTTP request smuggling, एक तकनीक जहां सर्वर द्वारा इंजेक्शन के बाद जोड़े गए अतिरिक्त हेडर या बॉडी तत्व विभिन्न सुरक्षा शोषणों का कारण बन सकते हैं।
Exploitation:
Malicious Prefix Injection: यह विधि अगले उपयोगकर्ता के अनुरोध या एक वेब कैश को एक दुर्भावनापूर्ण उपसर्ग निर्दिष्ट करके ज़हर देने में शामिल है। इसका एक उदाहरण है:
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
Crafting a Prefix for Response Queue Poisoning: यह दृष्टिकोण एक उपसर्ग बनाने में शामिल है जो, जब पीछे के बेकार के साथ मिलाया जाता है, एक पूर्ण दूसरा अनुरोध बनाता है। यह प्रतिक्रिया कतार ज़हर देने को प्रेरित कर सकता है। इसका एक उदाहरण है:
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 एक key-value store है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है। अधिक जानकारी के लिए:
11211 - Pentesting Memcacheपूर्ण जानकारी के लिए पढ़ें मूल लेख
यदि एक प्लेटफ़ॉर्म HTTP अनुरोध से डेटा ले रहा है और इसे बिना साफ किए memcache सर्वर पर अनुरोध करने के लिए उपयोग कर रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके नए memcache आदेशों को इंजेक्ट कर सकता है।
उदाहरण के लिए, मूल खोजी गई कमजोरी में, कैश कुंजियों का उपयोग उपयोगकर्ता को कनेक्ट करने के लिए IP और पोर्ट लौटाने के लिए किया गया था, और हमलावरों ने memcache आदेशों को इंजेक्ट करने में सक्षम थे जो कैश को ज़हर देने के लिए विज़िटर्स के विवरण (उपयोगकर्ता नाम और पासवर्ड सहित) को हमलावर सर्वरों पर भेजते थे:
इसके अलावा, शोधकर्ताओं ने यह भी खोजा कि वे memcache प्रतिक्रियाओं को असंक्रियित कर सकते हैं ताकि हमलावरों के IP और पोर्ट को उन उपयोगकर्ताओं को भेजा जा सके जिनके ईमेल हमलावर को नहीं पता था:
CRLF (Carriage Return and Line Feed) या HTTP Header Injections के जोखिमों को कम करने के लिए, निम्नलिखित रणनीतियों की सिफारिश की जाती है:
Response Headers में सीधे उपयोगकर्ता इनपुट से बचें: सबसे सुरक्षित दृष्टिकोण यह है कि उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को सीधे प्रतिक्रिया हेडर में शामिल करने से बचें।
विशेष वर्णों को एन्कोड करें: यदि सीधे उपयोगकर्ता इनपुट से बचना संभव नहीं है, तो सुनिश्चित करें कि CR (Carriage Return) और LF (Line Feed) जैसे विशेष वर्णों को एन्कोड करने के लिए एक फ़ंक्शन का उपयोग करें। यह प्रथा CRLF इंजेक्शन की संभावना को रोकती है।
प्रोग्रामिंग भाषा को अपडेट करें: अपने वेब अनुप्रयोगों में उपयोग की जाने वाली प्रोग्रामिंग भाषा को नियमित रूप से नवीनतम संस्करण में अपडेट करें। एक ऐसे संस्करण का चयन करें जो HTTP हेडर सेट करने वाले फ़ंक्शनों के भीतर CR और LF वर्णों के इंजेक्शन की अनुमति नहीं देता है।
Bug bounty tip: साइन अप करें Intigriti के लिए, एक प्रीमियम बग बाउंटी प्लेटफॉर्म जो हैकर्स द्वारा, हैकर्स के लिए बनाया गया है! आज ही https://go.intigriti.com/hacktricks पर हमारे साथ जुड़ें, और $100,000 तक के बाउंटी कमाना शुरू करें!
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)