Le Site a été piraté par Injection SQL

C'est un attaque par dépassement. Ils UNION-ed avec votre requête existante. le remplacement de tous vos %20 (espace) depuis son url-encodé rendements:

=-999.9 UNION ALL SELECT CONCAT(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536-

décomposer:

1. =-999.9 termine juste votre requête actuelle
2. 0x31303235343830303536NULL - ils sont juste correspondant au nombre de colonnes dans votre requête existante. Si vous aviez SELECT * FROM users et users avait 4 colonnes, le UNION doit également avoir 4 colonnes. En conséquence, ils ont juste utilisé ' valeurs nulles pour peupler ces colonnes.
3. la véritable confusion est dans le CONCAT(). Ils combinent 126, 39, nom de la base de données comme valeur hexadécimale, 39, et 126
4. -- est un commentaire mysql - il ignore le reste de votre requête après

à en juger par cette attaque, je soupçonne que vous n'emballez pas vos données dans mysql_real_escape_string(), qui permet d'attaquer pour sauter hors de votre requête et exécuter leur propre.

owasp.org pour plus d'informations.

ce n'est pas la requête complète, en fait la personne a entré cette chaîne dans votre application web.

d'abord, remplacez %20 par un espace vide dans la partie union, vous obtenez:

SELECT concat(0x7e,0x27,Hex(cast(database() as char)),0x27,0x7e),0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

Semble que l'utilisateur de mettre la chaîne dans un endroit où vous vous attendiez à un nombre. Donc, vous voyez qu'en premier il y a un nombre (999.9) pour compléter la condition originale de la requête. Puis, une partie syndicale est ajoutée. Enfin, après la partie UNION, les caractères de commentaire sont ajoutés ( -- ) ainsi cela, le reste de la requête (qui pourrait être ajouté par votre système) est contourné.

nous pouvons formater le code pour une meilleure compréhension:

SELECT 
    concat
    (
        0x7e,
        0x27,
        Hex(cast(database() as char)),
        0x27,
        0x7e
    ),
    0x31303235343830303536,
    0x31303235343830303536,
    0x31303235343830303536

Maintenant, la 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 retourne le nom de la base de données en utilisant DATABASE (), il l'a ensuite converti en valeur hexadécimale en utilisant HEx () fonction.

une fois qu'ils ont eu ceci ils pouvaient utiliser UNHEX function

regardez UNHEX exemples

mysql> SELECT UNHEX('4D7953514C');
        -> 'MySQL'
mysql> SELECT 0x4D7953514C;
        -> 'MySQL'
mysql> SELECT UNHEX(HEX('string'));
        -> 'string'
mysql> SELECT HEX(UNHEX('1267'));
        -> '1267'

il est bon de savoir comment ils sont entrés, mais dans l'ensemble, vous devez réparer votre code pour éviter L'Injection SQL.

-999.9 UNION ALL SELECT 
CONCAT('Hex(cast(database() as char))'),
0x31303235343830303536,
0x31303235343830303536,
0x31303235343830303536

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.

ceci est un exemple d'injection avec Havij Les 0x7E et 0x27 correspondent à ~ et ' qui seront utilisés pour encadrer L'affichage HTML notamment 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 va rendre ~'Alfred' ~ qui est la valeur de champ du nom de colonne, à partir de la table sample_tbl dans le test de table

~'r3dm0v3_hvj_injection'~ est le code de signature Havij unhex 0x7233646D3076335F68766A5F696E6A656374696f6e selon http://www.string-functions.com/hex-string.aspx

tout d'abord, la requête semble codée HTML. Remplacer le %20 s avec des espaces et il deviendra un peu plus lisible. Ils convertissent aussi une partie de la requête en représentation hexadécimale de quelque chose. Essayez hexadécimal décodage de la partie de la déclaration.

un risque D'injection SQL est créé lorsque vous essayez de créer un SQL dynamiquement sous forme de chaîne, puis de l'envoyer au 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 compléter la requête et laisser l'attaque entrer, ils auraient besoin de faire leur entrée comme ceci:

'x' or 1=1

Dans ce cas, la requête sera le suivant:

SELECT * FROM SOME_TABLE WHERE SOME_COLUMN='x' or 1=1

SOME_COLUMN peut être n'importe quelle variable, peu importe où elle échoue, ce qui compte c'est que 1=1 est toujours vrai, donnant ainsi potentiellement à l'attaquant l'accès à chaque ligne dans cette table.

Maintenant que vous savez à ce sujet, parcourez votre code et remplacez chaque requête créée dynamiquement par des instructions préparées. Le site OWASP dispose également de nombreuses ressources pour le codage défensif:

www.owasp.org

Oui il a la forme hexadécimale du nom de votre base de données qui est '74545883'. En le débitant, il aurait eu le vrai nom de la base de données.