L(O*62).ONG, qui rallonge les URL

 (loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.ong)
4 points par GN⁺ 2024-06-03 | 1 commentaires | Partager sur WhatsApp

Un outil qui rallonge les URL

  • Fonction : un outil qui permet de rendre une URL très longue.
  • Créateurs : co-créé par ccbikai et ChatGPT.
  • Inspiration : inspiré par llIlI.lI.

L’avis de GN⁺

  • Utilité : cet outil peut être utile dans certaines situations où il faut allonger une URL. Par exemple, il peut servir à tester des systèmes dont le comportement varie selon la longueur de l’URL.
  • Aspect intéressant : il peut éveiller la curiosité sur les raisons pour lesquelles on aurait besoin de rallonger une URL.
  • Considérations techniques : des URL trop longues peuvent poser des problèmes de traitement côté navigateur ou serveur. Il faut donc faire attention en usage réel.
  • Alternative : c’est le concept inverse des services de raccourcissement d’URL, et il existe divers outils permettant d’ajuster la longueur des URL.

À lire aussi

1 commentaires

 
GN⁺ 2024-06-03
Avis sur Hacker News

  • Je suis l’auteur. Je comptais le publier moi-même, mais je ne savais pas que quelqu’un l’avait déjà posté
    J’ai rencontré pas mal de problèmes pendant le déploiement, principalement liés aux certificats HTTPS. Le segment le plus long d’un nom de domaine fait 63 caractères, et la longueur maximale du commonName d’un certificat HTTPS est de 64 caractères ; Cloudflare, Vercel et Netlify utilisaient donc le nom de domaine comme commonName et n’arrivaient pas à le faire signer par Let’s Encrypt, mais Zeabur y est parvenu
    Au final, j’ai remplacé le certificat Cloudflare par Google Trust Services LLC et la signature a réussi. Le certificat correspondant est visible ici : https://crt.sh/?q=looooooooooooooooooooooooooooooooooooooooo...

    • Let’s Encrypt prend en charge depuis 2023 les certificats sans CN, donc les domaines longs sont entièrement pris en charge : https://community.letsencrypt.org/t/simplifying-issuance-for...
      L’ancien contournement consistait à inclure dans le certificat un second domaine plus court, mais ce n’était pas toujours simple ni possible
    • Au passage, commonName n’est absolument pas obligatoire dans un certificat et relève en fait plutôt du deprecated/legacy
      Let’s Encrypt n’exige pas de définir un commonName ; il suffit d’avoir un nom alternatif du sujet (SAN), et un SAN peut aller jusqu’à 255 caractères. Pourtant, certains fournisseurs exigent un commonName sans vraie raison
    • Les domaines en .ong ne sont-ils pas réservés aux organisations non gouvernementales situées hors de Chine ?
      D’après [1] https://www.godaddy.com/help/about-ong-domains-41384
    • J’aime bien ça
      Ma première impression a été : « C’est quoi ce QA ? Qu’est-ce qui va casser ? » Je comprends qu’on ait utilisé le nom de domaine comme commonName, mais ça me semble être une méthode dépassée. Aujourd’hui, l’extension x.509 SAN devrait couvrir ça ; c’est assez surprenant que les autorités de certification s’accrochent encore aux anciennes pratiques
    • Excellent. Tu vas aussi proposer un service d’e-mail ? ^^

  • C’est tellement bien fait que ça en devient agaçant
    C’est ici : https://looooooooooooooooooooooooooooooooooooooooooooooooooo...

    • Pourquoi un site destiné à Hacker News affiche-t-il un avertissement de contenu ?
      1. Les combinaisons de majuscules et minuscules créent des motifs visuels assez intéressants quand on plisse les yeux
      2. C’est quoi ce truc, mdr

  • Il faudrait une étiquette indiquant qu’il faut d’abord mettre le protocole. En arrivant sur le site, j’ai tapé google.com et rien ne s’est passé ; pendant un moment, j’ai cru que c’était cassé ou que le site subissait une avalanche de trafic HN

    • J’ai fait exactement pareil. D’ailleurs, pourquoi est-ce nécessaire ?
    • Je ne comprends pas. Qu’est-ce qui est nécessaire ? J’ai aussi essayé avec Google.com, mais je ne vois pas ce qu’il faut faire
    • D’accord. J’allais demander pourquoi ça ne marchait pas sur mobile, et c’était donc ça la raison

  • J’avais déjà fait quelque chose de similaire pour rendre les liens « louches »
    La génération automatique de liens peut probablement casser, mais si on copie-colle ou si on crée le lien correctement, ça devrait fonctionner
    https://sketchylinkasdf.com/ssl_webmaster.zip/qwerty/

    • Pourquoi ne pas ajouter un sous-domaine ? Faire en sorte que le domaine complet ressemble à mail.com.sketchylinkasdf.com, par exemple
    • Je fais du pentest en purple team, et je ne sais pas si cette URL me donne plutôt du PTSD ou me fait plutôt rire
    • Super site. Je suis allé sur la page /feedback, mais il ne semble pas y avoir de vrai moyen de soumettre un feedback. Est-ce que j’ai raté quelque chose ?
    • Il existe quelques autres générateurs d’« URL louches », on peut les trouver en cherchant

  • Une société appelée Halibut Stuff vendait autrefois des t-shirts avec un forwarding d’e-mail gratuit inclus
    Mon adresse était myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com, et elle cassait quantité de formulaires d’inscription. Comme je travaillais à l’époque dans le test logiciel, on avait envisagé de créer un service d’e-mail « très susceptible de casser » et de le vendre à d’autres testeurs, mais on a laissé tomber en se disant que les personnes qui en auraient besoin auraient du mal à l’expliquer aux décideurs budgétaires

    • C’est un critère arbitraire, mais en général, pour un champ e-mail en base de données, on prévoit au minimum un n?varchar de 100 caractères

  • J’adore la méthode qui encode l’URL en binaire, puis remplace les 0 et les 1 par O et o. C’est génial

    • Comment tu l’as su ? Où peut-on le lire ? Est-ce que j’ai raté quelque chose ?

  • En pratique, le https:// nécessaire devrait être prérempli dans le formulaire

    • En plus, ça a l’air de ne vérifier que http: + un seul caractère, ce qui est un peu déroutant. Par exemple, https:/a devient aussi un domaine « valide »

  • Est-ce que je suis en train de faire un AVC ? Je suis sûr à 100 % d’avoir vu hier exactement ce sujet et exactement ces commentaires, et maintenant tout est indiqué comme datant d’il y a 5 heures

    • Ça arrive quand un post est ressuscité depuis le second-chance pool. Si j’ai bien compris, la seule façon actuelle de réactiver le fil est de modifier son horodatage, ce qui est assez déroutant pour les gens qui ont réellement vu l’ancien fil
      Voici un lien de recherche Algolia avec l’explication de dang à la même question et d’anciennes explications : https://news.ycombinator.com/item?id=36472976
    • Ils ont vraiment ingénieré un effet Mandela

  • Il faut être prudent quand on crée ce genre de site. Il y a longtemps, j’en avais fait un similaire (urllengthener.sadale.net) et le site a été signalé comme une « campagne de spam ». Il s’est avéré qu’un spammeur abusait de mon site pour générer des liens de spam, et comme j’ai immédiatement fermé le site, je n’ai pas subi de vraie sanction
    Voici comment ça marchait. Le spammeur utilisait mon URL lengthener comme service de redirection vers un site qui, en apparence, ressemblait à un projet inachevé, mais c’était en fait une façade. Ce site contenait du JavaScript qui détectait l’identifiant de fragment d’URL, c’est-à-dire la partie hash à la fin de l’URL, et si le fragment correspondait à sa publicité, il redirigeait vers la vraie pub de spam
    Par exemple, supposons que le spammeur possède example.org. Il faisait en sorte que, via mon service, https://urllengthener.sadale.net/foobarbaz redirige vers https://example.org, puis envoyait aux victimes par spam le lien https://urllengthener.sadale.net/foobarbaz#identifierXYZ. Quand la victime cliquait, elle arrivait sur https://example.org/#identifierXYZ et voyait la publicité. https://example.org/ lui-même avait l’air normal, et comme le fragment d’URL est un élément côté client, il n’apparaît même pas dans les logs du serveur HTTP. Sans le signalement de cet abus de spam, je ne l’aurais sans doute jamais découvert, donc je leur en suis presque reconnaissant
    Pour référence, example.org n’est pas le vrai site de spam, c’est un domaine d’exemple. Un jour, quand j’aurai le temps, il faudra que j’écrive un billet là-dessus. Et après avoir testé ce service, il semble pouvoir être exploité exactement de la même manière que mon site. Je recommande vivement de désactiver au minimum la redirection des identifiants de fragment d’URL. Voici un exemple d’abus possible : https://looooooooooooooooooooooooooooooooooooooooooooooooooo...

    • Tu dis que tu as « fermé le site et n’as pas subi de vraie sanction » ; quel genre de sanction pensais-tu risquer, et de la part de qui ?
    • En quoi est-ce différent des paramètres GET d’une URL ? Je me demande si ça ne concerne que les fragments d’URL. JavaScript peut aussi parser les paramètres d’URL, et un site de spam pourrait aussi en abuser en réécrivant la partie chemin
    • Oui. C’est déprimant, mais il ne reste sans doute qu’à attendre 3… 2… 1… avant qu’un acteur malveillant n’exploite ce service à de mauvaises fins

  • Ne pourrait-on pas utiliser des sous-domaines pour le rendre encore plus loooong ?
    Si j’ai bien compris, un domaine peut aller jusqu’à 255 caractères
    https://a.lot.looooooooo(...)nger.than.looooooooo(...).ng

    • Il existe une limite de fait à la longueur totale d’une URL [0], et cette limite dépasse largement 255 caractères. La partie chemin de l’URL peut être arbitrairement longue dans cette limite, donc n’utiliser que des sous-domaines serait inutilement restrictif, et les combiner n’apporterait pas grand-chose
      [0] https://stackoverflow.com/questions/417142/what-is-the-maxim...