26Aug
Même si vous n'avez suivi que vaguement les événements des groupes de hackers Anonymous et LulzSec, vous avez probablement entendu parler de sites web et de services piratés, comme les infâmes Sony hacks. Avez-vous déjà demandé comment ils le font?
Il y a un certain nombre d'outils et de techniques que ces groupes utilisent, et bien que 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 systématiquement à leur sujet sont «Déni de service( Distributed)»( DDoS) et «SQL Injections»( SQLI).Voici comment ils fonctionnent.
Image par xkcd
Attaque par déni de service
Qu'est-ce que c'est?
Un "déni de service"( parfois appelé "déni de service distribué" ou attaque DDoS) se produit lorsqu'un système, dans ce cas un serveur Web, reçoit tant de requêtes en même temps que les ressources du serveur sont surchargées que le système verrouille simplementet s'arrête. Le but et le résultat d'une attaque DDoS réussie sont les sites Web sur le serveur cible qui ne sont pas disponibles pour légitimer les demandes de trafic.
Comment ça marche?
La logistique d'une attaque DDoS peut être mieux expliquée par un exemple.
Imaginez qu'un million de personnes( les attaquants) se réunissent dans le but d'entraver l'activité de la société X en détruisant leur centre d'appels. Les attaquants se coordonnent pour que le mardi à 9 heures, ils appellent tous le numéro de téléphone de la compagnie X.Très probablement, le système téléphonique de la société X ne pourra pas traiter un million d'appels à la fois, de sorte que toutes les lignes entrantes seront bloquées par les attaquants. Le résultat est que les appels de clients légitimes( c'est-à-dire ceux qui ne sont pas les attaquants) ne passent pas parce que le système téléphonique est occupé à gérer les appels provenant des attaquants. Donc, en substance, la société X est potentiellement perdre des affaires en raison des demandes légitimes étant incapables de passer à travers.
Une attaque DDoS sur un serveur Web fonctionne exactement de la même manière. Comme il n'existe pratiquement aucun moyen de savoir quel trafic provient de demandes légitimes par rapport aux attaquants tant que le serveur Web ne traite pas la demande, ce type d'attaque est généralement très efficace.
Exécution de l'attaque
En raison de la nature "brute force" d'une attaque DDoS, vous devez avoir plusieurs ordinateurs coordonnés pour attaquer en même temps. Revisitant notre exemple de centre d'appels, cela nécessiterait que tous les attaquants sachent appeler à 9h00 et appellent réellement à ce moment-là.Bien que ce principe fonctionne certainement quand il s'agit d'attaquer un serveur web, il devient beaucoup plus facile d'utiliser des ordinateurs zombies, au lieu de véritables ordinateurs personnels.
Comme vous le savez probablement, il existe un grand nombre de variantes de logiciels malveillants et de chevaux de Troie qui, une fois sur votre système, restent inactifs et parfois "téléphonent" pour obtenir des instructions. 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 du matin. Ainsi, avec une seule mise à jour de l'emplacement d'origine du logiciel malveillant respectif, un seul attaquant peut instantanément coordonner des centaines de milliers d'ordinateurs compromis pour effectuer une attaque DDoS massive.
La beauté de l'utilisation des ordinateurs zombies est non seulement dans son efficacité, mais aussi dans son anonymat, car l'attaquant n'a pas vraiment besoin d'utiliser son ordinateur pour exécuter l'attaque.
SQL Injection Attack
Qu'est-ce que c'est?
Une attaque "SQL injection"( SQLI) est un exploit qui tire parti des techniques de développement Web médiocres et, généralement, associé à une sécurité de base de données défaillante. Le résultat d'une attaque réussie peut aller de l'emprunt d'identité d'un compte utilisateur à une compromission complète de la base de données ou du serveur respectif. Contrairement à une attaque DDoS, une attaque SQLI est complètement et facilement évitable si une application Web est correctement programmée.
Exécution de l'attaque
Lorsque vous vous connectez à un site Web et entrez votre nom d'utilisateur et votre mot de passe, l'application Web peut exécuter une requête comme suit:
SELECT UserID FROM Users WHERE UserName = 'monutilisateur' AND Mot de passe= 'mypass';
Remarque: les valeurs de chaîne dans une requête SQL doivent être placées entre guillemets simples, c'est pourquoi 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 dans la table Users pour qu'un utilisateur puisse être renvoyé.S'il n'y a pas de correspondance, aucun ID utilisateur n'est renvoyé, les informations de connexion ne sont donc pas valides. Bien qu'une implémentation particulière puisse différer, la mécanique est assez standard.
Examinons maintenant une requête d'authentification par template que nous pouvons remplacer par les valeurs entrées par l'utilisateur sur le formulaire web:
SELECT UserID FROM Utilisateurs WHERE UserName = '[utilisateur]' AND Mot de passe = '[pass]'
Au premier coup d'oeilCela peut sembler une étape simple et logique pour valider facilement les utilisateurs, mais 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.
Par exemple, supposons que "myuser'-" soit entré dans le champ du nom d'utilisateur et que "wrongpass" 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 Utilisateurs WHERE UserName = 'myuser' - 'ET Password =' erreur '
Une clé de cette instruction est l'inclusion des deux tirets( -).Ceci est le jeton de commentaire de début pour les instructions SQL, donc tout ce qui apparaît après les deux tirets( inclus) sera ignoré.Essentiellement, la requête ci-dessus est exécutée par la base de données comme:
SELECT UserID FROM Utilisateurs 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 avons pu nous connecter en tant que "myuser" sans connaître le mot de passe correspondant. Cet acte de manipulation de la requête pour produire des résultats inattendus est une attaque par injection SQL.
Quel dommage peut-on faire?
Une attaque par injection SQL est provoquée par un codage d'application négligent et irresponsable et est complètement évitable( ce que nous verrons dans un instant), cependant l'ampleur des dommages qui peuvent ê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, l'application doit fournir une connexion à la base de données( notez que ceci est différent d'un utilisateur se connectant 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 n'importe quoi des autorisations de lecture / écriture dans les tables existantes uniquement pour accéder à la base de données complète. Si ce n'est pas clair maintenant, quelques exemples devraient aider à fournir une certaine clarté.
Basé sur l'exemple ci-dessus, vous pouvez voir qu'en entrant, par exemple, "youruser '-", "admin' -" ou tout autre nom d'utilisateur, nous pouvons nous connecter instantanément au site sans connaître le mot de passe. Une fois que nous sommes dans le système ne sait pas que nous ne sommes pas réellement cet utilisateur, nous avons un accès complet au compte respectif. Les autorisations de base de données n'offriront pas de filet de sécurité pour cela, car un site Web doit généralement avoir au moins un accès en lecture / écriture à sa base de données respective.
Supposons maintenant que le site Web ait le contrôle total de sa base de données, ce qui permet de supprimer des enregistrements, ajouter / supprimer des tables, ajouter de nouveaux comptes de sécurité, etc. Il est important de noter que certaines applications web peuvent avoir besoin de ce type d'autorisation.ce n'est pas automatiquement une mauvaise chose qu'un contrôle total soit accordé.
Donc, pour illustrer les dommages qui peuvent être causés dans cette situation, nous allons utiliser l'exemple fourni dans la bande dessinée ci-dessus en entrant le texte suivant 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 Utilisateurs WHERE UserName = 'Robert';DROP TABLE Utilisateurs; - 'AND Password =' erreur '
Remarque: le point-virgule est dans une requête SQL qui 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 comme:
SELECT UserID FROM Utilisateurs WHERE UserName = 'Robert'
DROP TABLE Utilisateurs
Donc juste comme ça, nous avons utilisé une attaque SQLI pour supprimer toute la table Users.
Bien sûr, bien pire, les attaquants peuvent modifier les valeurs, vider les tables( ou toute la base de données elle-même) dans un fichier texte, créer de nouveaux comptes de connexion ou même détourner toute l'installation de la base de données.
Prévention d'une attaque par injection SQL
Comme nous l'avons mentionné plusieurs fois précédemment, une attaque par injection SQL est facilement évitable. L'une des règles cardinales du développement web est de ne jamais faire aveuglément confiance à l'entrée de l'utilisateur comme nous l'avons fait 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 qu'on appelle la désinfection( ou l'échappement) de vos entrées. Le processus de nettoyage est en fait assez trivial car tout ce qu'il fait est de gérer de façon appropriée tous les guillemets simples en ligne( ') de sorte qu'ils ne peuvent pas être utilisés pour terminer prématurément une chaîne à l'intérieur d'une instruction SQL.
Par exemple, si vous vouliez rechercher "O'neil" dans une base de données, vous ne pouviez pas utiliser la substitution simple car la simple citation après l'O entraînerait la fin prématurée de la chaîne. Au lieu de cela, 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 pour un guillemet simple en ligne est en train de préfixer chaque guillemet avec un symbole \.Donc "O'neal" serait aseptisé comme "O \ 'neil".
Ce simple acte d'assainissement évite à peu près une attaque SQLI.Pour illustrer, revenons sur nos exemples précédents et voyons les requêtes résultantes lorsque l'entrée de l'utilisateur est nettoyée.
myuser '- / incorrect pass :
SELECT ID utilisateur FROM Users WHERE NomUtilisateur =' myuser '-' ET MotDePasse = 'erreurpass'
Parce que la citation unique après myuser est échappée( ce qui signifie qu'elle est considérée comme faisant partie de la cible)value), la base de données cherchera littéralement le nom d'utilisateur de "myuser '-".De plus, comme les tirets sont inclus dans la valeur de la 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 Utilisateurs; - / incorrect :
SELECT UserID FROM Utilisateurs WHERE UserName = 'Robert \';DROP TABLE Utilisateurs - '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, donc la base de données cherchera littéralement "Robert";- "au lieu d'exécuter la table delete.
En résumé
Alors 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 contre les attaques éprouvées qui ont été l'inspiration de plusieurs "outils hackers" disponibles pour les exploiter.
Certains types d'attaques, comme les attaques DDoS, ne peuvent pas être facilement évités, alors que d'autres, comme SQLI, le peuvent. Cependant, les dommages qui peuvent être causés par ces types d'attaques peuvent aller d'un inconvénient à catastrophique en fonction des précautions prises.
