Le Site a été piraté par Injection SQL
Récemment, mon site a été piraté par injection SQL. Le hacker a utilisé la requête suivante
pour obtenir mon nom DB. Je ne comprends pas cette requête, ils ont écrit.
Requête:
=-999.9%20UNION%20ALL%20SELECT%20concat(0x7e,0x27,Hex(cast(database()%20as%20char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--
Après que la requête a été couru il a montré un résultat sous forme d'entier, quelque chose comme "74545883
".
Pouvez-vous expliquer comment la requête fonctionne?
- merci de ne pas signer vos requêtes, nous savons qui vous êtes
- est-ce la seule entrée que vous avez dans votre journal?
- merci de ne pas signer vos requêtes - un instant, je me demandais ce n'est la signature d'une requête mysql veux dire 🙂
- requête en question ha... mauvais montage qui, depuis sa ambigu
Vous devez vous connecter pour publier un commentaire.
Il ressemble à un attaque par dépassement de la. Ils
UNION
-ed avec votre requête existante. le remplacement de tous vos%20
avec (espace) depuis son url-encodé rendements:décomposer:
=-999.9
est juste pour la résiliation de votre requête0x31303235343830303536
estNULL
- ils sont juste correspondant au nombre de colonnes dans votre requête existante. Si vous aviezSELECT * FROM users
etusers
a 4 colonnes, laUNION
doit également avoir 4 colonnes. En conséquence, ils ont juste utilisé des valeurs NULL pour remplir ces colonnes.CONCAT()
. Ils sont combinant 126, 39, nom de base de données comme valeur hexadécimale, 39, 126 et--
est une base de données mysql commentaire - il ignore le reste de votre requête aprèsÀ en juger par cette attaque, je soupçonne que vous n'êtes pas d'emballage d'entrée dans
mysql_real_escape_string()
, ce qui a permis à attaqué à sauter hors de votre requête et d'exécuter leurs propres.Voir owasp.org pour plus d'informations.
Ce n'est pas la requête complète, en fait d'entrée de la personne dans cette chaîne de votre application web.
Maintenant, tout d'abord remplacer %20 avec un espace vide dans l'union de la partie, vous obtenez:
Semble que l'utilisateur de mettre la chaîne dans un endroit où vous vous attendiez à un nombre. Donc, vous voyez qu'il y a d'abord un certain nombre (999.9) pour valider l'état d'origine de la requête. Ensuite, une partie de l'UNION est ajouté.
Enfin, après l'UNION de la partie, le commentaire de l'ajout de caractères ( -- ), de sorte que, le reste de la requête (qui peuvent être ajoutés par votre système) est court-circuité.
Nous permet de formater le code pour mieux comprendre:
Maintenant, sous-chaîne de la première colonne du résultat contiendra l'hexagone forme codée de votre datbase nom. En fait, il doit être entouré de guillemets simples (0x27), puis de nouveau entouré par ~ (0x7e)
La requête a retourné le nom de Base de données à l'aide de (BASE de données) , il est ensuite converti en une valeur hexadécimale à l'aide de HEx() fonction.
Une fois qu'ils avaient ce qu'ils pourraient utiliser UNHEX fonction
Ont un look à la
UNHEX
exemplesIl est bon de savoir comment ils sont arrivés, mais dans l'ensemble, vous avez besoin de réparer votre code afin d'éviter l'Injection SQL.
Je pense que vous devez avoir d'autres entrées dans votre journal, si ce n'est qu'il savait avant la main que vous avez 3 colonnes.
C'est un exemple de l'injection à l'aide de Havij
Le 0x7e et 0x27 correspondent à ~ et ' qui sera utilisé pour cadre l'affichage HTML
comme
id=999999.9+union+all+select+0x31303235343830303536,(select+concat(0x7e,0x27,unhex(Hex(cast(sample_tbl.name+as+char))),0x27,0x7e)+from+
test
.sample_tbl+Order+by+id+limit+0,1)+--Cette requête sera rendu ~'Alfred'~ qui est la valeur du champ de la colonne nom de la table sample_tbl dans le test de la table
~'r3dm0v3_hvj_injection'~ est la Havij signature de code unhex 0x7233646D3076335F68766A5F696E6A656374696f6e selon http://www.string-functions.com/hex-string.aspx
Tout d'abord, la requête ressemble à du HTML codé. Remplacer le
%20
s avec des espaces et il va devenir un peu plus lisible. Ils sont aussi de convertir une partie de la requête dans un hex représentation de quelque chose. Essayez hexadécimal décodage de la partie de la déclaration ainsi.Un risque d'injection SQL est créée lorsque vous essayez de créer un SQL de façon dynamique comme une chaîne, et puis de l'envoyer vers le SGBD. Imaginez une chaîne comme celle-ci stockés dans votre système pour une utilisation dans une barre de recherche, etc:
SELECT * FROM SOME_TABLE WHERE SOME_COLUMN=
Pour exécuter la requête et de laisser l'attaque, ils auraient besoin pour faire leur entrée comme ceci:
'x' or 1=1
Dans ce cas, la requête devient:
SELECT * FROM SOME_TABLE WHERE SOME_COLUMN='x' or 1=1
SOME_COLUMN
pourrait être n'importe quelle variable, il n'a pas d'importance où il échoue, la chose qui importe, c'est que1=1
est TOUJOURS vrai, ce qui pourrait donner à l'attaquant d'accéder à chaque ligne de cette table.Maintenant que vous savez à ce sujet, allez par le biais de votre code et de le remplacer tous les créé dynamiquement une requête avec un Préparées. L'OWASP site a beaucoup de ressources pour se défendre de codage ainsi:
http://www.owasp.org
Oui, il a eu l'hex forme de votre nom de base de données dont vous dites qu'il est "74545883'.
Par Unhexing il il en aurait eu le vrai nom de base de données.