Ένα απλό παράδειγμα χρήσης PHP και AJAX. Δημιουργία φόρμας επικοινωνίας με χρήση επέκτασης Bootstrap, PHP και AJAX General Entity

04.09.2024

Στη λίστα με τους δέκα πιο συνηθισμένους τύπους επιθέσεων σύμφωνα με το OWASP, οι δύο πρώτες θέσεις καταλαμβάνονται από την ένεση κώδικα και τις επιθέσεις XSS (cross-site scripting). Πηγαίνουν χέρι-χέρι γιατί το XSS, όπως και ένας αριθμός άλλων τύπων επιθέσεων, εξαρτάται από την επιτυχία των επιθέσεων με ένεση. Αυτό το όνομα κρύβει μια ολόκληρη κατηγορία επιθέσεων στις οποίες εισάγονται δεδομένα σε μια εφαρμογή Ιστού για να την αναγκάσουν να εκτελέσει ή να ερμηνεύσει κακόβουλο κώδικα με τον τρόπο που θέλει ο εισβολέας. Αυτές οι επιθέσεις περιλαμβάνουν, για παράδειγμα, XSS, SQL injection, header injection, code injection και Full Path Disclosure. Και αυτό είναι μόνο ένα μικρό μέρος.


Οι επιθέσεις με ένεση είναι μια ιστορία τρόμου για όλους τους προγραμματιστές. Είναι πιο κοινά και επιτυχημένα λόγω της ποικιλίας, της κλίμακας και (μερικές φορές) της δυσκολίας προστασίας από αυτά. Όλες οι εφαρμογές πρέπει να λαμβάνουν δεδομένα από κάπου. Το XSS και το UI Redress είναι ιδιαίτερα κοινά, γι' αυτό αφιέρωσα ξεχωριστά κεφάλαια σε αυτά και τα διαχώρισα από τη γενική τάξη.


Το OWASP προσφέρει τον ακόλουθο ορισμό των επιθέσεων έγχυσης:


Ευκαιρίες ένεσης - όπως SQL, OS και LDAP - προκύπτουν όταν ο διερμηνέας λαμβάνει μη αξιόπιστα δεδομένα ως μέρος ενός αιτήματος εντολής. Τα κακόβουλα δεδομένα μπορούν να ξεγελάσουν τον διερμηνέα ώστε να εκτελέσει ορισμένες εντολές ή να αποκτήσει πρόσβαση σε μη εξουσιοδοτημένα δεδομένα.

SQL injection

Η ένεση SQL είναι η πιο κοινή και εξαιρετικά επικίνδυνη μορφή επίθεσης με ένεση. Είναι δύσκολο να υπερεκτιμηθεί η σοβαρότητα αυτής της απειλής, επομένως είναι εξαιρετικά σημαντικό να κατανοήσουμε τι επηρεάζει την επιτυχία των επιθέσεων και πώς να προστατευτείτε από αυτές.


Έτσι, τα δεδομένα εγχέονται στην εφαρμογή Ιστού και στη συνέχεια χρησιμοποιούνται σε ερωτήματα SQL. Συνήθως προέρχονται από μη αξιόπιστες πηγές εισόδου, όπως φόρμες ιστού. Ωστόσο, η έγχυση μπορεί να γίνει και από άλλα μέρη, ας πούμε από την ίδια τη βάση δεδομένων. Οι προγραμματιστές πιστεύουν συχνά στην πλήρη ασφάλεια της βάσης δεδομένων τους, χωρίς να συνειδητοποιούν ότι αν ήταν ασφαλής σε μια περίπτωση, αυτό δεν σημαίνει καθόλου ότι θα είναι ασφαλές στο μέλλον. Τα δεδομένα από τη βάση δεδομένων θα πρέπει να θεωρούνται αναξιόπιστα μέχρι να αποδειχθεί το αντίθετο, δηλαδή μέχρι να επαληθευτούν.


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


Δείτε αυτό το ερώτημα:


$db = new mysqli("localhost", "username", "password", "storedb"); $result = $db->query("SELECT * FROM συναλλαγές WHERE user_id = " . $_POST["user_id"]);

Υπάρχουν πολλά τζάμπα εδώ. Πρώτον, δεν ελέγξαμε τα περιεχόμενα των δεδομένων POST για να βεβαιωθούμε ότι το user_id είναι σωστό. Δεύτερον, επιτρέπουμε σε μια μη αξιόπιστη πηγή να μας πει ποιο user_id να χρησιμοποιήσουμε: ένας εισβολέας μπορεί να γλιστρήσει σε οποιοδήποτε έγκυρο user_id. Μπορεί να περιέχονταν σε ένα κρυφό πεδίο σε μια φόρμα που πιστεύαμε ότι ήταν ασφαλής επειδή δεν ήταν δυνατή η επεξεργασία της (ενώ ξεχνάμε ότι οι εισβολείς μπορούσαν να εισάγουν οποιαδήποτε δεδομένα). Τρίτον, δεν διαφύγαμε από το user_id ούτε το περάσαμε στο ερώτημα ως δεσμευμένη παράμετρο, η οποία επιτρέπει επίσης σε έναν εισβολέα να εισάγει αυθαίρετες συμβολοσειρές που θα χειριστούν το ερώτημα SQL, δεδομένου ότι δεν μπορέσαμε να το ελέγξουμε εξαρχής.


Αυτές οι τρεις παραλείψεις είναι πολύ συχνές σε εφαρμογές web.


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


Επίσης, δώστε προσοχή σε έναν άλλο παράγοντα υλοποίησης της SQL: η μόνιμη αποθήκευση δεν χρειάζεται πάντα να διατηρείται στον διακομιστή. Η HTML 5 υποστηρίζει τη χρήση μιας βάσης δεδομένων από την πλευρά του πελάτη, όπου μπορείτε να στείλετε ερωτήματα χρησιμοποιώντας SQL και JavaScript. Υπάρχουν δύο API για αυτό: WebSQL και IndexedDB. Το 2010, το W3C δεν συνέστησε την επιλογή WebSQL. υποστηρίζεται από προγράμματα περιήγησης WebKit που χρησιμοποιούν το SQLite ως backend. Πιθανότατα, η υποστήριξη θα παραμείνει για χάρη της συμβατότητας προς τα πίσω, ακόμη και παρά τη σύσταση του W3C. Όπως υποδηλώνει το όνομά του, αυτό το API δέχεται ερωτήματα SQL, πράγμα που σημαίνει ότι μπορεί να αποτελέσει στόχο για επιθέσεις ένεσης. Το IndexedDB είναι μια νεότερη εναλλακτική, μια βάση δεδομένων NoSQL (δεν απαιτεί τη χρήση ερωτημάτων SQL).

Παραδείγματα ένεσης SQL

Ο χειρισμός ερωτημάτων SQL μπορεί να έχει τους ακόλουθους στόχους:

  • Διαρροές δεδομένων.
  • Αποκάλυψη αποθηκευμένων πληροφοριών.
  • Χειρισμός αποθηκευμένων πληροφοριών.
  • Παράκαμψη εξουσιοδότησης.
  • Έγχυση SQL από την πλευρά του πελάτη.
  • Προστασία έγχυσης SQL

    Η προστασία από την έγχυση SQL βασίζεται στην αρχή του echeloning. Πριν χρησιμοποιήσετε δεδομένα σε ένα ερώτημα, πρέπει να ελέγξετε ότι η μορφή τους είναι σωστή. Είναι επίσης απαραίτητο να απομονώσετε τα δεδομένα πριν τα συμπεριλάβετε στο αίτημα ή να τα συμπεριλάβετε ως παράμετρο μετάβασης.

    Εξέταση

    Το επαναλαμβάνω συνέχεια: όλα τα δεδομένα που δεν δημιουργήθηκαν ρητά στον πηγαίο κώδικα PHP του τρέχοντος αιτήματος είναι αναξιόπιστα. Ελέγξτε τα αυστηρά και απορρίψτε οτιδήποτε δεν περνάει τους ελέγχους. Μην προσπαθήσετε να "διορθώσετε" τα δεδομένα μπορούν να γίνουν μόνο μικρές, αισθητικές αλλαγές στη μορφή.


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

    Θωράκιση

    Χρησιμοποιώντας την επέκταση mysqli, μπορείτε να απομονώσετε όλα τα δεδομένα που περιλαμβάνονται σε ένα ερώτημα SQL. Η συνάρτηση mysqli_real_escape_string() το κάνει αυτό. Η επέκταση pgsql για το PostgresSQL προσφέρει τις συναρτήσεις pg_escape_bytea() , pg_escape_identifier() , pg_escape_literal() και pg_escape_string(). Η επέκταση mssql (Microsoft SQL Server) δεν διαθέτει λειτουργίες απομόνωσης και η προσέγγιση addslashes() είναι αναποτελεσματική - θα χρειαστείτε μια προσαρμοσμένη συνάρτηση.


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


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

    Παραμετροποιημένα ερωτήματα (έτοιμες εκφράσεις)

    Η παραμετροποίηση ή η δέσμευση παραμέτρων είναι ο προτεινόμενος τρόπος δημιουργίας ερωτημάτων SQL. Όλες οι καλές βιβλιοθήκες βάσεων δεδομένων το χρησιμοποιούν από προεπιλογή. Ακολουθεί ένα παράδειγμα χρήσης της επέκτασης PDO για PHP:


    if(ctype_digit($_POST["id"]) && is_int($_POST["id"])) ($validatedId = $_POST["id"]; $pdo = νέο PDO ("mysql:store.db") $stmt = $pdo->prepare("SELECT * FROM user_id = :id"; // απορρίψτε την τιμή αναγνωριστικού και αναφέρετε ένα σφάλμα στον χρήστη )

    Η μέθοδος bindParam(), που είναι διαθέσιμη για εκφράσεις PDO, επιτρέπει τη δέσμευση των παραμέτρων σε "placeholders" που παρέχονται σε μια προηγουμένως προετοιμασμένη έκφραση. Αυτή η μέθοδος δέχεται παραμέτρους βασικών τύπων δεδομένων, όπως PDO::PARAM_INT , PDO::PARAM_BOOL , PDO::PARAM_LOB και PDO::PARAM_STR . Αυτή είναι η προεπιλογή για το PDO::PARAM_STR εκτός εάν ορίζεται διαφορετικά, γι' αυτό θυμηθείτε και για άλλες τιμές!


    Σε αντίθεση με τη μη αυτόματη απομόνωση, η σύνδεση παραμέτρων (ή οποιαδήποτε μέθοδος χρησιμοποιεί η βιβλιοθήκη της βάσης δεδομένων σας) θα απομονώσει σωστά τα αυτόματα δεσμευμένα δεδομένα, ώστε να μην χρειάζεται να θυμάστε ποια συνάρτηση να χρησιμοποιήσετε. Επίσης, η συνεπής δέσμευση παραμέτρων είναι πολύ πιο αξιόπιστη από την προσπάθεια να θυμάστε ότι πρέπει να απομονώσετε τα πάντα χειροκίνητα.

    Εφαρμογή της αρχής του ελάχιστου προνομίου

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


    Εάν ένας χρήστης έχει υψηλά προνόμια, ένας εισβολέας μπορεί να απορρίψει πίνακες και να αλλάξει τα προνόμια άλλων χρηστών εκτελώντας νέες ενέσεις SQL για λογαριασμό τους. Για να μην συμβεί αυτό, μην έχετε ποτέ πρόσβαση στη βάση δεδομένων από μια εφαρμογή web ως root, διαχειριστής ή άλλος χρήστης με υψηλά προνόμια.


    Μια άλλη εφαρμογή της αρχής είναι ο διαχωρισμός των ρόλων ανάγνωσης και εγγραφής δεδομένων στη βάση δεδομένων. Επιλέξτε έναν χρήστη με δικαιώματα μόνο εγγραφής και έναν άλλο με δικαιώματα μόνο για ανάγνωση. Εάν η επίθεση απευθύνεται στον χρήστη που «διαβάζει», τότε ο εισβολέας δεν θα μπορεί να χειριστεί τα δεδομένα στον πίνακα ή να τα γράψει. Μπορείτε να περιορίσετε την πρόσβαση ακόμη πιο στενά, μειώνοντας έτσι τον αντίκτυπο των επιτυχημένων επιθέσεων SQL injection.


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

    Εισαγωγή κώδικα (γνωστή ως απομακρυσμένη συμπερίληψη αρχείου)

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


    Μπορείτε να εισάγετε τον πηγαίο κώδικα απευθείας από μια μη αξιόπιστη πηγή εισόδου ή να αναγκάσετε την εφαρμογή Ιστού να τον φορτώσει από το τοπικό σύστημα αρχείων ή έναν εξωτερικό πόρο, όπως μια διεύθυνση URL. Όταν εισάγεται κώδικας ως αποτέλεσμα συμπερίληψης εξωτερικής πηγής, αναφέρεται συνήθως ως συμπερίληψη απομακρυσμένου αρχείου (RFI), αν και το ίδιο το RFI προορίζεται πάντα για την εισαγωγή κώδικα.


    Οι κύριοι λόγοι για την εισαγωγή κώδικα:

    • παράκαμψη ελέγχου δεδομένων εισόδου,
    • έγχυση μη αξιόπιστης εισόδου σε οποιοδήποτε πλαίσιο όπου θα αντιμετωπίζεται ως κώδικας PHP,
    • παραβίαση της ασφάλειας των αποθετηρίων πηγαίου κώδικα,
    • απενεργοποιήστε τις προειδοποιήσεις σχετικά με τη φόρτωση βιβλιοθηκών τρίτων,
    • επαναδιαμόρφωση του διακομιστή έτσι ώστε να περνά αρχεία που δεν είναι PHP στον διερμηνέα PHP.

    Δώστε ιδιαίτερη προσοχή στο τελευταίο σημείο: σε αυτήν την περίπτωση, οι μη αξιόπιστοι χρήστες μπορούν να ανεβάσουν οποιαδήποτε αρχεία στον διακομιστή.

    Παραδείγματα εισαγωγής κώδικα

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

    Συμπεριλαμβανομένου ενός αρχείου

    Οι πιο προφανείς στόχοι για την ένεση κώδικα είναι οι συναρτήσεις include() , include_once() , require() και require_once(). Εάν τα αναξιόπιστα δεδομένα εισόδου σάς επιτρέπουν να προσδιορίσετε την παράμετρο διαδρομής που μεταβιβάζεται σε αυτές τις λειτουργίες, τότε μπορείτε να ελέγξετε εξ αποστάσεως ποιο αρχείο θα συμπεριλάβετε. Θα πρέπει να σημειωθεί ότι το αρχείο που περιλαμβάνεται δεν χρειάζεται να είναι πραγματικό αρχείο PHP, μπορεί να χρησιμοποιηθεί οποιαδήποτε μορφή αρχείου ικανή να αποθηκεύει δεδομένα κειμένου (δηλαδή, σχεδόν χωρίς περιορισμούς).


    Η παράμετρος διαδρομής μπορεί επίσης να είναι ευάλωτη σε επιθέσεις διέλευσης καταλόγου ή απομακρυσμένης συμπερίληψης αρχείων. Η χρήση των συνδυασμών χαρακτήρων ../ ή... στη διαδρομή επιτρέπει σε έναν εισβολέα να πλοηγηθεί σε σχεδόν οποιοδήποτε αρχείο στο οποίο έχει πρόσβαση η διαδικασία PHP. Ταυτόχρονα, στην προεπιλεγμένη διαμόρφωση PHP, οι παραπάνω συναρτήσεις δέχονται μια διεύθυνση URL εκτός εάν το allow_url_include είναι απενεργοποιημένο.

    Εξέταση

    Η συνάρτηση PHP eval() δέχεται μια γραμμή κώδικα PHP για εκτέλεση.

    Εφαρμογή κανονικών εκφράσεων

    Η συνάρτηση PCRE (Perl Compatible Regular Expression) preg_replace() στην PHP επιτρέπει τη χρήση του τροποποιητή e (PREG_REPLACE_EVAL). Αυτό σημαίνει μια συμβολοσειρά αντικατάστασης, η οποία μετά την αντικατάσταση θα θεωρείται κώδικας PHP. Και αν υπάρχει μη αξιόπιστη είσοδος σε αυτή τη γραμμή, τότε θα μπορούν να εισάγουν εκτελέσιμο κώδικα PHP.

    Ελαττωματική λογική συμπερίληψης αρχείων

    Οι εφαρμογές Ιστού, εξ ορισμού, περιλαμβάνουν τα αρχεία που απαιτούνται για την εξυπηρέτηση τυχόν αιτημάτων. Εάν εκμεταλλευτείτε ελαττώματα στη λογική δρομολόγησης, τη διαχείριση εξαρτήσεων, την αυτόματη φόρτωση και άλλες διεργασίες, τότε ο χειρισμός της διαδρομής αιτήματος ή των παραμέτρων της θα αναγκάσει τον διακομιστή να συμπεριλάβει συγκεκριμένα τοπικά αρχεία. Εφόσον η εφαρμογή Ιστού δεν έχει σχεδιαστεί για να χειρίζεται τέτοιους χειρισμούς, οι συνέπειες μπορεί να είναι απρόβλεπτες. Για παράδειγμα, η εφαρμογή θα εκθέσει άθελά της διαδρομές που προορίζονται μόνο για χρήση στη γραμμή εντολών. Ή θα αποκαλύψει άλλες κλάσεις των οποίων οι κατασκευαστές εκτελούν εργασίες (καλύτερα να μην σχεδιάζετε κλάσεις με αυτόν τον τρόπο, αλλά αυτό εξακολουθεί να συμβαίνει). Οποιοδήποτε από αυτά τα σενάρια θα μπορούσε να επηρεάσει τις λειτουργίες backend της εφαρμογής, επιτρέποντας χειρισμό δεδομένων ή επιθέσεις DOS σε λειτουργίες έντασης πόρων που δεν περιλαμβάνουν άμεση πρόσβαση.

    Προκλήσεις Code Injection

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

    Άμυνα έναντι Code InjectionCommand InjectionΠαραδείγματα Command InjectionDefenses έναντι Command InjectionLog Injection (γνωστό ως Log File Injection)

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


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


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


    sprintf("Αποτυχία προσπάθειας σύνδεσης από %s", $username);

    Τι γίνεται αν ο εισβολέας χρησιμοποιεί το όνομα "AdminnΕπιτυχής σύνδεση από τον Διαχειριστή" στη φόρμα;


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


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

    Καταγραφή εργασιών έγχυσης

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


    $username = "iamnothacker! τη Δευτέρα 01 Ιανουαρίου 00:00:00 +1000 2009"; sprintf("Αποτυχία προσπάθειας σύνδεσης από %s στο %s", $username,)

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

    Προστασία έγχυσης κορμού

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


    Η δεύτερη μέθοδος προστασίας είναι η μετατροπή κομματιών αναξιόπιστων δεδομένων εισόδου χρησιμοποιώντας ένα σύστημα όπως το base64, το οποίο υποστηρίζει ένα περιορισμένο σύνολο χαρακτήρων ενώ εξακολουθεί να επιτρέπει την αποθήκευση μιας ποικιλίας πληροφοριών σε μορφή κειμένου.

    Διαδρομή διαδρομής (γνωστή ως διέλευση καταλόγου)

    Οι επιθέσεις διέλευσης διαδρομής είναι προσπάθειες να επηρεάσουν τις λειτουργίες ανάγνωσης ή εγγραφής αρχείων στο backend μιας εφαρμογής Ιστού. Αυτό γίνεται με την εισαγωγή παραμέτρων που σας επιτρέπουν να χειρίζεστε τις διαδρομές των αρχείων που εμπλέκονται σε λειτουργίες υποστήριξης. Έτσι, αυτός ο τύπος επίθεσης διευκολύνει την αποκάλυψη πληροφοριών και την τοπική/απομακρυσμένη έγχυση αρχείων.


    Θα εξετάσουμε τέτοιες επιθέσεις ξεχωριστά, αλλά η βάση της επιτυχίας τους είναι ακριβώς η διέλευση μονοπατιών. Δεδομένου ότι οι λειτουργίες που περιγράφονται παρακάτω είναι συγκεκριμένες για τον χειρισμό διαδρομών αρχείων, είναι λογικό να αναφέρουμε ότι πολλές συναρτήσεις PHP δεν δέχονται διαδρομές αρχείων με τη συνήθη έννοια της λέξης. Αντίθετα, συναρτήσεις όπως η include() ή η file() δέχονται ένα URI.


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


    include('/var/www/vendor/library/Class.php'); include('file:///var/www/vendor/library/Class.php');

    Το θέμα είναι ότι η σχετική διαδρομή επεξεργάζεται στο πλάι (η ρύθμιση include_path στο php.ini και οι διαθέσιμοι αυτόματες φορτωτές). Σε τέτοιες περιπτώσεις, οι συναρτήσεις της PHP είναι ιδιαίτερα ευάλωτες σε πολλές μορφές χειρισμού παραμέτρων, συμπεριλαμβανομένης της Αντικατάστασης σχήματος URI αρχείου, όπου ένας εισβολέας μπορεί να εισάγει ένα URI HTTP ή FTP εάν ενσωματωθούν μη αξιόπιστα δεδομένα στην αρχή της διαδρομής του αρχείου. Θα μιλήσουμε για αυτό με περισσότερες λεπτομέρειες στην ενότητα για τις απομακρυσμένες επιθέσεις συμπερίληψης αρχείων, αλλά προς το παρόν θα επικεντρωθούμε στην παράκαμψη των διαδρομών του συστήματος αρχείων.


    Αυτή η ευπάθεια περιλαμβάνει την αλλαγή της διαδρομής για την πρόσβαση σε άλλο αρχείο. Αυτό συνήθως επιτυγχάνεται με την ένεση μιας σειράς ακολουθιών ../ σε ένα όρισμα, το οποίο στη συνέχεια προστίθεται σε συναρτήσεις ή εισάγεται εξ ολοκλήρου σε συναρτήσεις όπως include() , require() , file_get_contents() , και ακόμη λιγότερο ύποπτες (σε ορισμένες) συναρτήσεις όπως το DODocument: :load() .


    Χρησιμοποιώντας την ακολουθία ../, ο εισβολέας αναγκάζει το σύστημα να επιστρέψει στον γονικό κατάλογο. Έτσι, η διαδρομή /var/www/public/../vendor πηγαίνει στην πραγματικότητα στο /var/www/vendor. Η ακολουθία ../ μετά το /public μας μεταφέρει πίσω στον γονικό κατάλογο, π.χ. /var/www. Αυτό επιτρέπει στον εισβολέα να αποκτήσει πρόσβαση σε αρχεία που βρίσκονται εκτός του /public directory που είναι προσβάσιμο από τον διακομιστή web.


    Φυσικά, το να διασχίσεις ένα μονοπάτι δεν περιορίζεται μόνο στην επιστροφή. Μπορείτε να εφαρμόσετε νέα στοιχεία διαδρομής για πρόσβαση σε θυγατρικούς καταλόγους που δεν είναι προσβάσιμοι από το πρόγραμμα περιήγησης λόγω των ρυθμίσεων περιορισμών .htaccess. Οι λειτουργίες του συστήματος αρχείων PHP δεν ενδιαφέρονται για τη ρύθμιση παραμέτρων ελέγχου πρόσβασης μη δημόσιων αρχείων και καταλόγων στον διακομιστή web.

    Παραδείγματα Path TraversalDefenses έναντι Path TraversalXML Injection

    Παρά την εισαγωγή του JSON ως ένα ελαφρύ μέσο μεταφοράς δεδομένων μεταξύ διακομιστή και πελάτη, η XML παραμένει μια δημοφιλής εναλλακτική λύση και τα API υπηρεσιών web συχνά την υποστηρίζουν παράλληλα με το JSON. Η XML χρησιμοποιείται επίσης για την ανταλλαγή δεδομένων χρησιμοποιώντας σχήματα XML: RSS, Atom, SOAP και RDF, κ.λπ.


    Η XML είναι πανταχού παρούσα: μπορεί να βρεθεί σε διακομιστές εφαρμογών Ιστού, προγράμματα περιήγησης (ως η προτιμώμενη μορφή για αιτήματα και απαντήσεις XMLHttpRequest) και επεκτάσεις προγράμματος περιήγησης. Δεδομένης της επικράτησης και της προεπιλεγμένης επεξεργασίας του από δημοφιλείς αναλυτές όπως το libxml2, που χρησιμοποιείται από την PHP στο DOM και στις επεκτάσεις SimpleXML και XMLReader, η XML έχει γίνει στόχος επιθέσεων ένεσης. Όταν το πρόγραμμα περιήγησης συμμετέχει ενεργά στην ανταλλαγή XML, πρέπει να λαμβάνεται υπόψη ότι μέσω του XSS, οι εξουσιοδοτημένοι χρήστες μπορούν να μεταδώσουν αιτήματα XML που δημιουργήθηκαν πραγματικά από εισβολείς.

    Ενσωμάτωση εξωτερικής οντότητας XML (XXE)

    Αυτές οι επιθέσεις υπάρχουν επειδή οι βιβλιοθήκες ανάλυσης XML υποστηρίζουν συχνά τη χρήση προσαρμοσμένων αναφορών οντοτήτων. Θα μάθετε για την τυπική ολοκλήρωση οντοτήτων XML, η οποία χρησιμοποιείται για την αναπαράσταση ειδικών χαρακτήρων σήμανσης όπως > , < ; και '. Η XML σάς επιτρέπει να επεκτείνετε το σύνολο των τυπικών οντοτήτων ορίζοντας προσαρμοσμένες οντότητες μέσω του ίδιου του εγγράφου XML. Μπορούν να οριστούν με απευθείας συμπερίληψή τους στο προαιρετικό DOCTYPE. Η εκτεταμένη τιμή που αντιπροσωπεύουν μπορεί να αναφέρεται σε έναν εξωτερικό πόρο που πρέπει να συμπεριληφθεί. Οι επιθέσεις XXE έγιναν δημοφιλείς ακριβώς λόγω της ικανότητας της συνηθισμένης XML να αποθηκεύει προσαρμοσμένους συνδέσμους που μπορούν να επεκταθούν λόγω του περιεχομένου εξωτερικών πόρων. Υπό κανονικές συνθήκες, οι μη αξιόπιστες εισροές δεν πρέπει ποτέ να αλληλεπιδρούν με το σύστημά μας με απροσδόκητους τρόπους. Και οι περισσότεροι προγραμματιστές XXE σχεδόν σίγουρα δεν προβλέπουν επιθέσεις XXE, κάτι που προκαλεί ιδιαίτερη ανησυχία.


    Ας ορίσουμε, για παράδειγμα, μια νέα προσαρμοσμένη οντότητα αβλαβή:



    Ένα έγγραφο XML με αυτόν τον ορισμό μπορεί πλέον να παραπέμπει σε μια οντότητα όπου επιτρέπονται γενικά οι οντότητες:


    Αυτό το αποτέλεσμα είναι

    Όταν ένας αναλυτής XML όπως το PHP DOM ερμηνεύει αυτό το XML, θα επεξεργαστεί αυτήν την προσαρμοσμένη οντότητα μόλις φορτωθεί το έγγραφο. Επομένως, όταν ζητάτε το αντίστοιχο κείμενο, θα επιστρέψει τα εξής:


    Αυτό το αποτέλεσμα είναι εντελώς ακίνδυνο


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


    &harmless;

    Ανάλογα με τα περιεχόμενα του ζητούμενου τοπικού αρχείου, τα δεδομένα μπορούν να χρησιμοποιηθούν κατά την επέκταση της οντότητας. Στη συνέχεια, το διευρυμένο περιεχόμενο μπορεί να εξαχθεί από τον αναλυτή XML και να συμπεριληφθεί στα εξερχόμενα δεδομένα της διαδικτυακής εφαρμογής για ανάλυση από τον εισβολέα. Για παράδειγμα, για την αποκάλυψη πληροφοριών. Το εξαγόμενο αρχείο θα ερμηνευτεί ως XML, αν και δεν υπάρχουν ειδικοί χαρακτήρες για την ενεργοποίηση αυτής της ερμηνείας. Αυτό περιορίζει τον βαθμό στον οποίο μπορούν να εκτεθούν τα περιεχόμενα του τοπικού αρχείου. Εάν το αρχείο ερμηνεύεται ως XML, αλλά δεν περιέχει έγκυρο XML, τότε πιθανότατα θα λάβουμε ένα σφάλμα, το οποίο θα αποτρέψει την αποκάλυψη του περιεχομένου. Ωστόσο, ένα καθαρό τέχνασμα είναι διαθέσιμο στην PHP για την παράκαμψη του ορίου εύρους, έτσι ώστε τα απομακρυσμένα αιτήματα HTTP να επηρεάζουν την εφαρμογή Ιστού ακόμα κι αν η απάντηση που επιστρέφεται δεν μπορεί να μεταδοθεί στον εισβολέα.


    Υπάρχουν τρεις κοινά χρησιμοποιούμενες μέθοδοι για την ανάλυση και τη χρήση XML στην PHP: PHP DOM, SimpleXML και XMLReader. Όλοι χρησιμοποιούν την επέκταση libxml2 και η υποστήριξη για εξωτερικές οντότητες είναι ενεργοποιημένη από προεπιλογή. Κατά συνέπεια, η PHP είναι ευάλωτη σε επιθέσεις XXE από προεπιλογή, κάτι που είναι πολύ εύκολο να χάσετε όταν εξετάζετε την ασφάλεια μιας εφαρμογής Ιστού ή μιας βιβλιοθήκης που χρησιμοποιεί XML.


    Μην ξεχνάτε επίσης ότι τα XHTML και HTML 5 μπορούν να σειριοποιηθούν ως έγκυρα XML. Αυτό σημαίνει ότι ορισμένες σελίδες XHTML ή HTML 5 σε σειρά XML μπορούν να αναλυθούν ως XML, χρησιμοποιώντας DOMDocument::loadXML() αντί για DOMDocument::loadHTML(). Αυτή η χρήση ενός αναλυτή XML είναι επίσης ευάλωτη στην έγχυση εξωτερικών οντοτήτων XML. Να θυμάστε ότι το libxml2 δεν αναγνωρίζει ακόμη το HTML 5 DOCTYPE, επομένως δεν μπορεί να το επικυρώσει ως XHTML DOCTYPES.

    Παραδείγματα υλοποίησης εξωτερικών οντοτήτων XMLΠεριεχόμενα αρχείου και αποκάλυψη

    Εξετάσαμε ένα παράδειγμα αποκάλυψης πληροφοριών παραπάνω, σημειώνοντας ότι μια προσαρμοσμένη οντότητα XML μπορεί να αναφέρει ένα εξωτερικό αρχείο.


    &harmless;

    Σε αυτήν την περίπτωση, η προσαρμοσμένη οντότητα θα επεκταθεί με τα περιεχόμενα των αρχείων. Εφόσον όλα αυτά τα αιτήματα εκτελούνται τοπικά, αυτό επιτρέπει την έκθεση των περιεχομένων όλων των αρχείων που μπορεί να διαβάσει η εφαρμογή. Δηλαδή, όταν η εκτεταμένη οντότητα περιλαμβάνεται στα εξερχόμενα δεδομένα της εφαρμογής, ο εισβολέας θα μπορεί να εξετάσει αρχεία που δεν είναι προσβάσιμα. Ωστόσο, σε αυτήν την περίπτωση υπάρχει ένας σοβαρός περιορισμός: τα αρχεία πρέπει να είναι είτε σε μορφή XML είτε σε μορφή που δεν θα οδηγήσει σε σφάλμα ανάλυσης XML. Αλλά το θέμα είναι ότι αυτός ο περιορισμός μπορεί να αγνοηθεί εντελώς στην PHP:


    &harmless;

    Η PHP παρέχει πρόσβαση στο περιτύλιγμα ως URI, ένα από τα πρωτόκολλα που είναι αποδεκτά από τις τυπικές λειτουργίες του συστήματος αρχείων: file_get_contents(), require(), require_once(), file(), copy() και πολλά άλλα. Το περιτύλιγμα PHP υποστηρίζει έναν αριθμό φίλτρων που μπορούν να εφαρμοστούν σε έναν συγκεκριμένο πόρο, έτσι ώστε τα αποτελέσματα να επιστρέφονται καλώντας μια συνάρτηση. Στο παραπάνω παράδειγμα, εφαρμόζουμε το φίλτρο convert.base-64-encode στο αρχείο προορισμού που θέλουμε να διαβάσουμε.


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

    Παράκαμψη ελέγχου πρόσβασης

    Η πρόσβαση ελέγχεται με διάφορους τρόπους. Εφόσον οι επιθέσεις XXE πραγματοποιούνται στο backend της εφαρμογής Ιστού, δεν θα είναι δυνατή η χρήση της συνεδρίας του τρέχοντος χρήστη. Ωστόσο, ένας εισβολέας μπορεί να παρακάμψει τον έλεγχο πρόσβασης στο backend χρησιμοποιώντας αιτήματα από τον τοπικό διακομιστή. Σκεφτείτε αυτόν τον πρωτόγονο έλεγχο πρόσβασης:


    if (isset($_SERVER["HTTP_CLIENT_IP"] || isset($_SERVER["HTTP_X_FORWARDED_FOR"]) || !in_array(@$_SERVER["REMOTE_ADDR"], array("127.0.0.1", "::1 ",))) ( header("HTTP/1.0 403 Forbidden"); exit ("Δεν επιτρέπεται η πρόσβαση σε αυτό το αρχείο."); )

    Αυτό το κομμάτι της PHP, όπως και αμέτρητα άλλα σαν αυτό, περιορίζει την πρόσβαση σε ορισμένα αρχεία PHP στον τοπικό διακομιστή, δηλαδή στον localhost. Ωστόσο, μια επίθεση XXE στο μπροστινό μέρος της εφαρμογής δίνει στον εισβολέα τα ακριβή διαπιστευτήρια που απαιτούνται για να παρακάμψει αυτά τα στοιχεία ελέγχου πρόσβασης, επειδή όλα τα αιτήματα HTTP στον αναλυτή XML θα γίνονται από τον localhost.


    &harmless;

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

    Επιθέσεις DOS

    Σχεδόν οτιδήποτε υπαγορεύει την κατανάλωση πόρων διακομιστή μπορεί να χρησιμοποιηθεί για επιθέσεις DOS. Με την εισαγωγή μιας εξωτερικής οντότητας XML, ένας εισβολέας μπορεί να κάνει αυθαίρετα αιτήματα HTTP που, υπό τις κατάλληλες συνθήκες, εξαντλούν τους πόρους του διακομιστή.


    Θα μιλήσουμε αργότερα για άλλες πιθανές χρήσεις DOS επιθέσεων XXE από την άποψη της επέκτασης οντοτήτων XML.

    Προστασία από την έγχυση εξωτερικών οντοτήτων XML

    Αυτές οι επιθέσεις είναι πολύ δημοφιλείς, οπότε θα εκπλαγείτε πόσο εύκολο είναι να αμυνθείτε εναντίον τους. Εφόσον τα DOM, SimpleXML και XMLReader βασίζονται στο libxml2, μπορείτε απλά να χρησιμοποιήσετε τη συνάρτηση libxml_disable_entity_loader() για να απενεργοποιήσετε τη χρήση εξωτερικών οντοτήτων. Ωστόσο, αυτό δεν θα απενεργοποιήσει προσαρμοσμένες οντότητες που είναι προκαθορισμένες στο DOCTYPE, επειδή δεν χρησιμοποιούν εξωτερικούς πόρους που απαιτούν αίτημα HTTP ή λειτουργία συστήματος αρχείων.


    $oldValue = libxml_disable_entity_loader(true); $dom = νέο DODocument(); $dom->loadXML($xml); libxml_disable_entity_loader($oldValue);

    Αυτό πρέπει να γίνει για όλες τις λειτουργίες που περιλαμβάνουν φόρτωση XML από συμβολοσειρές, αρχεία ή απομακρυσμένα URI.


    Όπου μια εφαρμογή δεν απαιτεί ποτέ εξωτερικές οντότητες και για τα περισσότερα από τα αιτήματά της, η φόρτωση εξωτερικών πόρων μπορεί να απενεργοποιηθεί εντελώς σε πιο παγκόσμιο επίπεδο. Στις περισσότερες περιπτώσεις, αυτό είναι πολύ προτιμότερο για τον καθορισμό όλων των σημείων φόρτωσης XML, δεδομένου ότι πολλές βιβλιοθήκες έχουν εγγενή τρωτά σημεία στις επιθέσεις XXE:


    libxml_disable_entity_loader(true);

    Απλώς θυμηθείτε να επιστρέψετε το TRUE μετά από κάθε προσωρινή ενεργοποίηση φόρτωσης εξωτερικών πόρων. Μπορεί να το χρειαστείτε για κάτι τόσο αβλαβές όπως η μετατροπή Docbook XML σε HTML, όπου η εφαρμογή των στυλ XSL εξαρτάται από εξωτερικές οντότητες.


    Ωστόσο, η λειτουργία απενεργοποίησης libxml2 δεν είναι πανάκεια. Αναλύστε άλλες επεκτάσεις και βιβλιοθήκες PHP που αναλύουν ή επεξεργάζονται με άλλο τρόπο την XML για να βρείτε τους «διακόπτες» τους για χρήση εξωτερικών οντοτήτων.


    Εάν αυτό δεν είναι δυνατό, ελέγξτε επιπλέον εάν το έγγραφο XML δηλώνει DOCTYPE. Εάν ναι, και εάν εξωτερικές οντότητες είναι απενεργοποιημένες, τότε απλώς πετάξτε το έγγραφο XML, αρνούμενοι την πρόσβαση σε μη αξιόπιστη XML στον δυνητικά ευάλωτο αναλυτή και καταγράφοντας το ως πιθανή επίθεση. Αυτό είναι ένα απαραίτητο βήμα γιατί δεν θα υπάρχουν άλλα σημάδια - ούτε σφάλματα, ούτε εξαιρέσεις. Ενσωματώστε αυτόν τον έλεγχο στην τακτική επικύρωση εισόδου. Αλλά αυτή η μέθοδος απέχει πολύ από το να είναι ιδανική, επομένως συνιστάται ιδιαίτερα η ουσιαστική επίλυση του προβλήματος των εξωτερικών οντοτήτων.


    /** * Προσπαθήστε έναν γρήγορο εντοπισμό */ $collapsedXML = preg_replace("/[:space:]/", "", $xml); if(preg_match("/