[FiRe_StoRM]

Bonjour à toutes et tous.

Etant sur une épreuve de hack depuis quelque jours (que je ne citerais pas mais étant de bonne foi, autant le dire de suite), j'ai comme d'hab' fait pas mal de recherches sur Google.

Finalement j'ai trouvé une explication qui à l'air plus ou moins fiable sauf que je n'avais jamais vu ce genre de concept en PHP (noob je précise, donc pas un gros expert loin de là ) et que j'ai du mal à le comprendre.

Comme le dit le titre il s'agit (si c'est bien comme ça qu'on appelle) de la notion de single byte et multi byte.

J'ai lu qu'il s'agirait d'encodage de caractères (en gros, loin de la vérité à mon avis).

Par exemple un quote est 0x27 (déjà rien que la structure me fais penser à une adresse mémoire XD).

C'est bien beau mais ça fonctionne comment ? Fin je veux dire si je tape 0x27 dans un champ ou dans l'URL pas sûr qu'il comprendra (ça serait trop beau, quoique si c'est le cas je suis le roi des cons XD).

Là j'avoue que c'est flou, voir brouillard total. 


Qu'on se comprenne bien, je ne veux pas tricher sur une épreuve (car on pourrait le croire, et je ne suis même pas sur de mon coup p'tet même que je fonce dans le ravin là XD ) mais juste comprendre ce principe de single byte - multi byte qui est totalement nouveau (et c'est tant mieux ^^, on est là pour apprendre ).

Voilou, je pourrai expliquer ce que j'ai déjà trouvé et pense avoir compris mais j'attends de voir l'avis des modérateurs (et si je vais trop loin, censurez voir même supprimez le topic et je m'excuse d'avance si c'est le cas).

Si une âme charitable est d'accord pour quelques explications, je suis preneur ! 

Merci d'avance pour les futures réponses. ^^

Cordialement (amicalement etc etc etc  ),

Kev.

EDIT: Pourquoi dans la section hacking et pas PHP ? Parce apparemment c'est un principe utiliser en hacking (m'enfin je ne vois pas d'inconvénients si vous souhaitez le déplacer dans la partie PHP).

[NiklosKoda]

Salut FiRe_StoRM,

0x27 est juste la notation hexadécimale du nombre 39. Le préfixe 0x servant à préciser qu'il s'agit d'un chiffre en hexadécimal.
Tu peux le vérifier en PHP en faisant echo 0x27; , ce qui t'affichera 39.
(Si cela te fait penser à une adresse mémoire c'est parce qu'elles emploient la même notation.)
Il ne faut pas confondre avec MySQL, qui interprète les chiffres en notation hexadécimale comme des chaines de caractères, ainsi (SELECT 0x616263 renverra abc)
Et on peut aussi remarquer que 39 est le code ASCII d'une simple quote. Toujours vérifiable en faisant echo chr(0x27); qui t'affiche '.

Maintenant parlons des caractères multibytes.
Le jeu de caractères habituels que nous employons utilise des caractères qui sont codés sur 1 octet (donc de 0 à 255).
En effet vu le peu de caractères cela suffit. Mais certains alphabets en contiennent un si grand nombre, qu'il devient impossible de les coder tous en utilisant seulement les valeurs possibles avec un seul octet : dans ce cas le charset utilise alors plusieurs octets pour coder un caractère, c'est un charset multi-octet (ou multi-byte en anglais). On peut citer en exemple les charsets chinois comme GBK ou BIG5.

Maintenant, le seul problème de sécurité en php que je connais qui fait intervenir cela, c'est celui de l'échappement des caractères par une fonction qui ne tient pas compte du charset utilisé par MySQL (addslashes, mysql_escape_string ou les magic_quotes). Voici un lien intéressant à ce sujet : http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Voilà un exemple de ce problème (qui paraphrase ce que dit l'auteur) : imaginons que MySQL utilise le charset BIG5. Addslashes ne tient pas compte du fait que big5 utilise des caractères multi-octets comme par exemple ce caractère 兝 dont le code hexadécimal est 0xa25c. Et avec addslashes, les quotes (entre autres) dont le code hexadécimal est 0x27 seront précédés d'un anti-slash 0x5c. Donc si j'envoie la chaine « ¢' », 0xa227 en hexadécimal, elle sera remplacée par la chaine 0xa25c27, et lorsque cette chaine sera utilisée dans la requête SQL, étant donné que 0xa25c est un caractère valide dans le charset BIG5, MySQL l'interprétera comme une chaine formée de deux caractères : notre caractère multi-octet et une quote ! On pourra donc utiliser des quotes dans une requête censée être sécurisée, ce qui nous mène au problème des injections SQL ...


Voilà voilà,
j'espère que c'est plus clair.
++
Niklos

[akway]

Merci NiklosKoda 

Perso je m' endormirai moins bête ce soir.

[mogg41]

Merci de partager ton savoir mais je pense que ça aide beaucoup pour une certaine épreuve et que pas mal de personnes (moi le premier) vont pas tarder à la valider.

[ThunderLord]

@ mogg41 Si tu veux parler d'une épreuve de hacking, je peux t'assurer que la faille de la fonction addslashes telle que NiklosKoda l'expose ici n'est pas à exploiter dans aucune des épreuves, même s'il y en a effectivement une pour laquelle j'ai cherché pas mal de temps de ce côté là.

[mogg41]

Effectivement je pensais que cette faille était celle qu'il fallait exploiter dans l'épreuve "Toujours réfléchir... Avant d'agir".

Mes excuses pour les suspicions.

Et du coup faut que je trouve une autre faille et ça m'arrange pas

[FiRe_StoRM]

Merci NiklosKoda pour les explications. 

Rectification pour la fameuse épreuve, j'étais sur que c'était quelque chose du genre et bah pas du tout, je faisais fausse route donc voilà au final ça n'aide pour aucune épreuve (du moins pas celle sur lesquel je me suis penché).

Mais c'est effectivement très intéressant quand même (car ça répond à une vieille question que je me posais ^^).