sql injection testing tutorial example
SQL Injection Παραδείγματα και τρόποι αποτροπής επιθέσεων SQL Injection σε εφαρμογές Web
Κατά τη δοκιμή ενός ιστότοπου ή ενός συστήματος, ο στόχος του ελεγκτή είναι να διασφαλίσει εάν το δοκιμασμένο προϊόν προστατεύεται όσο το δυνατόν περισσότερο.
Ο έλεγχος ασφαλείας πραγματοποιείται συνήθως για το σκοπό αυτό. Προκειμένου να εκτελέσουμε αυτόν τον τύπο δοκιμών, αρχικά, πρέπει να εξετάσουμε, ποιες επιθέσεις είναι πιο πιθανό να συμβούν. Το SQL Injection είναι μία από αυτές τις επιθέσεις.
Το SQL Injection θεωρείται ως μία από τις πιο κοινές επιθέσεις, καθώς μπορεί να έχει σοβαρές και επιβλαβείς συνέπειες στο σύστημά σας και σε ευαίσθητα δεδομένα.
Τι θα μάθετε:
- Τι είναι το SQL Injection;
- Κίνδυνοι της έγχυσης SQL
- Η ουσία αυτής της επίθεσης
- Προτεινόμενο εργαλείο
- Δοκιμή ασφαλείας εφαρμογών Ιστού κατά SQL Injection
- Ευπαθή μέρη αυτής της επίθεσης
- Αυτοματοποίηση δοκιμών έγχυσης SQL
- Σύγκριση με άλλες επιθέσεις
- συμπέρασμα
- Συνιστώμενη ανάγνωση
Τι είναι το SQL Injection;
Ορισμένες από τις εισόδους του χρήστη ενδέχεται να χρησιμοποιηθούν στο πλαίσιο Δηλώσεις SQL που στη συνέχεια εκτελούνται από την εφαρμογή στη βάση δεδομένων. Είναι πιθανό μια εφαρμογή ΔΕΝ να χειρίζεται τις εισόδους που δίνει ο χρήστης σωστά.
Εάν συμβαίνει αυτό, Ένας κακόβουλος χρήστης θα μπορούσε να παρέχει απροσδόκητες εισόδους στην εφαρμογή που στη συνέχεια χρησιμοποιούνται για το πλαίσιο και την εκτέλεση δηλώσεων SQL στη βάση δεδομένων. Αυτό ονομάζεται SQL Injection. Οι συνέπειες μιας τέτοιας δράσης θα μπορούσαν να είναι ανησυχητικές.
Όπως υποδηλώνει το ίδιο το όνομα, ο σκοπός της επίθεσης SQL Injection είναι να εισαγάγει τον κακόβουλο κώδικα SQL.
Κάθε πεδίο ενός ιστότοπου είναι σαν μια πύλη στη βάση δεδομένων. Στη φόρμα σύνδεσης, ο χρήστης εισάγει τα δεδομένα σύνδεσης, στο πεδίο αναζήτησης ο χρήστης εισάγει ένα κείμενο αναζήτησης, στη φόρμα αποθήκευσης δεδομένων ο χρήστης εισάγει δεδομένα για αποθήκευση. Όλα αυτά τα αναφερόμενα δεδομένα πηγαίνουν στη βάση δεδομένων.
Αντί για σωστά δεδομένα, εάν εισαχθεί οποιοσδήποτε κακόβουλος κώδικας, τότε υπάρχουν πιθανότητες να προκληθεί σοβαρή ζημιά στη βάση δεδομένων και σε ολόκληρο το σύστημα.
Το SQL Injection εκτελείται με τη γλώσσα προγραμματισμού SQL. Το SQL (Structured Query Language) χρησιμοποιείται για τη διαχείριση των δεδομένων που διατηρούνται στη βάση δεδομένων. Επομένως, κατά τη διάρκεια αυτής της επίθεσης, αυτός ο κωδικός γλώσσας προγραμματισμού χρησιμοποιείται ως κακόβουλη ένεση.
Αυτή είναι μια από τις πιο δημοφιλείς επιθέσεις, καθώς οι βάσεις δεδομένων χρησιμοποιούνται για όλες σχεδόν τις τεχνολογίες.
Πολλές εφαρμογές χρησιμοποιούν κάποιο τύπο βάσης δεδομένων. Μια υπό δοκιμή εφαρμογή ενδέχεται να έχει μια διεπαφή χρήστη που δέχεται είσοδο χρήστη που χρησιμοποιείται για την εκτέλεση των ακόλουθων εργασιών:
# 1) Εμφάνιση των σχετικών αποθηκευμένων δεδομένων στον χρήστη, π.χ. η εφαρμογή ελέγχει τα διαπιστευτήρια του χρήστη χρησιμοποιώντας τα στοιχεία σύνδεσης που εισάγει ο χρήστης και εκθέτει μόνο τη σχετική λειτουργικότητα και δεδομένα στον χρήστη
#δύο) Αποθηκεύστε τα δεδομένα που εισήγαγε ο χρήστης στη βάση δεδομένων π.χ. Μόλις ο χρήστης συμπληρώσει μια φόρμα και την υποβάλει, η εφαρμογή προχωρά στην αποθήκευση των δεδομένων στη βάση δεδομένων. Αυτά τα δεδομένα στη συνέχεια τίθενται στη διάθεση του χρήστη στην ίδια περίοδο λειτουργίας καθώς και στις επόμενες συνεδρίες
Κίνδυνοι της έγχυσης SQL
Σήμερα, μια βάση δεδομένων χρησιμοποιείται για σχεδόν όλα τα συστήματα και τους ιστότοπους, καθώς τα δεδομένα πρέπει να αποθηκεύονται κάπου.
Καθώς τα ευαίσθητα δεδομένα αποθηκεύονται στη βάση δεδομένων, υπάρχουν περισσότεροι κίνδυνοι που εμπλέκονται στην ασφάλεια του συστήματος. Εάν κάποιο προσωπικό ιστότοπο ή δεδομένα ιστολογίου θα κλαπεί, τότε δεν θα υπάρξει μεγάλη ζημιά σε σύγκριση με τα δεδομένα που θα κλαπεί από το τραπεζικό σύστημα.
Ο κύριος σκοπός αυτής της επίθεσης είναι να χαράξει τη βάση δεδομένων του συστήματος, επομένως οι συνέπειες αυτής της επίθεσης μπορεί πραγματικά να είναι επιβλαβείς.
Τα ακόλουθα πράγματα ενδέχεται να προκύψουν από το SQL Injection
- Παραβίαση λογαριασμού άλλου ατόμου.
- Κλοπή και αντιγραφή ευαίσθητων δεδομένων ιστότοπου ή συστήματος.
- Αλλαγή των ευαίσθητων δεδομένων του συστήματος.
- Διαγραφή ευαίσθητων δεδομένων συστήματος.
- Ο χρήστης θα μπορούσε να συνδεθεί στην εφαρμογή ως άλλος χρήστης, ακόμη και ως διαχειριστής.
- Ο χρήστης θα μπορούσε να δει ιδιωτικές πληροφορίες που ανήκουν σε άλλους χρήστες, π.χ. λεπτομέρειες για προφίλ άλλων χρηστών, λεπτομέρειες συναλλαγής κ.λπ.
- Ο χρήστης θα μπορούσε να αλλάξει τις πληροφορίες διαμόρφωσης της εφαρμογής και τα δεδομένα των άλλων χρηστών.
- Ο χρήστης θα μπορούσε να τροποποιήσει τη δομή της βάσης δεδομένων. ακόμη και να διαγράψετε πίνακες στη βάση δεδομένων της εφαρμογής.
- Ο χρήστης θα μπορούσε να πάρει τον έλεγχο του διακομιστή βάσης δεδομένων και να εκτελέσει τις εντολές του κατά βούληση.
Οι παραπάνω αναφερόμενοι κίνδυνοι μπορούν πραγματικά να θεωρηθούν σοβαροί, καθώς η αποκατάσταση μιας βάσης δεδομένων ή των δεδομένων της μπορεί να κοστίσει πολύ. Μπορεί να κοστίσει στην εταιρεία σας μια φήμη και χρήματα για την αποκατάσταση των χαμένων δεδομένων και συστήματος. Επομένως, συνιστάται ιδιαίτερα να προστατεύετε το σύστημά σας από αυτόν τον τύπο επίθεσης και να θεωρείτε το Δοκιμή ασφαλείας ως καλή επένδυση στη φήμη του προϊόντος και της εταιρείας σας.
Ως εξεταστής, θα ήθελα να σχολιάσω, ότι η δοκιμή κατά πιθανών επιθέσεων είναι μια καλή πρακτική, ακόμη κι αν Δοκιμή ασφαλείας δεν είχε προγραμματιστεί. Με αυτόν τον τρόπο μπορείτε να προστατεύσετε και να δοκιμάσετε το προϊόν από απρόσμενες περιπτώσεις και κακόβουλους χρήστες.
Η ουσία αυτής της επίθεσης
Όπως αναφέρθηκε προηγουμένως, η ουσία αυτής της επίθεσης είναι η παραβίαση της βάσης δεδομένων με κακόβουλο σκοπό.
Για να εκτελέσετε αυτόν τον έλεγχο ασφαλείας, αρχικά, πρέπει να βρείτε τα ευπαθή μέρη του συστήματος και, στη συνέχεια, να στείλετε κακόβουλο κώδικα SQL μέσω αυτών στη βάση δεδομένων. Εάν αυτή η επίθεση είναι δυνατή για ένα σύστημα, τότε θα αποσταλεί κατάλληλος κακόβουλος κώδικας SQL και ενδέχεται να πραγματοποιηθούν επιβλαβείς ενέργειες στη βάση δεδομένων.
Κάθε πεδίο ενός ιστότοπου είναι σαν μια πύλη στη βάση δεδομένων. Τυχόν δεδομένα ή στοιχεία που συνήθως εισάγουμε σε οποιοδήποτε πεδίο του συστήματος ή του ιστότοπου μεταβαίνουν στο ερώτημα της βάσης δεδομένων. Επομένως, αντί για σωστά δεδομένα, αν πληκτρολογήσουμε κακόβουλο κώδικα, τότε μπορεί να εκτελεστεί στο ερώτημα της βάσης δεδομένων και να έχει επιβλαβείς συνέπειες.
Προτεινόμενο εργαλείο
# 1) Kiuwan
Βρείτε εύκολα και διορθώστε ευπάθειες όπως SQL injection στον κώδικά σας σε κάθε στάδιο του SDLC. Το Kiuwan συμμορφώνεται με τα πιο αυστηρά πρότυπα ασφαλείας, συμπεριλαμβανομένων των OWASP, CWE, SANS 25, HIPPA και πολλά άλλα.
Ενσωματώστε το Kiuwan στο IDE σας για άμεση ανατροφοδότηση κατά τη διάρκεια της ανάπτυξης. Το Kiuwan υποστηρίζει όλες τις μεγάλες γλώσσες προγραμματισμού και ενσωματώνεται με κορυφαία εργαλεία DevOps.
=> Σαρώστε τον κωδικό σας δωρεάν
Για την εκτέλεση αυτής της επίθεσης, πρέπει να αλλάξουμε την πράξη και τον σκοπό ενός κατάλληλου ερωτήματος βάσης δεδομένων. Μία από τις πιθανές μεθόδους για να το εκτελέσετε είναι να κάνετε το ερώτημα πάντα αληθινό και μετά από αυτό να εισαγάγετε τον κακόβουλο κωδικό σας. Η αλλαγή του ερωτήματος βάσης δεδομένων σε πάντα αληθινή μπορεί να πραγματοποιηθεί με απλό κώδικα όπως «ή 1 = 1; -.
Οι δοκιμαστές θα πρέπει να έχουν κατά νου, ότι ενώ ελέγχοντας εάν μπορεί να πραγματοποιηθεί ή όχι η αλλαγή του ερωτήματος σε πάντα αληθές, θα πρέπει να δοκιμαστούν διαφορετικά εισαγωγικά - μεμονωμένα και διπλά. Επομένως, εάν έχουμε δοκιμάσει κώδικα όπως 'ή 1 = 1; -, θα πρέπει επίσης να δοκιμάσουμε τον κώδικα με διπλά εισαγωγικά' ή 1 = 1; -.
Για παράδειγμα, ας υποθέσουμε ότι έχουμε ένα ερώτημα, που αναζητά τη λέξη που έχει εισαχθεί στον πίνακα βάσης δεδομένων:
επιλέξτε * από τις σημειώσεις nt όπου nt.subject = ‘search_word’;
Επομένως, αντί της λέξης αναζήτησης, εάν εισαγάγουμε ένα ερώτημα SQL Injection 'ή 1 = 1; -, τότε το ερώτημα θα είναι πάντα αληθινό.
επιλέξτε * από τις σημειώσεις nt όπου nt.subject = '' ή 1 = 1; -
Σε αυτήν την περίπτωση, η παράμετρος 'θέμα' κλείνει με το απόσπασμα και στη συνέχεια έχουμε κώδικα ή 1 = 1, κάτι που κάνει ένα ερώτημα πάντα αληθινό. Με το σύμβολο '-' σχολιάζουμε τον υπόλοιπο κώδικα ερωτήματος, ο οποίος δεν θα εκτελεστεί. Είναι ένας από τους πιο δημοφιλείς και ευκολότερους τρόπους για να αρχίσετε να ελέγχετε το ερώτημα.
Λίγοι άλλοι κωδικοί μπορούν επίσης να χρησιμοποιηθούν για να κάνουν το ερώτημα πάντα αληθινό, όπως:
- 'Ή' abc '=' abc '· -
- 'Ή' '=' '; -
Το πιο σημαντικό μέρος εδώ είναι ότι μετά το σύμβολο κόμμα μπορούμε να εισαγάγουμε οποιονδήποτε κακόβουλο κώδικα, τον οποίο θα θέλαμε να εκτελεστεί.
Για παράδειγμα, μπορεί να είναι «ή 1 = 1 · ρίξτε σημειώσεις πίνακα; -
Εάν αυτή η ένεση είναι δυνατή, τότε μπορεί να γραφτεί οποιοσδήποτε άλλος κακόβουλος κωδικός. Σε αυτήν την περίπτωση, εξαρτάται μόνο από τη γνώση και την πρόθεση του κακόβουλου χρήστη. Πώς να ελέγξετε το SQL Injection;
Ο έλεγχος αυτής της ευπάθειας μπορεί να γίνει πολύ εύκολα. Μερικές φορές αρκεί να πληκτρολογήσετε 'ή' συνδεθείτε στα δοκιμασμένα πεδία. Εάν επιστρέψει οποιοδήποτε απροσδόκητο ή εξαιρετικό μήνυμα, τότε μπορούμε να είμαστε σίγουροι ότι το SQL Injection είναι δυνατό για αυτό το πεδίο.
Για παράδειγμα , εάν λάβετε ένα μήνυμα σφάλματος όπως 'Εσωτερικό σφάλμα διακομιστή' ως αποτέλεσμα αναζήτησης, τότε μπορούμε να είμαστε σίγουροι ότι αυτή η επίθεση είναι δυνατή σε αυτό το τμήμα του συστήματος.
Άλλα αποτελέσματα, που μπορούν να κοινοποιήσουν πιθανή επίθεση περιλαμβάνουν:
- Η κενή σελίδα φορτώθηκε.
- Δεν υπάρχουν μηνύματα σφάλματος ή επιτυχίας - η λειτουργικότητα και η σελίδα δεν αντιδρούν στην είσοδο.
- Μήνυμα επιτυχίας για κακόβουλο κώδικα.
Ας δούμε πώς λειτουργεί αυτό στην πράξη.
Για παράδειγμα, Ας δοκιμάσουμε εάν ένα κατάλληλο παράθυρο σύνδεσης είναι ευάλωτο στο SQL Injection. Για το σκοπό αυτό, στο πεδίο διεύθυνσης email ή κωδικού πρόσβασης, πληκτρολογούμε απλώς πινακίδα όπως φαίνεται παρακάτω.
Εάν τέτοια είσοδος επιστρέφει σαν μήνυμα σφάλματος «Εσωτερικό σφάλμα διακομιστή» ή οποιοδήποτε άλλο αναφερόμενο ακατάλληλο αποτέλεσμα, τότε μπορούμε σχεδόν να είμαστε σίγουροι ότι αυτή η επίθεση είναι δυνατή για αυτό το πεδίο.
Πολύ δύσκολο Κωδικός έγχυσης SQL μπορεί επίσης να δοκιμαστεί. Θα ήθελα να αναφέρω, ότι στην καριέρα μου δεν αντιμετώπισα καμία περίπτωση όταν υπήρχε μήνυμα «Εσωτερικό σφάλμα διακομιστή» ως αποτέλεσμα του σημείου, αλλά κατά καιρούς τα πεδία δεν αντέδρασαν για πιο περίπλοκο κώδικα SQL.
Επομένως, ο έλεγχος για SQL Injection με ένα μόνο απόσπασμα «είναι αρκετά αξιόπιστος τρόπος για να ελέγξετε αν αυτή η επίθεση είναι δυνατή ή όχι.
Εάν η μεμονωμένη προσφορά δεν επιστρέφει ακατάλληλο αποτέλεσμα, τότε μπορούμε να προσπαθήσουμε να εισαγάγουμε διπλά εισαγωγικά και να ελέγξουμε τα αποτελέσματα.
Επίσης, ο κώδικας SQL για την αλλαγή του ερωτήματος σε πάντα αληθές μπορεί να θεωρηθεί ως τρόπος για να ελέγξετε εάν αυτή η επίθεση είναι δυνατή ή όχι. Κλείνει την παράμετρο και αλλάζει το ερώτημα σε «true». Επομένως, εάν δεν επικυρώνεται, τέτοια είσοδος μπορεί επίσης να επιστρέψει οποιοδήποτε απροσδόκητο αποτέλεσμα και να ενημερώσει το ίδιο, ότι αυτή η επίθεση είναι δυνατή σε αυτήν την περίπτωση.
Ο έλεγχος για πιθανές επιθέσεις SQL μπορεί επίσης να πραγματοποιηθεί από τον σύνδεσμο του ιστότοπου. Ας υποθέσουμε ότι έχουμε έναν σύνδεσμο ιστότοπου ως http://www.testing.com/books=1 . Σε αυτήν την περίπτωση, τα «βιβλία» είναι μια παράμετρος και το «1» είναι η αξία του. Εάν στον παρεχόμενο σύνδεσμο γράφουμε «σημάδι αντί για 1, τότε θα ελέγξαμε για πιθανή ένεση.
Επομένως συνδέστε http://www.testing.com/books= θα είναι σαν ένα τεστ αν η επίθεση SQL είναι δυνατή για τον ιστότοπο http://www.testing.com ή όχι.
Σε αυτήν την περίπτωση, εάν υπάρχει σύνδεσμος http://www.testing.com/books= επιστρέφει ένα μήνυμα σφάλματος όπως «Εσωτερικό σφάλμα διακομιστή» ή μια κενή σελίδα ή οποιοδήποτε άλλο απροσδόκητο μήνυμα σφάλματος, τότε επίσης μπορούμε να είμαστε σίγουροι ότι το SQL Injection είναι δυνατό για αυτόν τον ιστότοπο. Αργότερα, μπορούμε να προσπαθήσουμε να στείλουμε πιο δύσκολο κώδικα SQL μέσω του συνδέσμου του ιστότοπου.
Για να ελέγξετε εάν αυτή η επίθεση είναι δυνατή μέσω του συνδέσμου του ιστότοπου ή όχι, μπορεί να σταλεί κωδικός όπως «ή 1 = 1» - μπορεί επίσης να σταλεί.
Ως έμπειρος ελεγκτής λογισμικού, θα ήθελα να υπενθυμίσω ότι όχι μόνο το απροσδόκητο μήνυμα σφάλματος μπορεί να θεωρηθεί ως ευπάθεια SQL Injection. Πολλοί ελεγκτές ελέγχουν για πιθανές επιθέσεις μόνο σύμφωνα με τα μηνύματα σφάλματος.
Ωστόσο, πρέπει να θυμόμαστε, ότι κανένα μήνυμα σφάλματος επικύρωσης ή μήνυμα επιτυχίας για κακόβουλο κώδικα δεν μπορεί επίσης να αποτελεί ένδειξη, ότι αυτή η επίθεση είναι δυνατή.
Δοκιμή ασφαλείας εφαρμογών Ιστού κατά SQL Injection
Ο έλεγχος ασφαλείας εφαρμογών ιστού εξηγείται με απλά παραδείγματα:
Δεδομένου ότι οι συνέπειες από την αποδοχή αυτής της τεχνικής ευπάθειας μπορεί να είναι σοβαρές, συνεπάγεται ότι αυτή η επίθεση πρέπει να δοκιμαστεί κατά τη διάρκεια της δοκιμής ασφαλείας μιας εφαρμογής. Τώρα με μια επισκόπηση αυτής της τεχνικής, ας καταλάβουμε μερικά πρακτικά παραδείγματα SQL injection.
Σημαντικό: Αυτό το SQL Injection Test θα πρέπει να δοκιμάζεται μόνο στο περιβάλλον δοκιμής.
Εάν η εφαρμογή διαθέτει σελίδα σύνδεσης, είναι πιθανό η εφαρμογή να χρησιμοποιεί δυναμική SQL, όπως η παρακάτω δήλωση. Αυτή η δήλωση αναμένεται να επιστρέψει τουλάχιστον μία σειρά με τα στοιχεία χρήστη από τον πίνακα Χρήστες ως αποτέλεσμα που ορίζεται όταν υπάρχει μια σειρά με το όνομα χρήστη και τον κωδικό πρόσβασης που έχουν εισαχθεί στη δήλωση SQL.
ΕΠΙΛΟΓΗ * ΑΠΟ Χρήστες ΠΟΥ ΕΧΟΥΝ Όνομα χρήστη = ‘” & strUserName & “‘ AND Password = ‘” & Κωδικός πρόσβασης & '';'
Εάν ο ελεγκτής εισάγει τον John ως strUserName (στο πλαίσιο κειμένου για το όνομα χρήστη) και Smith ως strPassword (στο πλαίσιο κειμένου για κωδικό πρόσβασης), η παραπάνω δήλωση SQL θα γίνει:
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;
Εάν ο υπεύθυνος δοκιμών εισάγει το John’– ως strUserName και χωρίς strPassword, η δήλωση SQL θα γίνει:
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;
Σημειώστε ότι το τμήμα της δήλωσης SQL μετά τον John μετατρέπεται σε σχόλιο. Εάν υπήρχε κάποιος χρήστης με το όνομα χρήστη του John στον πίνακα Χρήστες, η εφαρμογή θα μπορούσε να επιτρέψει στον ελεγκτή να συνδεθεί ως χρήστης John. Ο ελεγκτής θα μπορούσε τώρα να δει τις προσωπικές πληροφορίες του χρήστη John.
Τι γίνεται αν ο υπεύθυνος δοκιμών δεν γνωρίζει το όνομα του υπάρχοντος χρήστη της εφαρμογής; Σε μια τέτοια περίπτωση, ο υπεύθυνος δοκιμών θα μπορούσε να δοκιμάσει κοινά ονόματα χρηστών όπως διαχειριστής, διαχειριστής και sysadmin. Εάν κανένας από αυτούς τους χρήστες δεν υπάρχει στη βάση δεδομένων, ο υπεύθυνος δοκιμών θα μπορούσε να εισαγάγει τον John 'ή' x '=' x ως strUserName και Smith 'ή' x '=' x ως strPassword. Αυτό θα έκανε τη δήλωση SQL να γίνει όπως η παρακάτω.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;
Δεδομένου ότι η κατάσταση 'x' = 'x' ισχύει πάντα, το σύνολο αποτελεσμάτων θα αποτελείται από όλες τις σειρές στον πίνακα 'Χρήστες'. Η εφαρμογή θα μπορούσε να επιτρέψει στον ελεγκτή να συνδεθεί ως ο πρώτος χρήστης στον πίνακα Χρήστες.
Σημαντικό: Ο ελεγκτής πρέπει να ζητήσει από τον διαχειριστή της βάσης δεδομένων ή τον προγραμματιστή να αντιγράψει τον εν λόγω πίνακα πριν επιχειρήσει τις ακόλουθες επιθέσεις.
Εάν ο εξεταστής μπήκε στον John »· DROP table users_details; ’- ως strUserName και οτιδήποτε άλλο ως strPassword, η δήλωση SQL θα γίνει όπως η παρακάτω.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';
Αυτή η δήλωση θα μπορούσε να προκαλέσει τη μόνιμη διαγραφή του πίνακα 'users_details' από τη βάση δεδομένων.
Αν και τα παραπάνω παραδείγματα ασχολούνται με τη χρήση της τεχνικής έγχυσης SQL μόνο της σελίδας σύνδεσης, ο υπεύθυνος δοκιμής θα πρέπει να δοκιμάσει αυτήν την τεχνική σε όλες τις σελίδες της εφαρμογής που δέχονται είσοδο χρήστη σε μορφή κειμένου π.χ. αναζήτηση σελίδων, σελίδων σχολίων κ.λπ.
Η ένεση SQL ενδέχεται να είναι δυνατή σε εφαρμογές που χρησιμοποιούν SSL. Ακόμα και ένα τείχος προστασίας ενδέχεται να μην είναι σε θέση να προστατεύσει την εφαρμογή από αυτήν την τεχνική.
Προσπάθησα να εξηγήσω αυτήν την τεχνική επίθεσης σε μια απλή μορφή. Θα ήθελα να επαναλάβω ότι αυτή η επίθεση πρέπει να δοκιμαστεί μόνο σε περιβάλλον δοκιμών και όχι στο περιβάλλον ανάπτυξης, στο περιβάλλον παραγωγής ή σε οποιοδήποτε άλλο περιβάλλον.
συγκρίνετε δύο αρχεία στο linux και βρείτε τις διαφορές
Αντί να δοκιμάσετε με μη αυτόματο τρόπο εάν η εφαρμογή είναι ευάλωτη σε επίθεση SQL ή όχι, θα μπορούσε κανείς να χρησιμοποιήσει ένα Σαρωτής ευπάθειας στο Διαδίκτυο που ελέγχει για αυτήν την ευπάθεια.
Σχετική ανάγνωση: Δοκιμή ασφαλείας της εφαρμογής Web . Ελέγξτε αυτό για περισσότερες λεπτομέρειες σχετικά με διαφορετικές ευπάθειες ιστού.
Ευπαθή μέρη αυτής της επίθεσης
Πριν ξεκινήσει η διαδικασία δοκιμών, κάθε ειλικρινής εξεταστής θα πρέπει να γνωρίζει λίγο πολύ ποια μέρη θα ήταν πιο ευάλωτα σε πιθανή αυτή την επίθεση.
Είναι επίσης μια καλή πρακτική να σχεδιάζετε ποιο πεδίο του συστήματος πρόκειται να δοκιμαστεί ακριβώς και με ποια σειρά. Στη δοκιμαστική μου καριέρα, έμαθα ότι δεν είναι καλή ιδέα να δοκιμάζω πεδία ενάντια σε επιθέσεις SQL τυχαία, καθώς ορισμένα πεδία μπορούν να χαθούν.
Καθώς αυτή η επίθεση εκτελείται στη βάση δεδομένων, όλα τα μέρη του συστήματος εισαγωγής δεδομένων, τα πεδία εισαγωγής και οι σύνδεσμοι ιστότοπων είναι ευάλωτα.
Τα ευπαθή μέρη περιλαμβάνουν:
- Πεδία σύνδεσης
- Αναζήτηση πεδίων
- Πεδία σχολίων
- Οποιαδήποτε άλλα πεδία εισαγωγής και αποθήκευσης δεδομένων
- Σύνδεσμοι ιστότοπου
Είναι σημαντικό να παρατηρήσετε ότι ενώ δοκιμάζετε αυτήν την επίθεση δεν αρκεί να ελέγξετε μόνο ένα ή μερικά πεδία. Είναι πολύ κοινό, ότι ένα πεδίο μπορεί να προστατεύεται από το SQL Injection, αλλά στη συνέχεια ένα άλλο δεν το προστατεύει. Επομένως, είναι σημαντικό να μην ξεχάσετε να δοκιμάσετε όλα τα πεδία του ιστότοπου.
Αυτοματοποίηση δοκιμών έγχυσης SQL
Καθώς ορισμένα δοκιμασμένα συστήματα ή ιστότοποι μπορεί να είναι αρκετά περίπλοκο και να περιέχουν ευαίσθητα δεδομένα, η χειροκίνητη δοκιμή μπορεί να είναι πολύ δύσκολη και χρειάζεται πολύς χρόνος επίσης. Επομένως, οι δοκιμές κατά αυτής της επίθεσης με ειδικά εργαλεία μπορεί να είναι πολύ χρήσιμες κατά καιρούς.
Ένα τέτοιο εργαλείο SQL Injection είναι UI σαπουνιού . Εάν έχουμε αυτοματοποιημένους ελέγχους παλινδρόμησης σε επίπεδο API, μπορούμε επίσης να αλλάξουμε τον έλεγχο ενάντια σε αυτήν την επίθεση χρησιμοποιώντας αυτό το εργαλείο. Στο εργαλείο SOI UI, υπάρχουν ήδη προετοιμασμένα πρότυπα κώδικα για έλεγχο κατά αυτής της επίθεσης. Αυτά τα πρότυπα μπορούν επίσης να συμπληρωθούν από τον δικό σας γραπτό κωδικό.
Είναι ένα αρκετά αξιόπιστο εργαλείο.
Ωστόσο, μια δοκιμή θα πρέπει ήδη να αυτοματοποιηθεί σε επίπεδο API, κάτι που δεν είναι τόσο εύκολο. Ένας άλλος πιθανός τρόπος αυτόματης δοκιμής είναι η χρήση διαφόρων προσθηκών προγράμματος περιήγησης.
Θα πρέπει να αναφερθεί, ότι ακόμη και αν τα αυτοματοποιημένα εργαλεία εξοικονομούν χρόνο, δεν θεωρούνται πάντα αξιόπιστα. Εάν δοκιμάζουμε ένα τραπεζικό σύστημα ή οποιονδήποτε ιστότοπο με πολύ ευαίσθητα δεδομένα, συνιστάται να το δοκιμάσετε χειροκίνητα. Όπου μπορείτε να δείτε τα ακριβή αποτελέσματα και να τα αναλύσετε. Επίσης, σε αυτήν την περίπτωση, μπορούμε να είμαστε σίγουροι, ότι τίποτα δεν παραλείφθηκε.
Σύγκριση με άλλες επιθέσεις
Το SQL Injection μπορεί να θεωρηθεί ως μία από τις πιο σοβαρές επιθέσεις, καθώς επηρεάζει τη βάση δεδομένων και μπορεί να προκαλέσει σοβαρή ζημιά στα δεδομένα σας και σε ολόκληρο το σύστημα.
Σίγουρα μπορεί να έχει πιο σοβαρές συνέπειες από ένα Javascript Injection ή HTML Injection, καθώς και τα δύο εκτελούνται από την πλευρά του πελάτη. Για σύγκριση, με αυτήν την επίθεση, μπορείτε να έχετε πρόσβαση σε ολόκληρη τη βάση δεδομένων.
Θα πρέπει να αναφερθεί, ότι για να δοκιμάσετε αυτήν την επίθεση, θα πρέπει να έχετε πολύ καλή γνώση της γλώσσας προγραμματισμού SQL και γενικά, πρέπει να γνωρίζετε πώς λειτουργούν τα ερωτήματα βάσεων δεδομένων. Επίσης, κατά την εκτέλεση αυτής της επίθεσης ένεσης, θα πρέπει να είστε πιο προσεκτικοί και προσεκτικοί, καθώς τυχόν ανακρίβεια μπορεί να παραμείνει ως ευπάθεια SQL.
συμπέρασμα
Ελπίζω να έχετε μια σαφή ιδέα για το τι είναι ένα SQL Injection και πώς πρέπει να αποτρέψουμε αυτές τις επιθέσεις.
Ωστόσο, συνιστάται ιδιαίτερα να κάνετε δοκιμές έναντι αυτού του τύπου επίθεσης κάθε φορά που δοκιμάζεται ένα σύστημα ή ιστότοπος με βάση δεδομένων. Κάθε αριστερή βάση δεδομένων ή ευπάθειες συστήματος μπορεί να κοστίσει τη φήμη μιας εταιρείας και πολλούς πόρους για την αποκατάσταση ολόκληρου του συστήματος.
Καθώς η δοκιμή ενάντια σε αυτήν την ένεση βοηθά να βρει τα περισσότερα σημαντικές ευπάθειες ασφαλείας , συνιστάται επίσης να επενδύσετε στις γνώσεις και τα εργαλεία δοκιμών σας.
Εάν έχει προγραμματιστεί δοκιμή ασφαλείας, τότε θα πρέπει να προγραμματιστεί δοκιμή έναντι του SQL Injection ως ένα από τα πρώτα μέρη δοκιμής.
Έχετε συναντήσει κάποιο τυπικό SQL Injection; Μη διστάσετε να μοιραστείτε τις εμπειρίες σας στην παρακάτω ενότητα σχολίων.
Συνιστώμενη ανάγνωση
- Tutorial HTML Injection: Τύποι & πρόληψη με παραδείγματα
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
- Εκμάθηση έκλειψης σε βάθος για αρχάριους
- Οδηγός καταστροφικών δοκιμών και μη καταστροφικών δοκιμών
- Testing Primer eBook Λήψη
- Λειτουργική δοκιμή Vs Μη λειτουργική δοκιμή
- Εκμάθηση δοκιμών SOA: Μεθοδολογία δοκιμών για ένα μοντέλο αρχιτεκτονικής SOA
- Εκμάθηση Pairwise Test ή All-Pairs Testing με εργαλεία και παραδείγματα