L(O*62).ONG: Make your URL longer
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.ong
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.ong
Encountered quite a few problems during the deployment, mainly related to HTTPS certificates.
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
Related certificates can be viewed at https://crt.sh/?q=looooooooooooooooooooooooooooooooooooooooo...
[1] According to https://www.godaddy.com/help/about-ong-domains-41384
The .ong domain has a policy that has criteria. https://thenew.org/org-people/about-pir/policies/ngo-and-ong...
These are not hard to meet, nor should they be.
But hard for a random url-elongator site to meet.
> Registrants are required to certify that they meet the following eligibility requirements when registering a .NGO or .ONG domain name:
> 1. Focused on acting in the public interest. [...] work for the good of humankind and/or the preservation of the planet
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
Clearly this site doesn't qualify.
Operating a publicly available lengthening service is in the public interest and is working for the good of all humans. I used to use hugeurl, but it's no longer in service.
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
This is an active organization, pursing a mission of longer urls for the good of all. Maybe this sounds frivolous, but there's a lot of frivolous but chartered 501(c)(3)s, and the requirements doesn't specifically require a registrant to be registered as a non-profit or charity or similar (although such a registration is likely to satisfy an audit, tax records showing a lack of profits/retained earnings may be sufficient)
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
We don't have evidence of how it's operated. Many organizations operate websites without publishing their bylaws. Although, I'll grant that circumstantial evidence seems to be that it's operated by an individual.
Running the website (in this case, an url elongator) is not required to be an objective in the articles of incorporation.
Nevertheless, an URL elongator strikes me as funny, and providing fun for free is surely for the good of humankind.
Letsencrypt does not require you to set it, just subject alternate names, which can be up to 255 characters, but some providers require it for no reason
It's only more recently that browsers and other common software stopped validating it though
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
* https://datatracker.ietf.org/doc/html/rfc2818#section-3.1 Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID). If
the client chooses to compare a reference identifier of type CN-ID
against that string, it MUST follow the comparison rules for the DNS
domain name portion of an identifier of type DNS-ID, SRV-ID, or
URI-ID, as described under Section 6.4.1, Section 6.4.2, and
Section 6.4.3.
* https://www.rfc-editor.org/rfc/rfc6125#section-6.4.4Also from 2015:
9.2.2 Subject Distinguished Name Fields
a. Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address
or Fully-Qualified Domain Name that is one of the values contained
in the Certificate’s subjectAltName extension (see Section 9.2.1).
* https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf#page=17* https://stackoverflow.com/questions/5935369/how-do-common-na...
https://community.letsencrypt.org/t/simplifying-issuance-for...
The previous workaround available was to include a second, shorter domain on the certificate but that wasn’t always easy or possible.
My first impression was: "What in the QA is this? I wonder what this breaks?"
> because they used the domain name as the commonName
Understandable, but that's old-school, right? I'm pretty sure the x.509 extensions for SAN cover this now, and I'm kind of surprised that CA's are sticking to the old way of doing this.
Here: (literally) https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
Love it as a piece of art/commentary, though.
2) what the fuck lmao
You need to put the protocol like I said.
Otherwise the service would have to presume. Which either excludes http:// or https:// probably the first.
I've ran into this when writing an url shortener and decide that without the protocol, I'd just put https:// in there. So that people could still add webcal://, ftp:// ssh:// and http:// in there if they wish.
will probably break any auto linking stuff but should work if copy&pasted or properly linked
https://sketchylinkasdf.com/ssl_webmaster.zip/qwerty/<IMG SRC="javascript:alert('XSS')"/a95a33ab-9f0d-4f64-9cf3-a80d48593de0https://root:ssh@mail.com.sketchylinkasdf.com…
I was myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com
It broke a LOT of signup forms.
I was working in software testing at the time and we talked about setting up a "likely to break things" email service and selling it to other testers, but realized that the people who'd need it would find it hard to explain to the people who write the checks.
>In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 256 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 256.
utils.js, which contains the (de)serialization code: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
tool.js, which does the serialization: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
display.js, which does the deserialization and redirect: https://github.com/ccbikai/loooooooooooooooooooooooooooooooo...
https://xdpirate.github.io/ghost-translator/ghost-translator...
Also, it seems to only look for `http:` + one character, which is a bit disorienting. (E.g. `https:/a` would be a "valid" domain)
See dang's explanation to the same question here (and his link to an algolia search of other previous explanations): https://news.ycombinator.com/item?id=36472976
The way how it worked is that the spammer used my urllengthener as a redirection service to a website that looks like an incomplete project, which is actually a disguise. There's javascript code on their site that if there's a URL fragment identifier (the hash thingie postfix for URL) detection mechanism and if the URL fragment identifier matches an ad of their own, it'd redirect to the actual spam ad.
Let's say the spammer owns example.org. The spammer would generate link with my service such that https://urllengthener.sadale.net/foobarbaz would redirect to https://example.org. Then it'd send spam with a link of https://urllengthener.sadale.net/foobarbaz#identifierXYZ to the victim. Then the victim would click on the link, which redirects him to https://example.org/#identifierXYZ, which would show victim the ad. https://example.org/ looks legit on its own and there is no log shown on the HTTP server because the URL fragment identifier is a client-side thing. I'm kind of thankful of that spam abuse report. Otherwise I might have never found out.
(Remarks: example.org isn't the actual spam site. I just use this domain name as an example.)
I don't have the time for now but I think I should make a write up about that some time later.
And I've tested your service and apparently your site is vulnerable for the exact same kind of abuse as mine. I'd strongly recommend you to at least disabling redirection of URL fragment identifier. Example of URL that's prone to abuse: https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
I haven't tested that but I think it's possible to modify the fragment with Javascript: https://stackoverflow.com/a/4282075
So my idea would be getting looo.ong to create a special client-side redirection webpage that would remove the fragment part using Javascript before performing the redirection with Javascript. And no. Using HTTP redirection response on server side won't work.
EDIT: I've actually seen URL redirection websites that removes the fragment part so it should be doable. Perhaps the purpose of that is to avoid spam abuse.
Yes, this is how single-page apps allowed linking to subpages before history.pushState existed.
What kind of penalty do you think you could've gotten and by whom?
You can imagine what your hosting provider or ISP will do with this.
Source: I ran a URL shortening service from 2004-2007 and this happened to me.
No one would shut down the post (DHL) for allowing a drug enterprise to send illegal substances using DHL.
So yeah, these links will be abused. What isn't abused?
From my understanding the domain could be 255 characters long.
[0] https://stackoverflow.com/questions/417142/what-is-the-maxim...
I absolutely love it.
https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
https://httpscolonforwardslashforwardslashwwwdotzoltanbalazs...
Slightly disappointed that doesn't have a 10hr version of https://www.youtube.com/watch?v=dys8KUnwGGg
https://looooooooooooooooooooooooooooooooooooooooooooooooooo...
Somehow I have even more questions now. Is this a registered ONG then!?
[1]: https://thenew.org/org-people/about-pir/policies/ngo-and-ong...
https://web.archive.org/web/20140208032349/http://hugeurl.co...
Secondly, this is maybe the last service I'd recommend people use. First time I opened it all of the images failed to load and no CSS. Then, I refreshed it with the console open and there were 40+ errors and 500+ warnings in the console, but everything loaded... including 2 pop-up ads stacked on top of each other and a ton of banner ads. Feels like I should wash my laptop with soap and water after opening that URL.
URL filters may have a hard time though.