API8:2019 Injection
| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) |
|---|---|---|
| Εξαρτώνται από το API : Εκμεταλλευσιμότητα 3 | Επικράτηση (Prevalence) 2 : Ανιχνευσιμότητα 3 | Τεχνικές Επιπτώσεις 3 : Εξαρτώνται από την Επιχείρηση |
| Οι εισβολείς εισάγουν στο API κακόβουλα δεδομένα μέσω οποιασδήποτε διαθέσιμης μεθόδου εισαγωγής δεδομένων αναμένοντας να σταλούν τελικώς σε έναν διερμηνέα λογισμικού (interpreter). Οι μέθοδοι αυτοί που μπορούν να χρησιμοποιηθούν για εισαγωγή κακόβουλων δεδομένων που καταλήγουν σε διερμηνείς λογισμικού ονομάζονται διανύσματα έγχυσης (injection vectors). Παραδείγματα τέτοιων μεθόδων είναι η άμεση εισαγωγή δεδομένων (direct input), οι παράμετροι (parameters), οι ολοκληρωμένες/ενσωματωμένες υπηρεσίες (integrated services) κ.λπ. | Οι ευπάθειες έγχυσης είναι πολύ κοινές και εντοπίζονται συχνά σε ερωτήματα SQL, LDAP ή NoSQL, εντολές λειτουργικού συστήματος, αναλυτές XML και ORM. Αυτές οι ευπάθειες είναι εύκολο να εντοπιστούν κατά τον έλεγχο του πηγαίου κώδικα. Οι επιτιθέμενοι μπορούν να χρησιμοποιήσουν σαρωτές και fuzzers για να εντοπίσουν τέτοιες ευπάθειες. | Η έγχυση (injection) μπορεί να οδηγήσει σε αποκάλυψη πληροφοριών και απώλεια δεδομένων. Μπορεί επίσης να οδηγήσει σε επιθέσεις άρνησης εξυπηρέτησης (DoS) ή πλήρη κατάληψη του κεντρικού υπολογιστή. |
Πότε το API είναι ευάλωτο
Το API είναι ευάλωτο σε ευπάθεια έγχυσης (injection flaw) όταν:
- Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες δεν επικυρώνονται, δεν φιλτράρονται ή δεν απολυμαίνονται (sanitized) από το API.
- Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες χρησιμοποιούνται απευθείας ή συνδέονται με ερωτήματα SQL/NoSQL/LDAP, εντολές λειτουργικού συστήματος, αναλυτές XML και σχεσιακή αντιστοίχιση αντικειμένων (ORM) / χαρτογράφηση εγγράφων αντικειμένου (ODM).
- Τα δεδομένα που προέρχονται από εξωτερικά συστήματα (π.χ. ολοκληρωμένα/ενσωματωμένα συστήματα) δεν επικυρώνονται (validation), δεν φιλτράρονται (filtering) ή δεν απολυμαίνονται (sanitization) από το API.
Παραδείγματα από Σενάρια Επίθεσης
Σενάριο Επίθεσης #1
Το υλικολογισμικό (firmware) μιας συσκευής γονικού ελέγχου παρέχει το τελικό σημείο προορισμού /api/CONFIG/restore το οποίο έχει σχεδιαστεί έτσι ώστε η παράμετρος appId να αποστέλεται ως παράμετρος πολλαπλών τμημάτων (multipart parameter).
Χρησιμοποιώντας έναν απομεταγλωττιστή (decompiler), ένας εισβολέας ανακαλύπτει ότι το appId περνάει απευθείας σε μια κλήση συστήματος χωρίς καμία απολύμανση (sanitization):
snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
"/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);
Η ακόλουθη εντολή επιτρέπει στον εισβολέα να τερματίσει οποιαδήποτε συσκευή με το ίδιο ευάλωτο υλικολογισμικό:
$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'
Σενάριο Επίθεσης #2
Έχουμε μια εφαρμογή με βασική λειτουργικότητα CRUD για λειτουργίες με κρατήσεις (bookings).
Ένας εισβολέας κατάφερε να αναγνωρίσει ότι η εισαγωγή NoSQL μπορεί να είναι δυνατή μέσω της παραμέτρου ερωτήματος bookingId στο αίτημα διαγραφής κράτησης. To αίτημα είναι το εξής: DELETE /api/bookings?bookingId=678.
Ο διακομιστής API χρησιμοποιεί την ακόλουθη λειτουργία (function) για να χειριστεί αιτήματα διαγραφής:
router.delete('/bookings', async function (req, res, next) {
try {
const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
res.status(200);
} catch (err) {
res.status(400).json({error: 'Unexpected error occured while processing a request'});
}
});
Ο εισβολέας υπέκλεψε το αίτημα και άλλαξε την παράμετρο ερωτήματος bookingId, όπως φαίνεται παρακάτω. Σε αυτήν την περίπτωση, ο εισβολέας κατάφερε να διαγράψει την κράτηση άλλου χρήστη:
DELETE /api/bookings?bookingId[$ne]=678
Τρόπος Πρόληψης
Η πρόληψη της έγχυσης απαιτεί τη διατήρηση των δεδομένων ξεχωριστά από εντολές και ερωτήματα.
- Εκτελέστε επικύρωση (validation) δεδομένων χρησιμοποιώντας μια αξιόπιστη και ενεργά συντηρούμενη βιβλιοθήκη.
- Όλα τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες ή άλλα δεδομένα που προέρχονται από ενσωματωμένα συστήματα πρέπει να επικυρώνονται (validation), φιλτράρονται ή/και να απολυμαίνονται (sanitization).
- Οι ειδικοί χαρακτήρες θα πρέπει να διαφεύγονται (escape) χρησιμοποιώντας τη συγκεκριμένη σύνταξη του διερμηνέα λογισμικού που λαμβάνει τα δεδομένα.
- Προτιμήστε ένα ασφαλές API που παρέχει μια παραμετροποιημένη διεπαφή.
- Φροντίστε να περιορίσετε τον αριθμό των επιστρεφόμενων εγγραφών για να αποτρέψετε τη μαζική παραβίαση δεδομένων σε περίπτωση επίθεσης.
- Επικυρώστε τα εισερχόμενα δεδομένα χρησιμοποιώντας επαρκή φίλτρα για να επιτρέπονται μόνο έγκυρες τιμές για κάθε παράμετρο εισόδου.
- Ορίστε τύπους δεδομένων και αυστηρά μοτίβα για όλες τις παραμέτρους αιτημάτων.