Έγχυση SQL

Η έγχυση SQL (SQL Injection) χρησιμοποιείται στο πλαίσιο μιας επίθεσης σε εφαρμογές που αποθηκεύουν και διαχειρίζονται τα δεδομένα τους μέσω ενός Συστήματος Διαχείρισης Βάσης Δεδομένων. Χρησιμοποιώντας αυτή την τεχνική ο επιτιθέμενος εκμεταλλεύται μια ευπάθεια της εφαρμογής και εισάγει κακόβουλο SQL κώδικα σε σημεία όπου η εφαρμογή περιμένει θεμιτά δεδομένα από τον χρήστη.^[1] Μια τέτοια ευπάθεια προκύπτει στην περίπτωση που η εφαρμογή δεν διαθέτει έναν μηχανισμό που να φιλτράρει σωστά τα δεδομένα εισόδου του χρήστη. Λ.χ. δεν ψάχνει για τυχόν χαρακτήρες διαφυγής εμφωλευμένους μέσα στο αίτημα ενός χρήστη ή δεν υπάρχει αυστηρός έλεγχος των τύπων των δεδομένων που εισάγει ο χρήστης.

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

Ιστορία

Οι πρώτες δημόσιες συζητήσεις για επιθέσεις έγχυσης SQL ξεκίνησαν από το 1998.^[2][3]

Μορφή

Οι επιθέσεις έγχυσης (με την έγχυση SQL να είναι εκ των σημαντικότερων) θεωρούνται επί σειρά ετών ως οι κρισιμότερες για την ασφάλεια των διαδικτυακών εφαρμογών με βάση το Open Web Application Security Project (OWASP).^[4][5][6] Υπάρχουν τέσσερις (4) υποκατηγορίες έγχυσης SQL:

• Κλασική έγχυση SQL
• Τυφλή έγχυση SQL
• Έγχυση SQL με βάση το Σύστημα Διαχείρισης Βάσης Δεδομένων (ΣΔΒΔ)
• Σύνθετη έγχυση SQL
  • Έγχυση SQL + ανεπαρκής αυθεντικοποίηση^[7]
  • Έγχυση SQL + επιθέσεις άρνησης υπηρεσιών^[8]
  • Έγχυση SQL + DNS hijacking^[8]
  • Έγχυση SQL + Cross-site scripting^[8]

Το Storm Worm αποτελεί παράδειγμα σύνθετης έγχυσης SQL.^[9]

Τεχνική Υλοποίηση

Λανθασμένο φιλτράρισμα χαρακτήρων διαφυγής

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

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

Ο παραπάνω SQL κώδικας είναι σχεδιασμένος ώστε να επιστρέφει τις εγγραφές που έχουν ένα καθορισμένο όνομα χρήστη (όπως αυτό ορίζεται από την μεταβλητή “userName”) από τον πίνακα “users” της βάσης. Ωστόσο, εάν η μεταβλητή “userName” λάβει μία κακόβουλη τιμή από τον χρήστη, τότε το εν λόγω SQL αίτημα μπορεί να εκτελέσει παραπάνω λειτουργίες απ’ ό,τι αρχικά προοριζόταν από τον συγγραφέα του κώδικα. Για παράδειγμα, δίνοντας στην μεταβλητή “userName” την τιμή:

' OR '1'='1

ή κάνοντας χρήση σχολίων για να παραβλεφθεί το υπόλοιπο του SQL αιτήματος.^[10] Να σημειωθεί πως υπάρχουν τρεις τρόποι για να χρηση σχολίων στην SQL όπως παρατηρούμε παρακάτω (όλες οι παρακάτω γραμμές έχουν κενό στο τέλος):

' OR '1'='1' --
' OR '1'='1' {

' OR '1'='1' /* 

Οι παραπάνω τιμές δημιουργούν τα ακόλουθα SQL αιτήματα:

SELECT * FROM users WHERE name = '' OR '1'='1';

SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

Εάν αυτός ο κώδικας επρόκειτο να χρησιμοποιηθεί κατά την διαδικασία αυθεντικοποίησης, τότε το παράδειγμα αυτό θα μπορούσε να χρησιμοποιηθεί ώστε να επιβάλλει την επιλογή κάθε πεδίου δεδομένων (*) κάθε χρήστη και όχι ενός χρήστη όπως προβλεπόταν αρχικά από τον προγραμματιστή, διότι η συνθήκη ‘1’ = ‘1’ είναι πάντα αληθής.

Η ακόλουθη τιμή της μεταβλητής “userName” θα προκαλούσε την διαγραφή του πίνακα “users”, καθώς και την επιλογή όλων των δεδομένων του πίνακα “userinfo” (ουσιαστικά αποκαλύπτοντας τις πληροφορίες κάθε χρήστη), κάνοντας χρήση μίας Διεπαφής Προγραμματισμού Εφαρμογών (API) που επιτρέπει την εκτέλεση πολλαπλών αιτημάτων:

 a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Η παραπάνω είσοδος, οδηγεί στην κατασκευή του ακόλουθου SQL αιτήματος:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Ενώ οι περισσότεροι SQL εξυπηρετητές επιτρέπουν την εκτέλεση πολλαπλών SQL αιτημάτων με μία κληση, ορισμένες Διεπαφές Προγραμματισμού Εφαρμογών SQL, όπως η συνάρτηση mysql_query()της PHP δεν το επιτρέπουν για λόγους ασφάλειας. Αυτό, αποτρέπει την έγχυση ολόκληρων ξεχωριστών αιτημάτων, αλλά όχι και την τροποποίηση ενός αιτήματος.

Τυφλή έγχυση SQL

Μία επίθεση τυφλής έγχυσης SQL μπορεί να πραγματοποιηθεί όταν η εφαρμογή είναι μεν ευάλωτη σε επιθέσεις έγχυσης SQL, αλλά τα αποτελέσματα αυτής δεν είναι ορατά στον επιτιθέμενο. Συγκεκριμένα, η ευάλωτη σελίδα, ανάλογα με το λογικό αίτημα που θα εισαχθεί στην SQL επερώτηση, θα μπορεί να έχει διαφορετική μορφή (λ.χ. διαφορετικό περιεχόμενο) ή να μην αλλάζει καθόλου. Αυτό θα συμβεί γιατί το επερώτημα που θα εκτελεστεί στην βάση θα έχει ως αποτέλεσμα μια λογική τιμή αληθής η ψευδής. Αυτό το είδος επίθεσης θεωρείται χρονοβόρο, καθώς για κάθε νέο bit πληροφορίας απαιτείται η κατασκευή ενός νέου SQL αιτήματος. Επιπλέον, στο πλαίσιο της επίθεσης, μπορεί να γίνουν πολλά ανεπιτυχή αιτήματα χωρίς αποτέλεσμα. Με τη χρήση μερικών νέων τεχνικών, ο επιτιθέμενος μπορεί με ένα αίτημα να ανακτά πολλαπλά bits, χωρίς ανεπιτυχή αιτήματα.^[11] Μάλιστα, υπάρχουν ορισμένα εργαλεία που μπορούν να αυτοματοποιήσουν τέτοιες εξελιγμένες επιθέσεις μόλις εντοπιστεί το σημείο ευπάθειας.^[12]

Απόκριση υπό όρους

Ένα είδος τυφλής έγχυσης SQL αναγκάζει την βάση δεδομένων να αξιολογήσει ένα λογικό αίτημα. Για παράδειγμα, ένας ιστότοπος αξιολόγησης βιβλίων χρησιμοποιεί μία συμβολοσειρά ερωτήματος (query string) για να αποφασίσει ποια αξιολόγηση βιβλίου θα προβληθεί. Έτσι, το URL https://books.example.com/review?id=5 θα οδηγούσε τον εξυπηρετητή στην εκτέλεση του ερωτήματος:

SELECT * FROM bookreviews WHERE ID = '5';

από το οποίο θα λάμβανε τα δεδομένα που προορίζονται για χρήση στην σελίδα που θα προβληθεί και η οποία αφορά την αξιολόγηση με ID ίσο με 5. Το ερώτημα εκτελείται στον εξυπηρετητή και ο χρήστης δεν γνωρίζει το όνομα της βάσης δεδομένων, των πινάκων ή των πεδίων, αλλά ούτε και την συμβολοσειρά ερωτήματος. Το μόνο που γνωρίζει είναι πως το παραπάνω URL οδηγεί στην εμφάνιση της αξιολόγησης ενός βιβλίου. Ένας επιτιθέμενος μπορεί να φορτώσει τα παρακάτω URL: https://books.example.com/review?id=5 OR 1=1 και https://books.example.com/review?id=5 AND 1=2, τα οποία οδηγούν στην κατασκευή των παρακάτω ερωτημάτων αντίστοιχα:

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

Εάν, (1) η αρχική αξιολόγηση προβληθεί με το πρώτο (“1=1”) URL και (2) μία κενή σελίδα ή σελίδα λάθους εμφανιστεί από το δεύτερο (“1=2”) και η επιστρεφόμενη σελίδα δεν έχει δημιουργηθεί ούτως ώστε να ενημερώνει τον χρήστη για μη έγκυρη είσοδο δεδομένων, τότε τα ερωτήματα έχουν εκτελεστεί με επιτυχία και ο ιστότοπος είναι ενδεχομένως ευάλωτος σε επιθέσεις έγχυσης SQL. Σε μια τέτοια περίπτωση, ο επιτιθέμενος μπορεί να προχωρήσει στην κατασκευή μίας συμβολοσειράς ερωτήματος που αποκαλύπτει την έκδοση της MySQL που χρησιμοποιείται στον εξυπηρετητή, όπως το παρακάτω: https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4. Σε μια τέτοια περίπτωση, ο ιστότοπος θα εμφάνιζε την αξιολόγηση του βιβλίου σε έναν εξυπηρετητή που έχει την MySQL 4 και μία κενή σελίδα ή σελίδα λάθους διαφορετικά. Ο επιτιθέμενος μπορεί να συνεχίσει να χρησιμοποιεί κώδικα μέσα στις συμβολοσειρές ερωτήματος, ούτως ώστε να επιτύχει τον σκοπό του ή να αποσπάσει περισσότερες πληροφορίες αναφορικά με τον εξυπηρετητή.^[13][14]

Έγχυση SQL δεύτερης τάξης

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

Αντίμετρα

Οι επιθέσεις έγχυσης SQL είναι ιδιαίτερα διαδεδομένες επιθέσεις που μπορούν να αποφευχθούν σχετικά εύκολα. Να σημειωθεί πως μετά από μία επίθεση τέτοιου τύπου το 2015 ενάντια της εταιρείας TalkTalk, το BBC ανέφερε πως οι ειδικοί ασφάλειας ήταν έκπληκτοι που μία εταιρεία τέτοιου βεληνεκούς ήταν ευάλωτη σε τέτοιες επιθέσεις.^[15]

Εντοπισμός

Το φιλτράρισμα ενέσεων SQL λειτουργεί με παρόμοιο τρόπο με εκείνο που χρησιμοποιείται για spam emails. Τα τείχη προστασίας των βάσεων δεδομένων εντοπίσουν ενέσεις SQL βάσει του αριθμού των μη έγκυρων ερωτημάτων που προέρχονται από έναν host. Να σημειωθεί πως τα φίλτρα λαμβάνουν υπόψη την ύπαρξη και τον αριθμό των OR ή UNION blocks μέσα στον κώδικα του ερωτήματος.^[16]

Παραμετροποιημένα αιτήματα

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

Η χρήση παραμετροποιημένων αιτημάτων απαιτεί από τον προγραμματιστή να καθορίσει όλον τον SQL κώδικα και κατόπιν, να περάσει κάθε παράμετρο στο SQL ερώτημα. Υπάρχει, έτσι, ξεκάθαρη διάκριση μεταξύ κώδικα και δεδομένων και δεν μπορεί κανείς να εισάγει «πραγματικές» SQL εντολές, προκειμένου να αλλάξει τον σκοπό του ερωτήματος αυτού. Έστω, για παράδειγμα, το παρακάτω ερώτημα:

query = “SELECT * FROM users WHERE username = ?”;

Ο χαρακτήρας “?” αντιπροσωπεύει μία παράμετρο της οποίας ο τύπος έχει καθοριστεί από τον προγραμματιστή. Εάν, κάποιος επιτιθέμενος δώσει (με κάποιον τρόπο) ως είσοδο την τιμή: jdoe’ or ‘1’=1’ , τότε το ερώτημα θα αναζητήσει κυριολεκτικά έναν χρήστη με username ίδιο με την είσοδο. Συνεπώς, τα παραμετροποιημένα αιτήματα δεν είναι ευάλωτα σε επιθέσεις έγχυσης SQL κώδικα.^[17]

Επιβολή σε επίπεδο κώδικα

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

Διαφυγή χαρακτήρων

Ένας ευθύς, αν και επιρρεπής σε λάθη, τρόπος αποτροπής ενέσεων είναι η διαφυγή χαρακτήρων που έχουν ιδιαίτερη σημασία στην SQL. Ο οδηγός κάθε Συστήματος Διαχείρισης Βάσης Δεδομένων επεξηγεί ποιοι είναι οι χαρακτήρες αυτοί. Για παράδειγμα, η εμφάνιση της αποστρόφου (single quote) σε μία παράμετρο πρέπει να αντικατασταθεί από δύο single quotes για την διαμόρφωση ενός έγκυρου SQL αιτήματος. Στην γλώσσα προγραμματισμού PHP, για παράδειγμα, χρησιμοποιείται συνήθως η συνάρτηση mysqli_real_escape_string() προτού σταλθεί το αίτημα στην βάση:

$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($username),
                  $mysqli->real_escape_string($password));
$mysqli->query($query);

Αυτή η συνάρτηση προσθέτει μία ανάποδη κάθετο (backslash) στην αρχή των ακόλουθων χαρακτήρων:  \x00, \n, \r, \, ', " και \x1a. Χρησιμοποιείται, κυρίως, για να καταστήσει τα δεδομένα ασφαλή προτού σταλθεί ένα αίτημα σε βάση δεδομένων MySQL.^[18] Η PHP έχει παρόμοιες συναρτήσεις και για λοιπά συστήματα βάσεων δεδομένων, όπως η pg_escape_string() που χρησιμοποιείται για PostgreSQL βάσεις δεδομένων. Η συνάρτηση addslashes(string $str) έχει ως σκοπό την διαφυγή χαρακτήρων και χρησιμοποιείται συνήθως για ερωτήματα σε βάσεις δεδομένων που δεν διαθέτουν την δική τους συνάρτηση διαφυγής στην γλώσσα PHP. Επιστρέφει μια συμβολοσειρά με ανάποδη κάθετο στην αρχή των χαρακτήρων που πρέπει να υποβληθούν σε διαδικασία διαφυγής προτού εκτελεστεί το ερώτημα. Αυτοί οι χαρακτήρες είναι η απόστροφος (‘), η διπλή απόστροφος (“), η κάθετος (\) και το NUL (NULL byte).^[19]

Έλεγχος μοτίβου

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

Άδειες βάσης δεδομένων

Ο περιορισμός των αδειών στην σύνδεση με την βάση δεδομένων που χρησιμοποιείται από την εφαρμογή στα απολύτως απαραίτητα δύναται να περιορίσει την αποτελεσματικότητα μίας πιθανής επίθεσης έγχυσης SQL. Για παράδειγμα, στο Σύστημα Διαχείρισης Βάσεων Δεδομένων Microsoft SQL Server, μία σύνδεση στην βάση δεδομένων θα μπορούσε να μην έχει την δυνατότητα επιλογής ορισμένων πινάκων, το οποίο θα περιόριζε προσπάθειες εισαγωγής JavaScript σε όλες τις στήλες κειμένου στην βάση δεδομένων.

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Παραδείγματα

• Τον Φεβρουάριο του 2002, ανακαλύφθηκε πως η Guess.com είναι ευάλωτη σε επίθεση έγχυσης SQL, δίνοντας την δυνατότητα απόκτησης πρόσβασης σε περισσότερα από 200 χιλιάδες ονόματα, χρεωστικές κάρτες και ημερομηνίες λήξης αυτών σε οποιονδήποτε ήταν ικανός να κατασκευάσει το απαραίτητο URL για την επίθεση στην βάση δεδομένων των πελατών του ιστότοπου.^[20]
• Την 1η Νοεμβρίου του 2005, ένας έφηβος χάκερ κατάφερε να εισβάλλει στον ιστότοπο ενός Ταϊβανέζικου περιοδικού ασφάλειας πληροφοριών, κάνοντας χρήση έγχυσης SQL. Ως αποτέλεσμα, απέσπασε δεδομένα των πελατών του εν λόγω περιοδικού.^[21]
• Τον Μάρτιο του 2006, ένας χάκερ ανακάλυψε μία ευπάθεια έγχυσης SQL σε έναν επίσημο τουριστικό ιστότοπο της Ινδικής κυβέρνησης.^[22]
• Στις 29 Ιουνίου του 2007, ένας χάκερ παραμόρφωσε τον ιστότοπο της Microsoft του Ηνωμένου Βασιλείου, χρησιμοποιώντας έγχυση SQL.^[23]
• Τον Ιούλιο του 2008, ο Μαλαισιανός ιστότοπος της εταιρείας Kaspersky έπεσε θύμα επίθεσης έγχυσης SQL.^[24]
• Το 2008, μία σειρά επιθέσεων ξεκίνησε να εκμεταλλεύεται ευπάθειες εφαρμογών που χρησιμοποιούσαν τον εξυπηρετητή ιστού IIS και τον εξυπηρετητή βάσης δεδομένων SQL Server της Microsoft. Πιο συγκεκριμένα, μία HTML συμβολοσειρά που δείχνει σε ένα κακόβουλο αρχείο JavaScript προστίθεται στο τέλος κάποιας ή κάποιων τιμών κειμένου στην βάση δεδομένων. Έπειτα, όταν η τιμή αυτή προβάλλεται από την βάση στον χρήστη, το script επιχειρεί να αποκτήσει τον έλεγχο στο σύστημα του χρήστη.^[25][26] Ο αριθμός των "μολυσμένων" ιστοσελίδων εκτιμάται σε 500 χιλιάδες.^[27]
• Στις 17 Αυγούστου του 2009, το Υπουργείο Δικαιοσύνης των Η.Π.Α κατηγόρησε έναν Αμερικανό πολίτη, καθώς και δύο Ρώσους για την κλοπή 130 εκατομμυρίων αριθμών πιστωτικών καρτών με την χρήση επίθεσης έγχυσης SQL. Η επίθεση στόχευε τα συστήματα πληρωμών εμπόρων λιανικής, ανάμεσα στις οποίες συγκαταλέγεται η αλυσίδα 7-Eleven και Hannaford Brothers.^[28]
• Τον Ιούλιο του 2010, ένας Αργεντίνος χάκερ ονόματι "Ch Russo" κατάφερε να αποκτήσει πρόσβαση στην βάση δεδομένων χρηστών του The Pirate Bay, κάνοντας χρήση επίθεσης έγχυσης SQL. Τα δεδομένα που εκτέθηκαν περιλάμβαναν usernames, MD5 αποτυπώματα κωδικών, διευθύνσεις IP, καθώς και αρχείο των torrents που οι χρήστες είχαν μεταφορτώσει.^[29]
• Τον Νοέμβριου του 2010, ο ιστότοπος του Βασιλικού Ναυτικού του Ηνωμένου Βασιλείου παραβιάστηκε από έναν Ρουμάνο χάκερ ονόματι TinKode με την χρήση έγχυσης SQL.^[30]
• Στις 27 Μαρτίου του 2011, ο ιστότοπος της MySQL παραβιάστηκε από έναν χάκερ με την χρήση έγχυσης SQL.
• Την 1η Ιουνίου του 2011, χάκερς της ομάδας LulzSec κατηγορήθηκαν για την χρήση έγχυσης SQL, προκειμένου να υποκλέψουν κουπόνια, download keys και κωδικούς ενός εκατομμυρίου χρηστών της εταιρείας Sony.^[31]
• Στις 4 Νοεμβρίου του 2013, η ομάδα hackers "RaptorSwag" σε συνεργασία με τους Anonymous παραβίασε 71 βάσεις δεδομένων της Κινεζικής Κυβέρνησης κάνοντας χρήση έγχυσης SQL.^[32]
• Στις 7 Μαρτίου του 2014, αξιωματούχοι του Πανεπιστημίου Johns Hopkins ανακοίνωσαν πως οι διακομιστές της Βιοϊατρικής Μηχανικής είχαν δεχθεί επίθεση έγχυσης SQL, με αποτέλεσμα να υποκλαπούν προσωπικά στοιχεία 878 μαθητών και προσωπικού.^[33]
• To 2014, ο ιστότοπος ξενοδοχειακών κρατήσεων Worldview έπεσε θύμα επίθεσης έγχυσης SQL, με αποτέλεσμα να υποκλαπούν τα στοιχεία των καρτών 3.814 πελατών. Μάλιστα, παρά το γεγονός ότι τα στοιχεία των καρτών ήταν κρυπτογραφημένα, το κλειδί αποκρυπτογράφησης αποθηκευόταν μαζί με τα δεδομένα.^[34]
• Το 2017, δεκάδες πανεπιστήμια τόσο του Ηνωμένου Βασιλείου όσο και των Ηνωμένων Πολιτειών, καθώς και κυβερνητικά ιδρύματα των Ηνωμένων Πολιτειών, αποτέλεσαν τον στόχο ενός χάκερ που χρησιμοποίησε έγχυση SQL, προκειμένου να αποκτήσει πρόσβαση στις βάσεις δεδομένων τους. Έπειτα, η πρόσβαση αυτή πουλήθηκε σε άλλα κακόβουλα άτομα.^[35]
• Τον Άυγουστο του 2020, μία επίθεση έγχυσης SQL χρησιμοποιήθηκε προκειμένου να υποκλαπούν δεδομένα μαθητών του Stanford που είχαν χρησιμοποιήσει τον ιστότοπο Link.^[36]

Παραπομπές

1. Archiveddocs (10 Απριλίου 2012). «SQL Injection». docs.microsoft.com (στα Αγγλικά). Ανακτήθηκε στις 26 Αυγούστου 2020. 
2. Kerner, Sean Michael (25 Νοεμβρίου 2013). «How Was SQL Injection Discovered?». www.esecurityplanet.com (στα Αγγλικά). Ανακτήθηκε στις 26 Αυγούστου 2020. 
3. «.:: Phrack Magazine ::». phrack.org. Ανακτήθηκε στις 26 Αυγούστου 2020. 
4. «OWASP Top 10 - 2013: The Ten Most Critical Web Application Security Risks» (PDF) (στα Αγγλικά). OWASP. Ανακτήθηκε στις 26 Αυγούστου 2020. 
5. «OWASP Top 10 - 2017: The Ten Most Critical Web Application Security Risks» (PDF) (στα Αγγλικά). OWASP. Ανακτήθηκε στις 26 Αυγούστου 2020. 
6. «OWASP Top Ten Web Application Security Risks». owasp.org (στα Αγγλικά). OWASP. Ανακτήθηκε στις 26 Αυγούστου 2020. 
7. «WHID 2007-60: The blog of a Cambridge University security team hacked | Xiom». Xiom. Αρχειοθετήθηκε από το πρωτότυπο στις 19 Ιουνίου 2011. Ανακτήθηκε στις 26 Αυγούστου 2020. 
8. Singh, Jai Puneet. (2016). Analysis of SQL Injection Detection Techniques. Theoretical and Applied Informatics. 28. 10.20904/281-2037.
9. «Dancho Danchev's Blog - Mind Streams of Information Security Knowledge: Social Engineering and Malware». Dancho Danchev's Blog - Mind Streams of Information Security Knowledge. Ανακτήθηκε στις 26 Αυγούστου 2020. 
10. «Overview of SQL Syntax», IBM Informix Guide to SQL: Syntax, IBM, σελ. 45, http://publibfp.dhe.ibm.com/epubs/pdf/c2736111.pdf, ανακτήθηκε στις 2020-08-26 
11. «Training for manipulating all kinds of things: Extracting Multiple Bits Per Request From Full-blind SQL Injection Vulnerabilities». Αρχειοθετήθηκε από το πρωτότυπο στις 8 Ιουλίου 2016. Ανακτήθηκε στις 26 Αυγούστου 2020. 
12. «Using SQLBrute to brute force data from a blind SQL injection point (justinclarke.com)». Αρχειοθετήθηκε από το πρωτότυπο στις 14 Ιουνίου 2008. Ανακτήθηκε στις 26 Αυγούστου 2020. 
13. macd3v. «Blind SQL Injection tutorial». Αρχειοθετήθηκε από το πρωτότυπο στις 14 Δεκεμβρίου 2012. Ανακτήθηκε στις 26 Αυγούστου 2020. 
14. Rassokhin, Andrey· Oleksyuk, Dmitry. «TDSS botnet: full disclosure». Αρχειοθετήθηκε από το πρωτότυπο στις 9 Δεκεμβρίου 2012. Ανακτήθηκε στις 26 Αυγούστου 2020. 
15. «Questions for TalkTalk - BBC News». BBC News (στα Αγγλικά). Αρχειοθετήθηκε από το πρωτότυπο στις Οκτωβρίου 26, 2015. Ανακτήθηκε στις Οκτωβρίου 26, 2015. 
16. «Methods of SQL Injections Detection». DataSunrise Data & Database Security (στα Αγγλικά). Ανακτήθηκε στις 26 Αυγούστου 2020. 
17. «SQL Injection Prevention - OWASP Cheat Sheet Series». cheatsheetseries.owasp.org. Ανακτήθηκε στις 26 Αυγούστου 2020. 
18. «PHP: mysqli::real_escape_string - Manual». www.php.net. Ανακτήθηκε στις 26 Αυγούστου 2020. 
19. «PHP: addslashes - Manual». www.php.net. Ανακτήθηκε στις 26 Αυγούστου 2020. 
20. «Guesswork Plagues Web Hole Reporting». SecurityFocus. Ανακτήθηκε στις 27 Αυγούστου 2020. 
21. «WHID 2005-46: Teen uses SQL injection to break to a security magazine web site» (στα Αγγλικά). Web Application Security Consortium. Αρχειοθετήθηκε από το πρωτότυπο στις 17 Ιανουαρίου 2010. Ανακτήθηκε στις 28 Αυγούστου 2020. 
22. «WHID 2006-27: SQL Injection in incredibleindia.org | xiom.com». Web Application Security Consortium. 29 Μαρτίου 2006. Αρχειοθετήθηκε από το πρωτότυπο στις 1 Ιουλίου 2009. Ανακτήθηκε στις 28 Αυγούστου 2020. 
23. Ward, Keith (29 Ιουνίου 2007). «Hacker Defaces Microsoft U.K. Web Page». rcpmag.com (στα Αγγλικά). Redmond Channel Partner Online. Αρχειοθετήθηκε από το πρωτότυπο στις 23 Δεκεμβρίου 2007. Ανακτήθηκε στις 28 Αυγούστου 2020. 
24. Danchev, Dancho. «Kaspersky's Malaysian site hacked by Turkish hacker». ZDNet (στα Αγγλικά). Ανακτήθηκε στις 28 Αυγούστου 2020. 
25. «SQL Injection Attacks on IIS Web Servers». blogs.iis.net (στα Αγγλικά). Ανακτήθηκε στις 13 Σεπτεμβρίου 2020. 
26. swiat (30 Μαΐου 2008). «SQL Injection Attack». Microsoft Security Response Center (στα Αγγλικά). Ανακτήθηκε στις 13 Σεπτεμβρίου 2020. 
27. «Huge Web Hack Attack Infects 500,000 Pages». PCWorld (στα Αγγλικά). 25 Απριλίου 2008. Αρχειοθετήθηκε από το πρωτότυπο στις 14 Αυγούστου 2020. Ανακτήθηκε στις 13 Σεπτεμβρίου 2020. 
28. «US man 'stole 130m card numbers'» (στα αγγλικά). 2009-08-18. http://news.bbc.co.uk/2/hi/americas/8206305.stm. Ανακτήθηκε στις 2020-09-13. 
29. Reviews, Electronic Notepad. «Pirate Bay Hack Exposes User Booty — Krebs on Security» (στα Αγγλικά). Ανακτήθηκε στις 13 Σεπτεμβρίου 2020. 
30. «Royal Navy website attacked by Romanian hacker» (στα αγγλικά). BBC News. 2010-11-08. https://www.bbc.com/news/technology-11711478. Ανακτήθηκε στις 2020-09-13. 
31. «Lulzsec hacker pleads guilty over Sony attack» (στα αγγλικά). BBC News. 2012-10-15. https://www.bbc.com/news/technology-19949624. Ανακτήθηκε στις 2020-09-13. 
32. Kovacs, Eduard. «Hackers Leak Data Allegedly Stolen from Chinese Chamber of Commerce Website». softpedia (στα Αγγλικά). Ανακτήθηκε στις 13 Σεπτεμβρίου 2020. 
33. Sun, Scott Dance, The Baltimore. «Hacker breaches Hopkins server, but officials say identity theft not a concern». baltimoresun.com (στα Αγγλικά). Αρχειοθετήθηκε από το πρωτότυπο στις 27 Σεπτεμβρίου 2020. Ανακτήθηκε στις 15 Σεπτεμβρίου 2020. 
34. Layden, John (5 Νοεμβρίου 2014). «Watchdog bites hotel booking site: Over 3k card details slurped». www.theregister.com (στα Αγγλικά). Ανακτήθηκε στις 15 Σεπτεμβρίου 2020. 
35. Zorz, Zeljka (16 Φεβρουαρίου 2017). «Hacker breached 60+ unis, govt agencies via SQL injection». Help Net Security (στα Αγγλικά). Ανακτήθηκε στις 15 Σεπτεμβρίου 2020. 
36. «Vulnerability in 'Link' website may have exposed data on Stanford students' crushes». The Stanford Daily. 14 Αυγούστου 2020. Ανακτήθηκε στις 15 Σεπτεμβρίου 2020.