🧠 Comment expliquez-vous ceci ?
✓ 192.168.1.69 = 192.168.1.069
✕ 192.168.1.10 ≠ 192.168.1.010
🤹 Cette adresse IP est valide mais « étrange », pourquoi ?
𝟷.𝟹.𝟹.𝟽
La réponse à la première question est parfaitement exacte. En effet, tu fais bien de préciser ce point ; ce ping par exemple fonctionnera sous Linux mais pas sous FreeBSD.
ping -b 0377.0377.0377.0377
WARNING: pinging broadcast address
PING 0377.0377.0377.0377 (255.255.255.255)
Certains malins emploient des combinaisons d'astuces de représentations pour effectuer du contournement, de l'offuscation,... Et en la matière, il y a de quoi faire.
Bien joué @x0r
@colt Ici sous FreeBSD 12, cette commande fonctionne (même si ça ne ping personne sur mon réseau) :
# ping 0377.0377.0377.0377
PING 0377.0377.0377.0377 (255.255.255.255): 56 data bytes
^C
--- 0377.0377.0377.0377 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
@colt Et il est même possible de zapper certains morceaux de l’IP qui seront complétés :
- ping 192.168.1 fonctionne
- tout comme ping 1.1 (qui répond d’ailleurs)
@colt @lord Car dans le 2e cas, wget envoie l'en-tête Host: 91.134.128.017. Or c'est mal formé : cet en-tête n'admet, pour les adresses IPv4, que la notation canonique en base 10.
La RFC 9110 définit l'en-tête Host en renvoyant vers la RFC 3986 § 3.2.2 pour sa syntaxe.
https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2
On notera que les deux URL marchent avec curl.
Et c'est une nouvelle fois une excellente réponse. Bravo @x0r 👍
Copier-coller ce texte dans un fichier, puis l'ouvrir avec un éditeur hexa donne un bel indice (merci à toi)... mais attise encore plus ma curiosité.
:)
@wawa La question n°2 est pour les malins
🤹 Cette adresse IP est valide mais « étrange », pourquoi ?
𝟷.𝟹.𝟹.𝟽
Courage 🤹
@colt Il est possible de représenter les octets d'une adresse IPv4 en base 8, 10 ou 16. 010 est interprété comme 8 à cause du 0 en préfixe. Mais 069 n'est pas un nombre octal valable ; d'ailleurs, le ping de FreeBSD rejette cette adresse comme non valable.