Γιατί τα URL διαρρέουν ευαίσθητα δεδομένα (και η λύση)

Ένα URL μοιάζει ιδιωτικό, επειδή θα έπρεπε να το έχουν μόνο όσοι το λαμβάνουν από εσάς. Στην πράξη, το URL είναι από τα δεδομένα που καταγράφονται περισσότερο στο διαδίκτυο: το σημειώνουν, το αντιγράφουν και το προωθούν συστήματα που δεν σας ζήτησαν ποτέ άδεια και που δεν μπορείτε να ελέγξετε. Παρακάτω θα δείτε ακριβώς πού διαρρέει και πώς να σχεδιάσετε συνδέσμους που αντέχουν τη διαρροή. Για τον ίδιο λόγο, ένα εργαλείο δημιουργίας μυστικών συνδέσμων μίας χρήσης κρατά το κλειδί αποκρυπτογράφησης μετά το # του συνδέσμου: αυτό το τμήμα δεν φτάνει ποτέ στα αρχεία καταγραφής ενός διακομιστή.

Πού διαρρέει ένα URL

• Ιστορικό του προγράμματος περιήγησης. Κάθε URL που επισκέπτεται ο χρήστης αποθηκεύεται τοπικά και μπορεί να συγχρονιστεί σε άλλες συσκευές, αλλά και στην υπηρεσία συγχρονισμού του κατασκευαστή του προγράμματος περιήγησης.
• Αρχεία καταγραφής πρόσβασης του διακομιστή HTTP. Οι περισσότεροι διακομιστές καταγράφουν από προεπιλογή ολόκληρη τη διαδρομή του αιτήματος και το query string. Όποιος έχει πρόσβαση στα αρχεία καταγραφής έχει και το URL.
• Reverse proxy και CDN. Το Cloudflare, το Fastly, ο εξισορροπητής φορτίου σας: όλα καταγράφουν το URL, το καθένα με τη δική του πολιτική διατήρησης.
• Συστήματα συγκέντρωσης αρχείων καταγραφής. Τα αρχεία καταγραφής πρόσβασης σπάνια μένουν σε ένα μηχάνημα. Στέλνονται σε κεντρικές υπηρεσίες καταγραφής και παρακολούθησης, και έτσι πολλαπλασιάζονται τα συστήματα που κρατούν το URL.
• Κεφαλίδες Referer. Όταν η σελίδα φορτώνει έναν πόρο από τρίτο ιστότοπο, το πρόγραμμα περιήγησης μπορεί να στείλει το URL της σελίδας στην κεφαλίδα Referer. Το λαμβάνουν τα scripts στατιστικών, τα ενσωματωμένα βίντεο και τα pixel διαφημίσεων.
• Επεκτάσεις του προγράμματος περιήγησης. Οι επεκτάσεις με άδεια «ανάγνωσης ιστορικού περιήγησης» βλέπουν κάθε URL, μαζί με το τμήμα μετά το #.
• Συγχρονισμός σελιδοδεικτών. Τα URL των σελιδοδεικτών συγχρονίζονται στις συσκευές του χρήστη και στους διακομιστές του κατασκευαστή του προγράμματος περιήγησης.
• Μηχανισμοί προεπισκόπησης συνδέσμων. Το Slack, το Teams, το iMessage, το LinkedIn και τα προγράμματα email ανοίγουν τα URL για να δείξουν προεπισκόπηση, αθόρυβα, τη στιγμή που στέλνεται το μήνυμα.
• Εταιρικά proxy και πύλες email. Πολλοί οργανισμοί ελέγχουν, ξαναγράφουν και καταγράφουν κάθε URL που περνά τα όριά τους.

Κρατά το HTTPS το URL ιδιωτικό;

Όχι. Το HTTPS κρυπτογραφεί το URL κατά τη μεταφορά και τίποτε άλλο. Και οι δύο άκρες εξακολουθούν να το αποθηκεύουν. Αξίζει να είμαστε ακριβείς εδώ, γιατί το «η σύνδεση είναι κρυπτογραφημένη» συχνά παρανοείται ως «το URL είναι ιδιωτικό».

Το TLS κρυπτογραφεί τη διαδρομή και το query string κατά τη μεταφορά: όποιος παρακολουθεί το δίκτυο ανάμεσα στο πρόγραμμα περιήγησης και στον διακομιστή δεν μπορεί να διαβάσει το /reset?token=.... Αυτό που δεν κρύβει το TLS είναι το όνομα του διακομιστή προορισμού (φαίνεται από την επίλυση DNS και από το πεδίο SNI του TLS στις περισσότερες συνδέσεις σήμερα) και ό,τι υπάρχει στις δύο άκρες. Το πρόγραμμα περιήγησης εξακολουθεί να καταγράφει ολόκληρο το URL στο ιστορικό, και ο διακομιστής το γράφει στο αρχείο καταγραφής πρόσβασης. Η κρυπτογράφηση κατά τη μεταφορά προστατεύει τα δεδομένα στο δίκτυο, όχι τις δύο άκρες, και τα URL διαρρέουν ακριβώς στις άκρες.

Ένα πρακτικό παράδειγμα: η ζωή ενός URL

Ας ακολουθήσουμε ένα ευαίσθητο URL, ας πούμε έναν σύνδεσμο επαναφοράς κωδικού, https://example.com/reset?token=8f3a91..., από την αποστολή μέχρι το κλικ:

1. Ο πάροχος email αποθηκεύει το μήνυμα (μαζί με το URL) χωρίς χρονικό όριο, και ο σαρωτής ασφαλείας του μπορεί να ανοίξει το URL κατά την παράδοση.
2. Η πύλη email του παραλήπτη ξαναγράφει και καταγράφει το URL και το ανοίγει ξανά τη στιγμή του κλικ.
3. Το DNS επιλύει το example.com. Το όνομα διακομιστή (όχι η διαδρομή) βρίσκεται πλέον στα αρχεία καταγραφής του resolver.
4. Ο διακομιστής web γράφει ολόκληρη τη γραμμή του αιτήματος στο αρχείο καταγραφής πρόσβασης. Μια εγγραφή στην προεπιλεγμένη μορφή «combined» του nginx/Apache μοιάζει έτσι:

203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
  "GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."

5. Το CDN μπροστά του καταγράφει το ίδιο URL με τη δική του πολιτική διατήρησης.
6. Το script στατιστικών της σελίδας καταγράφει το URL της σελίδας, μαζί με όλο το query string, σε σύστημα τρίτου, εκτός αν έχει ρυθμιστεί ρητά να το αφαιρεί.
7. Το πρόγραμμα περιήγησης αποθηκεύει το URL στο ιστορικό και το συγχρονίζει.

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

Η κεφαλίδα Referer στην πράξη

Αν η σελίδα όπου εμφανίζεται το μυστικό φορτώνει οποιονδήποτε εξωτερικό πόρο (μια γραμματοσειρά από CDN, ένα script στατιστικών, μια ενσωματωμένη εικόνα), το πρόγραμμα περιήγησης μπορεί να στείλει το URL της σελίδας σε εκείνον τον ιστότοπο, στην κεφαλίδα Referer.

Τα σύγχρονα προγράμματα περιήγησης χρησιμοποιούν από προεπιλογή την πολιτική strict-origin-when-cross-origin (MDN: Referrer-Policy), που περιορίζει το referrer προς άλλους ιστότοπους μόνο στην προέλευση (https://example.com/ αντί για ολόκληρη τη διαδρομή). Είναι πραγματική πρόοδος, αλλά δεν πρέπει να βασίζεστε σε αυτήν: τα αιτήματα προς τον ίδιο ιστότοπο φέρουν ακόμη ολόκληρο το URL, μια πολιτική σε επίπεδο σελίδας μπορεί να χαλαρώσει την προεπιλογή, και τα παλαιότερα προγράμματα περιήγησης και τα ενσωματωμένα webview διαφέρουν.

Δύο πρακτικά μέτρα:

<!-- Strip the referer for outbound requests on the page -->
<meta name="referrer" content="no-referrer" />

Referrer-Policy: no-referrer

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

Είναι ασφαλέστερο ένα token στη διαδρομή, στο query string ή στο fragment;

Μόνο το fragment μένει έξω από το αίτημα, άρα μόνο το fragment μένει έξω από τα αρχεία καταγραφής του διακομιστή. Η διαδρομή και το query string είναι ισοδύναμα. Το σημείο του URL όπου βάζετε ένα token καθορίζει ποιος το βλέπει:

Το fragment είναι πραγματικά διαφορετικό: σύμφωνα με το RFC 3986, ενότητα 3.5, το επεξεργάζεται ο client και δεν περιλαμβάνεται ποτέ στο αίτημα HTTP. Για αυτόν τον λόγο τα εργαλεία επικόλλησης με κρυπτογράφηση από άκρο σε άκρο βάζουν εκεί το κλειδί αποκρυπτογράφησης: ο διακομιστής κυριολεκτικά δεν το λαμβάνει ποτέ. Δεν είναι όμως αόρατο. Το ιστορικό περιήγησης, οι επεκτάσεις και κάθε JavaScript που τρέχει στη σελίδα μπορούν να το διαβάσουν. Η διάκριση ανάμεσα σε διαδρομή και query, αντίθετα, δεν κάνει καμία διαφορά στο απόρρητο: και τα δύο καταλήγουν στα ίδια αρχεία καταγραφής.

Το πρόβλημα των token επαναφοράς κωδικού

Τα ευαίσθητα token μέσα σε URL είναι αναγνωρισμένη κατηγορία ευπαθειών. Το CWE-598 της MITRE («Use of GET Request Method With Sensitive Query Strings») καλύπτει ακριβώς αυτό: τα ευαίσθητα δεδομένα στο query string καταλήγουν σε αρχεία καταγραφής, ιστορικά και referrer, ακόμη και με κρυπτογράφηση κατά τη μεταφορά. Για αυτό οι καλοσχεδιασμένες διαδικασίες επαναφοράς κωδικού πρόσβασης δεν βασίζονται ποτέ μόνο στη μυστικότητα του URL. Κάνουν το token μίας χρήσης, σύντομης διάρκειας και δεμένο με την επόμενη ενέργεια (τον ορισμό νέου κωδικού), ώστε ένα token που ανακτήθηκε από ένα αρχείο καταγραφής τρεις εβδομάδες αργότερα να μην αξίζει τίποτα.

Αυτό είναι το γενικό μάθημα: συνήθως δεν μπορείτε να κρατήσετε ένα URL έξω από τα αρχεία καταγραφής, μπορείτε όμως να κάνετε το καταγεγραμμένο URL άχρηστο μέχρι τη στιγμή που θα το διαβάσει κάποιος.

Σχεδιασμός URL που μπορούν να διαρρεύσουν χωρίς ζημιά

Υποθέστε ότι κάθε URL που δημιουργείτε θα εμφανιστεί τελικά κάπου που δεν το θέλατε, και σχεδιάστε ώστε να μην έχει σημασία:

• Μία μόνο χρήση. Διαγράψτε οριστικά το μυστικό μετά την πρώτη επιτυχημένη ανάγνωση, ώστε ένα URL που διέρρευσε να μη λειτουργεί πια όταν εμφανιστεί στο ιστορικό κάποιου.
• Σύντομη λήξη. Περιορίστε το χρονικό παράθυρο της διαρροής. Ένα URL που λειτουργούσε για πέντε λεπτά αξίζει πολύ λιγότερο από ένα που λειτουργούσε για μια εβδομάδα.
• Φράση πρόσβασης από άλλο κανάλι. Ζητήστε ένα μυστικό που δεν βρέθηκε ποτέ στο URL. Έτσι το URL μόνο του, το μόνο που έχουν τα αρχεία καταγραφής, δεν αρκεί.
• Χωριστή λήψη και εμφάνιση. Στο GET επιστρέψτε μόνο μεταδεδομένα και δώστε το περιεχόμενο μόνο με ρητό POST, ώστε οι μηχανισμοί προεπισκόπησης συνδέσμων και οι σαρωτές να μη μπορούν να καταναλώσουν το μυστικό.
• Κανένας πόρος από τρίτους στις ευαίσθητες σελίδες, μαζί με Referrer-Policy: no-referrer και <meta name="robots" content="noindex">.
• Αποκρύψτε τις μυστικές διαδρομές στα δικά σας αρχεία καταγραφής. Στο nginx, αντιστοιχίστε το URI του αιτήματος πριν από την καταγραφή (δείτε την τεκμηρίωση του ngx_http_log_module για το log_format):

map $request_uri $loggable_uri {
    ~^/s/   "/s/[redacted]";
    default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
                    '"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;

Ελέγχετε μόνο τα δικά σας αρχεία καταγραφής. Τα αντίγραφα στο CDN, στο proxy και στο πρόγραμμα περιήγησης μένουν, και ακριβώς για αυτό τα τρία πρώτα σημεία αυτής της λίστας σηκώνουν το μεγαλύτερο βάρος.

Πώς αυτό διαμορφώνει τους μυστικούς συνδέσμους

Αυτό το μοντέλο απειλών εξηγεί γιατί οι μυστικοί σύνδεσμοι του LinkPilot δουλεύουν όπως δουλεύουν: θεωρούμε ότι το URL αναπόφευκτα θα διαρρεύσει, οπότε το URL μόνο του δεν αρκεί ποτέ. Ένα GET επιστρέφει μόνο μεταδεδομένα. Για το περιεχόμενο χρειάζεται ρητή εμφάνιση με POST, προαιρετικά με φράση πρόσβασης που περνά από hash SHA-256 στο πρόγραμμα περιήγησης. Τα μυστικά που έχουν διαγραφεί οριστικά, έχουν λήξει ή έχουν ανακληθεί επιστρέφουν HTTP 410 και το περιεχόμενό τους έχει αντικατασταθεί μη αναστρέψιμα. Οι απαντήσεις εμφάνισης φέρουν Cache-Control: no-store, και τα συμβάντα προβολής καταγράφουν μια IP σε μορφή hash με salt που αλλάζει καθημερινά, όχι την ίδια τη διεύθυνση. Και ένα ειλικρινές όριο, που αναφέρεται στη σελίδα αρχιτεκτονικής ασφαλείας: το κλειδί αποκρυπτογράφησης ταξιδεύει στο fragment του URL, οπότε ολόκληρος ο σύνδεσμος πρέπει να αντιμετωπίζεται ως το μυστικό. Αυτός είναι ακριβώς ο κίνδυνος που περιγράφει το άρθρο. Η σύντομη λήξη, η διαγραφή μετά την ανάγνωση και μια φράση πρόσβασης από άλλο κανάλι είναι αυτά που περιορίζουν τη ζημιά όταν ένας σύνδεσμος διαρρεύσει.

Ενημέρωση, 29 Σεπτεμβρίου 2026: αυτή η παράγραφος έλεγε αρχικά ότι το LinkPilot δεν προσέφερε κρυπτογράφηση από άκρο σε άκρο. Πλέον κρυπτογραφεί το περιεχόμενο κειμένου στο πρόγραμμα περιήγησης, μαζί με τα συνημμένα.

Όρια

Ο σχεδιασμός των URL δεν διορθώνει τα πάντα. Δεν ελέγχει τι κάνει ο παραλήπτης μετά από μια νόμιμη ανάγνωση, δεν μπορεί να σβήσει αντίγραφα που ήδη κρατούν τρίτοι, και δεν σώζει ένα URL που κουβαλά προσωπικά δεδομένα σε κοινή θέα. Αν η διεύθυνση email ενός χρήστη βρίσκεται στο query string, καμία λήξη δεν τη βγάζει από τα αρχεία καταγραφής. Ο κανόνας που ισχύει πάντα: μη βάζετε ποτέ σε ένα URL δεδομένα που θα χρειαστεί να διαγράψετε αργότερα, γιατί η διαγραφή ενός URL από κάθε σημείο όπου έχει αντιγραφεί είναι πρακτικά αδύνατη. Σχεδιάστε λοιπόν URL που δεν αξίζουν τίποτα όταν διαρρεύσουν.

Σχετικά άρθρα

• Πώς λειτουργούν οι μυστικοί σύνδεσμοι μίας χρήσης
• Σαρωτές συνδέσμων και μυστικά μίας χρήσης
• Ασφαλής κοινή χρήση κωδικών πρόσβασης: 5 μέθοδοι σε σύγκριση

Πηγές

• IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, section 3.5 Fragment.
• MDN Web Docs, Referrer-Policy header.
• nginx, Module ngx_http_log_module.