En parlant de codage d’URL, vous pensez peut-être à la vulnérabilité de codage d’URL il y a N ans. C'est dommage que je sois né au mauvais moment. Lorsque je suis entré en contact avec Internet, la faille avait disparu depuis longtemps.
Plus près de chez nous, qu’est-ce que l’encodage d’URL ? Jetez un œil à la définition que j'ai copiée sur Internet :
Citation : Le codage d'URL est un format utilisé par les navigateurs pour regrouper la saisie d'un formulaire. Le navigateur récupère tous les noms et valeurs du formulaire et les envoie au serveur dans le cadre de l'URL ou séparément, en utilisant l'encodage des paramètres nom/valeur (suppression des caractères non transmissibles, tri des données, etc.). Dans les deux cas, le format de saisie du formulaire côté serveur ressemble à ceci :
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
Le codage d'URL suit les règles suivantes : Chaque paire nom/valeur est séparée par une esperluette ; vient de la forme séparée par les caractères =. Si l'utilisateur ne saisit pas de valeur pour le nom, le nom apparaîtra quand même, mais sans valeur. Tous les caractères spéciaux (c'est-à-dire ceux qui ne sont pas de simples ASCII à sept bits, comme les caractères chinois) seront codés en hexadécimal avec le signe pour cent %, y compris bien sûr les caractères spéciaux comme =, & et %.
Haha, vous l'avez compris, en fait, l'encodage URL est le code ASCII hexadécimal d'un caractère. Il y a cependant un léger changement. Vous devez ajouter « % » devant. Par exemple, "", son code ASCII est 92 et la valeur hexadécimale de 92 est 5c, donc le codage URL de "" est . Alors qu’en est-il du codage URL des caractères chinois ? C'est très simple, regardez l'exemple : le code ascii de "Hu" est -17670, l'hexadécimal est BAFA, et l'encodage url est "%BA%FA". Haha, tu sais comment le convertir.
Nous n'utilisons généralement pas le codage d'URL, car IE convertira automatiquement les lettres non numériques que vous saisissez dans la barre d'adresse en codage d'URL. Donc pour le navigateur http://blog.csdn.net/l%61ke2 équivaut à http://blog.csdn.net/lake2 (notez que j'ai remplacé a par %61 dans la première URL). Haha, vous vous souvenez peut-être que quelqu'un a suggéré d'ajouter "#" dans le nom de la base de données pour empêcher son téléchargement, car IE ignorera les lettres suivantes lorsqu'il rencontrera #. La méthode de craquage est très simple : remplacez # par l'encodage d'URL #. J'ai initialement essayé d'utiliser le codage d'URL pour éviter les contrôles d'injection, mais cela a échoué car le serveur convertissait le codage d'URL en caractères.
Attendez, il me semble que je suis hors sujet, haha, désolé :)
L'injection SQL est très populaire maintenant, donc certaines personnes ont écrit des scripts anti-injection. Bien sûr, les idées sont différentes et les résultats sont très différents. Chers lecteurs, veuillez jeter un œil à une partie du code de la version asp anti-injection universelle ××SQL ci-dessous.
Fy_Url=Request.ServerVariables("QUERY_STRING")
Fy_a=split(Fy_Url,"&")
redim Fy_Cs(ubound(Fy_a))
En cas d'erreur, reprendre ensuite
pour Fy_x=0 vers ubound(Fy_a)
Fy_Cs(Fy_x) = gauche(Fy_a(Fy_x),instr(Fy_a(Fy_x),"=")-1)
Suivant
Pour Fy_x=0 vers ubound(Fy_Cs)
Si Fy_Cs(Fy_x)<>"" Alors
Si Instr(LCase(Request(Fy_Cs(Fy_x))),"and")<>0 alors
Réponse.Écrivez « Une erreur s'est produite ! »
Réponse.Fin
Fin si
Fin si
Suivant
L'idée est d'abord d'obtenir les données soumises, d'utiliser "&" comme démarcation pour obtenir et traiter le groupe nom/valeur, puis de déterminer si la valeur contient les mots-clés définis (pour plus de simplicité ici, je laisse seulement "et"). Si c'est le cas, c'est une injection.
À première vue, la valeur est vérifiée et il ne semble y avoir aucun problème. Haha, oui, il n'y a pas de problème de valeur, mais qu'en est-il du nom ?
Sa valeur de groupe nom/valeur provient de Request.ServerVariables("QUERY_STRING"), haha, désolé, quelque chose s'est mal passé ici. Request.ServerVariables("QUERY_STRING") doit obtenir la chaîne soumise par le client. Le codage de l'URL ne sera pas automatiquement converti ici Haha, si nous encodons le nom en URL et le soumettons ensuite, haha, alors la vérification peut être contournée. Par exemple, si le paramètre est ph4nt0m=lake2 et lis0, le programme peut le détecter à ce moment ; si vous soumettez %50h4nt0m=lake2 et lis0 (codage URL p), le programme jugera la valeur de %50h4nt0m et %50h4nt0m. sera converti en ph4nt0m , donc la valeur de %50h4nt0m est vide, contournant ainsi la détection.
Attendez, pourquoi la vérification peut-elle être contournée si le nom n'est pas décodé mais que la valeur ne peut pas être contournée ? Étant donné que la valeur de value est extraite de Request(Fy_Cs(Fy_x)), le serveur la décodera.
Comment le programme peut-il être amélioré ? Tant que vous pouvez obtenir les données décodées soumises par le client, modifiez simplement l'instruction pour obtenir le nom For Each SubmitName In Request.QueryString.
Haha, merci d'avoir patienté en lisant mon article ^_^
lake2