Δοκιμές για ευπάθειες SQL Injection

Οι επιθέσεις SQL Injection θέτουν τεράστιους κινδύνους για τις εφαρμογές ιστού που εξαρτώνται από ένα backend βάσης δεδομένων για τη δημιουργία δυναμικού περιεχομένου. Σε αυτόν τον τύπο επίθεσης, οι χάκερ χειρίζονται μια εφαρμογή ιστού σε μια προσπάθεια να εισάγουν τις δικές τους εντολές SQL σε εκείνες που εκδίδονται από τη βάση δεδομένων. Για παράδειγμα, ανατρέξτε στο άρθρο SQL Attacks Injection on Databases. Σε αυτό το άρθρο, ρίχνουμε μια ματιά σε διάφορους τρόπους που μπορείτε να δοκιμάσετε τις εφαρμογές ιστού σας για να διαπιστώσετε εάν είναι ευάλωτοι στις επιθέσεις εισβολής SQL.

Αυτοματοποιημένη σάρωση με ένεση SQL

Μια πιθανότητα είναι η χρήση ενός αυτοματοποιημένου σαρωτή ευπάθειας για εφαρμογές ιστού, όπως το WebInspect της HP, το AppScan της IBM ή η χαλαρή καταιγίδα του Cenzic. Όλα αυτά τα εργαλεία προσφέρουν εύκολους, αυτοματοποιημένους τρόπους ανάλυσης των εφαρμογών ιστού για πιθανές ευπάθειες SQL Injection. Ωστόσο, είναι αρκετά ακριβό, τρέχοντας μέχρι και $ 25,000 ανά θέση.

Μη αυτόματες δοκιμές έγχυσης SQL

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

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

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

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

ΕΠΙΛΟΓΗ τηλεφώνου από τον κατάλογο WHERE όνομα = 'chapple' και όνομα = 'mike'

Ας πειραματιστούμε με αυτό λίγο. Με την παραδοχή μας παραπάνω, μπορούμε να κάνουμε μια απλή αλλαγή στη διεύθυνση URL που ελέγχει για επιθέσεις SQL injection:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

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

ΕΠΙΛΟΓΗ τηλεφώνου από τον κατάλογο WHERE το επώνυμο = 'chapple' και firstname = 'mike' ΚΑΙ (επιλέξτε count (*) από ψεύτικο)> 0 Ή '1'

Θα παρατηρήσετε ότι η παραπάνω σύνταξη είναι λίγο διαφορετική από αυτήν της αρχικής διεύθυνσης URL. Πήρα την ελευθερία να μετατρέψω τη μεταβλητή που κωδικοποιείται με URL για τα ισοδύναμα ASCII, ώστε να είναι πιο εύκολο να ακολουθηθεί το παράδειγμα. Για παράδειγμα, το% 3d είναι η κωδικοποίηση URL για τον χαρακτήρα '='. Προστέθηκα επίσης μερικές παραλείψεις γραμμής για παρόμοιους σκοπούς.

Αξιολόγηση των αποτελεσμάτων

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

Σφάλμα: Δεν βρέθηκε χρήστης με όνομα mike + AND + (επιλέξτε + count (*) + από + ψεύτικο) +% 3e0 + OR + 1% 3d1 Chapple!

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

Microsoft Provider OLE DB για προγράμματα οδήγησης ODBC σφάλμα '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Μη έγκυρο όνομα αντικειμένου "ψεύτικο". /directory.asp, γραμμή 13

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

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

Εάν λάβετε ένα από τα δύο παραπάνω σφάλματα, η εφαρμογή σας είναι ευάλωτη σε επίθεση κατά της έγχυσης SQL! Μερικά βήματα που μπορείτε να ακολουθήσετε για να προστατέψετε τις εφαρμογές σας από επιθέσεις SQL Injection περιλαμβάνουν: