Ces groupes utilisent un certain nombre d’outils et de techniques et, même si nous n’essayons pas de vous donner un manuel pour le faire vous-même, il est utile de comprendre ce qui se passe. Deux des attaques que vous entendez régulièrement les utiliser sont “Déni de service (DDoS)” et “Injections SQL” (SQLI). Voici comment ils fonctionnent.
Image par xkcd
Attaque par déni de service
Qu'Est-ce que c'est?
Une attaque de «déni de service» (parfois appelée «déni de service distribué» ou DDoS) se produit lorsqu'un système, dans ce cas un serveur Web, reçoit tellement de demandes en même temps que les ressources du serveur sont surchargées que le système se verrouille simplement. et ferme. L’objectif et le résultat d’une attaque DDoS réussie sont les sites Web du serveur cible ne sont pas disponibles pour les demandes de trafic légitimes.
Comment ça marche?
La logistique d'une attaque DDoS peut être mieux expliquée par un exemple.
Imaginez un million de personnes (les assaillants) qui s’unissent pour entraver les activités de la société X en supprimant leur centre d’appel. Les assaillants se coordonnent pour appeler mardi à 9 heures le numéro de téléphone de la société X. Très probablement, le système téléphonique de la société X ne sera pas en mesure de traiter un million d’appels en même temps; toutes les lignes entrantes seront alors bloquées par les attaquants. Il en résulte que les appels de clients légitimes (c’est-à-dire ceux qui ne sont pas les attaquants) ne sont pas acheminés car le système téléphonique est bloqué et traite les appels des attaquants. En résumé, la société X risque de perdre des clients en raison de l'impossibilité de répondre aux demandes légitimes.
Une attaque DDoS sur un serveur Web fonctionne exactement de la même manière. Étant donné qu'il n'existe pratiquement aucun moyen de savoir quel trafic provient de requêtes légitimes ou non d'attaques tant que le serveur Web n'a pas traité la requête, ce type d'attaque est généralement très efficace.
L'exécution de l'attaque
En raison de la nature «brutale» d'une attaque DDoS, de nombreux ordinateurs doivent être tous coordonnés pour attaquer en même temps. Pour revenir à notre exemple de centre d’appel, il faudrait que tous les attaquants sachent qu’ils doivent appeler à 9 heures et qu’ils appellent à ce moment-là. Ce principe fonctionnera certainement lorsqu'il s'agira d'attaquer un serveur Web, mais il deviendra beaucoup plus facile lorsque des ordinateurs zombies seront utilisés, au lieu des ordinateurs réels.
Comme vous le savez probablement, il existe de nombreuses variantes de programmes malveillants et de chevaux de Troie qui, une fois sur votre système, sont en sommeil et occasionnellement, téléphonez chez vous pour obtenir des instructions. L’une de ces instructions pourrait, par exemple, être d’envoyer des demandes répétées au serveur Web de la société X à 9 heures. Ainsi, avec une seule mise à jour du site d'origine du logiciel malveillant respectif, un seul attaquant peut instantanément coordonner des centaines de milliers d'ordinateurs infectés afin de mener une attaque DDoS massive.
L’intérêt d’utiliser des ordinateurs zombies réside non seulement dans son efficacité, mais également dans son anonymat, car l’attaquant n’a pas du tout besoin d’utiliser son ordinateur pour exécuter l’attaque.
Attaque par injection SQL
Qu'Est-ce que c'est?
Une attaque par «injection SQL» (SQLI) est un exploit qui tire parti de techniques de développement Web médiocres et, généralement associée à une sécurité de base de données défectueuse. Le résultat d'une attaque réussie peut aller de l'emprunt d'identité d'un compte d'utilisateur à un compromis complet de la base de données ou du serveur respectif. Contrairement à une attaque DDoS, une attaque SQLI peut être complètement et facilement évitée si une application Web est correctement programmée.
L'exécution de l'attaque
Chaque fois que vous vous connectez à un site Web et entrez votre nom d'utilisateur et votre mot de passe, afin de tester vos informations d'identification, l'application Web peut exécuter une requête comme celle-ci:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Remarque: les valeurs de chaîne dans une requête SQL doivent être placées entre guillemets, raison pour laquelle elles apparaissent autour des valeurs entrées par l'utilisateur.
Ainsi, la combinaison du nom d'utilisateur entré (myuser) et du mot de passe (mypass) doit correspondre à une entrée du tableau Utilisateurs pour qu'un identifiant utilisateur puisse être renvoyé. S'il n'y a pas de correspondance, aucun ID utilisateur n'est renvoyé, de sorte que les informations d'identification de connexion ne sont pas valides. Bien qu'une implémentation particulière puisse différer, les mécanismes sont assez standards.
Voyons maintenant une requête d’authentification de modèle à laquelle nous pouvons substituer les valeurs saisies par l’utilisateur sur le formulaire Web:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
À première vue, cela peut sembler une étape simple et logique pour une validation facile des utilisateurs. Toutefois, si une simple substitution des valeurs entrées par l'utilisateur est effectuée sur ce modèle, il est susceptible d'une attaque SQLI.
Supposons, par exemple, que "myuser’–" soit entré dans le champ du nom d'utilisateur et que "badpass" soit entré dans le mot de passe. En utilisant une simple substitution dans notre requête de modèle, nous obtiendrions ceci:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Une des clés de cette déclaration est l'inclusion des deux tirets
(--)
. Il s'agit du jeton de commentaire de début pour les instructions SQL. Par conséquent, tout élément apparaissant après les deux tirets (inclus) sera ignoré. Essentiellement, la requête ci-dessus est exécutée par la base de données en tant que:
SELECT UserID FROM Users WHERE UserName='myuser'
L'omission flagrante ici est l'absence de vérification du mot de passe.En incluant les deux tirets dans le champ utilisateur, nous avons complètement contourné la condition de vérification du mot de passe et nous avons pu nous connecter en tant que «myuser» sans connaître le mot de passe correspondant. Cette action de manipuler la requête pour produire des résultats inattendus est une attaque par injection SQL.
Quel dommage peut être fait?
Une attaque par injection SQL est causée par un codage d'application négligent et irresponsable et est totalement évitable (ce que nous verrons dans quelques instants). Toutefois, l'étendue des dommages pouvant être causés dépend de la configuration de la base de données. Pour qu'une application Web puisse communiquer avec la base de données principale, celle-ci doit fournir un identifiant de connexion à la base de données (il est à noter que cette connexion est différente de celle d'un utilisateur connecté au site Web lui-même). En fonction des autorisations requises par l'application Web, ce compte de base de données respectif peut nécessiter une autorisation d'accès en lecture / écriture dans les tables existantes uniquement à un accès complet à la base de données. Si ce n’est pas clair maintenant, quelques exemples devraient aider à clarifier les choses.
Sur la base de l'exemple ci-dessus, vous pouvez constater que vous entrez, par exemple,
'youruser'--', 'admin'--'
ou tout autre nom d'utilisateur, nous pouvons nous connecter instantanément au site en tant qu'utilisateur sans connaître le mot de passe. Une fois que nous sommes dans le système, nous ne savons pas que nous ne sommes pas cet utilisateur. Nous avons donc un accès complet au compte correspondant. Les autorisations de base de données ne constituent pas un filet de sécurité à cet égard car, en règle générale, un site Web doit avoir au moins un accès en lecture / écriture à sa base de données respective.
Supposons maintenant que le site Web contrôle totalement sa base de données, ce qui permet de supprimer des enregistrements, d’ajouter / supprimer des tables, d’ajouter de nouveaux comptes de sécurité, etc. Il est important de noter que certaines applications Web peuvent nécessiter ce type d’autorisation. n’est pas automatiquement mauvais d’accorder un contrôle total.
Donc, pour illustrer les dégâts pouvant être causés dans cette situation, nous allons utiliser l'exemple fourni dans la BD ci-dessus en entrant ce qui suit dans le champ du nom d'utilisateur:
'Robert'; DROP TABLE Users;--'.
Après une simple substitution, la requête d'authentification devient:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Remarque: le point-virgule dans une requête SQL est utilisé pour indiquer la fin d'une instruction particulière et le début d'une nouvelle instruction.
Qui est exécuté par la base de données en tant que:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Utilisateurs
Nous avons donc utilisé une attaque SQLI pour supprimer la totalité de la table Users.
Bien entendu, il est bien pire que, selon les autorisations SQL autorisées, l'attaquant puisse modifier des valeurs, vider des tables (ou même la base de données entière) en un fichier texte, créer de nouveaux comptes de connexion ou même pirater l'installation complète de la base de données.
Prévenir une attaque par injection SQL
Comme nous l'avons mentionné à plusieurs reprises, une attaque par injection SQL est facilement évitable. L'une des règles fondamentales du développement Web est que vous ne faites jamais confiance aveuglément aux entrées des utilisateurs, comme nous le faisions lorsque nous avons effectué une substitution simple dans notre requête de modèle ci-dessus.
Une attaque SQLI est facilement contrecarrée par ce que l'on appelle la désinfection (ou l'échappement) de vos entrées. Le processus de désinfection est en fait assez trivial, car il ne traite que les caractères entre guillemets simples (‘) insérés de manière appropriée, de sorte qu’ils ne peuvent pas être utilisés pour terminer prématurément une chaîne dans une instruction SQL.
Par exemple, si vous souhaitez rechercher «O’neil» dans une base de données, vous ne pouvez pas utiliser une simple substitution, car le guillemet simple après le 0 entraînerait la fin prématurée de la chaîne. À la place, vous le désinfectez en utilisant le caractère d'échappement de la base de données respective. Supposons que le caractère d'échappement d'un guillemet simple en ligne soit précédé de chaque guillemet par un symbole. Donc, "O’neal" serait assaini comme "O ’ Neil ".
Ce simple geste d’assainissement empêche quasiment une attaque SQLI. Pour illustrer notre propos, revoyons nos exemples précédents et voyons les requêtes résultantes lorsque la saisie de l’utilisateur est nettoyée.
myuser'--
/ mauvaise passe:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Étant donné que le guillemet simple après que myuser est échappé (c’est-à-dire qu’il fait partie de la valeur cible), la base de données recherchera littéralement le nom d’utilisateur de
'myuser'--'.
De plus, étant donné que les tirets sont inclus dans la valeur de chaîne et non dans l'instruction SQL elle-même, ils seront considérés comme faisant partie de la valeur cible au lieu d'être interprétés comme un commentaire SQL.
Robert'; DROP TABLE Users;--
/ mauvaise passe:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
En échappant simplement à la citation simple après Robert, le point-virgule et les tirets sont contenus dans la chaîne de recherche UserName afin que la base de données recherche littéralement
'Robert'; DROP TABLE Users;--'
au lieu d'exécuter la suppression de la table.
En résumé
Tandis que les attaques Web évoluent et deviennent plus sophistiquées ou se concentrent sur un point d’entrée différent, il est important de se protéger des attaques éprouvées qui ont été l’inspiration de plusieurs «outils de piratage» librement disponibles conçus pour les exploiter.
Certains types d'attaques, tels que les attaques DDoS, ne peuvent pas être facilement évités, tandis que d'autres, tels que SQLI, le peuvent. Toutefois, les dommages pouvant être causés par ces types d’attaques peuvent aller d’un inconvénient à catastrophique en fonction des précautions prises.
