Même si vous n'avez suivi que vaguement les événements des groupes de pirates Anonymous et LulzSec, vous avez probablement entendu parler des sites Web et les services étant piratés, comme les infâmes Sony Hack. Avez-vous déjà demandé comment ils le font?

Ces groupes utilisent un certain nombre d'outils et de techniques, 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 DDoS) Une attaque se produit lorsqu'un système, en l'occurrence un serveur Web, reçoit tant de demandes en même temps que les ressources du serveur sont surchargées que le système se bloque simplement et s'arrête. Le but et le résultat d'une attaque DDoS réussie est que les sites web sur le serveur cible 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 assaillants) se réunissent dans le but d'entraver les activités 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 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 gros, la société X risque de perdre des affaires en raison des demandes légitimes qui ne peuvent être traitées.

Une attaque DDoS sur un serveur Web fonctionne exactement de la même manière. Comme il n'y a 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 requête, ce type d'attaque est généralement très efficace.

Exécuter l'attaque

force "nature d'une attaque DDoS, vous devez avoir beaucoup d'ordinateurs tous 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 d'ordinateurs réels.

Comme vous le savez probablement, il existe de nombreuses variantes de logiciels malveillants et trojans , une fois sur votre système, rester inactif et parfois «téléphoner à la maison» 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 concerné, 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 aussi dans son anonymat car l'attaquant n'a pas 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 exploiter qui tire parti des techniques de développement Web pauvres et, généralement combiné avec, la sécurité de la base de données défectueuse. 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écuter l'attaque

Chaque fois que vous vous connectez à un site Web et entrez votre nom d'utilisateur et mot de passe, afin de tester votre informations d'identification l'application Web peut exécuter une requête comme suit:

SELECT UserID FROM utilisateurs WHERE UserName = "myuser" ET Password = "mypass";

Remarque: les valeurs de chaîne dans une requête SQL doivent être placées entre guillemets, c'est pourquoi elles apparaissent autour des valeurs saisies par l'utilisateur.

La combinaison du nom d'utilisateur entré (myuser) et du mot de passe (mypass) doit correspondre à Table des utilisateurs pour qu'un identifiant d'utilisateur soit 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, les mécanismes sont assez standard.

Voyons maintenant une requête d'authentification de modèle que nous pouvons substituer aux valeurs que l'utilisateur entre dans 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 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

Par exemple, supposons que "mon utilisateur" soit entré dans le champ "nom d'utilisateur" et que "mot de passe erroné" soit entré dans le mot de passe. En utilisant une substitution simple dans notre requête de modèle, nous obtiendrions ceci:

SELECT UserID FROM Utilisateurs WHERE UserName = "monutilisateur" - 'AND Password = "wrongpass"

Une clé de cette déclaration 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 causée par un codage d'application négligent et irresponsable et est complètement évitable. un moment), mais l'étendue 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 qui se connecte 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é.

Sur la base de l'exemple ci-dessus, vous pouvez voir qu'en entrant, par exemple,

"votre utilisateur" - "," 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 ne sait pas que nous ne sommes pas réellement cet utilisateur, nous avons un accès complet au compte respectif. Les permissions de base de données ne fourniront pas de filet de sécurité pour cela, car un site web doit avoir au moins un accès en lecture / écriture à sa base de données respective.Supposons maintenant que le site ait le contrôle total de sa base de données. pour 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, donc ce n'est pas automatiquement une mauvaise chose qu'un contrôle total soit accordé.

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 Utilisateurs; - ".Après substitution simple, la requête d'authentification devient:SELECT UserID FROM Utilisateurs WHERE UserName = "Robert"; DROP TABLE Utilisateurs; - 'AND Password = "wrongpass"

Note: le point-virgule est dans une requête SQL qui sert à 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 Users

Donc juste comme ça, nous avons utilisé une attaque SQLI pour supprimer toute la table Users.

En fonction des permissions SQL autorisées, l'attaquant peut changer des valeurs, vider des tables (ou toute la base de données) 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 aveuglément faire confiance aux entrées des utilisateurs comme nous l'avons fait lors de notre requête de template 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 dans une instruction SQL.

Par exemple, lookup "O'neil" dans une base de données, vous ne pouviez pas utiliser la substitution simple parce que la citation unique après l'O causerait 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 empêche à 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 '-

/

wrongpass : SELECT UserID FROM Utilisateurs WHERE UserName = " myuser "- 'ET Password =" wrongpass " Comme la citation unique après myuser est échappée (ce qui signifie qu'elle fait partie de la valeur cible), la base de données recherche littéralement le UserName 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 Users; -/wrongpass

: 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 recherche littéralement "Robert" ; DROP TABLE Utilisateurs; - "

au lieu d'exécuter la suppression du tableau

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 rappeler de protéger contre les attaques éprouvées qui ont inspiré plusieurs «outils hackers» librement 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 pouvant être causés par ces types d'attaques peuvent aller d'un désagrément à une catastrophe, selon les précautions prises.

Qu'est-ce que le lanceur de jeu de Samsung, et devriez-vous l'utiliser?

Ça a été une longue journée et vous avez du temps à tuer, alors prenez votre Samsung Galaxy S7 et allumez votre jeu préféré. Vous êtes tous prêts à écraser le niveau sur lequel vous avez été collé pendant les sept dernières semaines - c'est si proche que vous pouvez le goûter. Ensuite, votre bff décide d'envoyer un texte qui interrompt votre jeu, ce qui vous met hors de votre portée.

(how-to)

Quelle est la différence entre Sudo et Su sous Linux?

Si vous êtes un utilisateur Linux, vous avez probablement déjà vu des références à sudo et à su. Les articles ici sur How-To Geek et ailleurs instruisent les utilisateurs d'Ubuntu à utiliser sudo et d'autres utilisateurs de distributions Linux pour utiliser su, mais quelle est la différence? Sudo et su sont deux façons différentes d'obtenir des privilèges root.

(how-to)